rfc3124.txt

RFC 的详细文档！

   audio delivered to its users at a consistent sampling rate.  As a
   result, it must send data a regular rate, minimizing delaying
   transmissions and reducing buffering before playback.  To meet these
   requirements, this application can use the synchronous sender API
   (Section 4.2).

   When the source first starts, it uses the cm_query() call to get an
   initial estimate of network bandwidth and delay.  If some other
   streams on that macroflow have already been active, then it gets an
   initial estimate that is valid; otherwise, it gets negative values,
   which it ignores.  It then chooses an encoding that does not exceed
   these estimates (or, in the case of an invalid estimate, uses
   application-specific initial values) and begins transmitting data.
   The application also implements the cmapp_update() callback.  When
   the CM determines that network characteristics have changed, it calls
   the application's cmapp_update() function and passes it a new rate
   and round-trip time estimate.  The application must change its choice
   of audio encoding to ensure that it does not exceed these new
   estimates.







Balakrishnan, et. al.       Standards Track                    [Page 17]

RFC 3124                 The Congestion Manager                June 2001


5.2 Example congestion control module

   To illustrate the responsibilities of a congestion control module,
   the following describes some of the actions of a simple TCP-like
   congestion control module that implements Additive Increase
   Multiplicative Decrease congestion control (AIMD_CC):

   - query(): AIMD_CC returns the current congestion window (cwnd)
     divided by the smoothed rtt (srtt) as its bandwidth estimate.  It
     returns the smoothed rtt estimate as srtt.

   - notify(): AIMD_CC adds the number of bytes sent to its
     outstanding data window (ownd).

   - update(): AIMD_CC subtracts nsent from ownd.  If the value of rtt
     is non-zero, AIMD_CC updates srtt using the TCP srtt calculation.
     If the update indicates that data has been lost, AIMD_CC sets
     cwnd to 1 MTU if the loss_mode is CM_NO_FEEDBACK and to cwnd/2
     (with a minimum of 1 MTU) if the loss_mode is CM_LOSS_FEEDBACK or
     CM_EXPLICIT_CONGESTION.  AIMD_CC also sets its internal ssthresh
     variable to cwnd/2.  If no loss had occurred, AIMD_CC mimics TCP
     slow start and linear growth modes.  It increments cwnd by nsent
     when cwnd < ssthresh (bounded by a maximum of ssthresh-cwnd) and
     by nsent * MTU/cwnd when cwnd > ssthresh.

   - When cwnd or ownd are updated and indicate that at least one MTU
     may be transmitted, AIMD_CC calls the CM to schedule a
     transmission.

5.3 Example Scheduler Module

   To clarify the responsibilities of a scheduler module, the following
   describes some of the actions of a simple round robin scheduler
   module (RR_sched):

   - schedule(): RR_sched schedules as many streams as possible in round
     robin fashion.

   - query_share(): RR_sched returns 1/(number of streams in macroflow).

   - notify(): RR_sched does nothing.  Round robin scheduling is not
     affected by the amount of data sent.

6. Security Considerations

   The CM provides many of the same services that the congestion control
   in TCP provides.  As such, it is vulnerable to many of the same
   security problems.  For example, incorrect reports of losses and



Balakrishnan, et. al.       Standards Track                    [Page 18]

RFC 3124                 The Congestion Manager                June 2001


   transmissions will give the CM an inaccurate picture of the network's
   congestion state.  By giving CM a high estimate of congestion, an
   attacker can degrade the performance observed by applications.  For
   example, a stream on a host can arbitrarily slow down any other
   stream on the same macroflow, a form of denial of service.

   The more dangerous form of attack occurs when an application gives
   the CM a low estimate of congestion.  This would cause CM to be
   overly aggressive and allow data to be sent much more quickly than
   sound congestion control policies would allow.

   [Touch97] describes a number of the security problems that arise with
   congestion information sharing.  An additional vulnerability (not
   covered by [Touch97])) occurs because applications have access
   through the CM API to control shared state that will affect other
   applications on the same computer.  For instance, a poorly designed,
   possibly a compromised, or intentionally malicious UDP application
   could misuse cm_update() to cause starvation and/or too-aggressive
   behavior of others in the macroflow.

