RFC 2988 (rfc2988) - Page 2 of 8
Computing TCP's Retransmission Timer
Alternative Format: Original Text Document
RFC 2988 Computing TCP's Retransmission Timer November 2000
In some situations it may be beneficial for a TCP sender to be more
conservative than the algorithms detailed in this document allow.
However, a TCP MUST NOT be more aggressive than the following
algorithms allow.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [Bra97].
2 The Basic Algorithm
To compute the current RTO, a TCP sender maintains two state
variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip
time variation). In addition, we assume a clock granularity of G
seconds.
The rules governing the computation of SRTT, RTTVAR, and RTO are as
follows:
(2.1) Until a round-trip time (RTT) measurement has been made for a
segment sent between the sender and receiver, the sender SHOULD
set RTO RFC 1122 [Bra89]), though the
"backing off" on repeated retransmission discussed in (5.5)
still applies.
Note that some implementations may use a "heartbeat" timer
that in fact yield a value between 2.5 seconds and 3
seconds. Accordingly, a lower bound of 2.5 seconds is also
acceptable, providing that the timer will never expire
faster than 2.5 seconds. Implementations using a heartbeat
timer with a granularity of G SHOULD not set the timer below
2.5 + G seconds.
(2.2) When the first RTT measurement R is made, the host MUST set
SRTT