RFC 9743

Specifying New Congestion Control Algorithms

📅 published March 2025, from ietf

RFC 9743: Specifying New Congestion Control Algorithms 🦋

okay bestie, here's the tea on RFC 9743 ☕✨. It's called "Specifying New Congestion Control Algorithms" and it came out in March 2025. It's a Best Current Practice (that's BCP 133 💅), with ISSN 2070-1721. The editors are M. Duke (Google LLC) and G. Fairhurst (University of Aberdeen), both marked as Ed. 🫶 It obsoletes RFC 5033 and doesn't list any updates. Main character energy, honestly 👑

Abstract 🌸

RFC 5033 talks about the principles and guidelines for standardizing new congestion control algorithms, and this doc is its replacement 🔄 It obsoletes RFC 5033 to catch up with how the congestion control landscape has changed. It gives us a framework for building and assessing congestion control mechanisms, aiming for stability across all kinds of network paths 🛤️ The goal is to make sure proposed algorithms run efficiently and don't cause harm when they're used across the global Internet 🌍 It really stresses comprehensive testing and validation so new algorithms don't mess with existing flows. No chaos allowed 🙅‍♀️

Status of This Memo 📜

This memo documents an Internet Best Current Practice ✨

This is an IETF product, so it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on BCPs, check Section 2 of RFC 7841 📖

For the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9743 🔗

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they explain your rights and restrictions for this document 🧐 Any Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🌈

Table of Contents 📚

   1.  Introduction
   2.  Specification of Requirements
   3.  Guidelines for Authors
     3.1.  Evaluation Guidelines
     3.2.  Document-Status Guidelines
   4.  Specifying Algorithms for Use in Controlled Environments
   5.  Evaluation Criteria
     5.1.  Single Algorithm Behavior
       5.1.1.  Protection Against Congestion Collapse
       5.1.2.  Protection Against Bufferbloat
       5.1.3.  Protection Against High Packet Loss
       5.1.4.  Fairness Within the Proposed Congestion Control
               Algorithm
       5.1.5.  Short Flows
     5.2.  Mixed Algorithm Behavior
       5.2.1.  Existing General-Purpose Congestion Control
       5.2.2.  Real-Time Congestion Control
       5.2.3.  Short and Long Flows
     5.3.  Other Criteria
       5.3.1.  Differences with Congestion Control Principles
       5.3.2.  Incremental Deployment
   6.  General Use
     6.1.  Paths with Tail-Drop Queues
     6.2.  Tunnel Behavior
     6.3.  Wired Paths
     6.4.  Wireless Paths
   7.  Special Cases
     7.1.  Active Queue Management (AQM)
     7.2.  Operation with the Envelope Set by Network Circuit Breakers
     7.3.  Paths with Varying Delay
     7.4.  Internet of Things and Constrained Nodes
     7.5.  Paths with High Delay
     7.6.  Misbehaving Nodes
     7.7.  Extreme Packet Reordering
     7.8.  Transient Events
     7.9.  Sudden Changes in the Path
     7.10. Multipath Transport
     7.11. Data Centers
   8.  Security Considerations
   9.  IANA Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Appendix A.  Changes Since RFC 5033
   Acknowledgments
   Contributors
   Authors' Addresses

1. Introduction ✨

This doc gives the IETF guidelines to use when evaluating a proposed congestion control algorithm that's different from the general congestion control principles in [RFC2914] 🧠 The guidance is meant to help authors who are proposing these algorithms, and the wider IETF community deciding whether a proposal is ready to be published in the RFC Series and deployed on the Internet 🚀

This document obsoletes [RFC5033], which came out in 2007 as a Best Current Practice for evaluating proposed congestion control algorithms for publication in Experimental or Proposed Standard RFCs 🗓️

The IETF specifies standard Internet congestion control algorithms in the RFC Series. These algorithms can struggle in different environments, like high-speed networks, cellular and Wi-Fi wireless technologies, and long-distance satellite links 🛰️ They can also struggle when flows carry specific workloads, like Voice over IP (VoIP), gaming, and videoconferencing 🎮

When [RFC5033] was published, TCP [RFC9293] was the main focus of IETF congestion control work, and proposals were usually discussed in the Internet Congestion Control Research Group (ICCRG) 💬 At the same time, the Datagram Congestion Control Protocol (DCCP) [RFC4340] was developed to define new congestion control algorithms for datagram traffic, and the Stream Control Transmission Protocol (SCTP) [RFC9260] reused TCP congestion control algorithms 🔁

