doc: Add RFC documents

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]
+