LectureLecture 5.5.

InternetInternet TransportTransport Layer:Layer:

UserUser DatagramDatagram ProtocolProtocol (UDP)(UDP)

G.Bianchi, G.Neglia, V.Mancuso TransportTransport LayerLayer ProtocolsProtocols Entire network seen as a pipe

Internet ...

G.Bianchi, G.Neglia, V.Mancuso UDPUDP PacketsPackets

proc proc ÎConnection-Less UDP UDP IP IP IP Ö (no handshaking) IP IP ÎUDP packets () Ö Each application interacts with UDP transport sw to produce EXACTLY ONE UDP ! Application

UDP header Application data encapsulated in exactly 1 IP packet IP header UDP header Application data This is why, improperly, we use the term UDP packets

G.Bianchi, G.Neglia, V.Mancuso UDPUDP datagramdatagram formatformat 8 header + variable payload 0 7 15 23 31 source port destination port ÎUDP length field length (bytes) Checksum Ö all UDP datagram Ö (header + payload) Îpayload sizes allowed: Data Ö Empty Ö Odd size (bytes) ÎUDP functions limited to: Öaddressing Æwhich is the only strictly necessary role of a transport protocol ÖError checking Æwhich may even be disabled for performance

G.Bianchi, G.Neglia, V.Mancuso MaximumMaximum UDPUDP datagramdatagram sizesize Î16 bit UDP length field: Ö Maximum up to 216-1 = 65535 bytes Ö Includes 8 bytes UDP header (max data = 65527) ÎBut max IP packet size is also 65535 Ö Minus 20 bytes IP header, minus 8 bytes UDP header Ö Max UDP_data = 65507 bytes!

ÎMoreover, most OS impose further limitations! Ö most systems provide 8192 bytes maximum (max size in NFS) Ö some OS had (still have?) internal implementation features (bugs?) that limit 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 Maximum Transfer Unit (MTU) limits may fragment datagram – annoying for reliability! Ö E.g. = 1500 bytes; PPP on your modem = 576

G.Bianchi, G.Neglia, V.Mancuso UDP:UDP: aa lightweightlightweight protocolprotocol

ÎNo connection establishment Öno initial overhead due to handshaking ÎNo connection state Ögreater number of supported connections by a server! ÎSmall packet header overhead Ö8 bytes only vs 20 in TCP

Îoriginally intended for simple applications, oriented to short information exchange ÖDNS Ömanagement (e.g. SNMP) ÖDistributed file system support (e.g. NFS) Öetc

G.Bianchi, G.Neglia, V.Mancuso UnregulatedUnregulated sendsend raterate inin UDPUDP ÖNo rate limitations ÆNo throttling due to congestion & flow control mechanisms ÆNo retransmission ÖLess overhead ÖIn contrast to TCP, UDP may provide support

Îextremely important features for today multimedia applications! Îspecially for real time applications which can tolerate some but require a minimum send rate.

Be careful: UDP ok for multimedia because it does not provide anything at all (no features = no limits!). Application developers have to provide

supplementary transport capabilities at the ! G.Bianchi, G.Neglia, V.Mancuso Audio/VideoAudio/Video SupportSupport ÎUDP is candidate ÎUDP is too elementary! ÖNo sequence numbers ÖNo timestamp for resynchronization at receiver ÖNo multicasting ÎOld solution: let application developer build their own header ÎNew solution: use an enhanced transport protocol

Real (RTP, RFC 3550)

G.Bianchi, G.Neglia, V.Mancuso RTP:RTP: sublayersublayer ofof TransportTransport

Application RTP Transport UDP

IP

Lower layers

G.Bianchi, G.Neglia, V.Mancuso RTPRTP asas seenseen fromfrom ApplicationApplication

Application RTP SOCKET INTERFACE UDP Application developer integrates RTP into the application by: IP •writing code which creates the RTP encapsulating packets; •sends the RTP packets into a UDP Lower layers socket interface.

Details of RTP in subsequent courses – or see it in RFC 1889

G.Bianchi, G.Neglia, V.Mancuso ErrorError checksumchecksum Î16 bit checksum field, obtained by: Ösumming up all 16 bit words in header data and pseudoheader, in 0715 23 31 1’s complement (checksum fields Src port Dest port filled with 0s initially) UDP length checksum Ötake 1’s complement of result Data Öif result is 0, set it to 111111…11 (65535==0 in 1’s complement) 00000000 Îat destination: ÎZero padding Ö1’s complement sum should return 0, otherwise error detected Öwhen data size is odd Öupon error, no action (just packet Îchecksum disabled discard) Öby source, by setting 0 in Îefficient implementation RFC 1071 the checksum field

G.Bianchi, G.Neglia, V.Mancuso disablingdisabling checksumchecksum ÎIn principle never! ÖRemember that IP packet checksum DOES NOT include packet payload. ÎIn practice, often done in NFS Ösun was the first, to speed up implementation Îmay be tolerable in LANs under one’s control. ÎDefinitely dangerous in the wide ÖExist layer 2 protocols without error checking Ösome routers happen to have bugs that modify bits

G.Bianchi, G.Neglia, V.Mancuso PseudoPseudo headerheader ÎIs not transmitted! Ö it is information available at transmitter and at receiver Ö intention: double check that packet has arrived at correct destination and transport protocol Ö it violates protocol hierarcy! 0715 23 31 Source IP address 12 bytes Destination IP address pseudoheader 00000000 protocol UDP length Source port Destination port 8 bytes UDP header UDP length checksum

data

Same checksum calculation used in TCP. UDP length duplicated.

G.Bianchi, G.Neglia, V.Mancuso