Questions: UDP: User Datagram Protocol

Question 1

A live video conferencing application uses UDP. A packet containing several video frames is lost in transit. What happens next?

• A. The application skips those frames — a brief visual glitch is far less disruptive than pausing the stream to wait for retransmission
• B. UDP automatically retransmits the lost packet after detecting the loss via its checksum
• C. The video call halts until the lost packet arrives, ensuring smooth chronological playback
• D. The connection resets and a new UDP session is negotiated from the beginning

Answer: (A)

UDP provides no retransmission, acknowledgment, or error recovery — lost packets are simply gone. This is intentional for live video: a retransmitted frame arriving 200–500 ms late is useless or actively disruptive (out-of-order playback). The application skips missing frames, producing a brief glitch, which is far preferable to the latency of TCP retransmission. Options B and D describe TCP-like behaviors that UDP deliberately omits by design.

Question 2

A developer argues that UDP should only be used for applications that can tolerate unreliable delivery. Which statement best challenges this claim?

• A. Applications like QUIC build full reliability on top of UDP, demonstrating that UDP is a minimal foundation on which any transport behavior — including reliable delivery — can be constructed
• B. UDP is inherently unreliable and cannot be made reliable regardless of the application layer
• C. TCP is always faster than UDP for applications that need reliable delivery
• D. Modern networks rarely drop packets, so UDP's unreliability is not a meaningful concern in practice

Answer: (A)

QUIC (used in HTTP/3) directly refutes the claim. QUIC implements reliable, ordered, multiplexed streams on top of UDP, achieving TCP-level reliability while avoiding head-of-line blocking and ossified middlebox behavior. The insight is that UDP is not 'unreliable transport' — it is minimal transport. Reliability, ordering, congestion control — any transport behavior — can be implemented in application space on top of UDP. Choosing UDP means choosing to control those mechanisms yourself, not accepting their absence.

Question 3

A UDP datagram header includes sequence numbers so that receivers can detect out-of-order delivery and reassemble packets in the correct order.

• T. True
• F. False

Answer: False

UDP's header is intentionally minimal: source port, destination port, length, and checksum — just 8 bytes total. There are no sequence numbers, acknowledgment numbers, flags, or flow control fields. This is not an oversight; it is the point. Sequence numbers and ordering are TCP features that add overhead and latency. If a UDP application needs ordering, it must implement that logic at the application layer. The stripped-down header is why UDP adds almost no latency beyond network transit time itself.

Question 4

UDP is generally faster than TCP for any given application because it has lower protocol overhead.

• T. True
• F. False

Answer: False

UDP has lower per-packet overhead and no connection setup latency, but 'always faster' is incorrect. TCP's congestion control can achieve higher sustained throughput than uncontrolled UDP on congested networks, because UDP floods the network without backing off while TCP adapts to available capacity. UDP's advantages are lower latency for small exchanges and no head-of-line blocking — not universally higher throughput. The right choice depends entirely on the application's requirements.

Question 5

Why is UDP particularly well-suited for DNS queries, and what does the DNS application layer do to compensate for UDP's lack of reliability guarantees?

Model answer: DNS queries are single request-response exchanges. Using TCP would require a three-way handshake before any query, adding a full round-trip of latency to every DNS lookup — unacceptable for infrastructure that precedes nearly every network connection. UDP allows the client to send a query directly and receive a response in one round-trip. To compensate for potential packet loss, the DNS resolver implements a simple application-layer retry: if no response arrives within a timeout window, it retransmits the query. This is sufficient because DNS queries are idempotent (safe to repeat) and typically succeed on the first attempt.

DNS illustrates the general pattern for query-response protocols over UDP: the application implements lightweight timeout-and-retry logic, which is cheaper than TCP's full reliability machinery for short, stateless exchanges. The same pattern applies to NTP (network time synchronization), SNMP, and other protocols where queries are small, responses are expected quickly, and retrying is harmless. UDP's 8-byte header means almost no overhead per query — for a service handling billions of queries daily, this matters significantly.