rfc2914.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   [RFC2357]    Mankin, A., Romanow, A., Bradner, S. and V. Paxson,
                "IETF Criteria for Evaluating Reliable Multicast
                Transport and Application Protocols", RFC 2357, June
                1998.

   [RFC2414]    Allman, M., Floyd, S. and C. Partridge, "Increasing
                TCP's Initial Window", RFC 2414, September 1998.

   [RFC2475]    Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
                and W.  Weiss, "An Architecture for Differentiated
                Services", RFC 2475, December 1998.

   [RFC2481]    Ramakrishnan K. and S. Floyd, "A Proposal to add
                Explicit Congestion Notification (ECN) to IP", RFC 2481,
                January 1999.

   [RFC2525]    Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner,
                J., Heavens, I., Lahey, K., Semke, J. and B. Volz,
                "Known TCP Implementation Problems", RFC 2525, March
                1999.

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

   [RFC2582]    Floyd, S. and T. Henderson, "The NewReno Modification to
                TCP's Fast Recovery Algorithm", RFC 2582, April 1999.

   [RFC2616]    Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
                Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.




Floyd, ed.               Best Current Practice                 [Page 12]

RFC 2914             Congestion Control Principles        September 2000


   [SCWA99]     S. Savage, N. Cardwell, D. Wetherall, and T. Anderson,
                TCP Congestion Control with a Misbehaving Receiver, ACM
                Computer Communications Review, October 1999.

   [TCPB98]     Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan
                Seshan, Mark Stemm, and Randy H. Katz, TCP Behavior of a
                Busy Internet Server: Analysis and Improvements, IEEE
                Infocom, March 1998.  Available from:
                "http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz".

   [TCPF98]     Dong Lin and H.T. Kung, TCP Fast Recovery Strategies:
                Analysis and Improvements, IEEE Infocom, March 1998.
                Available from:
                "http://www.eecs.harvard.edu/networking/papers/infocom-
                tcp-final-198.pdf".

9.  TCP-Specific issues

   In this section we discuss some of the particulars of TCP congestion
   control, to illustrate a realization of the congestion control
   principles, including some of the details that arise when
   incorporating them into a production transport protocol.

