3.3 – Connectionless Transport: UDP
- UDP does just about as little as a transport protocol can do.
- Aside from the multiplexing/demultiplexing function and some light error checking, it adds nothing to IP.
- UDP takes messages from the application process, attaches source and destination port number fields for the multiplexing/demultiplexing, adds two other small fields and passes the resulting segment to the network layer.
- The network layer encapsulates it and makes it into an IP datagram. IP then makes a best-effort delivery. UDP then uses the destination port number to deliver it to the correct application process if it isn’t lost on the way.
- There’s no handshaking between sending and receiving transport-layer entities before sending a segment which is why UDP is said to be connectionless.
- DNS is an example of a protocol that uses UDP.
- When a DNS application wants to make a query it constructs a DNS query message and passes the message to UDP. UDP then adds header fields to it and passes it to the network layer who encapsulates it into a Datagram and sends it to a DNS server.
- It then waits for a reply and if it doesn’t get a reply then it will either resend it, send it to another host or inform the application that it cant get a reply.
- Some applications are better suited for UDP for the following reasons:
- Finer application-level control over what data is sent, and when:
- TCP has a congestion-control mechanismen that throttles the TCP sender when a link is excessively congested. TCP will also continue to resend a segment until the receipt of the segment has been acknowledged by the destination, regardless of how long it takes.
- Real-time applications often require minimum sending, do not want to overly delay segments transmission and can tolerate some data loss, which makes UDP a better choice as it doesn’t have all the mechanisms that TCP have.
- No connection establishment:
- UDP does not introduce any delay to establish a connection, UDP just blasts away without any formal preliminaries.
- No connection State:
- TCP maintains connection state in the end-systems. This connection state includes receive and send buffers, congestion-control parameters, and sequence and acknowledgement number parameters. UDP on the other hand does not maintain a connection state and does not track any of these parameters (thus a server can typically support many more active clients over UDP than TCP).
- Small packet header overhead:
- The TCP segment has 20 bytes header overhead in every segment, UDP only has 8 bytes of overhead.
- Applications and their protocol:
- Electronic mail: SMTP – TCP
- Remote terminal access: Telnet – TCP
- Web: HTTP – TCP
- File transfer: FTP – TCP
- Remote file server: NFS - Typically UDP
- Streaming multimedia: typically proprietary – UDP or TCP
- Internet telephony: typically proprietary – UDP or TCP
- Network management: SNMP – Typically UDP
- Name translation DNS - Typically UDP
- The lack of congestion control in UDP can result in high loss rates between a UDP sender and receiver, and the crowding out of TCP session. It’s a serious issue and many researchers have proposed new mechanisms to force all sources including UDP sources to perform adaptive congestion control.
3.3.1 – UDP Segment Structure
- The application data occupies the data field of the UDP segment.
- The UDP header has only 4 fields each of consisting of 2 bytes.
- Source port and destination port – allows the segment to be delivered to the correct socket/process
- Length – needed since the size of the data field may differ from one UDP segment to the next.
- The checksum is used by the receiving host to check whether errors have been introduced into the segment.
3.3.2 UDP Checksum
- Provides error detection to determine whether bits within the segment has been altered as it moved from the source to the destination.
- UDP at the sender side performs the 1s complement of the sum of all the 16-bit words in the segment, with any overflow encountered during the sum being wrapped around. This result is put in the checksum field of the segment.
- Example:
- 011001100110000001010101010101011000111100001100
- The sum of the first two 16-bit words is:011001100110000001010101010101011011101110110101
- Adding the third word to the sum above gives us:101110111011010110001111000011000100101011000010
- Since this was a 1s compliment we have to invert the numbers and we get:1011010100111101 which becomes the checksum
- At the receiver, all four 16-bit words are added including the checksum. If there’s no errors then the sum will be 1111111111111111. If there’s a 0 we know there has been introduced an error.
- Given that neither link-by-link reliability nor in-memory error detection is guaranteed, UDP must provide error detection at the transport layer, on an end-end basis, if the end-end data transfer service is to provide error detection.
- Because IP is supposed to run over just about any layer-2 protocol, it is useful for the transport layer to provide error checking as a safety measure. Although UDP provides error checking, it does not do anything to recover from an error. Some implementation of UDP discard the damaged segment, other just pass it.