Computing TCP's Retransmission Timer
RFC 6298

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Internet Engineering Task Force (IETF)                         V. Paxson
Request for Comments: 6298                              ICSI/UC Berkeley
Obsoletes: 2988                                                M. Allman
Updates: 1122                                                       ICSI
Category: Standards Track                                         J. Chu
ISSN: 2070-1721                                                   Google
                                                              M. Sargent
                                                                    CWRU
                                                               June 2011

                  Computing TCP's Retransmission Timer

Abstract

   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 4.2.3.1 of RFC 1122 and upgrades the requirement of
   supporting the algorithm from a SHOULD to a MUST.  This document
   obsoletes RFC 2988.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6298.

Paxson, et al.               Standards Track                    [Page 1]
RFC 6298          Computing TCP's Retransmission Timer         June 2011

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   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 4.2.3.1
   of RFC 1122 and upgrades the requirement of supporting the algorithm
   from a SHOULD to a MUST.  RFC 5681 [APB09] 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 5681
   [APB09].

   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.  This document obsoletes RFC 2988 [PA00].

   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.

Paxson, et al.               Standards Track                    [Page 2]
RFC 6298          Computing TCP's Retransmission Timer         June 2011

   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 <- 1 second, though the "backing off" on repeated
         retransmission discussed in (5.5) still applies.

         Note that the previous version of this document used an initial
         RTO of 3 seconds [PA00].  A TCP implementation MAY still use
         this value (or any other value > 1 second).  This change in the
         lower bound on the initial RTO is discussed in further detail
         in Appendix A.

   (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)