Computing TCP's Retransmission Timer
obsoletes
- rfc-2988 — Computing TCP's Retransmission Timer
updates
- rfc-1122 — Requirements for Internet Hosts - Communication Layers
Extracted elements (22)
A minimum RTO of 1 second is required because research suggests a large minimum RTO is needed to keep TCP conservative and avoid spurious retransmissions, particularly since traditional TCP implementations use coarse-grain clocks.
The initial RTO was lowered from 3 seconds (RFC 2988) to 1 second because studies found over 97.5% of connections have RTTs under 1 second, and faster recovery from early packet loss outweighs the ~2.5% of connections that may incur a spurious SYN retransmission. The 3-second fallback after SYN timeout mitigates the impact on long-RTT connections.
The smoothing constants alpha=1/8 and beta=1/4 are specified as SHOULD-level recommendations based on Jacobson and Karels [JK88]. Using more RTT samples per RTT than one-per-RTT may make these constants inadequate, which remains an open research question.
RFC 1323 recommends that TCP connections with large congestion windows take many RTT samples per window of data to avoid aliasing effects, but the alpha/beta values in this document may be inadequate in that case.
The TCP timestamp option (RFC 1323) removes the ambiguity in Karn's algorithm: when timestamps are employed, RTT samples MAY be taken from retransmitted segments because the timestamp identifies which instance of the data segment triggered the ACK.
A maximum value MAY be placed on RTO provided it is at least 60 seconds.
A TCP implementation MUST take at least one RTT measurement per RTT, unless that is not possible per Karn's algorithm.
A TCP MUST NOT be more aggressive than the algorithms defined in this document allow, though it MAY be more conservative. This upgrades the algorithm from a SHOULD (RFC 1122) to a MUST.
An implementation MUST manage retransmission timer(s) such that a segment is never retransmitted too early, i.e., less than one RTO after the previous transmission of that segment.
If the K*RTTVAR term in the RTO calculation equals zero, the variance term MUST be rounded up to G seconds, ensuring RTO <- SRTT + max(G, K*RTTVAR) is always applied.
If the timer expires waiting for the ACK of a SYN and the implementation is using an RTO less than 3 seconds, the RTO MUST be re-initialized to 3 seconds when data transmission begins (after the three-way handshake completes).
On subsequent RTT measurements R', the host MUST update RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'| then SRTT <- (1 - alpha) * SRTT + alpha * R' (in that order), then RTO <- SRTT + max(G, K*RTTVAR). The update order is mandatory: RTTVAR must be computed before SRTT is updated.
TCP MUST use Karn's algorithm for taking RTT samples: RTT samples MUST NOT be made using segments that were retransmitted, due to ambiguity about which transmission triggered the ACK. The exception is when the TCP timestamp option is employed.
Until a round-trip time measurement has been made, the sender SHOULD set RTO to 1 second, though exponential backoff on repeated retransmission still applies. A TCP implementation MAY use 3 seconds or any other value greater than 1 second.
When the first RTT measurement R is made, the host MUST initialize SRTT <- R, RTTVAR <- R/2, and RTO <- SRTT + max(G, K*RTTVAR) where K=4.
When the retransmission timer expires, the host MUST set RTO <- RTO * 2 (exponential backoff). The maximum RTO value from section 2.5 may bound this doubling.
Whenever RTO is computed, if it is less than 1 second, it SHOULD be rounded up to 1 second. This minimum is required to keep TCP conservative and avoid spurious retransmissions.
TCP senders maintain two state variables for RTO computation: SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation), plus a clock granularity constant G. The smoothing constants are alpha=1/8 and beta=1/4.
An attacker can inflate RTO by adding artificial latency to timed packets or their ACKs. However, this attack is largely redundant: the ability to delay packets usually implies the ability to drop them, offering no additional leverage.
An attacker who can forge ACKs for segments not yet received could lower RTO to an unsafe value, destabilizing the network. This requires the attacker to monitor path traffic to spoof correctly, and the sender's exponential backoff limits the sustained impact under actual congestion.
Correct RTO implementation is critical to Internet stability. Overly aggressive TCP behavior induced by manipulated RTO values could contribute to congestion collapse. The security considerations of RFC 5681 (TCP Congestion Control) also apply.
The retransmission timer has three management rules: (5.1) start timer on any data send if not running; (5.2) stop timer when all outstanding data is acknowledged; (5.3) restart timer when an ACK acknowledging new data is received. On expiry: retransmit earliest unacknowledged segment, double RTO, and restart timer.