1 00:00:00,120 --> 00:00:07,620 Information may be segmented or broken up into smaller chunks for transmission across a physical medium. 2 00:00:07,920 --> 00:00:14,580 The maximum transmission unit or M2 of an outgoing interface depends on the physical medium. 3 00:00:14,850 --> 00:00:20,040 As an example, the M2 of Fast Ethernet is thousand 500 bytes. 4 00:00:20,670 --> 00:00:29,240 However, TCP can theoretically support 65,495 bytes in a single packet. 5 00:00:29,250 --> 00:00:35,400 When that is sent to the lower layers of the AC model, that will need to be broken up into fragments 6 00:00:35,400 --> 00:00:41,670 for transmission across the physical medium, which, for example, only supports 5500 bytes. 7 00:00:42,120 --> 00:00:49,830 Data is therefore broken up into smaller chunks and the receiver using TCP will need to put those fragments 8 00:00:49,830 --> 00:00:51,060 back together again. 9 00:00:51,390 --> 00:00:58,890 The maximum segment size or mass is the largest amount of data in bytes that TCP is willing to send 10 00:00:58,890 --> 00:01:00,210 in a single segment. 11 00:01:00,480 --> 00:01:07,020 For best performance, the MSRPS should be set small enough to avoid IP fragmentation, which can lead 12 00:01:07,020 --> 00:01:09,720 to excessive transmissions if there's packet loss. 13 00:01:10,970 --> 00:01:19,160 TCP supports something called maximum segment size and path M2 discovery or path maximum transmission 14 00:01:19,160 --> 00:01:25,700 unit discovery with the sender and the receiver can automatically determine what the maximum transmission 15 00:01:25,700 --> 00:01:34,010 unit is on a path between them, and TCP will only put enough data into a single packet that fits that 16 00:01:34,010 --> 00:01:42,350 MMBtu, thus avoiding fragmentation of packets and thus avoiding the overhead associated with fragmentation 17 00:01:42,620 --> 00:01:45,290 and the putting together of the IP fragments. 18 00:01:45,740 --> 00:01:54,140 Path MTU discovery is optional in IP version four, but has now become mandatory in IP version six because 19 00:01:54,140 --> 00:02:01,280 of the efficiencies that it brings to the TCP transmission and the fact that IP version six does not 20 00:02:01,280 --> 00:02:06,530 support fragmentation on routers along the path between two hosts. 21 00:02:08,190 --> 00:02:13,980 UDP does not support this and requires higher layer protocols to sort out the fragments. 22 00:02:15,810 --> 00:02:16,830 Flow control. 23 00:02:17,040 --> 00:02:24,600 TCP uses end to end flow control to avoid having the sender send data too quickly for the receiver to 24 00:02:24,600 --> 00:02:26,970 receive it and process it reliably. 25 00:02:27,390 --> 00:02:33,630 If the sender transmits data faster than the receiver can handle, the receiver will drop the data which 26 00:02:33,630 --> 00:02:35,370 will require retransmission. 27 00:02:35,520 --> 00:02:42,480 Retransmission will waste time and network resources, which is why most flow control mechanisms try 28 00:02:42,480 --> 00:02:48,510 to maximize the transfer rate while minimizing the requirements to retransmit. 29 00:02:49,250 --> 00:02:57,290 You may, as an example, have a PC with a powerful CPU sending data to a handheld PDA, which can only 30 00:02:57,290 --> 00:02:59,720 process data at a much lower rate. 31 00:03:00,320 --> 00:03:04,850 The PDA should therefore regulate the data flow so it's not overwhelmed. 32 00:03:05,240 --> 00:03:13,130 In TCP basic flow, control is implemented by acknowledgement from the receiver in receipt of data transmitted. 33 00:03:14,070 --> 00:03:18,900 TCP uses something called a sliding window to control the flow of data. 34 00:03:19,290 --> 00:03:25,740 Windowing will allow a receiving computer to advertise how much data it's able to receive before transmitting 35 00:03:25,740 --> 00:03:27,930 an acknowledgement to the sending computer. 36 00:03:28,590 --> 00:03:36,060 In each TCP segment, the receiver will specify in the receiver window field the amount of additional 37 00:03:36,060 --> 00:03:40,740 received data in bytes that it is willing to buffer for the connection. 38 00:03:40,890 --> 00:03:47,310 The sending host can only send up to that amount of data before it must wait for an acknowledgement 39 00:03:47,670 --> 00:03:50,850 and window size update from the receiving host. 40 00:03:51,850 --> 00:03:54,490 UDP does not implement flow control. 41 00:03:55,360 --> 00:03:59,670 And in a VoIP environment is an example which uses UDP. 42 00:03:59,680 --> 00:04:05,590 Even though there's no physical connection between two handsets involved in a telephone call, the call 43 00:04:05,590 --> 00:04:12,250 will stay up and the sender will merrily continue sending huge amounts of data, even though the receiver 44 00:04:12,250 --> 00:04:14,680 cannot process the received data. 45 00:04:15,010 --> 00:04:19,690 UDP relies on higher layer protocols to implement flow control. 46 00:04:20,260 --> 00:04:25,510 Once again, TCP is connection orientated and UDP is connection less. 47 00:04:25,900 --> 00:04:32,710 TCP will establish the session connection and maintain the connection during the entire transmission. 48 00:04:32,830 --> 00:04:36,400 Once a transmission is complete, the session is terminated. 49 00:04:37,090 --> 00:04:43,540 UDP does not set up sessions and will just send the data in the hope that the receiver will receive 50 00:04:43,540 --> 00:04:43,900 it. 51 00:04:44,960 --> 00:04:51,500 Once again, TCP implements reliability, where every segment transmitted is acknowledged. 52 00:04:51,860 --> 00:04:55,250 And if the segment went missing, it is retransmitted. 53 00:04:56,360 --> 00:05:03,920 UDP does not implement reliability and once again relies on high layer protocols to implement any reliability 54 00:05:03,920 --> 00:05:12,860 if required in certain cases, such as voice over IP or video transmitted over an IP infrastructure. 55 00:05:12,950 --> 00:05:15,260 Reliability is not required. 56 00:05:15,350 --> 00:05:18,650 There is no point re transmitting lost voice packets. 57 00:05:19,830 --> 00:05:29,580 So a quick comparison between UDP and TCP or a reliable protocol and a best effort or unreliable protocol. 58 00:05:30,890 --> 00:05:33,650 TCP once again is connection orientated. 59 00:05:33,860 --> 00:05:37,700 No data is transmitted before a session is established. 60 00:05:38,270 --> 00:05:42,660 A three way handshake takes place before any data is transmitted. 61 00:05:42,680 --> 00:05:48,830 They are acknowledgments of data received and sequence numbers to track transmission of data. 62 00:05:49,340 --> 00:05:56,120 UDP, on the other hand, is connection less and does not track data and does not ensure delivery of 63 00:05:56,120 --> 00:05:56,690 data. 64 00:05:57,750 --> 00:05:59,730 TCP uses sequenced numbers. 65 00:06:00,000 --> 00:06:01,410 UDP does not. 66 00:06:02,370 --> 00:06:08,550 Applications that use TCP include HTTP, email and FTP. 67 00:06:09,240 --> 00:06:15,840 Applications that use UDP include voice streaming applications like voice over IP and video streaming 68 00:06:15,840 --> 00:06:16,830 applications. 69 00:06:17,160 --> 00:06:24,320 Because of the nature of VOIP or video, there is no reason to retransmit in a VoIP environment. 70 00:06:24,330 --> 00:06:32,610 The talker will be required to repeat what they said if the listener was unable to decipher what was 71 00:06:32,610 --> 00:06:33,600 communicated. 72 00:06:34,230 --> 00:06:41,550 If you've ever used Skype at times, it may sound like the person speaking is under water, or they 73 00:06:41,550 --> 00:06:45,240 sound more like a machine than the person you know speaking. 74 00:06:46,050 --> 00:06:49,230 But you may still be able to understand what they've said. 75 00:06:49,620 --> 00:06:53,970 And thus, even though data went missing, the conversation can continue. 76 00:06:54,000 --> 00:06:59,010 Or if it gets bad enough, you would ask the speaker to repeat what they said. 77 00:06:59,310 --> 00:07:01,290 In a video streaming environment. 78 00:07:01,320 --> 00:07:07,950 You may notice that part of the image is not refresh properly, but you're still able to follow what's 79 00:07:07,950 --> 00:07:13,380 happening in the video because of the time sensitive nature of voice and video. 80 00:07:13,860 --> 00:07:19,120 It is pointless re transmitting data and thus TCP is not used in these environments. 81 00:07:19,140 --> 00:07:20,610 UDP is used. 82 00:07:21,770 --> 00:07:24,600 So UDP is a transport layer protocol. 83 00:07:24,620 --> 00:07:27,290 It resides at layer four when the OCI model. 84 00:07:28,360 --> 00:07:35,710 It provides applications with access to the network layer or layer three without the overhead of reliability 85 00:07:35,710 --> 00:07:36,670 mechanisms. 86 00:07:37,060 --> 00:07:41,860 As discussed, this is ideal for voice of IP or video applications. 87 00:07:42,340 --> 00:07:49,540 Its connection less where one way datagram is sent to a destination without advanced notification to 88 00:07:49,540 --> 00:07:51,130 the destination device. 89 00:07:51,250 --> 00:07:55,180 There is no communication before transmission of data. 90 00:07:55,630 --> 00:08:01,480 The data just arrives at the receiver and it's expected that the receiver handle that data. 91 00:08:01,810 --> 00:08:09,130 UDP is capable of providing very limited error checking the UDP datagram does include an optional checksum 92 00:08:09,130 --> 00:08:13,660 value which the receiving device can use to test the integrity of the data. 93 00:08:14,660 --> 00:08:22,370 The UDP header also includes a destination port number and if that datagram is directed to an inactive 94 00:08:22,370 --> 00:08:29,420 port on the receiving device, a return message can be transmitted to indicate that that port is unreachable. 95 00:08:29,780 --> 00:08:32,630 I'm going to discuss port numbers in more detail in a moment. 96 00:08:32,929 --> 00:08:35,510 It's a very important concept to understand. 97 00:08:35,960 --> 00:08:38,970 UDP provides best effort delivery. 98 00:08:38,990 --> 00:08:41,870 There is no guarantee that data is delivered. 99 00:08:42,440 --> 00:08:48,410 Packets may be misdirected, duplicated or lost on their way to the destination. 100 00:08:48,710 --> 00:08:50,870 There is no guarantee of receipt. 101 00:08:50,990 --> 00:08:57,020 Higher layer protocols will need to implement reliability if required. 102 00:08:57,900 --> 00:09:00,930 There are also no data recovery features in UDP. 103 00:09:01,380 --> 00:09:07,320 Once again, higher layer protocols will need to recover from lost or corrupted packets. 104 00:09:07,830 --> 00:09:14,460 TFTP, as an example, has a built in mechanism to handle data loss and TFTP. 105 00:09:14,490 --> 00:09:23,370 Using UDP has its own built in sequencing and retransmission mechanisms as it cannot rely on UDP to 106 00:09:23,370 --> 00:09:24,840 implement reliability. 107 00:09:25,380 --> 00:09:27,180 The UDP header is very simple. 108 00:09:27,630 --> 00:09:32,880 It has a 16 bit source port number, a 16 bit port destination number. 109 00:09:33,790 --> 00:09:40,150 So these specify the port number used by the source and a port number used by the destination. 110 00:09:40,810 --> 00:09:47,300 It has a 16 bit UDP length field that specifies the length in bytes of the entire data gram. 111 00:09:47,320 --> 00:09:53,710 In other words, the header and the data, the minimum length for UDP data gram is eight bytes because 112 00:09:53,710 --> 00:09:55,180 that's the length of the header. 113 00:09:55,930 --> 00:10:05,290 Theoretically, the maximum size is 65,535 bytes, but IP version four will impose a maximum limit of 114 00:10:05,290 --> 00:10:08,260 65,507 bytes. 115 00:10:08,920 --> 00:10:13,120 Optionally, a UDP checksum can be used for error checking. 116 00:10:13,810 --> 00:10:19,210 This is optional in IP version four but is not optional and IP version six.