452 lines
15 KiB
Plaintext
452 lines
15 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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 <- 3 seconds (per 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 <- 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
|
||
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 <- SRTT + max (G, K*RTTVAR)
|
||
|
||
(2.4) Whenever RTO is computed, if it is less than 1 second then the
|
||
RTO SHOULD be rounded up to 1 second.
|
||
|
||
Traditionally, TCP implementations use coarse grain clocks to
|
||
measure the RTT and trigger the RTO, which imposes a large
|
||
minimum value on the RTO. Research suggests that a large
|
||
minimum RTO is needed to keep TCP conservative and avoid
|
||
spurious retransmissions [AP99]. Therefore, this
|
||
specification requires a large minimum RTO as a conservative
|
||
approach, while at the same time acknowledging that at some
|
||
future point, research may show that a smaller minimum RTO is
|
||
acceptable or superior.
|
||
|
||
(2.5) A maximum value MAY be placed on RTO provided it is at least 60
|
||
seconds.
|
||
|
||
3 Taking RTT Samples
|
||
|
||
TCP MUST use Karn's algorithm [KP87] for taking RTT samples. That
|
||
is, RTT samples MUST NOT be made using segments that were
|
||
retransmitted (and thus for which it is ambiguous whether the reply
|
||
was for the first instance of the packet or a later instance). The
|
||
only case when TCP can safely take RTT samples from retransmitted
|
||
segments is when the TCP timestamp option [JBB92] is employed, since
|
||
the timestamp option removes the ambiguity regarding which instance
|
||
of the data segment triggered the acknowledgment.
|
||
|
||
Traditionally, TCP implementations have taken one RTT measurement at
|
||
a time (typically once per RTT). However, when using the timestamp
|
||
option, each ACK can be used as an RTT sample. RFC 1323 [JBB92]
|
||
suggests that TCP connections utilizing large congestion windows
|
||
should take many RTT samples per window of data to avoid aliasing
|
||
effects in the estimated RTT. A TCP implementation MUST take at
|
||
least one RTT measurement per RTT (unless that is not possible per
|
||
Karn's algorithm).
|
||
|
||
|
||
|
||
|
||
|
||
Paxson & Allman Standards Track [Page 3]
|
||
|
||
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 <- SRTT + max (G, K*RTTVAR)
|
||
|
||
Experience has shown that finer clock granularities (<= 100 msec)
|
||
perform somewhat better than more coarse granularities.
|
||
|
||
Note that [Jac88] outlines several clever tricks that can be used to
|
||
obtain better precision from coarse granularity timers. These
|
||
changes are widely implemented in current TCP implementations.
|
||
|
||
5 Managing the RTO Timer
|
||
|
||
An implementation MUST manage the retransmission timer(s) in such a
|
||
way that a segment is never retransmitted too early, i.e. less than
|
||
one RTO after the previous transmission of that segment.
|
||
|
||
The following is the RECOMMENDED algorithm for managing the
|
||
retransmission timer:
|
||
|
||
(5.1) Every time a packet containing data is sent (including a
|
||
retransmission), if the timer is not running, start it running
|
||
so that it will expire after RTO seconds (for the current value
|
||
of RTO).
|
||
|
||
(5.2) When all outstanding data has been acknowledged, turn off the
|
||
retransmission timer.
|
||
|
||
(5.3) When an ACK is received that acknowledges new data, restart the
|
||
retransmission timer so that it will expire after RTO seconds
|
||
(for the current value of RTO).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Paxson & Allman Standards Track [Page 4]
|
||
|
||
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 <- RTO * 2 ("back off the timer"). The
|
||
maximum value discussed in (2.5) above may be used to provide an
|
||
upper bound to this doubling operation.
|
||
|
||
(5.6) Start the retransmission timer, such that it expires after RTO
|
||
seconds (for the value of RTO after the doubling operation
|
||
outlined in 5.5).
|
||
|
||
Note that after retransmitting, once a new RTT measurement is
|
||
obtained (which can only happen when new data has been sent and
|
||
acknowledged), the computations outlined in section 2 are performed,
|
||
including the computation of RTO, which may result in "collapsing"
|
||
RTO back down after it has been subject to exponential backoff
|
||
(rule 5.5).
|
||
|
||
Note that a TCP implementation MAY clear SRTT and RTTVAR after
|
||
backing off the timer multiple times as it is likely that the
|
||
current SRTT and RTTVAR are bogus in this situation. Once SRTT and
|
||
RTTVAR are cleared they should be initialized with the next RTT
|
||
sample taken per (2.2) rather than using (2.3).
|
||
|
||
6 Security Considerations
|
||
|
||
This document requires a TCP to wait for a given interval before
|
||
retransmitting an unacknowledged segment. An attacker could cause a
|
||
TCP sender to compute a large value of RTO by adding delay to a
|
||
timed packet's latency, or that of its acknowledgment. However,
|
||
the ability to add delay to a packet's latency often coincides with
|
||
the ability to cause the packet to be lost, so it is difficult to
|
||
see what an attacker might gain from such an attack that could cause
|
||
more damage than simply discarding some of the TCP connection's
|
||
packets.
|
||
|
||
The Internet to a considerable degree relies on the correct
|
||
implementation of the RTO algorithm (as well as those described in
|
||
RFC 2581) in order to preserve network stability and avoid
|
||
congestion collapse. An attacker could cause TCP endpoints to
|
||
respond more aggressively in the face of congestion by forging
|
||
acknowledgments for segments before the receiver has actually
|
||
received the data, thus lowering RTO to an unsafe value. But to do
|
||
so requires spoofing the acknowledgments correctly, which is
|
||
difficult unless the attacker can monitor traffic along the path
|
||
between the sender and the receiver. In addition, even if the
|
||
|
||
|
||
|
||
Paxson & Allman Standards Track [Page 5]
|
||
|
||
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]
|
||
|