Lecture 5.

Internet Transport Layer:

User Datagram Protocol (UDP)

G. Bianchi, G. Neglia

Transport Layer Protocols

Entire network seen as a pipe

Internet ...

G. Bianchi, G. Neglia

1 UDP Packets

proc proc ÏConnection-Less UDP UDP IP IP IP Ù (no handshaking) IP IP ÏU D P packets (D atagram s) Ù Each application interacts w ith U D P transport sw to produce E X A CT LY O N E U D P datagram ! Application

U D P h e ad e r Application d ata encapsulated in exactly 1 IP packet IP h e ad e r U D P h e ad e r Application d ata This is why, improperly, weusethe term UDP packets G. Bianchi, G. Neglia

UDP datagram form at 8 bytesheader + variable payload 0 7 1 5 2 3 3 1 source port destination port ÏU D P length field length (bytes) Checksum Ù all UDP datagram Ù (header + payload) Ïpayload sizes allow ed: Data Ù Empty Ù Odd size (bytes) ÏUDP functionslim ited to: Ùad d re s s ing ‰which is the only strictly necessary role of a transport protocol ÙE rror ch e ck ing ‰which may even be disabled for performance G. Bianchi, G. Neglia

2 M axim um UDP datagram size Ï16 bit UDP length field: Ù M axim um up to 216-1 = 65535 bytes Ù Includes 8 bytes U D P header (m ax data = 65527) ÏB ut m ax IP packet size is also 65535 Ù M inus 20 bytes IP header, m inus 8 bytes U D P header Ù M ax U D P_data = 65507 bytes!

ÏM oreover, m ost O S im pose further lim itations! Ù m ost system s provide 8192 bytes m axim um (m ax size in N FS ) Ù som e O S had (still have?) internal im plem entation features (bugs?) that lim it IP packet size ‰SunOS 4.1.3 had 32767 for max tolerable IP packet transmittable (but 32786 in reception…) – bug fixed only in Solaris 2.2

Ï Finally, subnet M axim um T ransfer Unit (M T U) lim its m ay fragm ent datagram – annoying for reliability! Ù E.g. ethernet = 1500 bytes; PPP on your m odem = 576 G. Bianchi, G. Neglia

UDP: a lightweight protocol

ÏNo connection establishm ent Ùno initia l ov e rh e a d d u e to h a nd s h a k ing ÏNo connection state Ùg re a te r nu m b e r of s u p p orte d c onne c tions b y a s e rv e r! ÏSm allpacket header overhead Ù8 b y te s only v s 2 0 in T C P

Ïoriginally intended for sim ple applications, oriented to short inform ation exchange ÙD N S Ùm a na g e m e nt (e .g . S N M P ) ÙD is trib u te d file s y s te m s u p p ort (e .g . N F S ) Ùe tc G. Bianchi, G. Neglia

3 Unregulated send rate in UDP ÙN o ra te lim ita tions ‰No throttling due to congestion & flow control mechanisms ‰No retransmission ÙL e s s ov e rh e a d ÙIn c ontra s t to T C P , U D P m a y p rov id e m u ltic a s t s u p p ort

Ïextrem ely im portant features for today m ultim edia applications! Ïspecially for real tim e applications w hich can tolerate som e packet loss but require a m inim um send rate.

Be careful: U D P ok for m ultim edia because it does not provide anything at all(no features = no lim its!). A pplication developers have to provide supplem entary transport capabilities at the application layer! G. Bianchi, G. Neglia

Audio/Video Support ÏUDP istransport layer candidate ÏUDP is too elem entary! ÙN o s e q u e nc e nu m b e rs ÙN o tim e s ta m p for re s y nc h roniz a tion a t re c e iv e r ÙN o m u ltic a s ting ÏOld solution: let application developer build their own header ÏNew solution: use an enhanced transport protocol

Real Time Protocol (RTP, RFC 3550)

G. Bianchi, G. Neglia

4 RTP: sublayer of Transport

Application R T P T rans port U D P

IP

L ow e r lay e rs

G. Bianchi, G. Neglia

RTP asseen from Application

Application R T P S O C K E T IN T E R F AC E U D P Application developer integrates RTP into the application by: IP •writing code which creates the RTP encapsulating packets; •sends the RTP packets into a UDP L ow e r lay e rs socket interface.

Details o f R T P in su b seq u en t c o u rses œ o r see it in R F C 1 8 8 9 G. Bianchi, G. Neglia

5 Error checksum Ï16 bit checksum field, obtained by: Ùs u m m ing u p a ll 1 6 b it w ord s in h e a d e r d a ta a nd ps e u d oh e ad e r, in 0 7 1 5 2 3 3 1 1 ‘s c om p le m e nt (c h e c k s u m fie ld s S rc port D e s t port fille d w ith 0 s initia lly ) U D P le ng th ch e ck s u m Ùta k e 1 ‘s c om p le m e nt of re s u lt Data Ùif re s u lt is 0 , s e t it to 1 1 1 1 1 1 … 1 1 (6 5 5 3 5 = = 0 in 1 ‘s c om p le m e nt) 00000000 Ïat destination: ÏZero padding Ù1 ‘s c om p le m e nt s u m s h ou ld re tu rn 0 , oth e rw is e e rror d e te c te d Ùw h e n d a ta s iz e is od d Ùu p on e rror, no a c tion (ju s t p a c k e t Ïchecksum disabled d is c a rd ) Ùb y s ou rc e , b y s e tting 0 in Ïefficient implementation RFC 1071 th e c h e c k s u m fie ld

G. Bianchi, G. Neglia

disabling checksum ÏIn principle never! ÙR e m e m b e r th a t IP p a c k e t c h e c k s u m D O E S N O T inc lu d e p a c k e t p a y loa d . ÏIn practice, often done in NFS Ùs u n w a s th e firs t, to s p e e d u p im p le m e nta tion Ïm ay be tolerable in LANsunder one’s control. ÏDefinitely dangerous in the wide internet ÙE x is t la y e r 2 p rotoc ols w ith ou t e rror c h e c k ing Ùs om e rou te rs h a p p e n to h a v e b u g s th a t m od ify b its G. Bianchi, G. Neglia

6 Pseudo header ÏIsnot transm itted! Ù it is inform a tion a v a ila b le a t tra ns m itte r a nd a t re c e iv e r Ù inte ntion: d ou b le c h e c k th a t p a c k e t h a s a rriv e d a t c orre c t d e s tina tion a nd tra ns p ort p rotoc ol Ù it v iola te s p rotoc ol h ie ra rc y ! 0 7 1 5 2 3 3 1 S ou rce IP ad d re s s 1 2 b y te s D e s tination IP ad d re s s ps e u d oh e ad e r 00000000 protocol U D P le ng th S ou rce port D e s tination port 8 b y te s U D P h e ad e r U D P le ng th ch e ck s u m

d ata

Samechecksum calculationusedin TCP. UDP length duplicated. G. Bianchi, G. Neglia

7