Network Working Group S. Floyd Internet-Draft M. Allman Expires: December 2006 ICIR / ICSI October 2006 Specifying New Congestion Control Algorithms draft-floyd-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. 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 Expires: April 2007 [Page 1] draft-floyd-cc-alt-00.txt October 2006 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 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. Expires: April 2007 [Page 2] draft-floyd-cc-alt-00.txt October 2006 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 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. (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 Expires: April 2007 [Page 3] draft-floyd-cc-alt-00.txt October 2006 investigation into areas where the proposal does not perform well. (5) Full Backoff. All alternate congestion control algorithms ultimately should include some notion of "full backoff". That is, at some point the algorithm should 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 this "full backoff" comes into play will be algorithm-specific. However, this requirement is crucial to protect the network in times of extreme congestion. (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. 4. 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. 5. IANA Considerations This document does not require any IANA action. Acknowledgments Discussions with Lars Eggert and Aaron Falk seeded this document. This document also draws from [Metrics]. Normative References Informative References [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion Control, RFC 2581, Proposed Standard, April 1999. Expires: April 2007 [Page 4] draft-floyd-cc-alt-00.txt October 2006 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best Current Practice, September 2000. [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 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 Expires: April 2007 [Page 5] draft-floyd-cc-alt-00.txt October 2006 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: April 2007 [Page 6]