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 (Datagrams) Ö Each application interacts with UDP transport sw to produce EXACTLY ONE UDP datagram! 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 bytes 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. ethernet = 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 multicast support
Îextremely important features for today multimedia applications! Îspecially for real time applications which can tolerate some packet loss 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 application layer! G.Bianchi, G.Neglia, V.Mancuso Audio/VideoAudio/Video SupportSupport ÎUDP is transport layer 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 Time Protocol (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 internet Ö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