Computing TCP's Retransmission Timer
obsoleted by
- rfc-6298 — Computing TCP's Retransmission Timer
Extracted elements (19)
A large minimum RTO of 1 second is required because research suggests it is needed to keep TCP conservative and avoid spurious retransmissions; coarse-grain clocks traditionally impose this lower bound, and the spec acknowledges future research may justify a smaller minimum.
A TCP implementation MAY clear SRTT and RTTVAR after backing off the timer multiple times, since the current estimates are likely bogus after repeated retransmissions; they should then be re-initialized using the next RTT sample per rule 2.2.
This document upgrades the RTO algorithm requirement from SHOULD (RFC 1122) to MUST, reflecting consensus that the Jacobson/Karels algorithm is the correct standard approach for TCP retransmission timing.
When using the TCP timestamp option, each ACK can be used as an RTT sample, removing the retransmission ambiguity that Karn's algorithm is designed to avoid.
A TCP MUST NOT be more aggressive than the algorithms defined in this document allow; implementations may be more conservative but not more aggressive.
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.
An implementation MUST manage retransmission timers such that a segment is never retransmitted less than one RTO after the previous transmission of that segment.
For subsequent RTT measurements R', hosts MUST update RTTVAR <- (1 - beta)*RTTVAR + beta*|SRTT - R'|, then SRTT <- (1 - alpha)*SRTT + alpha*R', in that order, with alpha=1/8 and beta=1/4 RECOMMENDED, followed by RTO <- SRTT + max(G, K*RTTVAR).
If the K*RTTVAR term in the RTO calculation equals zero, the variance term MUST be rounded to G seconds, ensuring RTO <- SRTT + max(G, K*RTTVAR).
TCP MUST use Karn's algorithm: RTT samples MUST NOT be taken from retransmitted segments (due to ambiguity about which transmission triggered the ACK), unless the TCP timestamp option is employed.
Until the first RTT measurement is made, the sender SHOULD set RTO to 3 seconds, with a lower bound of 2.5 seconds acceptable for heartbeat-timer implementations.
When the first RTT measurement R is made, the host MUST set SRTT <- R, RTTVAR <- R/2, RTO <- SRTT + max(G, K*RTTVAR) where K=4.
When the retransmission timer expires, the host MUST set RTO <- RTO * 2 (exponential backoff); the optional maximum value from section 2.5 may bound this doubling.
Whenever RTO is computed, if it is less than 1 second then the RTO SHOULD be rounded up to 1 second.
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.
An attacker can inflate RTO by adding artificial delay to packets or their ACKs; however, this attack provides little advantage over simply dropping packets, since the ability to delay typically implies the ability to drop.
An attacker could forge premature ACKs to lower the sender's RTO to an unsafe value, destabilizing the network; however, this requires spoofing on-path traffic, and the sender's exponential backoff on loss limits the damage.
Timer management: start timer (if not running) on every data send; stop timer when all outstanding data is acknowledged; restart timer on ACK of new data; on expiry, retransmit earliest unacknowledged segment, double RTO, and restart timer.