7. References

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

   [Andersen00]      Balakrishnan, H., System Support for Bandwidth
                     Management and Content Adaptation in Internet
                     Applications, Proc. 4th Symp. on Operating Systems
                     Design and Implementation, San Diego, CA, October
                     2000.  Available from
                     http://nms.lcs.mit.edu/papers/cm-osdi2000.html

   [Balakrishnan98]  Balakrishnan, H., Padmanabhan, V., Seshan, S.,
                     Stemm, M., and Katz, R., "TCP Behavior of a Busy
                     Web Server:  Analysis and Improvements," Proc. IEEE
                     INFOCOM, San Francisco, CA, March 1998.

   [Balakrishnan99]  Balakrishnan, H., Rahul, H., and Seshan, S., "An
                     Integrated Congestion Management Architecture for
                     Internet Hosts," Proc. ACM SIGCOMM, Cambridge, MA,
                     September 1999.

   [Bradner96]       Bradner, S., "The Internet Standards Process ---
                     Revision 3", BCP 9, RFC 2026, October 1996.

   [Bradner97]       Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.




Balakrishnan, et. al.       Standards Track                    [Page 19]

RFC 3124                 The Congestion Manager                June 2001


   [Clark90]         Clark, D. and Tennenhouse, D., "Architectural
                     Consideration for a New Generation of Protocols",
                     Proc. ACM SIGCOMM, Philadelphia, PA, September
                     1990.

   [Eggert00]        Eggert, L., Heidemann, J., and Touch, J., "Effects
                     of Ensemble TCP," ACM Computer Comm. Review,
                     January 2000.

   [Floyd99a]        Floyd, S. and Fall, K.," Promoting the Use of End-
                     to-End Congestion Control in the Internet,"
                     IEEE/ACM Trans. on Networking, 7(4), August 1999,
                     pp. 458-472.

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

   [Jacobson88]      Jacobson, V., "Congestion Avoidance and Control,"
                     Proc. ACM SIGCOMM, Stanford, CA, August 1988.

   [Mahdavi98]       Mahdavi, J. and Floyd, S., "The TCP Friendly
                     Website,"
                     http://www.psc.edu/networking/tcp_friendly.html

   [Mogul90]         Mogul, J. and S. Deering, "Path MTU Discovery," RFC
                     1191, November 1990.

   [Padmanabhan98]   Padmanabhan, V., "Addressing the Challenges of Web
                     Data Transport," PhD thesis, Univ. of California,
                     Berkeley, December 1998.

   [Paxson00]        Paxson, V. and M. Allman, "Computing TCP's
                     Retransmission Timer", RFC 2988, November 2000.

   [Postel81]        Postel, J., Editor, "Transmission Control
                     Protocol", STD 7, RFC 793, September 1981.

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


   [Stevens94]       Stevens, W., TCP/IP Illustrated, Volume 1.
                     Addison-Wesley, Reading, MA, 1994.

   [Touch97]         Touch, J., "TCP Control Block Interdependence", RFC
                     2140, April 1997.



Balakrishnan, et. al.       Standards Track                    [Page 20]

RFC 3124                 The Congestion Manager                June 2001


8. Acknowledgments

   We thank David Andersen, Deepak Bansal, and Dorothy Curtis for their
   work on the CM design and implementation.  We thank Vern Paxson for
   his detailed comments, feedback, and patience, and Sally Floyd, Mark
   Handley, and Steven McCanne for useful feedback on the CM
   architecture.  Allison Mankin and Joe Touch provided several useful
   comments on previous drafts of this document.

9. Authors' Addresses

   Hari Balakrishnan
   Laboratory for Computer Science
   200 Technology Square
   Massachusetts Institute of Technology
   Cambridge, MA 02139

   EMail: [e-mail]
   Web: http://nms.lcs.mit.edu/~hari/


   Srinivasan Seshan
   School of Computer Science
   Carnegie Mellon University
   5000 Forbes Ave.
   Pittsburgh, PA 15213

   EMail: [e-mail]
   Web: http://www.cs.cmu.edu/~srini/






















Balakrishnan, et. al.       Standards Track                    [Page 21]

RFC 3124                 The Congestion Manager                June 2001


Full Copyright Statement

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



















Balakrishnan, et. al.       Standards Track                    [Page 22]