A lot has changed since then 📈 The protocols using congestion control have grown to include QUIC [RFC9000] and RTP Media Congestion Avoidance Techniques (RMCAT) (e.g., [RFC8836]) 🎥 Some alternative congestion control algorithms have also been tested and deployed at scale without full IETF review 😳 There's more interest in specialized use cases, like data centers (e.g., [RFC8257]), and in supporting a bunch of upper-layer protocols and applications, like real-time protocols ⚡ And the community has picked up a lot of experience with congestion indications beyond packet loss 🧪

Multicast congestion control is a much less mature field and it's not in scope for this document 🙅‍♀️ That said, Section 4 of [RFC8085] has extra guidelines for multicast and broadcast usage of UDP 📡

Some congestion control algorithms were developed outside the IETF, and at least two saw large-scale deployment 🌟 Those are CUBIC [HRX08] and Bottleneck Bandwidth and Round-trip propagation time (BBR) [BBR] 🏄‍♀️

CUBIC was written up in a research publication in 2008 [HRX08], and then it became the default congestion control algorithm for the TCP implementation in Linux 🐧 It was already carrying a big chunk of TCP connections over the Internet before it got documented in an Internet-Draft in 2015. It was published as an Informational RFC in 2017 as [RFC8312], and then as a Proposed Standard in 2023 [RFC9438] 🎉

BBR is currently being developed as an internal research project at Google, and its first implementation was contributed to Linux kernel 4.19 in 2016 🐣 It was described in an Internet-Draft in 2018 and first presented in the IRTF Internet Congestion Control Research Group. It's been regularly updated to document the evolving versions of the algorithm [BBR] 🔄 Today it's widely used for Google services over either TCP or QUIC, and it's also widely deployed outside of Google 🌏

We can't say for sure whether the original [RFC5033] authors expected developers to wait for IETF review before deploying a new congestion control algorithm widely over the Internet 🤷‍♀️ But CUBIC and BBR show that deploying new algorithms isn't actually gated by publishing the algorithm as an RFC 🚪

Still, a specification for a congestion control algorithm gives you a bunch of perks ✨

  • It can help implementers, operators, and other interested parties build a shared understanding of how the algorithm works and how it's expected to behave in different scenarios and configurations 🤝
  • It can help potential contributors understand the algorithm, which makes it easier for them to suggest improvements and/or spot limitations 🔍 The specification can also help several contributors agree on a consensus change to the algorithm 🫂
  • It can help (because anyone can access it) get around the problem that some implementers can't read open-source reference implementations because of the constraints of certain open-source licenses 📖

Beyond helping with specific algorithm proposals, guidelines can also remind inventors and developers about the many facets of the congestion control problem 💡

The evaluation guidelines in this doc are meant to line up with the congestion control principles from [RFC2914]. Those cover preventing congestion collapse, considering fairness, and optimizing a 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 🏁

This document doesn't set hard-and-fast requirements for a good congestion control algorithm 🙌 Instead, it gives a set of criteria that developers of alternative algorithms and the IETF should consider and weigh for each proposal ⚖️

The big-picture criterion for moving any proposal forward in the IETF is a serious scientific study of the pros and cons, done either when the proposal is considered for publication by the IETF or before it's deployed at large scale 🔬

After the initial studies, authors are encouraged to write up a specification of their proposal for the RFC Series 📝 That way, others can understand and dig into the wealth of proposals in this space 💖

This document is meant to lower the barriers to entry for new congestion control work at the IETF 🚪✨ So proponents of new congestion control algorithms ought not to treat these criteria as a checklist of requirements before they approach the IETF. Instead, they're encouraged to think about these issues ahead of time and be willing to do the work described in the rest of this document 💪🌷

2. Specification of Requirements 💖

Okay, so the BCP 14 key words are the official requirement words in this doc: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 🎀 They mean what BCP 14 [RFC2119] [RFC8174] says, but only when they show up in all capitals, just like that. If they're in lowercase, they're just regular English words 💅

3. Guidelines for Authors 🧚

3.1. Evaluation Guidelines 🧪

okay so this part is about how to actually evaluate a congestion control algorithm 🤓. this doc doesn't give specific evaluation methods, short of Internet-scale deployment and measurement (which is obviously the ultimate test 💅). there are multiple possible approaches, and each one has a role. the best one depends on what you're checking and how mature the spec is ✨.

for a lot of algorithms, the first evaluation looks at individual protocol mechanisms in a simulator, to check their stability and safety across a wide range of conditions, including overload 🌩️. for example, [RFC8869] describes evaluation test cases for interactive real-time media over wireless networks 📡. results like these could also be published or discussed in IRTF research groups, like ICCRG and MAPRG 🎀.

