In the previous page, we established that duplicate acknowledgments serve as TCP's implicit signal of potential packet loss. But a signal alone is meaningless without a well-defined response. The retransmission trigger is the precise mechanism by which TCP converts the observation of duplicate ACKs into decisive action—specifically, the immediate retransmission of the presumed-lost segment.

This trigger represents one of TCP's most impactful performance optimizations. Before fast retransmit (introduced in TCP Tahoe, 1988), TCP had only one recovery mechanism: the retransmission timeout (RTO). An RTO can last hundreds of milliseconds to several seconds, during which the connection sits idle. Fast retransmit, triggered by duplicate ACKs, can initiate recovery in mere round-trip times—a speedup of 10x to 100x in loss recovery latency.

The fast retransmit algorithm is elegantly simple in its core logic. RFC 5681 specifies:

When the third duplicate ACK is received, TCP SHOULD retransmit the segment that appears to be missing (i.e., the segment beginning at the sequence number in the ACK field of the duplicate ACK), without waiting for the retransmission timer to expire.

The operative phrase is "third duplicate ACK"—not the fourth, not any number configurable at runtime, but precisely three. This number is hardcoded in virtually all TCP implementations.

Counting Semantics:

The counting of duplicate ACKs requires careful attention:

1. Original ACK: The first ACK with a given acknowledgment number is the original, not a duplicate
2. Duplicate #1: The second ACK with the same number is duplicate #1
3. Duplicate #2: The third ACK is duplicate #2
4. Duplicate #3: The fourth ACK is duplicate #3 → TRIGGER!

So when we say "three duplicate ACKs," we mean the sender has received four total ACKs with the same acknowledgment number: one original plus three duplicates.

Why Exactly Three?

As discussed in the previous page, three represents the empirically-validated balance between:

• Avoiding false positives: Single or double reordering events are common; treating them as loss wastes bandwidth on unnecessary retransmissions and triggers congestion control penalties
• Minimizing recovery delay: Waiting for more duplicates delays recovery; the goal is to retransmit as soon as we're confident loss occurred

Research by Vern Paxson and others in the 1990s established that network reordering rarely exceeds 2-3 packets. The threshold of 3 duplicates provides the safety margin while enabling rapid recovery.

The fast retransmit algorithm, as specified in RFC 5681 and refined over subsequent RFCs, can be expressed in precise algorithmic form. While implementations vary in detail, the core logic is universal.

Formal Algorithm (RFC 5681 Section 3.2):

Algorithm Breakdown:

Step 1: Threshold Calculation

ssthresh = max(FlightSize / 2, 2 * SMSS)

• FlightSize: Amount of data currently in flight (sent but not yet acknowledged)
• SMSS: Sender Maximum Segment Size
• The /2 reflects the AIMD (Additive Increase, Multiplicative Decrease) principle
• The max with 2 * SMSS ensures we never set ssthresh below 2 segments

Step 2: Immediate Retransmission

retransmit_segment(snd_una)

• snd_una: Send Unacknowledged—the oldest byte not yet acknowledged
• The segment beginning at snd_una is exactly what the duplicate ACKs are asking for
• This is the segment whose loss caused the receiver to generate duplicate ACKs

Step 3: Enter Fast Recovery (Reno+)

cwnd = ssthresh + 3 * SMSS

• The + 3 * SMSS "inflates" cwnd to account for the 3 segments that generated the duplicate ACKs
• These segments are buffered at the receiver—they're out of the network
• This is the beginning of the fast recovery phase (covered in subsequent pages)

When fast retransmit triggers, the sender must decide which segment to retransmit. This decision seems obvious—retransmit the lost segment—but several subtleties arise in practice:

Without SACK: The Simple Case

When Selective Acknowledgment is not enabled, TCP has limited information. The duplicate ACKs tell us:

• All data up to snd_una - 1 has been received
• Data at snd_una has NOT been received (or hasn't been received contiguously)

The only logical choice is to retransmit the segment starting at snd_una. There's no information about what else might be lost.

With SACK: Targeted Retransmission

When SACK is negotiated during connection establishment, the situation improves dramatically. SACK blocks in the duplicate ACKs tell the sender exactly which byte ranges have been received:

Duplicate ACK contents:
  ACK: 5000
  SACK: [6460-7920], [7920-9380], [9380-10840], [10840-12000]

The sender can now deduce:

• Bytes 0-4999: Acknowledged (received and in order)
• Bytes 5000-6459: The only missing range → Retransmit this
• Bytes 6460-12000: Buffered at receiver (via SACK)

This precision matters when multiple segments are lost. Without SACK, after retransmitting the first lost segment, TCP must wait for its ACK before discovering additional losses. With SACK, all losses can be identified (and retransmitted) immediately.

Fast retransmit operates alongside—not instead of—the retransmission timeout (RTO) mechanism. Understanding their interaction is critical for robust TCP implementation.

The Timer States:

Race Conditions:

Several scenarios create interesting timing interactions:

Scenario 1: Fast Retransmit Wins (Common Case)

Time 0ms:    Segment 5 sent
Time 10ms:   Segment 5 lost in network
Time 20ms:   Segments 6, 7, 8 arrive at receiver
Time 40ms:   3 duplicate ACKs arrive at sender
Time 40ms:   Fast retransmit triggered → Segment 5 resent
Time 60ms:   Retransmitted segment 5 acknowledged
[RTO timer never fires—cancelled by ACK]

Recovery time: ~60ms (2 RTT)

Scenario 2: RTO Fires (Duplicate ACKs Insufficient)

Time 0ms:    Segments 5, 6, 7 sent (window = 3)
Time 10ms:   Segment 5 lost
Time 20ms:   Segments 6, 7 arrive → 2 duplicate ACKs (not enough!)
Time 200ms:  RTO timer expires → Segment 5 resent
Time 220ms:  ACK for segment 7 arrives (all recovered)
[Slow start initiated due to RTO]

Recovery time: ~220ms (RTO penalty)

While fast retransmit is remarkably effective in common scenarios, several edge cases expose its limitations. Understanding these cases is essential for both implementation and debugging.

Edge Case 1: Tail Loss

When the last segment(s) of a transmission are lost, there are no subsequent segments to generate duplicate ACKs. Fast retransmit cannot trigger.

Edge Case 2: Small Window

With a congestion window of 2 or fewer segments, fast retransmit is impossible—there aren't enough subsequent segments to generate 3 duplicate ACKs.

Edge Case 3: Burst Losses

When multiple consecutive segments are lost, fast retransmit handles only the first loss. Without SACK, subsequent losses require additional RTTs or RTO to discover.

Edge Case 4: ACK Loss

If the duplicate ACKs themselves are lost, the sender never receives the signal. The segment loss is eventually recovered via RTO, but the fast path is lost.

Edge Case 5: Spurious Retransmission

If network conditions cause significant reordering (3+ packets), fast retransmit may trigger spuriously—retransmitting a segment that will arrive on its own. This wastes bandwidth and may cause the sender to incorrectly infer congestion.

Mitigations:

While the core fast retransmit trigger (3 duplicate ACKs) is consistent across TCP variants, what happens after the trigger differs significantly. This affects both implementation and performance.

TCP Tahoe (1988) — Original Fast Retransmit

Tahoe was the first TCP variant to implement fast retransmit. Its behavior:

1. Detect 3 duplicate ACKs
2. Set ssthresh = max(flight_size/2, 2*SMSS)
3. Retransmit the lost segment
4. Set cwnd = 1 SMSS (enter slow start!)
5. Proceed with normal slow start recovery

The problem: entering slow start after fast retransmit is extremely conservative. Throughput drops to near-zero momentarily before rebuilding.

TCP Reno (1990) — The Standard

Reno introduced fast recovery to complement fast retransmit:

1. Detect 3 duplicate ACKs
2. Set ssthresh = max(flight_size/2, 2*SMSS)
3. Retransmit the lost segment
4. Set cwnd = ssthresh + 3*SMSS (inflate for buffered segments)
5. For each additional dup ACK: cwnd += SMSS
6. On new ACK: exit fast recovery, cwnd = ssthresh

Reno avoids slow start, maintaining ~50% of previous throughput during recovery.

TCP NewReno (1999) — Multiple Loss Handling

NewReno fixes Reno's behavior when multiple segments are lost. Reno would exit fast recovery on the first partial ACK; NewReno stays in fast recovery until all data sent before fast retransmit is acknowledged.

Modern Algorithms: CUBIC, BBR

CUBIC (Linux default since 2.6.19): Uses a cubic function to calculate cwnd, providing more aggressive growth in high-bandwidth networks while remaining fair in lower-bandwidth scenarios. Fast retransmit triggers the same way, but the recovery curve differs.

BBR (Bottleneck Bandwidth and Round-trip propagation time): Takes a fundamentally different approach. Rather than reacting to packet loss, BBR models the network's bottleneck bandwidth and round-trip time. It doesn't rely on duplicate ACK counting for loss detection—instead using RACK/timestamps. However, BBR still respects fast retransmit signals from the transport layer.

In production environments, understanding whether fast retransmit is working correctly—or failing—is essential for debugging performance issues. Here's a systematic approach to analyzing fast retransmit behavior.

Packet Capture Analysis:

The most definitive way to verify fast retransmit is examining packet captures. Look for the characteristic pattern:

ss and netstat Statistics (Linux):

Linux exposes TCP retransmission statistics that can reveal fast retransmit effectiveness:

The retransmission trigger—the mechanism that converts three duplicate ACKs into immediate retransmission—is the heart of TCP's fast loss recovery. It transforms what would be catastrophic connection stalls into brief hiccups, enabling TCP to maintain high throughput over lossy networks.

What's Next:

With fast retransmit triggered, the sender has retransmitted the lost segment. But the story doesn't end there. The next page explores timeout avoidance—how fast retransmit prevents the devastating performance impact of RTO expiration, and the quantitative analysis of performance improvement.