rfc2582.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页


RFC 2582      NewReno Modification to TCP's Fast Recovery     April 1999


   called "bugfix" in [F98], and is illustrated on pages 7 and 9.)  This
   modification uses a new variable "send_high", whose initial value is
   the initial send sequence number.  After each retransmit timeout, the
   highest sequence numbers transmitted so far is recorded in the
   variable "send_high".


   If, after a retransmit timeout, the TCP data sender retransmits three
   consecutive packets that have already been received by the data
   receiver, then the TCP data sender will receive three duplicate
   acknowledgements that do not acknowledge "send_high".  In this case,
   the duplicate acknowledgements are not an indication of a new
   instance of congestion.  They are simply an indication that the
   sender has unnecessarily retransmitted at least three packets.

   We note that if the TCP data sender receives three duplicate
   acknowledgements that do not acknowledge "send_high", the sender does
   not know whether these duplicate acknowledgements resulted from a new
   packet drop or not.  For a TCP that implements the bugfix described
   in this section for avoiding multiple fast retransmits, the sender
   does not infer a packet drop from duplicate acknowledgements in these
   circumstances.  As always, the retransmit timer is the backup
   mechanism for inferring packet loss in this case.

   The modification to Fast Retransmit for avoiding multiple Fast
   Retransmits replaces Step 1 in Section 3 with Step 1A below.  In
   addition, the modification adds Step 6 below:

   1A. When the third duplicate ACK is received and the sender is not
       already in the Fast Recovery procedure, check to see if those
       duplicate ACKs cover more than "send_high".  If they do, then set
       ssthresh to no more than the value given in equation 1, record
       the the highest sequence number transmitted in the variable
       "recover", and go to Step 2.  If the duplicate ACKs don't cover
       "send_high", then do nothing.  That is, do not enter the Fast
       Retransmit and Fast Recovery procedure, do not change ssthresh,
       do not go to Step 2 to retransmit the "lost" segment, and do not
       execute Step 3 upon subsequent duplicate ACKs.

   Steps 2-5 are the same as those steps in Section 3 above.

   6.  After a retransmit timeout, record the highest sequence number
       transmitted in the variable "send_high" and exit the Fast
       Recovery procedure if applicable.

   Step 1A above, in checking whether the duplicate ACKs cover *more*
   than "send_high", is the Careful variant of this algorithm.  Another
   possible variant would be to require simply that the three duplicate



Floyd & Henderson             Experimental                      [Page 7]

RFC 2582      NewReno Modification to TCP's Fast Recovery     April 1999


   acknowledgements *cover* "send_high" before initiating another Fast
   Retransmit.  We call this the Less Careful variant to Fast
   Retransmit.

   There are two separate scenarios in which the TCP sender could
   receive three duplicate acknowledgements acknowledging "send_high"
   but no more than "send_high".  One scenario would be that the data
   sender transmitted four packets with sequence numbers higher than
   "send_high", that the first packet was dropped in the network, and
   the following three packets triggered three duplicate
   acknowledgements acknowledging "send_high".  The second scenario
   would be that the sender unnecessarily retransmitted three packets
   below "send_high", and that these three packets triggered three
   duplicate acknowledgements acknowledging "send_high".  In the absence
   of SACK, the TCP sender in unable to distinguish between these two
   scenarios.

   For the Careful variant of Fast Retransmit, the data sender would
   have to wait for a retransmit timeout in the first scenario, but
   would not have an unnecessary Fast Retransmit in the second scenario.
   For the Less Careful variant to Fast Retransmit, the data sender
   would Fast Retransmit as desired in the first scenario, and would
   unnecessarily Fast Retransmit in the second scenario.  The NS
   simulator has implemented the Less Careful variant of NewReno, and
   the TCP implementation in Sun's Solaris 7 implements the Careful
   variant.  This document recommends the Careful variant given in Step
   1A above.

6. Implementation issues for the data receiver.

   [RFC2001] specifies that "Out-of-order data segments SHOULD be
   acknowledged immediately, in order to trigger the fast retransmit
   algorithm." Neal Cardwell has noted [C98] that some data receivers do
   not send an immediate acknowledgement when they send a partial
   acknowledgment, but instead wait first for their delayed
   acknowledgement timer to expire.  As [C98] notes, this severely
   limits the potential benefit from NewReno by delaying the receipt of
   the partial acknowledgement at the data sender.  Our recommendation
   is that the data receiver send an immediate acknowledgement for an
   out-of-order segment, even when that out-of-order segment fills a
   hole in the buffer.

7. Simulations

   Simulations with NewReno are illustrated with the validation test
   "tcl/test/test-all-newreno" in the NS simulator.  The command
   "../../ns test-suite-newreno.tcl reno" shows a simulation with Reno
   TCP, illustrating the data sender's lack of response to a partial



Floyd & Henderson             Experimental                      [Page 8]

RFC 2582      NewReno Modification to TCP's Fast Recovery     April 1999


   acknowledgement.  In contrast, the command "../../ns test-suite-
   newreno.tcl newreno_B" shows a simulation with the same scenario
   using the NewReno algorithms described in this paper.

   The tests "../../ns test-suite-newreno.tcl newreno1_B0" and "../../ns
   test-suite-newreno.tcl newreno1_B" show the Slow-but-Steady and the
   Impatient variants of NewReno, respectively.

