rfc2861.txt

RFC 的详细文档！

   Initially:
       T_last = tcpnow, T_prev = tcpnow, W_used = 0

   After sending a data segment:
       If tcpnow - T_last >= RTO
           (The sender has been idle.)
           ssthresh =  max(ssthresh, 3*cwnd/4)
           For i=1  To (tcpnow - T_last)/RTO
               win =  min(cwnd, receiver's declared max window)
               cwnd =  max(win/2, MSS)
           T_prev = tcpnow
           W_used = 0

       T_last = tcpnow

       If window is full
           T_prev = tcpnow
           W_used = 0
       Else
           If no more data is available to send
               W_used =  max(W_used, amount of unacknowledged data)
               If tcpnow - T_prev >= RTO
                   (The sender has been application-limited.)
                   ssthresh =  max(ssthresh, 3*cwnd/4)



Handley, et al.               Experimental                      [Page 6]

RFC 2861            TCP Congestion Window Validation           June 2000


                   win =  min(cwnd, receiver's declared max window)
                   cwnd = (win + W_used)/2
                   T_prev = tcpnow
                   W_used = 0

4. Simulations

   The CWV proposal has been implemented as an option in the network
   simulator NS [NS].  The simulations in the validation test suite for
   CWV can be run with the command "./test-all-tcp" in the directory
   "tcl/test".  The simulations show the use of CWV to reduce the
   congestion window after a period when the TCP connection was
   application-limited, and to limit the increase in the congestion
   window when a transfer is application-limited.  As the simulations
   illustrate, the use of ssthresh to maintain connection history is a
   critical part of the Congestion Window Validation algorithm.  [HPF99]
   discusses these simulations in more detail.

5. Experiments

   We have implemented the CWV mechanism in the TCP implementation in
   FreeBSD 3.2.  [HPF99] discusses these experiments in more detail.

   The first experiment examines the effects of the Congestion Window
   Validation mechanisms for limiting cwnd increases during
   application-limited periods.  The experiment used a real ssh
   connection through a modem link emulated using Dummynet [Dummynet].
   The link speed is 30Kb/s and the link has five packet buffers
   available.  Today most modem banks have more buffering available than
   this, but the more buffer-limited situation sometimes occurs with
   older modems.  In the first half of the transfer, the user is typing
   away over the connection.  About half way through the time, the user
   lists a moderately large file, which causes a large burst of traffic
   to be transmitted.

   For the unmodified TCP, every returning ACK during the first part of
   the transfer results in an increase in cwnd.  As a result, the large
   burst of data arriving from the application to the transport layer is
   sent as many back-to-back packets, most of which get lost and
   subsequently retransmitted.

   For the modified TCP with Congestion Window Validation, the
   congestion window is not increased when the window is not full, and
   has been decreased during application-limited periods closer to what
   the user actually used.  The burst of traffic is now constrained by
   the congestion window, resulting in a better-behaved flow with





Handley, et al.               Experimental                      [Page 7]

RFC 2861            TCP Congestion Window Validation           June 2000


   minimal loss.  The end result is that the transfer happens
   approximately 30% faster than the transfer without CWV, due to
   avoiding retransmission timeouts.

   The second experiment uses a real ssh connection over a real dialup
   ppp connection, where the modem bank has much more buffering.  For
   the unmodified TCP, the initial burst from the large file does not
   cause loss, but does cause the RTT to increase to approximately 5
   seconds, where the connection becomes bounded by the receiver's
   window.

   For the modified TCP with Congestion Window Validation, the flow is
   much better behaved, and produces no large burst of traffic.  In this
   case the linear increase for cwnd results in a slow increase in the
   RTT as the buffer slowly fills.

   For the second experiment, both the modified and the unmodified TCP
   finish delivering the data at precisely the same time.  This is
   because the link has been fully utilized in both cases due to the
   modem buffer being larger than the receiver window.  Clearly a modem
   buffer of this size is undesirable due to its effect on the RTT of
   competing flows, but it is necessary with current TCP implementations
   that produce bursts similar to those shown in the top graph.

6. Conclusions

   This document has presented several TCP algorithms for Congestion
   Window Validation, to be employed after an idle period or a period in
   which the sender was application-limited, and before an increase of
   the congestion window.  The goal of these algorithms is for TCP's
   congestion window to reflect recent knowledge of the TCP connection
   about the state of the network path, while at the same time keeping
   some memory (i.e., in ssthresh) about the earlier state of the path.
   We believe that these modifications will be of benefit to both the
   network and to the TCP flows themselves, by preventing unnecessary
   packet drops due to the TCP sender's failure to update its
   information (or lack of information) about current network
   conditions.  Future work will document and investigate the benefit
   provided by these algorithms, using both simulations and experiments.
   Additional future work will describe a more complex version of the
   CWV algorithm for TCP implementations where the sender does not have
   an accurate estimate of the TCP roundtrip time.









Handley, et al.               Experimental                      [Page 8]

RFC 2861            TCP Congestion Window Validation           June 2000


7. References

   [FF96]     Fall, K., and Floyd, S., Simulation-based Comparisons of
              Tahoe, Reno, and SACK TCP, Computer Communication Review,
              V. 26 N. 3, July 1996, pp. 5-21.  URL
              "http://www.aciri.org/floyd/papers.html".

   [HPF99]    Mark Handley, Jitendra Padhye, Sally Floyd, TCP Congestion
              Window Validation, UMass CMPSCI Technical Report 99-77,
              September 1999.  URL "ftp://www-
              net.cs.umass.edu/pub/Handley99-tcpq-tr-99-77.ps.gz".

   [HTH98]    Amy Hughes, Joe Touch, John Heidemann, "Issues in TCP
              Slow-Start Restart After Idle", Work in Progress.

   [J88]      Jacobson, V., Congestion Avoidance and Control, Originally
              from Proceedings of SIGCOMM '88 (Palo Alto, CA, Aug.
              1988), and revised in 1992.  URL "http://www-
              nrg.ee.lbl.gov/nrg-papers.html".

   [JKBFL96]  Raj Jain, Shiv Kalyanaraman, Rohit Goyal, Sonia Fahmy, and
              Fang Lu, Comments on "Use-it or Lose-it", ATM Forum
              Document Number:  ATM Forum/96-0178, URL
              "http://www.netlab.ohio-
              state.edu/~jain/atmf/af_rl5b2.htm".

   [JKGFL95]  R. Jain, S. Kalyanaraman, R. Goyal, S. Fahmy, and F. Lu, A
              Fix for Source End System Rule 5, AF-TM 95-1660, December
              1995, URL "http://www.netlab.ohio-
              state.edu/~jain/atmf/af_rl52.htm".

   [MSML99]   Matt Mathis, Jeff Semke, Jamshid Mahdavi, and Kevin Lahey,
              The Rate-Halving Algorithm for TCP Congestion Control,
              June 1999.  URL
              "http://www.psc.edu/networking/ftp/papers/draft-
              ratehalving.txt".

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

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

   [VH97]     Vikram Visweswaraiah and John Heidemann. Improving Restart
              of Idle TCP Connections, Technical Report 97-661,
              University of Southern California, November, 1997.





Handley, et al.               Experimental                      [Page 9]

RFC 2861            TCP Congestion Window Validation           June 2000


   [Dummynet] Luigi Rizzo, "Dummynet and Forward Error Correction",
              Freenix 98, June 1998, New Orleans.  URL
              "http://info.iet.unipi.it/~luigi/ip_dummynet/".

8. Security Considerations

   General security considerations concerning TCP congestion control are
   discussed in RFC 2581.  This document describes a algorithm for one
   aspect of those congestion control procedures, and so the
   considerations described in RFC 2581 apply to this algorithm also.
   There are no known additional security concerns for this specific
   algorithm.

9. Authors' Addresses

   Mark Handley
   AT&T Center for Internet Research at ICSI (ACIRI)

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


   Jitendra Padhye
   AT&T Center for Internet Research at ICSI (ACIRI)

   Phone: [phone]
   EMail: [e-mail]
   URL: http://www-net.cs.umass.edu/~jitu/


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

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














Handley, et al.               Experimental                     [Page 10]

RFC 2861            TCP Congestion Window Validation           June 2000


10. 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.



















Handley, et al.               Experimental                     [Page 11]