Fast Retransmit

The retransmission timeout (RTO) is TCP's mechanism of last resort—a blunt instrument that ensures eventual recovery when all else fails. But this reliability comes at an enormous performance cost. When RTO fires, TCP doesn't just retransmit a segment; it assumes the network is severely congested and responds with the most conservative measures available: resetting the congestion window to 1 segment and entering slow start.

Fast retransmit exists specifically to avoid RTO whenever possible. By detecting loss through duplicate ACKs and retransmitting immediately, TCP bypasses the lengthy timeout period entirely. The performance difference is not marginal—it can be 10x to 100x faster recovery, translating directly into higher throughput, lower latency, and better user experience.

To appreciate timeout avoidance, we must first understand exactly what happens during an RTO event. The retransmission timeout is not simply a delay—it triggers a cascade of conservative actions that devastate throughput.

The RTO Timeline:

1. Segment Sent: A data segment is transmitted and the RTO timer starts
2. Waiting Period: The sender waits for an acknowledgment (RTO duration)
3. Timer Expiration: No ACK arrives; RTO fires
4. Emergency Response: TCP assumes severe congestion and takes drastic action

The Double Penalty:

RTO imposes a double penalty on throughput:

1. The Wait: No data transmission during the entire RTO period (typically 200ms to several seconds)
2. The Reset: After RTO, cwnd resets to 1 segment, requiring slow start to rebuild

Consider a connection with cwnd = 100 segments (1.5MB window at MSS=1460). After RTO:

• Window drops from 100 segments to 1 segment (99% reduction)
• Must complete ~7 RTTs of slow start to return to 100 segments
• For RTT = 50ms, that's 350ms of suboptimal throughput after the RTO period

Total impact: RTO duration + slow start recovery time + opportunity cost of reduced window.

Why RTO Must Be Conservative:

The RTO is intentionally set higher than necessary because:

1. False positive danger: Premature retransmission wastes bandwidth and can worsen congestion
2. Network variability: RTT can spike due to queuing; RTO must accommodate variance
3. Safety margin: Conservative RTO prevents retransmission storms that could collapse the network
4. Clock granularity: Historically, systems had coarse timers (500ms ticks); RTO must be safe even with measurement error

The classic RTO formula (RFC 6298) includes 4x the RTT variance:

RTO = SRTT + max(G, K × RTTVAR)

Where K=4, G=clock granularity (typically 1ms today), SRTT=smoothed RTT, RTTVAR=RTT variance.

This formula errs heavily on the side of caution.

Let's develop a rigorous mathematical framework for understanding the performance cost of RTO versus fast retransmit. This analysis reveals why avoidance is so critical.

Recovery Time Comparison:

RTO Recovery Time = RTO + SlowStartRecovery + ResumeTime

Where:

• RTO: The timeout duration (1s minimum, often higher)
• SlowStartRecovery: Time to rebuild cwnd via slow start
• ResumeTime: Time to return to steady-state throughput

Fast Retransmit Recovery Time = 3 × PacketTime + RTT

Where:

• 3 × PacketTime: Time for 3 duplicate ACKs to arrive
• RTT: Time for retransmission to be acknowledged

Numerical Example:

Consider a connection with:

• RTT = 50ms
• cwnd = 100 segments before loss
• RTO = 1 second (minimum)

Scenario A: RTO Recovery

1. RTO fires: 1000ms wait
2. Slow start from 1 segment:
   - RTT 1: cwnd = 2
   - RTT 2: cwnd = 4
   - RTT 3: cwnd = 8
   - RTT 4: cwnd = 16
   - RTT 5: cwnd = 32
   - RTT 6: cwnd = 50 (ssthresh)
   - Congestion avoidance begins
   - RTT 7+: linear growth to 100
3. Total recovery: 1000ms + 7×50ms = 1350ms minimum

Scenario B: Fast Retransmit Recovery

1. 3 dup ACKs arrive: ~10ms (3 segments at typical BDP)
2. Retransmit immediately
3. ACK for retransmit: 50ms RTT
4. cwnd halved but maintained in fast recovery
5. Total recovery: ~60ms

Speedup: 1350ms / 60ms ≈ 22x faster!

Beyond raw recovery time, we must consider the impact on actual throughput. A stalled connection contributes zero bytes during recovery; the throughput impact compounds with loss frequency.

Theoretical Throughput Model:

For a TCP connection with:

• Steady-state throughput: T₀ (bytes/second)
• Loss probability: p (per segment)
• Average segments per loss event: N = 1/p
• Recovery time: R (seconds)

Effective throughput:

T_effective = T₀ × (transmission_time) / (transmission_time + recovery_time)
            = T₀ × (N × segment_time) / (N × segment_time + R)

For small R (fast retransmit): throughput impact is minimal For large R (RTO): throughput degrades significantly

Numerical Throughput Example:

Connection parameters:

• Link rate: 100 Mbps
• MSS: 1460 bytes
• RTT: 50ms
• Loss rate: 0.1% (1 in 1000 segments)

With RTO Recovery:

Segments per loss: 1000
Transmission time for 1000 segments: ~117ms (at 100 Mbps)
RTO recovery time: 1000ms (minimum)

Effective throughput = 100 × 117/(117+1000) = ~10.5 Mbps
Efficiency: 10.5% of link capacity

With Fast Retransmit:

Segments per loss: 1000
Transmission time for 1000 segments: ~117ms
Fast retransmit recovery: 60ms