before a proposed congestion control algorithm gets published as an Experimental or Standards Track RFC, the community SHOULD gain practical experience with implementations and with using the algorithm 🫶. implementations by independent teams can help show that a spec has avoided assumptions or ambiguity 🔍. an independent evaluation by multiple teams helps show that the design meets the evaluation criteria, and lets people assess typical interactions with other traffic 💜. this evaluation could use an emulated lab environment or a controlled experiment (within a limited domain or at Internet scale) 🧫. when a working group is deciding if a proposed spec is ready for publication, it will normally consider evidence of results 📊. this ought to be documented in any request from the working group to publish the specification 📝.

a congestion control algorithm without multiple implementations might still be published as an RFC if a single implementation is widely used, open source, and shown to have a positive impact on the Internet 🌈. this is especially true if the target status is Experimental 🧪.

3.2. Document-Status Guidelines 🚦

the guidelines in this document apply to specs of congestion control algorithms that want to be published as an RFC through the IETF Stream with an Experimental or Standards Track status 💌. evaluating either status involves the same questions, but the expectations for the answers, and how certain we need to be about them, are different 🎯.

specs of congestion control algorithms without empirical evidence of Internet-scale deployment MUST seek Experimental status, unless they aren't targeted for general use 🚨. algorithms that aren't targeted at general use don't need Internet-scale data 🙅‍♀️.

specs that want to be published as Experimental IETF Stream RFCs ought to explain why they have that status, and what further information would be needed to move on to a Standards Track RFC 🧭. for example, Section 12 of [RFC6928] has "Usage and Deployment Recommendations" that describe the experiments the TCPM Working Group expected 🧑‍🔬. Section 4 of [RFC7414] gives other examples of extensions that were considered experimental when their spec was published 🍓.

Experimental specs SHOULD NOT be deployed as a default 🙅‍♀️. they SHOULD only be deployed where they're being actively measured, and where it's possible to deactivate them if there are signs of pathological behavior 👀.

specs of congestion control algorithms with a record of measured Internet-scale deployment MAY directly seek Standards Track status, if there's solid data showing the algorithm is safe and the design is stable 📈. this should be guided by the considerations in Section 6 🗺️. but the existence of this data does not waive the other considerations in this document 🙃.

each specification submitted for publication as an RFC is REQUIRED to include a statement in the abstract saying whether or not there is IETF consensus that the proposed congestion control algorithm is considered safe for use on the Internet 📣. each such spec is also REQUIRED to include a statement in the abstract describing environments where the protocol is not recommended for deployment 🚧. there can be environments where the congestion control algorithm is deemed safe to use, but it still isn't recommended, because it doesn't perform well for the user 😬.

examples of these statements exist in [RFC3649], which specifies HighSpeed TCP 🏎️. its abstract says the proposed algorithm is experimental but may be deployed in the Internet 🌐. in contrast, the Quick-Start document [RFC4782] has a paragraph in its abstract saying the mechanism is only being proposed for use in controlled environments 🏫. the abstract also specifies environments where the Quick-Start request could give false positives, which would make it unsafe for incremental deployment where some routers forward but don't process the option 💀. it also specifies environments where packets containing the Quick-Start request could be dropped in the network. in that kind of environment, Quick-Start wouldn't be unsafe to deploy, but deployment is not recommended, because it could lead to unnecessary delays for connections trying to use Quick-Start ⏳. the Quick-Start method is discussed as an example in [RFC9049] 💖.

strictly speaking, documents for publication as Informational RFCs from the IETF Stream don't need to meet all of the criteria in this document, since they don't carry a formal recommendation from the IETF community 📚. instead, the community judges whether to publish these Informational RFCs based on how much they add to the information captured by the RFC Series 🌸.

even though it's out of scope for this doc, proponents of a new algorithm could alternatively seek publication of their spec as an Informational or Experimental RFC through the Internet Research Task Force (IRTF) Stream 🔬. in general, these algorithms are expected to be less mature than ones that follow the procedures in this document for IETF Stream publication 🌱. authors documenting deployed congestion control algorithms that can't be changed by IETF or IRTF review are invited to seek publication of their spec as an Informational RFC through the Independent Submission Stream 🦋.

4. Specifying Algorithms for Use in Controlled Environments 🏢

algorithms can be designed for general Internet deployment, or for use in controlled environments [RFC8799] 🏠. inside a controlled environment, an operator can make sure flows are isolated from other Internet flows, or they might let these flows share resources with other Internet flows 🤝. a data center is an example of a controlled environment that often deploys fabrics with rich signaling from switches to endpoints 🖥️.

algorithms that rely on specific functions or configurations in the network need to provide a reference or specification for those functions (like an RFC or another stable specification) 📖. for publication of a spec for one of these algorithms to go ahead, the IETF will need to consider whether a working group exists that can properly assess the network-layer aspects, and how they interact with the congestion control 🧩.

