What is head-of-line blocking in TCP, and how is it mitigated?

• A. If a lost in-order segment blocks delivery of subsequent data
• B. If the receiver reorders data
• C. UDP eliminates head-of-line blocking
• D. It cannot be mitigated

Answer: (A)

Head-of-line blocking in TCP happens because TCP delivers a byte stream in order. If the first (lost) segment in the sequence is not yet received, the receiver cannot pass along any later in-order data to the application, even if those later segments have arrived or are buffered. The app only sees data when there’s a contiguous, in-order sequence, so a single missing piece holds up everything behind it.

Mitigation comes from quick recovery of that missing piece. TCP uses retransmission triggered by timeouts or by fast retransmit when duplicate ACKs indicate a gap, and often enhanced with selective acknowledgments (SACK) so the sender knows exactly which segments were received and can retransmit only the missing ones. This minimizes how long data sits blocked and restores in-order delivery faster.

The other statements don’t fit: reordering at the receiver isn’t the root cause of the blocking (the need to deliver in-order data is), UDP does not provide head-of-line blocking since it doesn’t guarantee order, and head-of-line blocking can be mitigated with retransmission and SACK mechanisms.