RFC 2988 (rfc2988) - Page 2 of 8

Computing TCP's Retransmission Timer

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