when evaluating a new proposal for use in a controlled environment, the IETF community needs to understand the usage (for example, how it's scoped to the controlled environment) 🔭. they also need to know whether the algorithm will share resources with Internet traffic, and what could happen if it's used in a protocol that is bridged across an Internet path 🌉. algorithms designed to be confined to a controlled environment, and not intended for the general Internet, might instead seek real-world data for those environments 🌍. in such cases, the evaluation criteria in the rest of this document might not apply 🙈.

5. Evaluation Criteria 📋

as noted before, authors of a spec on a congestion control algorithm are expected to run a comprehensive evaluation of the advantages and disadvantages of any congestion control algorithms they present to the IETF community 💅. the following guidelines are meant to help authors and the community with this 🫶. they're a helpful framework, but they shouldn't be treated as an exhaustive checklist, since concerns beyond the scope of these guidelines may also come up 🧐.

when considering a proposed congestion control algorithm, the community MUST consider the criteria in the following sections ✅. these criteria will be evaluated in various domains (see Sections 6 and 7) 🗂️.

some of the sections below list criteria that SHOULD be met. it could happen that the proposal doesn't actually meet them. in those cases, the community MUST document whether not meeting the criteria is acceptable, for example, if there are practical limitations on carrying out an evaluation of the criteria 📝.

the requirement that the community consider a criterion doesn't mean the result needs to be described in an RFC 🙂. there's no formal requirement to document the results, although normal IETF policies for archiving proceedings will provide a record 🗄️.

this document, except where otherwise noted, doesn't provide normative guidance on the acceptable thresholds for any of these criteria 🚫. instead, the community will use these evaluations as an input when deciding whether to move the proposed algorithm spec forward in the publication process 🛤️.

5.1. Single Algorithm Behavior 🧍

the criteria in the following subsections evaluate the congestion control algorithm when one or more flows using that algorithm share a bottleneck link (in other words, with no flows using a differing congestion control algorithm) 🔗.

5.1.1. Protection Against Congestion Collapse 🛡️

a congestion control algorithm should either stop sending when the packet drop rate exceeds some threshold [RFC3714], or 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. then it would exponentially back off the time between single packet transmissions, if the congestion persists 📉. exactly when either "full backoff" or a pause in sending comes into play will be algorithm specific 🎛️. however, as discussed in [RFC2914] and [RFC8961], this requirement is crucial to protect the network in times of extreme (and persistent) congestion 🚑.

if full backoff is used, this test doesn't require the mechanism to be identical to that of TCP (see [RFC6298] and [RFC8961]) 🙌. for example, this doesn't rule out full backoff mechanisms that would give flows with different round-trip times comparable capacity during backoff ⚖️.

5.1.2. Protection Against Bufferbloat 🫧

Okay so a congestion control algorithm ought to try to avoid keeping excessive queues in the network 🫧 How it pulls that off is algorithm-specific, so check [RFC8961] and [RFC8085] for the requirements 💅

"Bufferbloat" is the name for building up excessive queues in the network [BUFFERBLOAT] 🍓 A lot of network routers come configured with really huge buffers 😭 The Standards Track RFCs [RFC5681] and [RFC9438] describe Reno and CUBIC (respectively), and they keep sending at faster and faster rates until a First In, First Out (FIFO) buffer is totally full. Only then do packet losses happen 💀 Every connection going through that bottleneck gets extra latency from the high buffer occupancy 🙈 That's unwanted lag that hurts super interactive stuff like videoconferencing or games, but it also messes with regular web browsing and video playing 📺

This has been talked about since 2011 [BUFFERBLOAT], but it wasn't in the congestion control principles published in September 2002 [RFC2914] 🌸 Reno and CUBIC don't address this problem, which means a brand new congestion control algorithm has the chance to level up the state of the art 👑

5.1.3. Protection Against High Packet Loss 🌧️

A congestion control algorithm needs to avoid causing excessively high rates of packet loss 🚫 To do that, it should avoid excessive increases in sending rate, and it should reduce its sending rate if it's experiencing high packet loss 📉

The first version of the BBR algorithm [BBRv1] failed this requirement, and that's the tea ☕ Experimental evaluation [BBRv1-EVALUATION] showed it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and a half times the Bandwidth Delay Product (BDP) 😬 Honestly, that was unsatisfactory, and that's why further versions provided a fix for this aspect of BBR [BBR] 🔧

This requirement does not imply that the algorithm should react to packet losses in exactly the same way as the congestion control algorithms described in current Standards Track RFCs (e.g., [RFC5681]). Not everyone has to copy-paste the same homework 📝

5.1.4. Fairness Within the Proposed Congestion Control Algorithm 🤝

When multiple competing flows all use the same proposed congestion control algorithm, the evaluation should explore how the capacity is shared among them ⚖️ Capacity fairness can be important when a small number of similar flows compete to fill a bottleneck 💜 However, it can also be not useful, for example, when comparing flows that seek to send at different rates, or when some of the flows don't last long enough to approach asymptotic behavior ⏳

5.1.5. Short Flows 🦋

A great deal of congestion control analysis is about the steady-state behavior of long flows, but ngl, many Internet flows are relatively short lived 🙄 Lots of short-lived flows today stay in the "slow start" mode of operation [RFC5681], which commonly features exponential congestion window growth, because the flow never experiences congestion (e.g., packet loss) 🌊

A proposal for a congestion control algorithm MUST consider how new and short-lived flows affect long-lived flows, and vice versa 🫶

5.2. Mixed Algorithm Behavior 🌈

The mixed algorithm behavior criteria look at how the proposed congestion control algorithms interact with the commonly deployed ones 👀

In contexts where different congestion control algorithms are used together, it's important to understand whether the proposed congestion control algorithm could cause more harm than the algorithms in previous Standards Track RFCs (e.g., [RFC5681], [RFC9002], and [RFC9438]) to flows sharing a common bottleneck 😤 The measure of harm isn't limited to unequal capacity. It also ought to consider things like introduced latency or an increase in packet loss 📈 An evaluation MUST assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff 🛑

5.2.1. Existing General-Purpose Congestion Control 🧁

A proposed congestion control algorithm MUST be evaluated when competing against standard IETF congestion controls (e.g., [RFC5681], [RFC9002], and [RFC9438]) 🥊 A proposed congestion control algorithm that has a significantly negative impact on flows using standard congestion control might be suspect, and this aspect should be part of the community's decision making about whether the proposal is suitable 🤔 The community should also consider other non-standard congestion control algorithms that are known to be widely deployed 🌍

Note that this guideline is NOT a requirement for strict Reno or CUBIC friendliness as a prerequisite for a proposed congestion control mechanism to advance to Experimental or Standards Track status. Just so we're clear 🙅‍♀️ For example, HighSpeed TCP is a congestion control mechanism specified in an Experimental RFC, and it is not Reno friendly in all environments 🏎️ When a new congestion control algorithm is deployed, the existing major algorithm deployments need to be considered to avoid severe performance degradation 🛟 Also, this guideline does not constrain interaction with flows that are not best effort 🎀

As an example from an Experimental RFC, fairness with standard TCP is discussed in Sections 4 and 6 of [RFC3649], and using spare capacity is discussed in Sections 6, 11.1, and 12 of [RFC3649] 📚

5.2.2. Real-Time Congestion Control 🎥

General-purpose algorithms need to coexist in the Internet with real-time congestion control algorithms. Those usually have finite throughput requirements (i.e., they don't try to use all available capacity) and stricter latency bounds 🎮 See [RFC8836] for a description of the characteristics of this use case and the resulting requirements 🗂️

[RFC8868] provides suggestions for real-time congestion control design, and [RFC8867] suggests test cases 🧪 [RFC9392] describes some considerations for the RTP Control Protocol (RTCP) 📡 In particular, real-time flows can use less frequent feedback (acknowledgment) than what reliable transports provide 🫧 This document does not change the Informational status of those RFCs 🤍

A proposal for a congestion control algorithm SHOULD consider coexistence with widely deployed real-time congestion control algorithms 💖 Regrettably, at the time of writing (2024), many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion control algorithms have incomplete public specifications 😔 It is hoped that this situation will change 🙏

To the extent that the behavior of widely deployed algorithms is understood, proponents of a proposed congestion control algorithm can analyze and simulate how the proposal interacts with those algorithms 🔍 To the extent that it isn't understood, experiments can be conducted where possible 🧫

Real-time flows can be directed into distinct queues via Differentiated Services Code Points (DSCPs) or other mechanisms, which can substantially reduce the interplay with other traffic 🚦 However, a proposal targeting general Internet use cannot assume this is always the case 🙅‍♀️

Section 7.2 describes the impact of network transport circuit breaker algorithms 🔌 [RFC8083] also defines a minimal set of RTP circuit breakers that operate end-to-end across a path 🛤️ These identify conditions under which a sender needs to stop transmitting media data to protect the network from excessive congestion 🛑 It's expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers ✨

5.2.3. Short and Long Flows 🐣

The effect on short-lived and long-lived flows using other common congestion control algorithms MUST be evaluated, as in Section 5.1.5 🔁

5.3. Other Criteria 🗂️

5.3.1. Differences with Congestion Control Principles 📜

A proposal for a congestion control algorithm MUST clearly explain any deviations from [RFC2914] and [RFC7141] 🫶

5.3.2. Incremental Deployment 🌱

A congestion control algorithm proposal MUST discuss whether it allows for incremental deployment in the targeted environment 🌿 For a mechanism targeted for deployment in the current Internet, the proposal SHOULD discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet 🛜 That includes routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like 🏠

Similarly, if the proposed congestion control algorithm is intended only for specific environments (and not the global Internet), the proposal SHOULD consider how that intention is to be realized 🎯 The IETF community will have to address whether the scope can be enforced by stating the restrictions, or whether additional protocol mechanisms are required to enforce this scoping 🤷‍♀️ The answer will necessarily depend on the proposed change 💭

As an example from an Experimental RFC, deployment issues of Quick-Start are discussed in Sections 10.3 and 10.4 of [RFC4782] 🚀

6. General Use 🌟

The criteria in Section 5 will be evaluated in the scenarios described in the following subsections 🎬 Unless a proposed congestion control algorithm specification of the IETF Stream explicitly forbids use on the public Internet, there MUST be IETF consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress 🗳️

The evaluation of each scenario SHOULD occur over a representative range of bandwidths, delays, and queue depths 📊 Of course, the set of parameters representative of the public Internet will change over time ⏰

These criteria are intended to capture a statistically dominant set of Internet conditions 📈 If a proposed congestion control algorithm has been tested at Internet scale, the results from that deployment are often useful for answering these questions 🌐

6.1. Paths with Tail-Drop Queues 🪣

The performance of a congestion control algorithm is affected by the queue discipline applied at the bottleneck link 🚧 The drop-tail queue discipline (using a FIFO buffer) MUST be evaluated 🫙 See Section 7.1 for evaluation of other queue disciplines 🔜

6.2. Tunnel Behavior 🚇

When a proposed congestion control algorithm relies on explicit signals from the path, the proposal MUST consider the effect of traffic passing through a tunnel, where routers may not be aware of the flow 🕳️

Designers of tunnels and similar encapsulations might need to consider nested congestion control interactions. For example, that happens when the Explicit Congestion Notification (ECN) is used by both an IP and a lower-layer technology [ECN-ENCAPS] 🪆

6.3. Wired Paths 🔌

Wired networks are usually characterized by extremely low rates of packet loss, except for those due to queue drops 💎 They tend to have stable aggregate capacity, usually higher than other types of links, and low non-queueing delay 🧈 Because the properties are relatively simple, wired links are typically used as a "baseline" case, even if they aren't always the bottleneck link in the modern Internet 🏁

6.4. Wireless Paths 📡✨

okay so wired links were the main characters of the early Internet 🎀, but now wireless properties are literally everywhere and they matter SO much for performance 😭🫶. bestie, a proposed congestion control algorithm should be tested in situations where some packet losses happen because of radio effects and NOT just because a router's queue overflowed 📡💅. the link capacity keeps shifting as link conditions change 🦋, and media-access delays plus link-layer retransmissions make round-trip times jittery 🌊. if you want more tea on wireless properties, check out [RFC3819] and Section 16 of [TOOLS] 💖.

7. Special Cases 👑🌈

the criteria in Section 5 get evaluated in the scenarios described in the following subsections 💅, unless the proposed congestion control algorithm specifically excludes its use in a scenario 🙈. for these specific use cases, the IETF community MAY let a proposal move forward even if the criteria give an unsatisfactory result for these scenarios 🫶✨.

in general, measurements from Internet-scale deployments might not show how things behave in each of these scenarios 💀, because these scenarios aren't as ubiquitous as the general-use ones 🧚.

7.1. Active Queue Management (AQM) 🌸

the proposed congestion control algorithm SHOULD be evaluated under a variety of bottleneck-queue disciplines 💜. the effect of an AQM discipline can be hard to detect from Internet evaluation 😭. at a minimum, a proposal should reason about how an algorithm responds to various AQM disciplines 🧠. simulation or empirical results are, of course, valuable 💖.

some of the AQM techniques that might have an impact on a proposed congestion control algorithm include:

  • Flow Queue CoDel (FQ-CoDel) [RFC8290] 🦋;
  • Proportional Integral controller Enhanced (PIE) [RFC8033]; and
  • Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332] ✨.

a proposed congestion control algorithm that sets one of the two ECN-Capable Transport (ECT) codepoints in the IP header can gain the benefits of receiving Explicit Congestion Notification-Congestion Experienced (ECN-CE) signals from an on-path AQM [RFC8087] 🎀. using ECN (see [RFC3168] and [RFC9332]) REQUIRES the congestion control algorithm to react when it receives a packet with an ECN-CE marking 🚨. that reaction needs to be evaluated to confirm the algorithm conforms with the requirements of the ECT codepoint that was used 🔍.

note that evaluating AQM techniques (as opposed to their impact on a specific proposed congestion control algorithm) is out of scope for this document 🙅‍♀️. [RFC7567] describes design considerations for AQMs 📚.

7.2. Operation with the Envelope Set by Network Circuit Breakers 🛡️

some equipment in the network uses an automatic mechanism to continuously monitor how much resource a flow (or an aggregate set of flows) is using [RFC8084] 👀. this kind of network transport circuit breaker can automatically detect excessive congestion 🚨, and when it does, it can terminate the flow(s) or significantly reduce their rate 💀. a well-designed congestion control algorithm ought to react before the flow uses excessive resources 🫶, so it will operate within the envelope set by network transport circuit breaker algorithms 🌈.

7.3. Paths with Varying Delay 🌊

an Internet path can include simple links, where the minimum delay is the propagation delay and any extra delay can be blamed on link buffering 🧃. but this CANNOT be assumed 🙅‍♀️. an Internet path can also include complex subnetworks where the minimum delay changes over different time scales, so the minimum delay isn't stationary 🌀.

varying delay happens when a subnet changes the forwarding path to optimize capacity, resilience, etc. 🦋. it could also come up when a subnet uses a capacity-management method where the available resource gets periodically distributed among the active nodes 🍓. a node might then have to buffer data until an assigned transmission opportunity comes up, or until the physical path changes (for example, when the length of a wireless path changes or when the physical layer switches its mode of operation) 📡. variation also shows up when traffic with a higher priority DSCP preempts transmission of traffic with a lower class 💅. in these cases the delay varies based on external factors, and trying to infer congestion from an increase in delay ends up reducing throughput 😭. this variation over short timescales (jitter) might not be distinguishable from jitter caused by other effects 🤷‍♀️.

a proposed congestion control algorithm SHOULD be evaluated to make sure its operation is robust when there is a significant change in the minimum delay 🫶.

7.4. Internet of Things and Constrained Nodes 🧚

the "Internet of Things" (IoT) is a broad concept, but when evaluating a proposed congestion control algorithm, it's often associated with unique characteristics 🍓. for example, IoT nodes might be more constrained in power, CPU, or other parameters than conventional Internet hosts 🔋. this might place limits on the complexity of any given algorithm 🧠. these power and radio constraints might make the volume of control packets in a given algorithm a key evaluation metric 📊.

extremely low-power links can lead to very low throughput and a low bandwidth-delay product, which is well below the standard operating range of most Internet flows 🐣.

furthermore, many IoT applications do not have a human in the loop 🙈, so they might have weaker latency constraints because they don't relate to a user experience 💤. congestion control algorithms still might need to share the path with other flows that have different constraints 🫶.

7.5. Paths with High Delay 🛰️

authors of a proposed congestion control algorithm ought not to presume that all general Internet paths have a low delay 🐢. some paths include links that add way more delay than a typical Internet path 😭. satellite links often have delays longer than is typical for wired paths [RFC2488] and high-delay-bandwidth products [RFC3649] 🌙.

paths can also present a variable delay, as described in Section 7.3 🌊.

7.6. Misbehaving Nodes 😈

a proposal for a congestion control algorithm SHOULD explore how the algorithm performs with non-compliant senders, receivers, or routers 🕵️‍♀️. the proposal should also explore how a proposed congestion control algorithm performs with outside attackers 🥷. this can be super important for proposed congestion control algorithms 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] 📖. 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.7. Extreme Packet Reordering 🔀

