What is TCP Fast Retransmit?
Learn how TCP fast retransmit uses three duplicate ACKs to recover from packet loss faster than a timeout, with fast recovery.
Expected Interview Answer
TCP fast retransmit is a loss-recovery mechanism where a sender resends a segment as soon as it receives three duplicate ACKs for it, instead of waiting for the much slower retransmission timeout to expire.
When a receiver gets a segment out of order, it immediately re-acknowledges the last in-order byte it has received rather than the new segment, producing a duplicate ACK. If the sender sees the same ACK number arrive three times in a row (the original plus two duplicates), it infers the next expected segment was likely lost rather than just reordered, and retransmits it immediately without waiting for the retransmission timer to fire. This shortcuts what could otherwise be a multi-hundred-millisecond or multi-second stall on a busy path, and is almost always paired with fast recovery, which halves the congestion window instead of collapsing it all the way back to one segment as a full timeout would. Fast retransmit relies on the receiver generating duplicate ACKs promptly and the sender tracking ACK counts per connection.
- Recovers from single packet loss far faster than a timeout
- Avoids the congestion-window collapse of a full timeout
- Works entirely from ACK behavior, no extra signaling needed
- Pairs with fast recovery to keep throughput high after loss
AI Mentor Explanation
TCP fast retransmit is like a scorer who, after hearing the crowd shout the wrong ball number three times in a row, immediately assumes the scoreboard update for that ball never arrived and resends it, instead of waiting for the usual end-of-over check. Getting the same confused shout three times is a much stronger signal than waiting for a scheduled recount. Reacting after three repeats rather than a full timeout is exactly how fast retransmit beats waiting for a TCP retransmission timer.
Step-by-Step Explanation
Step 1
Segment lost
A TCP segment is dropped somewhere along the path, but later segments arrive fine.
Step 2
Duplicate ACKs generated
The receiver re-acknowledges the last in-order byte each time it gets an out-of-order segment.
Step 3
Threshold reached
The sender counts three duplicate ACKs for the same sequence number.
Step 4
Immediate retransmit
The sender resends the missing segment immediately and enters fast recovery, halving the congestion window.
What Interviewer Expects
- Explains the three-duplicate-ACK trigger clearly
- Distinguishes fast retransmit from a full retransmission timeout
- Mentions fast recovery halving cwnd instead of resetting it
- Understands duplicate ACKs come from out-of-order segment arrival
Common Mistakes
- Confusing fast retransmit with the retransmission timeout (RTO) mechanism
- Thinking any single duplicate ACK triggers retransmission
- Forgetting fast recovery accompanies fast retransmit
- Assuming this requires explicit signaling from the receiver beyond ACKs
Best Answer (HR Friendly)
“TCP fast retransmit is a shortcut that lets a sender notice a lost packet almost immediately, instead of waiting for a slow timeout. If the receiver keeps re-confirming the same spot three times in a row, the sender takes that as a strong hint something went missing and resends it right away, which keeps a connection’s throughput from dropping off a cliff after just one lost packet.”
Code Example
# Watch ACK numbers to spot duplicate ACKs preceding a fast retransmit
sudo tcpdump -n -i any 'tcp and host 93.184.216.34'
# Typical pattern in the capture:
# ... ack 5001 (original ACK)
# ... ack 5001 (duplicate ACK 1, out-of-order segment arrived)
# ... ack 5001 (duplicate ACK 2)
# ... ack 5001 (duplicate ACK 3 -> triggers fast retransmit)
# ... seq 5001 (sender retransmits immediately, no RTO wait)Follow-up Questions
- How does fast recovery differ from slow start after a timeout?
- What is selective acknowledgment (SACK) and how does it improve on fast retransmit?
- Can reordering (not loss) trigger a false fast retransmit?
- How does fast retransmit interact with the congestion window?
MCQ Practice
1. How many duplicate ACKs typically trigger TCP fast retransmit?
Three duplicate ACKs (the original plus two repeats) is the standard trigger threshold.
2. What does fast retransmit avoid waiting for?
Fast retransmit reacts to duplicate ACKs instead of waiting for the much slower RTO timer.
3. What congestion behavior typically accompanies fast retransmit?
Fast recovery halves the congestion window rather than collapsing it fully, preserving throughput.
Flash Cards
What triggers fast retransmit? — Three duplicate ACKs for the same sequence number.
Why is it faster than RTO? — It reacts to ACK evidence immediately instead of waiting for a timer to expire.
What accompanies fast retransmit? — Fast recovery, which halves the congestion window.
What causes duplicate ACKs? — The receiver re-acknowledging the last in-order byte when a later segment arrives out of order.