Computing TCP's Retransmission Timer
RFC 6298
| Document | Type |
RFC - Proposed Standard
(June 2011; No errata)
Obsoletes RFC 2988
Updates RFC 1122
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | WG Document | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 6298 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Wesley Eddy | ||
| IESG note | Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. | ||
| Send notices to | (None) | ||
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
Show full document text