authors of a proposed congestion control algorithm ought not to presume that all general Internet paths reliably deliver packets in order 🙃. [RFC4653] discusses the effect of extreme packet reordering 📚.

7.8. Transient Events ⚡

a proposal for a congestion control algorithm SHOULD consider how it would perform in the presence of transient events, such as a sudden onset of congestion, a routing change, or a mobility event 🌪️. routing changes, link disconnections, intermittent link connectivity, and mobility are discussed in more detail in Section 16 of [TOOLS] 🗺️.

as an example from an Experimental RFC, a response to transient events is discussed in Section 9.2 of [RFC4782] 🧐.

7.9. Sudden Changes in the Path 🛤️

an IETF transport is not tied to a specific Internet path or type of path 🌍. the set of routers that form a path can and do change over time 🔄, and this will cause the properties of the path to change over time too 🎢. a proposal for a congestion control algorithm MUST evaluate the impact of changes in the path and be robust to changes in path characteristics on the interval of common Internet rerouting intervals 🚨💖.

7.10. Multipath Transport 🛣️

multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender 🪞. a multipath sender can schedule which packets travel on which of its active paths 📬. this enables a trade-off between timeliness and reliability ⚖️. there are various ways multipath techniques can be used 🌈.

one example use is failover from one path to another when the original path is no longer viable or gives inferior performance 🔁. designs need to track the congestion state of each path independently and demonstrate independent congestion control for each path being used 🧩. authors of a proposed multipath congestion control algorithm that implements path failover MUST evaluate the harm to performance resulting from a change in the path and show that this does not result in flow starvation 🚨. synchronization of failover (for example, where multiple flows change their path on similar time frames) can also contribute to harm and/or reduce fairness 😬. these effects also ought to be evaluated 🔍.