9.1.  Slow-start.

   The TCP sender can not open a new connection by sending a large burst
   of data (e.g., a receiver's advertised window) all at once.  The TCP
   sender is limited by a small initial value for the congestion window.
   During slow-start, the TCP sender can increase its sending rate by at
   most a factor of two in one roundtrip time.  Slow-start ends when
   congestion is detected, or when the sender's congestion window is
   greater than the slow-start threshold ssthresh.

   An issue that potentially affects global congestion control, and
   therefore has been explicitly addressed in the standards process,
   includes an increase in the value of the initial window
   [RFC2414,RFC2581].

   Issues that have not been addressed in the standards process, and are
   generally considered not to require standardization, include such
   issues as the use (or non-use) of rate-based pacing, and mechanisms
   for ending slow-start early, before the congestion window reaches
   ssthresh.  Such mechanisms result in slow-start behavior that is as
   conservative or more conservative than standard TCP.







Floyd, ed.               Best Current Practice                 [Page 13]

RFC 2914             Congestion Control Principles        September 2000


9.2.  Additive Increase, Multiplicative Decrease.

   In the absence of congestion, the TCP sender increases its congestion
   window by at most one packet per roundtrip time. In response to a
   congestion indication, the TCP sender decreases its congestion window
   by half.  (More precisely, the new congestion window is half of the
   minimum of the congestion window and the receiver's advertised
   window.)

   An issue that potentially affects global congestion control, and
   therefore would be likely to be explicitly addressed in the standards
   process, would include a proposed addition of congestion control for
   the return stream of `pure acks'.

   An issue that has not been addressed in the standards process, and is
   generally not considered to require standardization, would be a
   change to the congestion window to apply as an upper bound on the
   number of bytes presumed to be in the pipe, instead of applying as a
   sliding window starting from the cumulative acknowledgement.
   (Clearly, the receiver's advertised window applies as a sliding
   window starting from the cumulative acknowledgement field, because
   packets received above the cumulative acknowledgement field are held
   in TCP's receive buffer, and have not been delivered to the
   application.  However, the congestion window applies to the number of
   packets outstanding in the pipe, and does not necessarily have to
   include packets that have been received out-of-order by the TCP
   receiver.)

9.3.  Retransmit timers.

   The TCP sender sets a retransmit timer to infer that a packet has
   been dropped in the network.  When the retransmit timer expires, the
   sender infers that a packet has been lost, sets ssthresh to half of
   the current window, and goes into slow-start, retransmitting the lost
   packet.  If the retransmit timer expires because no acknowledgement
   has been received for a retransmitted packet, the retransmit timer is
   also "backed-off", doubling the value of the next retransmit timeout
   interval.

   An issue that potentially affects global congestion control, and
   therefore would be likely to be explicitly addressed in the standards
   process, might include a modified mechanism for setting the
   retransmit timer that could significantly increase the number of
   retransmit timers that expire prematurely, when the acknowledgement
   has not yet arrived at the sender, but in fact no packets have been
   dropped.  This could be of concern to the Internet standards process





Floyd, ed.               Best Current Practice                 [Page 14]

RFC 2914             Congestion Control Principles        September 2000


   because retransmit timers that expire prematurely could lead to an
   increase in the number of packets unnecessarily transmitted on a
   congested link.

9.4.  Fast Retransmit and Fast Recovery.

   After seeing three duplicate acknowledgements, the TCP sender infers
   a packet loss.  The TCP sender sets ssthresh to half of the current
   window, reduces the congestion window to at most half of the previous
   window, and retransmits the lost packet.

   An issue that potentially affects global congestion control, and
   therefore would be likely to be explicitly addressed in the standards
   process, might include a proposal (if there was one) for inferring a
   lost packet after only one or two duplicate acknowledgements.  If
   poorly designed, such a proposal could lead to an increase in the
   number of packets unnecessarily transmitted on a congested path.

   An issue that has not been addressed in the standards process, and
   would not be expected to require standardization, would be a proposal
   to send a "new" or presumed-lost packet in response to a duplicate or
   partial acknowledgement, if allowed by the congestion window.  An
   example of this would be sending a new packet in response to a single
   duplicate acknowledgement, to keep the `ack clock' going in case no
   further acknowledgements would have arrived.  Such a proposal is an
   example of a beneficial change that does not involve interoperability
   and does not affect global congestion control, and that therefore
   could be implemented by vendors without requiring the intervention of
   the IETF standards process.  (This issue has in fact been addressed
   in [DMKM00], which suggests that "researchers may wish to experiment
   with injecting new traffic into the network when duplicate
   acknowledgements are being received, as described in [TCPB98] and
   [TCPF98]."

9.5.  Other aspects of TCP congestion control.

   Other aspects of TCP congestion control that have not been discussed
   in any of the sections above include TCP's recovery from an idle or
   application-limited period [HPF00].

10. Security Considerations

   This document has been about the risks associated with congestion
   control, or with the absence of congestion control.  Section 3.2
   discusses the potentials for unfairness if competing flows don't use
   compatible congestion control mechanisms, and Section 5 considers the
   dangers of congestion collapse if flows don't use end-to-end
   congestion control.



Floyd, ed.               Best Current Practice                 [Page 15]

RFC 2914             Congestion Control Principles        September 2000


   Because this document does not propose any specific congestion
   control mechanisms, it is also not necessary to present specific
   security measures associated with congestion control.  However, we
   would note that there are a range of security considerations
   associated with congestion control that should be considered in IETF
   documents.

   For example, individual congestion control mechanisms should be as
   robust as possible to the attempts of individual end-nodes to subvert
   end-to-end congestion control [SCWA99].  This is a particular concern
   in multicast congestion control, because of the far-reaching
   distribution of the traffic and the greater opportunities for
   individual receivers to fail to report congestion.

   RFC 2309 also discussed the potential dangers to the Internet of
   unresponsive flows, that is, flows that don't reduce their sending
   rate in the presence of congestion, and describes the need for
   mechanisms in the network to deal with flows that are unresponsive to
   congestion notification.  We would note that there is still a need
   for research, engineering, measurement, and deployment in these
   areas.

   Because the Internet aggregates very large numbers of flows, the risk
   to the whole infrastructure of subverting the congestion control of a
   few individual flows is limited.  Rather, the risk to the
   infrastructure would come from the widespread deployment of many
   end-nodes subverting end-to-end congestion control.

AUTHOR'S ADDRESS

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

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















Floyd, ed.               Best Current Practice                 [Page 16]

RFC 2914             Congestion Control Principles        September 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.



















Floyd, ed.               Best Current Practice                 [Page 17]