Effective throughput = 100 × 117/(117+60) = ~66 Mbps
Efficiency: 66% of link capacity

Improvement: 66 Mbps vs 10.5 Mbps = 6.3x higher throughput!

The Exponential Backoff Multiplier:

The situation worsens dramatically when multiple consecutive losses occur. RTO uses exponential backoff:

• 1st timeout: RTO (e.g., 1s)
• 2nd timeout: 2 × RTO (2s)
• 3rd timeout: 4 × RTO (4s)
• 4th timeout: 8 × RTO (8s)
• ...

Two consecutive RTOs mean 3 seconds of idle time (1s + 2s). Three consecutive RTOs mean 7 seconds. This exponential penalty can cause perceived "connection freezes" that last several seconds—devastating for interactive applications.

Fast retransmit provides what we call the "fast path" for loss recovery. Understanding why this path is so much faster requires examining the fundamental differences in the two recovery mechanisms.

Signal Detection Speed:

The Information Advantage:

Duplicate ACKs carry information that pure timeout cannot provide:

1. Receiver is alive: The receiver is processing segments and sending ACKs
2. Network is functional: Segments are getting through (just not in order)
3. Specific loss identified: The ACK number tells exactly which byte is missing
4. Subsequent data buffered: Later segments arrived and are buffered

RTO provides none of this information. When RTO fires, TCP knows only that something went wrong—it could be:

• Packet loss
• ACK loss
• Route change with higher RTT
• Receiver crashed
• Network partition

This uncertainty forces the most conservative possible response.

Window Preservation:

One of fast recovery's key optimizations (introduced in TCP Reno) is window preservation:

RTO Path:

cwnd before loss: 100 segments
cwnd after RTO: 1 segment
Bandwidth utilization: 1% of previous

Fast Retransmit Path:

cwnd before loss: 100 segments
ssthresh after fast retransmit: 50 segments
cwnd during fast recovery: 50 + dup_acks × 1
Bandwidth utilization: ~50% of previous

The ability to maintain approximately half the previous window during fast recovery (rather than dropping to 1) is tremendously valuable. It means the pipe stays mostly full while recovery proceeds.

Despite its power, fast retransmit has fundamental limitations. Certain scenarios inevitably lead to timeout regardless of fast retransmit capability. Understanding these scenarios is essential for both implementation and debugging.

Scenario 1: Tail Loss (Insufficient Duplicate ACKs)

When the last few segments of a transmission are lost, there are no subsequent segments to generate duplicate ACKs.

Scenario 2: Small Congestion Window

With cwnd ≤ 3 segments, even loss of the first segment cannot generate 3 duplicate ACKs.

Scenario 3: Multiple Consecutive Losses

When many consecutive segments are lost, there may be no "bookending" segments to trigger duplicate ACKs.

Sent: [1][2][3][4][5][6][7][8][9][10]
Lost: [1][2][3][4][5][6][7][8]  ← 8 consecutive losses
Arrived at receiver: [9][10]

Receiver never got segment 1 (rcv_nxt = 1)
Segments 9, 10 are too far ahead → likely dropped or buffered
No contiguous acks possible → RTO required

Scenario 4: ACK Loss

If the duplicate ACKs themselves are lost, the sender never receives the signal.

Scenario 5: Network Partition

If the network path is completely broken (no packets getting through), neither data nor ACKs are flowing. RTO is the only detection mechanism.

The difference between RTO and fast retransmit recovery propagates up to applications in ways that directly affect user experience. Different application types have different sensitivities to these recovery mechanisms.

Web Browsing (HTTP/HTTPS):

Video Streaming:

• Fast Retransmit: Brief quality dip possible; buffer absorbs the ~100ms recovery time
• RTO: 1+ second stall may drain buffer, causing visible rebuffering
• Live Streaming: 1-second delay can desynchronize from real-time; fast retransmit keeps stream viable

Online Gaming:

• Fast Retransmit: ~100ms latency spike; noticeable but playable for most games
• RTO: 1+ second freeze; player likely dead/disconnected in competitive games
• Real-time requirement: Most games switch to UDP for this reason, implementing their own loss handling

VoIP/Video Conferencing:

• Fast Retransmit: Slight audio glitch or video artifact
• RTO: 1+ second of silence/frozen video; conversation interrupted
• Note: VoIP typically uses RTP over UDP; when used over TCP, RTO causes severe degradation

In production systems, monitoring the effectiveness of timeout avoidance is crucial for understanding TCP performance. Several metrics and tools can illuminate whether fast retransmit is working as expected.

Key Metrics:

Diagnostic Approach:

1. High RTO count: Check for tail loss (TLP may help), small windows (check cwnd, rwnd), or path issues (packet captures)

2. Low FastRetrans despite loss: Verify SACK negotiation, check for receiver issues, analyze duplicate ACK patterns

3. Spurious RTOs: RTO may be too aggressive; check RTT variance, consider increasing RTO min (non-standard)

4. FastRetrans not helping throughput: Verify fast recovery is working (not just fast retransmit); check for SACK reneging

Timeout avoidance is not merely an optimization—it is essential for TCP's viability on modern networks. Without fast retransmit, the combination of conservative RTO values and multiplicative backoff would render TCP unusable for most applications on lossy networks.

What's Next:

We've established that fast retransmit provides enormous performance benefits by avoiding timeout. The next page quantifies these benefits more precisely, exploring the performance improvement metrics and comparing TCP's behavior with and without fast retransmit across various network conditions.