1. UDP : User Datagram Protocol 2005. 4. 25 백 일 우 steigensonne@hufs.ac.kr

2. 2 Concept Introduction UDP Header Format Pseudo-header IP Fragmentation MTU discovery using UDP Interaction Between UDP and ARP Maximum UDP Size ICMP Source Quench Error

3. 3 Introduction Connectionless Oriented Service Out of Order Just Information Application process location Info of Two hosts No service for Reliability When UDP? For Not reliability, but SPEED : Realtime Multimedia Transmission  Not Needed to wait for ACK Can communicate to MANY : Multicast, Broadcast For periodic Transmission  Routing Protocol should communicate adjacent routers to spread info periodically (every 30 secs)  Very inefficient for TCP to do as above Simple And Light  So make CPU & memory light  Good to do service for the unspecific  DNS, WINS service could be good examples to this

4. 4 UDP Header Format IP HeaderUDP HeaderUDP Data UDP datagram IP datagram 20 Bytes 8 Bytes 16-bit source port number16-bit destination port number 16-bit UDP length16-bit UDP checksum data( if any ) 0 151631

5. 5 UDP Header Format – Cont’ UDP length = UDP Header + UDP data UDP checksum Range : UDP header + UDP data  IP checksum : IP header Unit : 16 bit words  The shortage is filled with Padding 0 When Checksum, Must Include pseudo-header  Purpose : UDP double-check If Calculated Checksum 0, Set 1 in Checksum field  If Checksum field is 0 at Receiver, means that Sender did not calculate checksum Checksum Error detected at receiver, Discarded immediately  Not generated error message

6. 6 Pseudo-header 16-bit source port number16-bit destination port number 16-bit UDP length16-bit UDP checksum data( if any ) 0 151631 32-bit source IP address 32-bit destination IP address zero8-bit protocol(17)16-bit UDP length Pad byte(0) UDP pseudo header UDP header

7. 7 IP Fragmentation When fragment, Flags bits field uses one bit as the “more fragments” bit Fragment offset field contains the offset of this fragment from the beginning of the original datagram Total length field of each fragment is changed to be the size of that fragment size Surely, “don’t fragment” bit set  If this filed tuned off and transmitted exceeded size than MTU, ICMP error would be generated.

8. 8 Example - Fragmentation Test Send data size : 1471, 1472, 1473, 1474 offset size ID UDP header+ UDP data

9. 9 Example - Fragmentation Test From 220.67.124.138 to www.naver.com

10. 10 MTU discovery using UDP

11. 11 MTU discovery using UDP - Cont’ FAIL FAIL-again Retry-frag’ OK FAIL ? > IP turns on the DF bit to see if the path MTU has increased, every 30secs

12. 12 RFC 1191 Says,.. 30 secs is too small, RFC 1191 recommends a value of 10mins Can be changed by modifying the parameter ip_ire_pathmtu_interval

13. 13 Interaction Between UDP and ARP If we send UDP packet (size : 8192),.. Would generate six fragments on an ethernet  1480*5(7400) < 8192 < 1480 * 6(=8880) Make ARP cache be empty before run IP datagram IP HeaderUDP HeaderUDP Data(1473 bytes) 20 Bytes 8 Bytes IP HeaderUDP Header 1472 bytes 20 bytes 8 bytes IP Header 20 bytes 1 bytes packet

14. 14 Interaction Between UDP and ARP 6 ARP request (before the first reply returned) -> 6 fragment’s request When first ARP reply received (line 7) only the last fragment sent (line 9) It appears that first five fragments have been discarded Most implementation keep only the last packet sent to a given destination while for an ARP reply Figure 11.17 Packet exchange when an 8192-byte UDP datagram is sent on an Ethernet verify ARP cache is empty

15. 15 Interaction Between UDP and ARP (con’t) ICMP “time exceeded during reassembly” error IP layer must start a timer when the first fragment appears (first fragment ≠ fragment offset of 0) Normal timeout value is 30 or 60 seconds If all the fragments for this datagram have not arrived when the timer expires, all these fragments are discarded Why don’t see the ICMP message here? Most Berkeley-derived implementations never generate this error The first fragment-the one with an offset of 0 containing the UDP header-was never received  Couldn’t tell which user process sent the datagram that was discarded

16. 16 Interaction Between UDP and ARP The Host Requirements RFC says,.. Require an implementation to prevent this type of ARP flooding  That is, Repeatedly sending an ARP request for the same IP address at high rate Recommended rate is one per second  Here we see six ARP previous in 4.3ms(approximately 0.7ms)  Too fast than recommended

17. 17 Interaction Between UDP and ARP

18. 18 Maximum UDP Datagram Size Theoretically, 65535 bytes, imposed by the 16-bit total length field in the IP header, but Most provide less than that First, Application may be limited by its programing interface  The socket API provide a function that application can call to set the size of the send and receive buffer  Most system provide a default of just over 8192 bytes (Default NFS read and write) Second, the kernel’s implementation of TCP/IP  Whether it is feature or bug,..  Limit the size of an IP datagram to less than 65535 bytes A host is required to receive at least a 576-byte IP datagram Many UDP applications are designed to restrict their application data to 512 bytes or less, to stay below this

19. 19 ICMP Source Quench Error Receives datagrams at a rate that is too fast to be processed is not always not required to send a source quench, even if it runs out of buffers and throws datagrams away Figure 11.18 ICMP source quench error

20. 20 ICMP Source Quench Error (con’t) BSD implementations normally ignore received source quenches if the protocol is UDP What Problem? process already terminated when the source quench is received UDP is an unreliable protocol Possible discarded by the router Need for acknowledgment into the application  Unless you do not as above, the sender has no idea whether the receiver really got the data

21. 21 ICMP Source Quench Error (con’t) RFC 1009[Braden and postel 1987] requires router to generate source quenches when it runs out of buffers But new Router Requirements RFC[Almquist 1993] changes this and says that a router must not originate source quench error since it consumes network BW and is an inefficient and unfair fix for congestion