Network Working Group V. Paxson
Request for Comments: 2988 ACIRI
Category: Standards Track M. Allman
Computing TCP's Retransmission Timer
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document defines the standard algorithm that Transmission
Control Protocol (TCP) senders are required to use to compute and
manage their retransmission timer. It expands on the discussion in
section 184.108.40.206 of RFC 1122 and upgrades the requirement of
supporting the algorithm from a SHOULD to a MUST.
The Transmission Control Protocol (TCP) [Pos81] uses a retransmission
timer to ensure data delivery in the absence of any feedback from the
remote data receiver. The duration of this timer is referred to as
RTO (retransmission timeout). RFC 1122 [Bra89] specifies that the
RTO should be calculated as outlined in [Jac88].
This document codifies the algorithm for setting the RTO. In
addition, this document expands on the discussion in section 220.127.116.11
of RFC 1122 and upgrades the requirement of supporting the algorithm
from a SHOULD to a MUST. RFC 2581 [APS99] outlines the algorithm TCP
uses to begin sending after the RTO expires and a retransmission is
sent. This document does not alter the behavior outlined in RFC 2581
Paxson & Allman Standards Track [Page 1]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
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
The rules governing the computation of SRTT, RTTVAR, and RTO are as
(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 <- 3 seconds (per RFC 1122 [Bra89]), though the
"backing off" on repeated retransmission discussed in (5.5)
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 <- R
RTTVAR <- R/2
RTO <- SRTT + max (G, K*RTTVAR)
where K = 4.
(2.3) When a subsequent RTT measurement R' is made, a host MUST set
RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
SRTT <- (1 - alpha) * SRTT + alpha * R'
Paxson & Allman Standards Track [Page 2]RFC 2988 Computing TCP's Retransmission Timer November 2000
The value of SRTT used in the update to RTTVAR is its value
before updating SRTT itself using the second assignment. That
is, updating RTTVAR and SRTT MUST be computed in the above
The above SHOULD be computed using alpha=1/8 and beta=1/4 (as
suggested in [JK88]).
After the computation, a host MUST update
RTO <- SRTT + max (G, K*RTTVAR)
(2.4) Whenever RTO is computed, if it is less than 1 second then the