Network Working Group S. Floyd Internet-Draft M. Allman Expires: June 2006 ICIR / ICSI December 2006 Specifying New Congestion Control Algorithms draft-floyd-tsvwg-cc-alt-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed or wireless networks). Recent research has yielded many alternate congestion control schemes. Using these new congestion control schemes in the global Internet has possible ramifications to both the network 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. TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: Changes from draft-floyd-cc-alt-00.txt: * Changed the name to draft-floyd-tsvwg-cc-alt-00.txt. Expires: June 2006 [Page 1] draft-floyd-tsvwg-cc-alt-00.txt December 2006 * Added a bullet about incremental deployment. Feedback from Colin Perkins * Clarified the fairness section; this section is not saying that strict TCP-friendliness is a requirement. * Clarified that as an alternative to Full Backoff, a flow could stop sending when the packet drop rate is above a certain threshold. * Clarified that the Full Backoff bullet does not require that different flows with different round-trip times use the same criteria about when they should back off to one packet per round-trip time or less. * Added a paragraph about Informational RFCs. * Added a bullet about response to transient events, including routing events or moving from a private to a shared network. END OF NOTES TO BE DELETED. 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. This document does not give hard-and-fast rules for what makes 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. Status Following the lead of HighSpeed TCP, 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 Expires: June 2006 [Page 2] draft-floyd-tsvwg-cc-alt-00.txt December 2006 the "Experimental" status. The first class is algorithms that are judged to be safe to deploy in the global Internet and further investigated in that environment. The second class is algorithms that, while promising, are not deemed safe enough for deployment on the Internet, but are being specified to facilitate investigations via simulation and testbeds. 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 even though it may not be unsafe for use. 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 [QuickStart] includes a paragraph in the abstract stating the the mechanism is only being proposed for controlled environments. The abstract specifies environments where the Quick-Start request would 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 researchers 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 Informational, 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. 3. Guidelines As noted above, authors are expected to do a well-rounded evaluations of the pros and cons of proposals brought to the IETF. The following are guidelines to help authors and the IETF community. Concerns that fall outside the scope of these guidelines are certainly possible and these guidelines should not be used as a check-list. (1) Fairness to Standard TCP, SCTP, and DCCP. In environments where standard congestion control is able to make reasonable use of the available bandwidth the proposed Expires: June 2006 [Page 3] draft-floyd-tsvwg-cc-alt-00.txt December 2006 change should not significantly change this state. For instance, in a situation where each of N flows uses 1/N of the network capacity, a new congestion control scheme should not significantly deviate from this state. For instance, a flow using an alternate congestion controller that took half the capacity and left each of the remaining N flows with 1/2N of the capacity would be suspect. 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. (2) Using Spare Capacity. Similar to point (1), alternate congestion control algorithms may take up spare capacity in the network, but may not steal significant amounts of capacity from flows using currently standardized congestion control. For instance, consider the case where N flows cannot naturally use all the capacity and equally share one-third of the capacity (with each flow using 1/3N of the capacity). A single flow using an alternate congestion control scheme could use the unused two-thirds of capacity. However, the flow using alternate congestion control should not steal significant amounts of additional capacity from the N standard flows. (3) Difficult Environments. An assessment of proposed algorithms in difficult environments such as paths containing wireless links and paths with reverse-path congestion. In addition, proposed algorithms should be evaluated in situations where the bottleneck has high and low levels of statistical multiplexing. (4) 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 and round-trip times. 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 extending the investigation into areas where the proposal does not perform well. (5) Protection Against Congestion Collapse. The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold Expires: June 2006 [Page 4] draft-floyd-tsvwg-cc-alt-00.txt December 2006 [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, this requirement is crucial to protect the network in times of extreme congestion. If "full backoff" is used, this bullet does not require that the full backoff mechanism must be identical to that of TCP. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round-trip times comparable bandwidth during backoff. (6) Fairness within the Alternate Congestion Control Algorithm. In environments with multiple competing flows using the alternate congestion control algorithm, the proposal should explore how bandwidth is shared among the competing flows. (7) 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. (8) 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. (9) Incremental Deployment. The proposal should discuss whether the alternate congestion control mechanism allows for incremental deployment in the targeted environment. If the alternate congestion control mechanism is intended only for specific environments, the proposal should consider how this intention is to be carried out. 4. Conclusions This document is intended as a guideline for researchers in bringing congestion control mechanisms to the IETF to be considered for Experimental status, and also as a guideline to the IETF in evaluating such proposals. Expires: June 2006 [Page 5] draft-floyd-tsvwg-cc-alt-00.txt December 2006 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. 6. IANA Considerations This document does not require any IANA action. Acknowledgments Discussions with Lars Eggert and Aaron Falk seeded this document. Thanks to Colin Perkins for feedback. This document also draws from [Metrics]. Thanks to Colin Perkins for feedback. Normative References Informative References [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion Control, RFC 2581, Proposed Standard, April 1999. [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best Current Practice, September 2000. [RFC3649] S. Floyd, HighSpeed TCP for Large Congestion Windows, RFC 3649, September 2003. [RFC3714] S. Floyd and J. Kempf, IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet, RFC 3714, March 2004. [Metrics] S. Floyd, Metrics for the Evaluation of Congestion Control Mechanisms. Internet-draft draft-irtf-tmrg-metrics-04, work in progress, August 2006. [QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, Quick-Start for TCP and IP. Internet-draft draft-ietf-tsvwg-quickstart-07.txt, work in progress, October 2006. Approved for Experimental. Authors' Addresses Sally Floyd Phone: +1 (510) 666-2989 ICIR (ICSI Center for Internet Research) Email: floyd@icir.org URL: http://www.icir.org/floyd/ Mark Allman Expires: June 2006 [Page 6] draft-floyd-tsvwg-cc-alt-00.txt December 2006 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/ Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Expires: June 2006 [Page 7]