📦 Tutorial 3: User Datagram Protocol (UDP) – Advanced

Comprehensive university‑level coverage – COMP347 (TrustOpen University)

📘 1. UDP in the Transport Layer Ecosystem

UDP is often described as a “thin” layer over IP. It adds two key functions:

• Multiplexing/Demultiplexing via port numbers.
• Error detection via an optional checksum (mandatory in IPv6).

Unlike TCP, UDP does not provide reliability, ordering, flow control, or congestion control. This minimalism allows UDP to achieve low latency and low overhead, making it ideal for applications that can tolerate occasional data loss or that implement their own reliability at the application layer.

The protocol is defined in RFC 768 (1980). Over the decades, it has remained essentially unchanged, a testament to its simplicity and utility.

📘 2. UDP Segment Structure and Fields

A UDP segment consists of an 8‑byte header followed by the payload. The header is composed of four 16‑bit fields:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Source Port (16 bits): Port number of the sending process. May be set to 0 if not used (e.g., when no reply is expected).
• Destination Port (16 bits): Port number of the receiving process. Required for demultiplexing.
• Length (16 bits): Total length of the UDP segment (header + data) in bytes. Minimum value is 8 (header only). The length field allows the receiver to know where the UDP data ends, even if the IP datagram contains padding.
• Checksum (16 bits): Error‑detection field computed over a pseudo‑header, the UDP header, and the data. In IPv4, it is optional (can be 0); in IPv6, it is mandatory.

The pseudo‑header is not transmitted but is used only for checksum calculation. It includes the source IP address, destination IP address, the protocol number (17 for UDP), and the UDP length. This ensures that the checksum also protects against misrouting.

Pseudo‑header structure (IPv4):

 0      7 8     15 16    23 24    31
 +--------+--------+--------+--------+
 |        source address              |
 +--------+--------+--------+--------+
 |      destination address           |
 +--------+--------+--------+--------+
 |  zero  |protocol|   UDP length     |
 +--------+--------+--------+--------+

📘 3. The UDP Checksum: In‑Depth Analysis

The UDP checksum provides error detection for the entire segment. The sender performs the following steps:

1. Construct the pseudo‑header from the IP addresses, protocol (17), and UDP length.
2. Concatenate the pseudo‑header, the UDP header (with checksum field initially set to 0), and the data. Pad with a zero byte at the end if the length is odd (to make the total length even).
3. Compute the 16‑bit one’s complement sum of all 16‑bit words. This is done by summing the words in binary, and if a carry occurs beyond the 16th bit, adding the carry back to the sum (end‑around carry).
4. Take the one’s complement (bitwise NOT) of the result and store it in the checksum field.

On the receiver side, the same computation is performed over the received segment (including the checksum field). If the result is all 1s (0xFFFF), the segment is considered error‑free. A result of 0xFFFF indicates that the checksum passed; a different value indicates an error.

Why one’s complement? It is endian‑independent and simplifies the receiver’s verification – the complement of the sum yields the same result regardless of byte order.

Checksum offloading: Modern NICs can compute the UDP checksum in hardware, reducing CPU overhead. The OS may set the checksum to 0 and let the NIC fill it.

📘 4. Advantages and Limitations of UDP

4.1 Advantages

• No connection establishment: Zero RTT delay before sending data.
• No connection state: Servers do not need to maintain per‑client state, reducing memory and processing overhead.
• Small header: Only 8 bytes, compared to TCP’s 20+ bytes.
• No congestion control: Applications can send at any rate, which is essential for real‑time media that cannot adapt to TCP’s rate changes.
• Message‑oriented: Preserves application‑layer message boundaries, unlike TCP’s byte‑stream.
• Supports multicast and broadcast: UDP is the natural choice for one‑to‑many communication.

4.2 Limitations

• No reliability: Packets may be lost, duplicated, or reordered.
• No flow control: Sender may overwhelm the receiver.
• No congestion control: Can cause network congestion and unfairness.
• Limited error detection: Checksum is not cryptographically strong; it detects only bit errors, not sophisticated corruption.

📘 5. Typical UDP Applications

📘 6. Building Reliability on Top of UDP

Applications that need reliability but choose UDP for performance reasons can implement their own reliability mechanisms. Common approaches include:

• Sequence numbers: To detect duplicates and reorder.
• Acknowledgments (ACKs): Receiver sends ACK for each packet (or cumulative).
• Timeouts and retransmissions: Sender retransmits if ACK not received.
• Forward Error Correction (FEC): Send redundant data to reconstruct lost packets without retransmission (e.g., in video streaming).
• Congestion control: Applications can implement their own (e.g., Google’s BBR in QUIC).

Examples: TFTP uses a simple stop‑and‑wait protocol over UDP. QUIC implements a full reliable, multiplexed transport with congestion control on top of UDP.

📘 7. Performance and Latency Considerations

UDP’s low overhead translates to measurable performance benefits:

• Lower latency: No handshake, no delayed ACKs, no retransmission delays (unless application implements them).
• Higher throughput: Smaller header means more data per packet.
• Reduced CPU usage: Less processing (no sequence numbers, timers, congestion control).

However, without congestion control, UDP flows can dominate network resources and cause unfairness. In practice, many networks employ policing or shaping to limit UDP rates.

Latency comparison: For a small request‑response transaction, UDP can be one RTT faster than TCP because it skips the three‑way handshake. For large data transfers, TCP may achieve higher throughput due to its congestion control and sliding window, but at the cost of increased latency under loss.

📘 8. UDP Variants: UDP‑Lite and Others

UDP‑Lite (RFC 3828) is a lightweight variant that allows the checksum to cover only a portion of the payload, leaving the rest unprotected. This is useful for applications that can tolerate corruption in some parts (e.g., video codecs where corrupted pixels are acceptable). The checksum coverage length is specified in the header.

Other extensions include UDP with congestion control (e.g., DCCP – Datagram Congestion Control Protocol), which adds congestion control to UDP‑like datagrams.

📘 9. Security Implications: Amplification Attacks

UDP’s connectionless nature and lack of handshake make it attractive for amplification attacks, where an attacker spoofs the source IP to a victim and sends a small request to a UDP service that replies with a much larger response (e.g., DNS, NTP, Memcached). The victim receives amplified traffic.

Mitigations include:

• Ingress filtering (BCP 38) to prevent spoofed packets from leaving a network.
• Rate limiting on UDP services.
• Response size limitation.
• Source IP verification (e.g., using cookies).

UDP’s checksum does not provide authentication; it only detects errors, not spoofing.

📝 Quiz

Test your understanding with these 25 questions. Answers are hidden below each question.

🛠️ Exercises

Apply your knowledge with these 15 exercises. Solutions are provided below each.

📚 Homework

These advanced problems require synthesis and research. Sample answers are provided below.