summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5033.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5033.txt')
-rw-r--r--doc/rfc/rfc5033.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc5033.txt b/doc/rfc/rfc5033.txt
new file mode 100644
index 0000000..67fb08c
--- /dev/null
+++ b/doc/rfc/rfc5033.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group S. Floyd
+Request for Comments: 5033 M. Allman
+BCP: 133 ICIR / ICSI
+Category: Best Current Practice August 2007
+
+
+ Specifying New Congestion Control Algorithms
+
+Status of This Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Abstract
+
+ The IETF's standard congestion control schemes have been widely shown
+ to be inadequate for various environments (e.g., high-speed
+ networks). Recent research has yielded many alternate congestion
+ control schemes that significantly differ from the IETF's congestion
+ control principles. Using these new congestion control schemes in
+ the global Internet has possible ramifications to both the traffic
+ using the new congestion control and to traffic using the currently
+ standardized congestion control. Therefore, the IETF must proceed
+ with caution when dealing with alternate congestion control
+ proposals. The goal of this document is to provide guidance for
+ considering alternate congestion control algorithms within the IETF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Floyd & Allman Best Current Practice [Page 1]
+
+RFC 5033 Specifying New Congestion Control Algorithms August 2007
+
+
+1. Introduction
+
+ This document provides guidelines for the IETF to use when evaluating
+ suggested congestion control algorithms that significantly differ
+ from the general congestion control principles outlined in [RFC2914].
+ The guidance is intended to be useful to authors proposing alternate
+ congestion control and for the IETF community when evaluating whether
+ a proposal is appropriate for publication in the RFC series.
+
+ The guidelines in this document are intended to be consistent with
+ the congestion control principles from [RFC2914] of preventing
+ congestion collapse, considering fairness, and optimizing the flow's
+ own performance in terms of throughput, delay, and loss. [RFC2914]
+ also discusses the goal of avoiding a congestion control "arms race"
+ among competing transport protocols.
+
+ This document does not give hard-and-fast requirements for an
+ appropriate congestion control scheme. Rather, the document provides
+ a set of criteria that should be considered and weighed by the IETF
+ in the context of each proposal. The high-order criteria for any new
+ proposal is that a serious scientific study of the pros and cons of
+ the proposal needs to have been done such that the IETF has a well-
+ rounded set of information to consider.
+
+ After initial studies, we encourage authors to write a specification
+ of their proposals for publication in the RFC series to allow others
+ to concretely understand and investigate the wealth of proposals in
+ this space.
+
+2. Document Status
+
+ Following the lead of HighSpeed TCP [RFC3649], alternate congestion
+ control algorithms are expected to be published as "Experimental"
+ RFCs until such time that the community better understands the
+ solution space. Traditionally, the meaning of "Experimental" status
+ has varied in its use and interpretation. As part of this document
+ we define two classes of congestion control proposals that can be
+ published with the "Experimental" status. The first class includes
+ algorithms that are judged to be safe to deploy for best-effort
+ traffic in the global Internet and further investigated in that
+ environment. The second class includes algorithms that, while
+ promising, are not deemed safe enough for widespread deployment as
+ best-effort traffic on the Internet, but are being specified to
+ facilitate investigations in simulation, testbeds, or controlled
+ environments. The second class can also include algorithms where the
+ IETF does not yet have sufficient understanding to decide if the
+ algorithm is or is not safe for deployment on the Internet.
+
+
+
+
+Floyd & Allman Best Current Practice [Page 2]
+
+RFC 5033 Specifying New Congestion Control Algorithms August 2007
+
+
+ Each alternate congestion control algorithm published is required to
+ include a statement in the abstract indicating whether or not the
+ proposal is considered safe for use on the Internet. Each alternate
+ congestion control algorithm published is also required to include a
+ statement in the abstract describing environments where the protocol
+ is not recommended for deployment. There may be environments where
+ the protocol is deemed *safe* for use, but still is not *recommended*
+ for use because it does not perform well for the user.
+
+ As examples of such statements, [RFC3649] specifying HighSpeed TCP
+ includes a statement in the abstract stating that the proposal is
+ Experimental, but may be deployed in the current Internet. In
+ contrast, the Quick-Start document [RFC4782] includes a paragraph in
+ the abstract stating the mechanism is only being proposed for
+ controlled environments. The abstract specifies environments where
+ the Quick-Start request could give false positives (and therefore
+ would be unsafe to deploy). The abstract also specifies environments
+ where packets containing the Quick-Start request could be dropped in
+ the network; in such an environment, Quick-Start would not be unsafe
+ to deploy, but deployment would still not be recommended because it
+ could cause unnecessary delays for the connections attempting to use
+ Quick-Start.
+
+ For authors of alternate congestion control schemes who are not ready
+ to bring their congestion control mechanisms to the IETF for
+ standardization (either as Experimental or as Proposed Standard), one
+ possibility would be to submit an internet-draft that documents the
+ alternate congestion control mechanism for the benefit of the IETF
+ and IRTF communities. This is particularly encouraged in order to
+ get algorithm specifications widely disseminated to facilitate
+ further research. Such an internet-draft could be submitted to be
+ considered as an Informational RFC, as a first step in the process
+ towards standardization. Such a document would also be expected to
+ carry an explicit warning against using the scheme in the global
+ Internet.
+
+ Note: we are not changing the RFC publication process for non-IETF
+ produced documents (e.g., those from the IRTF or Independent
+ Submissions via the RFC-Editor). However, we would hope the
+ guidelines in this document inform the IESG as they consider whether
+ to add a note to such documents.
+
+3. Guidelines
+
+ As noted above, authors are expected to do a well-rounded evaluation
+ of the pros and cons of proposals brought to the IETF. The following
+ are guidelines to help authors and the IETF community. Concerns that
+
+
+
+
+Floyd & Allman Best Current Practice [Page 3]
+
+RFC 5033 Specifying New Congestion Control Algorithms August 2007
+
+
+ fall outside the scope of these guidelines are certainly possible;
+ these guidelines should not be considered as an all-encompassing
+ check-list.
+
+ (0) Differences with Congestion Control Principles [RFC2914]
+
+ Proposed congestion control mechanisms should include a clear
+ explanation of the deviations from [RFC2914].
+
+ (1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340].
+
+ Proposed congestion control mechanisms should be evaluated when
+ competing with standard IETF congestion control [RFC2581,
+ RFC2960, RFC4340]. Alternate congestion controllers that have a
+ significantly negative impact on traffic using standard
+ congestion control may be suspect and this aspect should be part
+ of the community's decision making with regards to the
+ suitability of the alternate congestion control mechanism.
+
+ We note that this bullet is not a requirement for strict TCP-
+ friendliness as a prerequisite for an alternate congestion
+ control mechanism to advance to Experimental. As an example,
+ HighSpeed TCP is a congestion control mechanism that is
+ Experimental, but that is not TCP-friendly in all environments.
+ We also note that this guideline does not constrain the fairness
+ offered for non-best-effort traffic.
+
+ As an example from an Experimental RFC, fairness with standard
+ TCP is discussed in Sections 4 and 6 of [RFC3649] (HighSpeed TCP)
+ and using spare capacity is discussed in Sections 6, 11.1, and 12
+ of [RFC3649].
+
+ (2) Difficult Environments.
+
+ The proposed algorithms should be assessed in difficult
+ environments such as paths containing wireless links.
+ Characteristics of wireless environments are discussed in
+ [RFC3819] and in Section 16 of [Tools]. Other difficult
+ environments can include those with multipath routing within a
+ connection. We note that there is still much to be desired in
+ terms of the performance of TCP in some of these difficult
+ environments. For congestion control mechanisms with explicit
+ feedback from routers, difficult environments can include paths
+ with non-IP queues at layer-two, IP tunnels, and the like. A
+ minimum goal for experimental mechanisms proposed for widespread
+ deployment in the Internet should be that they do not perform
+ significantly worse than TCP in these environments.
+
+
+
+
+Floyd & Allman Best Current Practice [Page 4]
+
+RFC 5033 Specifying New Congestion Control Algorithms August 2007
+
+
+ While it is impossible to enumerate all the possible "difficult
+ environments", we note that the IETF has previously grappled with
+ paths with long delays [RFC2488], high delay bandwidth products
+ [RFC3649], high packet corruption rates [RFC3155], packet
+ reordering [RFC4653], and significantly slow links [RFC3150].
+ Aspects of alternate congestion control that impact networks with
+ these characteristics should be detailed.
+
+ As an example from an Experimental RFC, performance in difficult
+ environments is discussed in Sections 6, 9.2, and 10.2 of
+ [RFC4782] (Quick-Start).
+
+ (3) Investigating a Range of Environments.
+
+ Similar to the last criteria, proposed alternate congestion
+ controllers should be assessed in a range of environments. For
+ instance, proposals should be investigated across a range of
+ bandwidths, round-trip times, levels of traffic on the reverse
+ path, and levels of statistical multiplexing at the congested
+ link. Similarly, proposals should be investigated for robust
+ performance with different queueing mechanisms in the routers,
+ especially Random Early Detection (RED) [FJ03] and Drop-Tail.
+ This evaluation is often not included in the internet-draft
+ itself, but in related papers cited in the draft.
+
+ A particularly important aspect of evaluating a proposal for
+ standardization is in understanding where the algorithm breaks
+ down. Therefore, particular attention should be paid to
+ characterizing the areas where the proposed mechanism does not
+ perform well.
+
+ As an example from an Experimental RFC, performance in a range of
+ environments is discussed in Section 12 of [RFC3649] (HighSpeed
+ TCP) and Section 9.7 of [RFC4782] (Quick-Start).
+
+ (4) Protection Against Congestion Collapse.
+
+ The alternate congestion control mechanism should either stop
+ sending when the packet drop rate exceeds some threshold
+ [RFC3714], or should include some notion of "full backoff". For
+ "full backoff", at some point the algorithm would reduce the
+ sending rate to one packet per round-trip time and then
+ exponentially backoff the time between single packet
+ transmissions if congestion persists. Exactly when either "full
+ backoff" or a pause in sending comes into play will be
+ algorithm-specific. However, as discussed in [RFC2914], this
+ requirement is crucial to protect the network in times of extreme
+ congestion.
+
+
+
+Floyd & Allman Best Current Practice [Page 5]
+
+RFC 5033 Specifying New Congestion Control Algorithms August 2007
+
+
+ If "full backoff" is used, this bullet does not require that the
+ full backoff mechanism must be identical to that of TCP
+ [RFC2988]. As an example, this bullet does not preclude full
+ backoff mechanisms that would give flows with different round-
+ trip times comparable bandwidth during backoff.
+
+ (5) Fairness within the Alternate Congestion Control Algorithm.
+
+ In environments with multiple competing flows all using the same
+ alternate congestion control algorithm, the proposal should
+ explore how bandwidth is shared among the competing flows.
+
+ (6) Performance with Misbehaving Nodes and Outside Attackers.
+
+ The proposal should explore how the alternate congestion control
+ mechanism performs with misbehaving senders, receivers, or
+ routers. In addition, the proposal should explore how the
+ alternate congestion control mechanism performs with outside
+ attackers. This can be particularly important for congestion
+ control mechanisms that involve explicit feedback from routers
+ along the path.
+
+ As an example from an Experimental RFC, performance with
+ misbehaving nodes and outside attackers is discussed in Sections
+ 9.4, 9.5, and 9.6 of [RFC4782] (Quick-Start). This includes
+ discussion of misbehaving senders and receivers; collusion
+ between misbehaving routers; misbehaving middleboxes; and the
+ potential use of Quick-Start to attack routers or to tie up
+ available Quick-Start bandwidth.
+
+ (7) Responses to Sudden or Transient Events.
+
+ The proposal should consider how the alternate congestion control
+ mechanism would perform in the presence of transient events such
+ as sudden congestion, a routing change, or a mobility event.
+ Routing changes, link disconnections, intermittent link
+ connectivity, and mobility are discussed in more detail in
+ Section 17 of [Tools].
+
+ As an example from an Experimental RFC, response to transient
+ events is discussed in Section 9.2 of [RFC4782] (Quick-Start).
+
+ (8) Incremental Deployment.
+
+ The proposal should discuss whether the alternate congestion
+ control mechanism allows for incremental deployment in the
+ targeted environment. For a mechanism targeted for deployment in
+ the current Internet, it would be helpful for the proposal to
+
+
+
+Floyd & Allman Best Current Practice [Page 6]
+
+RFC 5033 Specifying New Congestion Control Algorithms August 2007
+
+
+ discuss what is known (if anything) about the correct operation
+ of the mechanism with some of the equipment installed in the
+ current Internet, e.g., routers, transparent proxies, WAN
+ optimizers, intrusion detection systems, home routers, and the
+ like.
+
+ As a similar concern, if the alternate congestion control
+ mechanism is intended only for specific environments (and not the
+ global Internet), the proposal should consider how this intention
+ is to be carried out. The community will have to address the
+ question of whether the scope can be enforced by simply stating
+ the restrictions or whether additional protocol mechanisms are
+ required to enforce the scoping. The answer will necessarily
+ depend on the change being proposed.
+
+ As an example from an Experimental RFC, deployment issues are
+ discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start).
+
+4. Minimum Requirements
+
+ This section suggests minimum requirements for a document to be
+ approved as Experimental with approval for widespread deployment in
+ the global Internet.
+
+ The minimum requirements for approval for widespread deployment in
+ the global Internet include the following guidelines on: (1)
+ assessing the impact on standard congestion control, (3)
+ investigation of the proposed mechanism in a range of environments,
+ (4) protection against congestion collapse, and (8) discussing
+ whether the mechanism allows for incremental deployment.
+
+ For other guidelines, i.e., (2), (5), (6), and (7), the author must
+ perform the suggested evaluations and provide recommended analysis.
+ Evidence that the proposed mechanism has significantly more problems
+ than those of TCP should be a cause for concern in approval for
+ widespread deployment in the global Internet.
+
+5. Security Considerations
+
+ This document does not represent a change to any aspect of the TCP/IP
+ protocol suite and therefore does not directly impact Internet
+ security. The implementation of various facets of the Internet's
+ current congestion control algorithms do have security implications
+ (e.g., as outlined in [RFC2581]). Alternate congestion control
+ schemes should be mindful of such pitfalls, as well, and should
+ examine any potential security issues that may arise.
+
+
+
+
+
+Floyd & Allman Best Current Practice [Page 7]
+
+RFC 5033 Specifying New Congestion Control Algorithms August 2007
+
+
+6. Acknowledgments
+
+ Discussions with Lars Eggert and Aaron Falk seeded this document.
+ Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye,
+ Colin Perkins, Pekka Savola, members of TSVWG, and participants at
+ the TCP Workshop at Microsoft Research for feedback and
+ contributions. This document also draws from [Metrics].
+
+7. Normative References
+
+ [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
+ Control", RFC 2581, April 1999.
+
+ [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
+ 2914, September 2000.
+
+ [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
+ Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
+ L., and V. Paxson, "Stream Control Transmission Protocol",
+ RFC 2960, October 2000.
+
+ [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
+ Control Protocol (DCCP)", RFC 4340, March 2006.
+
+8. Informative References
+
+ [FJ03] Floyd, S., and Jacobson, V., Random Early Detection
+ Gateways for Congestion Avoidance, IEEE/ACM Transactions on
+ Networking, V.1 N.4, August 1993.
+
+ [Metrics] S. Floyd, Metrics for the Evaluation of Congestion Control
+ Mechanisms, Work in Progress, July 2007.
+
+ [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over
+ Satellite Channels using Standard Mechanisms", BCP 28, RFC
+ 2488, January 1999.
+
+ [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
+ Timer", RFC 2988, November 2000.
+
+ [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
+ "End-to-end Performance Implications of Slow Links", BCP
+ 48, RFC 3150, July 2001.
+
+ [RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
+ Vaidya, "End-to-end Performance Implications of Links with
+ Errors", BCP 50, RFC 3155, August 2001.
+
+
+
+
+Floyd & Allman Best Current Practice [Page 8]
+
+RFC 5033 Specifying New Congestion Control Algorithms August 2007
+
+
+ [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
+ RFC 3649, December 2003.
+
+ [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
+ Control for Voice Traffic in the Internet", RFC 3714, March
+ 2004.
+
+ [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig,
+ R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood,
+ "Advice for Internet Subnetwork Designers", BCP 89, RFC
+ 3819, July 2004.
+
+ [RFC4653] Bhandarkar, S., Reddy, A. N., Allman, M., and E. Blanton,
+ "Improving the Robustness of TCP to Non-Congestion Events",
+ RFC 4653, August 2006.
+
+ [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
+ Start for TCP and IP", RFC 4782, January 2007.
+
+ [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of
+ Simulation and Testbed Scenarios, Work in Progress, July
+ 2007.
+
+Authors' Addresses
+
+ Sally Floyd
+ ICIR (ICSI Center for Internet Research)
+ 1947 Center Street, Suite 600
+ Berkeley, CA 94704-1198
+ Phone: +1 (510) 666-2989
+ EMail: floyd@icir.org
+ URL: http://www.icir.org/floyd/
+
+ Mark Allman
+ ICSI Center for Internet Research
+ 1947 Center Street, Suite 600
+ Berkeley, CA 94704-1198
+ Phone: (440) 235-1792
+ EMail: mallman@icir.org
+ URL: http://www.icir.org/mallman/
+
+
+
+
+
+
+
+
+
+
+
+Floyd & Allman Best Current Practice [Page 9]
+
+RFC 5033 Specifying New Congestion Control Algorithms August 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Floyd & Allman Best Current Practice [Page 10]
+