8. Conclusions

   Our recommendation is that TCP implementations include the NewReno
   modification to the Fast Recovery algorithm given in Section 3, along
   with the modification for avoiding multiple Fast Retransmits given in
   Section 5.  The NewReno modification given in Section 3 can be
   important even for TCP implementations that support the SACK option,
   because the SACK option can only be used for TCP connections when
   both TCP end-nodes support the SACK option.  The NewReno modification
   given in Section 3 implements the Impatient rather than the Slow-but-
   Steady variant of NewReno.

   While this document mentions several possible variations to the
   NewReno algorithm, we have not explored all of these possible
   variations, and therefore are unable to make recommendations about
   some of them.  Our belief is that the differences between any two
   variants of NewReno are small compared to the differences between
   Reno and NewReno.  That is, the important thing is to implement
   NewReno instead of Reno, for a TCP invocation without SACK; it is
   less important exactly which variant of NewReno is implemented.

9. Acknowledgements

   Many thanks to Anil Agarwal, Mark Allman, Vern Paxson, Kacheong Poon,
   and Bernie Volz for detailed feedback on this document.

10. References

   [C98]         Neal Cardwell, "delayed ACKs for retransmitted packets:
                 ouch!". November 1998.  Email to the tcpimpl mailing
                 list, Message-ID "Pine.LNX.4.02A.9811021421340.26785-
                 [e-mail]", archived at
                 "http://tcp-impl.lerc.nasa.gov/tcp-impl".

   [F98]         Sally Floyd.  Revisions to RFC 2001.  Presentation to
                 the TCPIMPL Working Group, August 1998.  URLs
                 "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" and
                 "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf".

   [FF96]        Kevin Fall and Sally Floyd.  Simulation-based



Floyd & Henderson             Experimental                      [Page 9]

RFC 2582      NewReno Modification to TCP's Fast Recovery     April 1999


                 Comparisons of Tahoe, Reno and SACK TCP.  Computer
                 Communication Review, July 1996.  URL
                 "ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z".

   [Flo94]       S. Floyd, TCP and Successive Fast Retransmits.
                 Technical report, October 1994.  URL
                 "ftp://ftp.ee.lbl.gov/papers/fastretrans.ps".

   [Hen98]       Tom Henderson, Re: NewReno and the 2001 Revision.
                 September 1998.  Email to the tcpimpl mailing list,
                 Message ID "Pine.BSI.3.95.980923224136.26134A-
                 [e-mail]", archived at
                 "http://tcp-impl.lerc.nasa.gov/tcp-impl".

   [Hoe95]       J. Hoe, Startup Dynamics of TCP's Congestion Control
                 and Avoidance Schemes. Master's Thesis, MIT, 1995.  URL
                 "http://ana-www.lcs.mit.edu/anaweb/ps-papers/hoe-
                 thesis.ps".

   [Hoe96]       J. Hoe, "Improving the Start-up Behavior of a
                 Congestion Control Scheme for TCP",  In ACM SIGCOMM,
                 August 1996.  URL
                 "http://www.acm.org/sigcomm/sigcomm96/program.html".


   [HTH98]       Hughes, A., Touch, J.  and J. Heidemann, "Issues in TCP
                 Slow-Start Restart After Idle", Work in Progress, March
                 1998.

   [LM97]        Dong Lin and Robert Morris, "Dynamics of Random Early
                 Detection", SIGCOMM 97, September 1997.  URL
                 "http://www.acm.org/sigcomm/sigcomm97/program.html".

   [MMFR96]      Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
                 Selective Acknowledgement Options", RFC 2018, October
                 1996.

   [NS]          The UCB/LBNL/VINT Network Simulator (NS). URL
                 "http://www-mash.cs.berkeley.edu/ns/".

   [RFC2001]     Stevens, W., "TCP Slow Start, Congestion Avoidance,
                 Fast Retransmit, and Fast Recovery Algorithms", RFC
                 2001, January 1997.

   [RFC2581]     Stevens, W., Allman, M. and V. Paxson, "TCP Congestion
                 Control", RFC 2581, April 1999.





Floyd & Henderson             Experimental                     [Page 10]

RFC 2582      NewReno Modification to TCP's Fast Recovery     April 1999


11. Security Considerations

   RFC 2581 discusses general security considerations concerning TCP
   congestion control.  This document describes a specific algorithm
   that conforms with the congestion control requirements of RFC 2581,
   and so those considerations apply to this algorithm, too.  There are
   no known additional security concerns for this specific algorithm.

12. AUTHORS' ADDRESSES

   Sally Floyd
   AT&T Center for Internet Research at ICSI (ACIRI)

   Phone: [phone] x189
   EMail: [e-mail]
   URL:  http://www.aciri.org/floyd/


   Tom Henderson
   University of California at Berkeley

   Phone: [phone]
   EMail: [e-mail]
   URL: http://www.cs.berkeley.edu/~tomh/



























Floyd & Henderson             Experimental                     [Page 11]

RFC 2582      NewReno Modification to TCP's Fast Recovery     April 1999


13.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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.
























Floyd & Henderson             Experimental                     [Page 12]