summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2988.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2988.txt')
-rw-r--r--doc/rfc/rfc2988.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc2988.txt b/doc/rfc/rfc2988.txt
new file mode 100644
index 0000000..2815ac8
--- /dev/null
+++ b/doc/rfc/rfc2988.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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]
+