another example use is concurrent multipath, where the transport protocol simultaneously schedules a flow to aggregate the capacity across multiple paths 🚀. the Internet provides no guarantee that different paths (for example, ones using different endpoint addresses) are disjoint 🫣. this introduces additional implications 🧵. a congestion control algorithm proposal MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck or share resources that are coupled between different paths, such as an overall capacity limit 🚨. a proposal SHOULD consider the potential for harm to other flows 💅. synchronization of congestion control mechanisms (for example, where multiple flows change their behavior on similar time frames) can also contribute to harm and/or reduce fairness 😭. these effects also ought to be evaluated 🫶.

at the time of writing (2024), there are currently no Standards Track RFCs for concurrent multipath, but there is an Experimental RFC [RFC6356] that specifies a concurrent multipath congestion control algorithm for Multipath TCP (MPTCP) [RFC8684] 🎀.

7.11. Data Centers 🏢

data centers are characterized by very low latencies (< 2 ms) ⚡. many workloads involve bursty traffic where many nodes complete a task at the same time 💥. as a controlled environment, data centers often deploy fabrics that employ rich signaling from switches to endpoints 📡. furthermore, the operator can often limit the number of operating congestion control algorithms 🔒.

for these reasons, data center congestion controls are often distinct from those running elsewhere on the Internet (see Section 4) 🧩. a proposed congestion control algorithm need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which algorithms are expected to safely coexist with it 🤝.

