How does TCP decide when to retransmit, and how is the retransmission timeout calculated?
Show the answer
Say this first
TCP retransmits either when the retransmission timer fires or earlier, when duplicate ACKs or SACK show a hole (fast retransmit). The timer, RTO, comes from measured round-trip times (RFC 6298): RTO = smoothed RTT + 4 x RTT variance, starting at 1 second before any sample. Each time the timer fires, the RTO doubles. A timeout is expensive: the congestion window drops to one segment and the sender goes back to slow start. Linux uses a 200 ms minimum RTO, lower than the RFC's 1 second.
Go deeper
The calculation
- First sample R: SRTT = R, RTTVAR = R / 2.
- Later samples R': RTTVAR = 3/4 RTTVAR + 1/4 abs(SRTT - R'), then SRTT = 7/8 SRTT + 1/8 R'.
- RTO = SRTT + max(G, 4 x RTTVAR), where G is the clock granularity.
- Bounds: the RFC says at least 1 second; Linux uses 200 ms minimum and 120 seconds maximum.
Karn's algorithm
An ACK for a retransmitted segment is ambiguous: it may acknowledge the first copy or the second. TCP takes no RTT sample from it, and keeps the backed-off RTO until a fresh sample arrives. Timestamps remove the ambiguity because the echoed value says which copy is being acknowledged.
When the timer fires
ssthresh = max(flight size / 2, 2 x MSS), cwnd = 1 segment, retransmit the oldest unacknowledged
segment, double the RTO. On Linux an established connection gives up after net.ipv4.tcp_retries2
(15) retransmissions, at least about 15 minutes.
Avoiding the timer
Most losses should be repaired by fast retransmit. Linux also sends a tail loss probe about two RTTs after the last segment if nothing has been acknowledged, so a lost final segment triggers recovery without waiting for the full RTO.
They will ask next
What does "TCP Spurious Retransmission" mean in Wireshark?
The capture already saw the receiver acknowledge that data, yet the sender sent it again. Often the RTO was too short for a sudden RTT increase, or the ACK was delayed or lost. It wastes bandwidth and shrinks cwnd for nothing.
Why is a burst of RTOs worse than the same number of fast retransmits?
Each RTO waits at least 200 ms on Linux (much more after backoff) with nothing sent, then restarts from one segment. Fast retransmit repairs the hole within about one RTT and only halves the window or less.
Traps
- Saying the RTO is a fixed value. It adapts to the measured RTT and backs off exponentially.