rfc2988.txt

计算机网络的课件Courseware for computer networks

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: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   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: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   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]