8. Security Considerations 🔐🚨

this document does not represent a change to any aspect of the TCP/IP protocol suite, so it does not directly impact Internet security 🙌. the implementation of various facets of the Internet's current congestion control algorithms DOES have security implications (for example, as outlined in [RFC5681]) 😱🔐.

a proposal for a congestion control algorithm MUST examine any potential security or privacy issues that may arise from its design 🕵️‍♀️🛡️.

9. IANA Considerations 📋

this document has no IANA actions 🌸.

10. References 📚💜

10.1. Normative References ✨

Okay bestie, these are the must-read docs that this one leans on 📚🫶 Here they are, with every detail kept exactly as-is:

10.2. Informative References 📚✨

Okay, now the bibliography for the fun, background reading, the stuff that isn't strictly required to implement but is so worth knowing about 🤓💖 Every entry is here exactly as the RFC lists it.

Appendix A. Changes Since RFC 5033 🎀

Ooh, a little changelog for the glow-up 💅 Here's everything that changed since RFC 5033:

  • Examined BCP 14 keywords and consistency with other RFCs
  • Rewrote the "Document Status" section
  • Added QUIC and other more recent congestion control standards
  • Aligned motivation for this work with the CCWG charter
  • Refined discussion of Quick-Start
  • Added criterion for bufferbloat
  • Added text on constrained environments/limited domains and circuit breakers and aligned with other RFCs
  • Added discussion of real-time protocols, short flows, AQM response, and multipath transports
  • Listed properties of wired and wireless networks
  • Added sections addressing IoT and Multicast (noting this is out of scope)

