Network Working Group V. Paxson
Request for Comments: 2988 ACIRI
Category: Standards Track M. Allman
NASA GRC/BBN
November 2000
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 Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
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 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
[APS99].
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
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 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
order.
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
RFC 2988 Computing TCP's Retransmission Timer November 2000
For fairly modest congestion window sizes research suggests that
timing each segment does not lead to a better RTT estimator [AP99].
Additionally, when multiple samples are taken per RTT the alpha and
beta defined in section 2 may keep an inadequate RTT history. A
method for changing these constants is currently an open research
question.
4 Clock Granularity
There is no requirement for the clock granularity G used for
computing RTT measurements and the different state variables.
However, if the K*RTTVAR term in the RTO calculation equals zero,
the variance term MUST be rounded to G seconds (i.e., use the
equation given in step 2.3).
RTO
RFC 2988 Computing TCP's Retransmission Timer November 2000
When the retransmission timer expires, do the following:
(5.4) Retransmit the earliest segment that has not been acknowledged
by the TCP receiver.
(5.5) The host MUST set RTO
RFC 2988 Computing TCP's Retransmission Timer November 2000
attacker can cause the sender's RTO to reach too small a value, it
appears the attacker cannot leverage this into much of an attack
(compared to the other damage they can do if they can spoof packets
belonging to the connection), since the sending TCP will still back
off its timer in the face of an incorrectly transmitted packet's
loss due to actual congestion.
Acknowledgments
The RTO algorithm described in this memo was originated by Van
Jacobson in [Jac88].
References
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network
Path Properties", SIGCOMM 99.
[APS99] Allman, M., Paxson V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[Bra89] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer
Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
[JK88] Jacobson, V. and M. Karels, "Congestion Avoidance and
Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", SIGCOMM 87.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
Paxson & Allman Standards Track [Page 6]
RFC 2988 Computing TCP's Retransmission Timer November 2000
Author's Addresses
Vern Paxson
ACIRI / ICSI
1947 Center Street
Suite 600
Berkeley, CA 94704-1198
Phone: 510-666-2882
Fax: 510-643-7684
EMail: vern@aciri.org
http://www.aciri.org/vern/
Mark Allman
NASA Glenn Research Center/BBN Technologies
Lewis Field
21000 Brookpark Rd. MS 54-2
Cleveland, OH 44135
Phone: 216-433-6586
Fax: 216-433-8705
EMail: mallman@grc.nasa.gov
http://roland.grc.nasa.gov/~mallman
Paxson & Allman Standards Track [Page 7]
RFC 2988 Computing TCP's Retransmission Timer November 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Paxson & Allman Standards Track [Page 8]