RFC 5033

Specifying New Congestion Control Algorithms

📅 published August 2007, from ietf

RFC 5033: Specifying New Congestion Control Algorithms 💖

okay bestie, let's get into it 🎀 This is BCP 133, a Best Current Practice, written by S. Floyd and M. Allman from ICIR / ICSI. It's dated August 2007 and it's in the Best Current Practice category. The header doesn't list any RFCs it obsoletes or updates 🦋

Status of This Memo 🫶

This document specifies an Internet Best Current Practices for the Internet Community, and it's requesting 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, like high-speed networks 😭 Recent research has produced lots of alternate congestion control schemes that differ a lot from the IETF's congestion control principles. Using these new schemes across the global Internet could have ramifications for both the traffic using the new congestion control and the traffic using the currently standardized congestion control. So the IETF has to proceed with caution when it deals with alternate congestion control proposals 👀 The goal of this document is to give guidance for considering alternate congestion control algorithms within the IETF 💅

1. Introduction ✨

okay so this document gives the IETF guidelines to use when it's evaluating suggested congestion control algorithms that differ significantly from the general congestion control principles outlined in [RFC2914] 🔥 The guidance is meant to help authors proposing alternate congestion control, and it also helps the IETF community decide whether a proposal is appropriate for publication in the RFC series 🧚

The guidelines here are meant to line up with the congestion control principles from [RFC2914]. Those are preventing congestion collapse, considering fairness, and optimizing the flow's own performance in terms of throughput, delay, and loss 💜 [RFC2914] also talks about avoiding a congestion control "arms race" among competing transport protocols, which is very much a vibe we don't want 💀

This document doesn't give hard-and-fast requirements for an appropriate congestion control scheme 🙈 Instead it gives 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, so the IETF has a well-rounded set of information to consider 🎀

After the initial studies, we encourage authors to write a specification of their proposals for publication in the RFC series. That way others can concretely understand and investigate the wealth of proposals in this space 🦋

2. Document Status 🌈

Taking after HighSpeed TCP [RFC3649], alternate congestion control algorithms are expected to be published as "Experimental" RFCs until the community better understands the solution space ✨ The meaning of "Experimental" status has traditionally varied in its use and interpretation, which is literally chaos 😭 So as part of this document, we define two classes of congestion control proposals that can be published with "Experimental" status 🍓

The first class includes algorithms that are judged to be safe to deploy for best-effort traffic in the global Internet, and that will be investigated further in that environment 💖 The second class includes algorithms that are promising but aren't deemed safe enough for widespread deployment as best-effort traffic on the Internet. These are specified to facilitate investigations in simulation, testbeds, or controlled environments 🧪 The second class can also include algorithms where the IETF doesn't yet have enough understanding to decide whether the algorithm is or isn't safe for deployment on the Internet 🤔

Each alternate congestion control algorithm that gets published is required to include a statement in the abstract saying whether or not the proposal is considered safe for use on the Internet ✨ It's 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 to use, but still isn't recommended because it doesn't perform well for the user 💅

Here are some examples of how that looks. [RFC3649], which specifies HighSpeed TCP, has an abstract statement saying the proposal is Experimental but may be deployed in the current Internet 🚀 On the flip side, the Quick-Start document [RFC4782] has a paragraph in its abstract saying the mechanism is only being proposed for controlled environments 🧚 Its abstract also lays out environments where the Quick-Start request could give false positives, which makes it unsafe to deploy 😬 It also specifies environments where packets containing the Quick-Start request could be dropped in the network. In that case Quick-Start wouldn't be unsafe to deploy, but deployment still wouldn't be recommended, because it could cause unnecessary delays for the connections trying to use Quick-Start 🙈

For authors of alternate congestion control schemes who aren't ready to bring their mechanisms to the IETF for standardization (either as Experimental or as Proposed Standard), one option is to submit an internet-draft that documents the alternate congestion control mechanism for the benefit of the IETF and IRTF communities 🫶 This is especially encouraged so that algorithm specifications get widely disseminated and further research can happen 📚 An internet-draft like that could be submitted to be considered as an Informational RFC, as a first step toward standardization 🌸 Such a document would also be expected to carry an explicit warning against using the scheme in the global Internet ⚠️

Note: we aren't changing the RFC publication process for non-IETF produced documents (for example, those from the IRTF or Independent Submissions via the RFC-Editor). However, we'd hope the guidelines in this document inform the IESG as it considers whether to add a note to such documents 🎀

3. Guidelines ✨

okay so bestie, authors are expected to do a well-rounded check on the pros AND cons of anything they bring to the IETF 💅 these guidelines are here to help authors and the community out 🫶 concerns outside this list are totally possible, so this is NOT an all-encompassing checklist 🙈

(0) Differences with Congestion Control Principles [RFC2914]

proposed congestion control mechanisms should include a clear explanation of any 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 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 about whether the alternate mechanism is suitable 👀

we note that this bullet is NOT a requirement for strict TCP-friendliness before an alternate congestion control mechanism can advance to Experimental 🌸 for example, HighSpeed TCP is Experimental but isn't TCP-friendly in all environments, and that's still a vibe 💜 this guideline also doesn't constrain the fairness offered to 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, like paths containing wireless links 📡 characteristics of wireless environments are discussed in [RFC3819] and in Section 16 of [Tools] 💅 other difficult environments can include ones with multipath routing within a connection 🌈 we note that there is still a lot to be desired in TCP's performance 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 💖

it's impossible to list every possible "difficult environment," but the IETF has already dealt 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 one, proposed alternate congestion controllers should be assessed across 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 📊 proposals should also 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 in the internet-draft itself, but in related papers the draft cites 📚

a really important part of evaluating a proposal for standardization is understanding where the algorithm breaks down 💀 so 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 back off the time between single-packet transmissions if congestion persists 🐢 exactly when either "full backoff" or a pause in sending kicks in will be algorithm-specific 🤷‍♀️ however, as discussed in [RFC2914], 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 be identical to TCP's [RFC2988] 🦋 for example, this bullet doesn't rule out full backoff mechanisms that 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 those 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 😈 it should also explore how the mechanism performs with outside attackers 🏴‍☠️ this can be especially 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 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 when there are transient events, like 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, the 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 at deployment in the current Internet, it would be helpful for the proposal to discuss what is known (if anything) about the mechanism operating correctly alongside equipment already 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 that intention is to be carried out 🎯 the community will have to figure out 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 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 the 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) investigating the proposed mechanism across a range of environments, (4) protection against congestion collapse, and (8) discussing whether the mechanism allows for incremental deployment 💖

for the 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 TCP should be a cause for concern when it comes to approval for widespread deployment in the global Internet 🚩

5. Security Considerations 🔐

this document does NOT change any aspect of the TCP/IP protocol suite, so it doesn't directly impact Internet security 🙌 the way various facets of the Internet's current congestion control algorithms are implemented DOES have security implications (e.g., as outlined in [RFC2581]) 😳 alternate congestion control schemes should be mindful of those same pitfalls and should examine any potential security issues that may come up 🛡️ this one is serious, bestie, so don't skip it 🚨

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 their 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 ✨

okay bestie, these are the receipts 🧾 the sources the doc leans on for background. they're informative, so you don't have to implement them, but they're the good reading 📚

  • [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.
  • [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 🦋

these are the people who wrote it, and where to find them 💌

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/

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. 🫶

📦 where this page comes from