Acknowledgments 🫶

Big shoutouts to the people who made this whole thing happen 💖

Sally Floyd and Mark Allman were the authors of this document's predecessor, [RFC5033], which served the community well for over a decade. Legends, honestly 👑

Thanks to Richard Scheffenegger for helping to get this revision process started 🌸

The editors would like to thank Mohamed Boucadair, Neal Cardwell, Reese Enghardt, Jonathan Lennox, Matt Mathis, Zahed Sarker, Juergen Schoenwaelder, Dave Taht, Sean Turner, Michael Welzl, Magnus Westerlund, and Greg White for suggesting improvements to this document ✨

Discussions with Lars Eggert and Aaron Falk seeded the original [RFC5033]. Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, Colin Perkins, Pekka Savola, members of TSVWG, and participants at the TCP Workshop at Microsoft Research all provided feedback and contributions to that document. It also drew from [RFC5166] 🦋

Contributors 💖

Okay bestie, first up are the contributors 🫶 Christian Huitema from Private Octopus, Inc. He's reachable at huitema@huitema.net, and he gets a big shoutout for helping make this happen ✨

Authors' Addresses 🎀

These are the people who wrote it, and they're the ones to contact about it 💅

Martin Duke (editor) is at Google LLC 🦋 His email is martin.h.duke@gmail.com.

Godred Fairhurst (editor) is at University of Aberdeen 🌸 His email is gorry@erg.abdn.ac.uk.

📦 where this page comes from