rfc9743v1.txt   rfc9743.txt 
skipping to change at line 13 skipping to change at line 13
Request for Comments: 9743 Google LLC Request for Comments: 9743 Google LLC
BCP: 133 G. Fairhurst, Ed. BCP: 133 G. Fairhurst, Ed.
Obsoletes: 5033 University of Aberdeen Obsoletes: 5033 University of Aberdeen
Category: Best Current Practice March 2025 Category: Best Current Practice March 2025
ISSN: 2070-1721 ISSN: 2070-1721
Specifying New Congestion Control Algorithms Specifying New Congestion Control Algorithms
Abstract Abstract
This document replaces RFC 5033, which discusses the principles and RFC 5033 discusses the principles and guidelines for standardizing
guidelines for standardizing new congestion control algorithms. It new congestion control algorithms. This document obsoletes RFC 5033
seeks to ensure that proposed congestion control algorithms operate to reflect changes in the congestion control landscape by providing a
without harm and efficiently alongside other algorithms in the global framework for the development and assessment of congestion control
mechanisms, promoting stability across diverse network paths. This
document seeks to ensure that proposed congestion control algorithms
operate efficiently and without harm when used in the global
Internet. It emphasizes the need for comprehensive testing and Internet. It emphasizes the need for comprehensive testing and
validation to prevent adverse interactions with existing flows. This validation to prevent adverse interactions with existing flows.
document provides a framework for the development and assessment of
congestion control mechanisms, promoting stability across diverse
network environments. It obsoletes RFC 5033 to reflect changes in
the congestion control landscape.
Status of This Memo Status of This Memo
This memo documents an Internet Best Current Practice. This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841. BCPs is available in Section 2 of RFC 7841.
skipping to change at line 98 skipping to change at line 97
7.7. Extreme Packet Reordering 7.7. Extreme Packet Reordering
7.8. Transient Events 7.8. Transient Events
7.9. Sudden Changes in the Path 7.9. Sudden Changes in the Path
7.10. Multipath Transport 7.10. Multipath Transport
7.11. Data Centers 7.11. Data Centers
8. Security Considerations 8. Security Considerations
9. IANA Considerations 9. IANA Considerations
10. References 10. References
10.1. Normative References 10.1. Normative References
10.2. Informative References 10.2. Informative References
Appendix A. Changes Since RFC 5033
Acknowledgments Acknowledgments
Contributors Contributors
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
This document provides guidelines for the IETF to use when evaluating This document provides guidelines for the IETF to use when evaluating
a proposed congestion control algorithm that differs from the general a proposed congestion control algorithm that differs from the general
congestion control principles outlined in [RFC2914]. The guidance is congestion control principles outlined in [RFC2914]. The guidance is
intended to be useful to authors proposing congestion control intended to be useful to authors proposing congestion control
skipping to change at line 153 skipping to change at line 153
Multicast congestion control is a considerably less mature field of Multicast congestion control is a considerably less mature field of
study and is not in the scope of this document. However, Section 4 study and is not in the scope of this document. However, Section 4
of [RFC8085] provides additional guidelines for multicast and of [RFC8085] provides additional guidelines for multicast and
broadcast usage of UDP. broadcast usage of UDP.
Congestion control algorithms have been developed outside of the Congestion control algorithms have been developed outside of the
IETF, including at least two that saw large scale deployment. These IETF, including at least two that saw large scale deployment. These
include CUBIC [HRX08] and Bottleneck Bandwidth and Round-trip include CUBIC [HRX08] and Bottleneck Bandwidth and Round-trip
propagation time (BBR) [BBR]. propagation time (BBR) [BBR].
CUBIC was documented in a research publication in 2007 [HRX08], and CUBIC was documented in a research publication in 2008 [HRX08], and
was then adopted as the default congestion control algorithm for the was then adopted as the default congestion control algorithm for the
TCP implementation in Linux. It was already used in a significant TCP implementation in Linux. It was already used in a significant
fraction of TCP connections over the Internet before being documented fraction of TCP connections over the Internet before being documented
in an Informational Internet-Draft in 2015, published as an in an Internet-Draft in 2015, and published as an Informational RFC
Informational RFC in 2017 as [RFC8312] and then as a Proposed in 2017 as [RFC8312] and then as a Proposed Standard in 2023
Standard in 2023 [RFC9438]. [RFC9438].
At the time of writing, BBR is being developed as an internal At the time of writing, BBR is being developed as an internal
research project by Google, with the first implementation contributed research project by Google, with the first implementation contributed
to Linux kernel 4.19 in 2016. It was described in an Internet-Draft to Linux kernel 4.19 in 2016. BBR was described in an Internet-Draft
in 2018, which has been regularly updated to document the evolving in 2018 and was first presented in the IRTF Internet Congestion
versions of the algorithm [BBR]. BBR is currently widely used for Control Research Group. It has since been regularly updated to
Google services using either TCP or QUIC and is also widely deployed document the evolving versions of the algorithm [BBR]. BBR is
outside of Google. currently widely used for Google services using either TCP or QUIC
and is also widely deployed outside of Google.
We cannot say whether the original authors of [RFC5033] expected that We cannot say whether the original authors of [RFC5033] expected that
developers would be waiting for IETF review before widely deploying a developers would be waiting for IETF review before widely deploying a
new congestion control algorithm over the Internet, but the examples new congestion control algorithm over the Internet, but the examples
of CUBIC and BBR illustrate that deployment of new algorithms is not, of CUBIC and BBR illustrate that deployment of new algorithms is not,
in fact, gated by the publication of the algorithm as an RFC. in fact, gated by the publication of the algorithm as an RFC.
Nevertheless, a specification for a congestion control algorithm Nevertheless, a specification for a congestion control algorithm
provides a number of advantages: provides a number of advantages:
* It can help implementers, operators, and other interested parties * It can help implementers, operators, and other interested parties
develop a shared understanding of how the algorithm works and how develop a shared understanding of how the algorithm works and how
it is expected to behave in various scenarios and configurations. it is expected to behave in various scenarios and configurations.
* It can help potential contributors understand the algorithm, which * It can help potential contributors understand the algorithm, which
can make it easier for them to suggest improvements and/or can make it easier for them to suggest improvements and/or
identify limitations. Furthermore, the specification can help identify limitations. Furthermore, the specification can help
multiple contributors align on a consensus change to the multiple contributors align on a consensus change to the
algorithm. algorithm.
* A specification that is accessible to anyone can circumvent the * It can help (by being accessible to anyone) to circumvent the
issue that some implementers may be unable to read open-source issue that some implementers may be unable to read open-source
reference implementations due to the constraints of some open- reference implementations due to the constraints of some open-
source licenses. source licenses.
Beyond helping develop specific algorithm proposals, guidelines can Beyond helping develop specific algorithm proposals, guidelines can
also serve as a reminder to potential inventors and developers of the also serve as a reminder to potential inventors and developers of the
multiple facets of the congestion control problem. multiple facets of the congestion control problem.
The evaluation guidelines in this document are intended to be The evaluation guidelines in this document are intended to be
consistent with the congestion control principles from [RFC2914] consistent with the congestion control principles from [RFC2914]
skipping to change at line 264 skipping to change at line 265
Before a proposed congestion control algorithm is published as an Before a proposed congestion control algorithm is published as an
Experimental or Standards Track RFC, the community SHOULD gain Experimental or Standards Track RFC, the community SHOULD gain
practical experience with implementations and experience using the practical experience with implementations and experience using the
algorithm. Implementations by independent teams can help provide algorithm. Implementations by independent teams can help provide
assurance that a specification has avoided assumptions or ambiguity. assurance that a specification has avoided assumptions or ambiguity.
An independent evaluation by multiple teams helps provide assurance An independent evaluation by multiple teams helps provide assurance
that the design meets the evaluation criteria and can assess typical that the design meets the evaluation criteria and can assess typical
interactions with other traffic. This evaluation could use an interactions with other traffic. This evaluation could use an
emulated laboratory environment or a controlled experiment (within a emulated laboratory environment or a controlled experiment (within a
limited domain or at the Internet scale). Evidence of results is limited domain or at Internet scale). When a working group is trying
normally considered by the working group in deciding if a to decide if a proposed specification is ready for publication, it
specification is ready for publication and ought to be documented in will normally consider evidence of results. This ought to be
any request for the working group to publish the specification. documented in any request from the working group to publish the
specification.
Publication might occur without multiple implementations if a single A congestion control algorithm without multiple implementations might
implementation is widely used, open source, and shown to have a still be published as an RFC if a single implementation is widely
positive impact on the Internet, particularly if the target status is used, open source, and shown to have a positive impact on the
Experimental. Internet, particularly if the target status is Experimental.
3.2. Document-Status Guidelines 3.2. Document-Status Guidelines
The guidelines in this document apply to specifications of congestion The guidelines in this document apply to specifications of congestion
control algorithms that seek publication as an RFC via the IETF control algorithms that seek publication as an RFC via the IETF
Stream with an Experimental or Standards Track status. The Stream with an Experimental or Standards Track status. The
evaluation of either status involves the same questions, but with evaluation of either status involves the same questions, but with
different expectations for both the answers and the degree of different expectations for both the answers and the degree of
certainty of those answers. certainty of those answers.
Specifications on congestion control algorithms without empirical Specifications of congestion control algorithms without empirical
evidence of Internet-scale deployment MUST seek Experimental status, evidence of Internet-scale deployment MUST seek Experimental status,
unless they are not targeted for general use. unless they are not targeted for general use. Algorithms not
targeted at general use do not require Internet-scale data.
Specifications that seek to be published as Experimental IETF Stream Specifications that seek to be published as Experimental IETF Stream
RFCs ought to explain the reason for the status and what further RFCs ought to explain the reason for the status and what further
information would be required to progress to a Standards Track RFC. information would be required to progress to a Standards Track RFC.
For example, Section 12 of [RFC6928] provides "Usage and Deployment For example, Section 12 of [RFC6928] provides "Usage and Deployment
Recommendations" that describe the experiments expected by the TCPM Recommendations" that describe the experiments expected by the TCPM
Working Group. Section 4 of [RFC4614] provides other examples of Working Group. Section 4 of [RFC7414] provides other examples of
extensions that were considered experimental when the specification extensions that were considered experimental when the specification
was published (note that [RFC4614] has since been obsoleted by was published.
[RFC7414]).
Experimental specifications SHOULD NOT be deployed as a default. Experimental specifications SHOULD NOT be deployed as a default.
They SHOULD only be deployed in situations where they are being They SHOULD only be deployed in situations where they are being
actively measured and where it is possible to deactivate them if actively measured and where it is possible to deactivate them if
there are signs of pathological behavior. there are signs of pathological behavior.
Specifications on congestion control algorithms with a record of Specifications of congestion control algorithms with a record of
measured Internet-scale deployment MAY directly seek Standards Track measured Internet-scale deployment MAY directly seek Standards Track
status if there is solid data that reflects that the algorithm is status if there is solid data that reflects that the algorithm is
safe and the design is stable, guided by the considerations in safe and the design is stable, guided by the considerations in
Section 6. However, the existence of this data does not waive the Section 6. However, the existence of this data does not waive the
other considerations in this document. other considerations in this document.
Each specification submitted for publication as an RFC is REQUIRED to Each specification submitted for publication as an RFC is REQUIRED to
include a statement in the abstract indicating whether or not there include a statement in the abstract indicating whether or not there
is IETF consensus that the proposed congestion control algorithm is is IETF consensus that the proposed congestion control algorithm is
considered safe for use on the Internet. Each such specification is considered safe for use on the Internet. Each such specification is
skipping to change at line 371 skipping to change at line 373
Algorithms that rely on specific functions or configurations in the Algorithms that rely on specific functions or configurations in the
network need to provide a reference or specification for these network need to provide a reference or specification for these
functions (such as an RFC or another stable specification). For functions (such as an RFC or another stable specification). For
publication of a specification of one of these algorithms to proceed, publication of a specification of one of these algorithms to proceed,
the IETF will need to consider whether a working group exists that the IETF will need to consider whether a working group exists that
can properly assess the network-layer aspects and their interaction can properly assess the network-layer aspects and their interaction
with the congestion control. with the congestion control.
In evaluating a new proposal for use in a controlled environment, the In evaluating a new proposal for use in a controlled environment, the
IETF needs to understand the usage, e.g., how the usage is scoped to IETF community needs to understand the usage (e.g., how the usage is
the controlled environment, whether the algorithm will share scoped to the controlled environment), whether the algorithm will
resources with Internet traffic, and consider what could happen if share resources with Internet traffic, and what could happen if used
used in a protocol that is bridged across an Internet path. in a protocol that is bridged across an Internet path. Algorithms
Algorithms that are designed to be confined to a controlled that are designed to be confined to a controlled environment and are
environment and are not intended for use in the general Internet not intended for use in the general Internet might instead seek real-
might instead seek real-world data for those environments. In such world data for those environments. In such cases, the evaluation
cases, the evaluation criteria in the remainder of this document criteria in the remainder of this document might not apply.
might not apply.
5. Evaluation Criteria 5. Evaluation Criteria
As previously noted, authors of a specification on a congestion As previously noted, authors of a specification on a congestion
control algorithm are expected to conduct a comprehensive evaluation control algorithm are expected to conduct a comprehensive evaluation
of the advantages and disadvantages of any congestion control of the advantages and disadvantages of any congestion control
algorithms presented to the IETF community. The following guidelines algorithms presented to the IETF community. The following guidelines
are intended to assist authors and the community in this endeavor. are intended to assist authors and the community in this endeavor.
While these guidelines provide a helpful framework, they should not While these guidelines provide a helpful framework, they should not
be regarded as an exhaustive checklist as concerns beyond the scope be regarded as an exhaustive checklist as concerns beyond the scope
skipping to change at line 411 skipping to change at line 412
practical limitations on carrying out an evaluation of the criteria. practical limitations on carrying out an evaluation of the criteria.
The requirement that the community consider a criterion does not The requirement that the community consider a criterion does not
imply that the result needs to be described in an RFC: there is no imply that the result needs to be described in an RFC: there is no
formal requirement to document the results, although normal IETF formal requirement to document the results, although normal IETF
policies for archiving proceedings will provide a record. policies for archiving proceedings will provide a record.
This document, except where otherwise noted, does not provide This document, except where otherwise noted, does not provide
normative guidance on the acceptable thresholds for any of these normative guidance on the acceptable thresholds for any of these
criteria. Instead, the community will use these evaluations as an criteria. Instead, the community will use these evaluations as an
input when considering whether to progress the proposed algorithm. input when considering whether to progress the proposed algorithm
specification in the publication process.
5.1. Single Algorithm Behavior 5.1. Single Algorithm Behavior
The criteria in the following subsections evaluate the congestion The criteria in the following subsections evaluate the congestion
control algorithm when one or more flows using that algorithm share a control algorithm when one or more flows using that algorithm share a
bottleneck link (i.e., with no flows using a differing congestion bottleneck link (i.e., with no flows using a differing congestion
control algorithm). control algorithm).
5.1.1. Protection Against Congestion Collapse 5.1.1. Protection Against Congestion Collapse
skipping to change at line 441 skipping to change at line 443
times of extreme (and persistent) congestion. times of extreme (and persistent) congestion.
If full backoff is used, this test does not require that the If full backoff is used, this test does not require that the
mechanism be identical to that of TCP (see [RFC6298] and [RFC8961]). mechanism be identical to that of TCP (see [RFC6298] and [RFC8961]).
For example, this does not preclude full backoff mechanisms that For example, this does not preclude full backoff mechanisms that
would give flows with different round-trip times comparable capacity would give flows with different round-trip times comparable capacity
during backoff. during backoff.
5.1.2. Protection Against Bufferbloat 5.1.2. Protection Against Bufferbloat
A congestion control algorithm should try to avoid maintaining A congestion control algorithm ought to try to avoid maintaining
excessive queues in the network. Exactly how the algorithm achieves excessive queues in the network. Exactly how the algorithm achieves
this is algorithm specific; see [RFC8961] and [RFC8085] for this is algorithm specific; see [RFC8961] and [RFC8085] for
requirements. requirements.
"Bufferbloat" refers to the building of excessive queues in the "Bufferbloat" refers to the building of excessive queues in the
network [BUFFERBLOAT]. Many network routers are configured with very network [BUFFERBLOAT]. Many network routers are configured with very
large buffers. The Standards Track RFCs [RFC5681] and [RFC9438] large buffers. The Standards Track RFCs [RFC5681] and [RFC9438]
describing the Reno and CUBIC congestion control algorithms describe the Reno and CUBIC congestion control algorithms
(respectively) send at progressively higher rates until a First In, (respectively), which send at progressively higher rates until a
First Out (FIFO) buffer completely fills; then packet losses occur. First In, First Out (FIFO) buffer completely fills; then packet
Every connection passing through that bottleneck experiences losses occur. Every connection passing through that bottleneck
increased latency due to the high buffer occupancy. This adds experiences increased latency due to the high buffer occupancy. This
unwanted latency that negatively impacts highly interactive adds unwanted latency that negatively impacts highly interactive
applications such as videoconferencing or games, but it also affects applications such as videoconferencing or games, but it also affects
routine web browsing and video playing. routine web browsing and video playing.
This problem has been widely discussed since 2011 [BUFFERBLOAT], but This problem has been widely discussed since 2011 [BUFFERBLOAT], but
was not discussed in the congestion control principles published in was not discussed in the congestion control principles published in
September 2002 [RFC2914]. The Reno and CUBIC congestion control September 2002 [RFC2914]. The Reno and CUBIC congestion control
algorithms do not address this problem, but a new congestion control algorithms do not address this problem, but a new congestion control
algorithm has the opportunity to improve the state of the art. algorithm has the opportunity to improve the state of the art.
5.1.3. Protection Against High Packet Loss 5.1.3. Protection Against High Packet Loss
A congestion control algorithm should try to avoid causing A congestion control algorithm needs to avoid causing excessively
excessively high rates of packet loss. To accomplish this, it should high rates of packet loss. To accomplish this, it should avoid
avoid excessive increases in sending rate and reduce its sending rate excessive increases in sending rate and reduce its sending rate if
if experiencing high packet loss. experiencing high packet loss.
The first version of the BBR algorithm [BBRv1] failed this The first version of the BBR algorithm [BBRv1] failed this
requirement. Experimental evaluation [BBRv1-EVALUATION] showed that requirement. Experimental evaluation [BBRv1-EVALUATION] showed that
it caused a sustained rate of packet loss when multiple BBRv1 flows 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 shared a bottleneck and the buffer size was less than roughly one and
a half times the Bandwidth Delay Product (BDP). This was a half times the Bandwidth Delay Product (BDP). This was
unsatisfactory, and, indeed, further versions provided a fix for this unsatisfactory, and, indeed, further versions provided a fix for this
aspect of BBR [BBR]. aspect of BBR [BBR].
This requirement does not imply that the algorithm should react to This requirement does not imply that the algorithm should react to
packet losses in exactly the same way as congestion control packet losses in exactly the same way as congestion control
algorithms described in current Standards Track RFCs (e.g., algorithms described in current Standards Track RFCs (e.g.,
[RFC5681]). [RFC5681]).
5.1.4. Fairness Within the Proposed Congestion Control Algorithm 5.1.4. Fairness Within the Proposed Congestion Control Algorithm
When multiple competing flows all use the same proposed congestion When multiple competing flows all use the same proposed congestion
control algorithm, the specification should explore how the capacity control algorithm, the evaluation should explore how the capacity is
is shared among the competing flows. Capacity fairness can be shared among the competing flows. Capacity fairness can be important
important when a small number of similar flows compete to fill a when a small number of similar flows compete to fill a bottleneck.
bottleneck. However, it can also not be useful, for example, when However, it can also not be useful, for example, when comparing flows
comparing flows that seek to send at different rates or if some of that seek to send at different rates or if some of the flows do not
the flows do not last sufficiently long to approach asymptotic last sufficiently long to approach asymptotic behavior.
behavior.
5.1.5. Short Flows 5.1.5. Short Flows
A great deal of congestion control analysis concerns the steady-state A great deal of congestion control analysis concerns the steady-state
behavior of long flows. However, many Internet flows are relatively behavior of long flows. However, many Internet flows are relatively
short lived. Many short-lived flows today remain in the "slow start" short lived. Many short-lived flows today remain in the "slow start"
mode of operation [RFC5681] that commonly features exponential mode of operation [RFC5681] that commonly features exponential
congestion window growth because the flow never experiences congestion window growth because the flow never experiences
congestion (e.g., packet loss). congestion (e.g., packet loss).
A proposed congestion control algorithm MUST consider how new and A proposal for a congestion control algorithm MUST consider how new
short-lived flows affect long-lived flows, and vice versa. and short-lived flows affect long-lived flows, and vice versa.
5.2. Mixed Algorithm Behavior 5.2. Mixed Algorithm Behavior
The mixed algorithm behavior criteria evaluate the interaction of the The mixed algorithm behavior criteria evaluate the interaction of the
proposed congestion control algorithms being specified with commonly proposed congestion control algorithms being specified with commonly
deployed congestion control algorithms. deployed congestion control algorithms.
In contexts where differing congestion control algorithms are used, In contexts where differing congestion control algorithms are used,
it is important to understand whether the proposed congestion control it is important to understand whether the proposed congestion control
algorithm could result in more harm than algorithms published in algorithm could result in more harm than algorithms published in
skipping to change at line 540 skipping to change at line 541
congestion control might be suspect, and this aspect should be part congestion control might be suspect, and this aspect should be part
of the community's decision making with regards to the suitability of of the community's decision making with regards to the suitability of
the proposed congestion control algorithm. The community should also the proposed congestion control algorithm. The community should also
consider other non-standard congestion control algorithms that are consider other non-standard congestion control algorithms that are
known to be widely deployed. known to be widely deployed.
Note that this guideline is not a requirement for strict Reno or Note that this guideline is not a requirement for strict Reno or
CUBIC friendliness as a prerequisite for a proposed congestion CUBIC friendliness as a prerequisite for a proposed congestion
control mechanism to advance to Experimental or Standards Track control mechanism to advance to Experimental or Standards Track
status. As an example, HighSpeed TCP is a congestion control status. As an example, HighSpeed TCP is a congestion control
mechanism that is specified in an Experimental RFC and is not TCP mechanism that is specified in an Experimental RFC and is not Reno
friendly in all environments. When a new congestion control friendly in all environments. When a new congestion control
algorithm is deployed, the existing major algorithm deployments need algorithm is deployed, the existing major algorithm deployments need
to be considered to avoid severe performance degradation. Note that to be considered to avoid severe performance degradation. Note that
this guideline does not constrain the interaction with flows that are this guideline does not constrain the interaction with flows that are
not best effort. not best effort.
As an example from an Experimental RFC, fairness with standard TCP is As an example from an Experimental RFC, fairness with standard TCP is
discussed in Sections 4 and 6 of [RFC3649], and using spare capacity discussed in Sections 4 and 6 of [RFC3649], and using spare capacity
is discussed in Sections 6, 11.1, and 12 of [RFC3649]. is discussed in Sections 6, 11.1, and 12 of [RFC3649].
skipping to change at line 567 skipping to change at line 568
for a description of the characteristics of this use case and the for a description of the characteristics of this use case and the
resulting requirements. resulting requirements.
[RFC8868] provides suggestions for real-time congestion control [RFC8868] provides suggestions for real-time congestion control
design and [RFC8867] suggests test cases. [RFC9392] describes some design and [RFC8867] suggests test cases. [RFC9392] describes some
considerations for the RTP Control Protocol (RTCP). In particular, considerations for the RTP Control Protocol (RTCP). In particular,
real-time flows can use less frequent feedback (acknowledgment) than real-time flows can use less frequent feedback (acknowledgment) than
that provided by reliable transports. This document does not change that provided by reliable transports. This document does not change
the Informational status of those RFCs. the Informational status of those RFCs.
A proposed congestion control algorithm SHOULD consider coexistence A proposal for a congestion control algorithm SHOULD consider
with widely deployed real-time congestion control algorithms. coexistence with widely deployed real-time congestion control
Regrettably, at the time of writing (2024), many algorithms with algorithms. Regrettably, at the time of writing (2024), many
detailed public specifications are not widely deployed, while many algorithms with detailed public specifications are not widely
widely deployed real-time congestion control algorithms have deployed, while many widely deployed real-time congestion control
incomplete public specifications. It is hoped that this situation algorithms have incomplete public specifications. It is hoped that
will change. this situation will change.
To the extent that behavior of widely deployed algorithms is To the extent that behavior of widely deployed algorithms is
understood, proponents of a proposed congestion control algorithm can understood, proponents of a proposed congestion control algorithm can
analyze and simulate a proposal's interaction with those algorithms. analyze and simulate a proposal's interaction with those algorithms.
To the extent that they are not, experiments can be conducted where To the extent that they are not, experiments can be conducted where
possible. possible.
Real-time flows can be directed into distinct queues via Real-time flows can be directed into distinct queues via
Differentiated Services Code Points (DSCPs) or other mechanisms, Differentiated Services Code Points (DSCPs) or other mechanisms,
which can substantially reduce the interplay with other traffic. which can substantially reduce the interplay with other traffic.
skipping to change at line 605 skipping to change at line 606
5.2.3. Short and Long Flows 5.2.3. Short and Long Flows
The effect on short-lived and long-lived flows using other common The effect on short-lived and long-lived flows using other common
congestion control algorithms MUST be evaluated, as in Section 5.1.5. congestion control algorithms MUST be evaluated, as in Section 5.1.5.
5.3. Other Criteria 5.3. Other Criteria
5.3.1. Differences with Congestion Control Principles 5.3.1. Differences with Congestion Control Principles
A proposed congestion control algorithm MUST clearly explain any A proposal for a congestion control algorithm MUST clearly explain
deviations from [RFC2914] and [RFC7141]. any deviations from [RFC2914] and [RFC7141].
5.3.2. Incremental Deployment 5.3.2. Incremental Deployment
A congestion control algorithm proposal MUST discuss whether it A congestion control algorithm proposal MUST discuss whether it
allows for incremental deployment in the targeted environment. For a allows for incremental deployment in the targeted environment. For a
mechanism targeted for deployment in the current Internet, the mechanism targeted for deployment in the current Internet, the
proposal SHOULD discuss what is known (if anything) about the correct proposal SHOULD discuss what is known (if anything) about the correct
operation of the mechanisms with some of the equipment in the current operation of the mechanisms with some of the equipment in the current
Internet (e.g., routers, transparent proxies, WAN optimizers, Internet (e.g., routers, transparent proxies, WAN optimizers,
intrusion detection systems, home routers, and the like). intrusion detection systems, home routers, and the like).
skipping to change at line 719 skipping to change at line 720
Some of the AQM techniques that might have an impact on a proposed Some of the AQM techniques that might have an impact on a proposed
congestion control algorithm include: congestion control algorithm include:
* Flow Queue CoDel (FQ-CoDel) [RFC8290]; * Flow Queue CoDel (FQ-CoDel) [RFC8290];
* Proportional Integral controller Enhanced (PIE) [RFC8033]; and * Proportional Integral controller Enhanced (PIE) [RFC8033]; and
* Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332]. * Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332].
A proposed congestion control algorithm that sets one of the two A proposed congestion control algorithm that sets one of the two ECN-
Explicit Congestion Transport (ECT) codepoints in the IP header can Capable Transport (ECT) codepoints in the IP header can gain the
gain the benefits of receiving Explicit Congestion Notification - benefits of receiving Explicit Congestion Notification-Congestion
Congestion Experienced (ECN-CE) signals from an on-path AQM Experienced (ECN-CE) signals from an on-path AQM [RFC8087]. Use of
[RFC8087]. Use of ECN (see [RFC3168] and [RFC9332]) requires the ECN (see [RFC3168] and [RFC9332]) requires the congestion control
congestion control algorithm to react when it receives a packet with algorithm to react when it receives a packet with an ECN-CE marking.
an ECN-CE marking. This reaction needs to be evaluated to confirm This reaction needs to be evaluated to confirm that the algorithm
that the algorithm conforms with the requirements of the ECT conforms with the requirements of the ECT codepoint that was used.
codepoint that was used.
Note that evaluation of AQM techniques -- as opposed to their impact Note that evaluation of AQM techniques -- as opposed to their impact
on a specific proposed congestion control algorithm -- is out of on a specific proposed congestion control algorithm -- is out of
scope of this document. [RFC7567] describes design considerations scope of this document. [RFC7567] describes design considerations
for AQMs. for AQMs.
7.2. Operation with the Envelope Set by Network Circuit Breakers 7.2. Operation with the Envelope Set by Network Circuit Breakers
Some equipment in the network uses an automatic mechanism to Some equipment in the network uses an automatic mechanism to
continuously monitor the use of resources by a flow or aggregate set continuously monitor the use of resources by a flow or aggregate set
skipping to change at line 791 skipping to change at line 791
might make the volume of control packets in a given algorithm a key might make the volume of control packets in a given algorithm a key
evaluation metric. evaluation metric.
Extremely low-power links can lead to very low throughput and a low Extremely low-power links can lead to very low throughput and a low
bandwidth-delay product, which is well below the standard operating bandwidth-delay product, which is well below the standard operating
range of most Internet flows. range of most Internet flows.
Furthermore, many IoT applications do not a have a human in the loop; Furthermore, many IoT applications do not a have a human in the loop;
therefore, they might have weaker latency constraints because they do therefore, they might have weaker latency constraints because they do
not relate to a user experience. Congestion control algorithms still not relate to a user experience. Congestion control algorithms still
may need to share the path with other flows with different might need to share the path with other flows with different
constraints. constraints.
7.5. Paths with High Delay 7.5. Paths with High Delay
A proposed congestion control algorithm ought not to presume that all Authors of a proposed congestion control algorithm ought not to
general Internet paths have a low delay. Some paths include links presume that all general Internet paths have a low delay. Some paths
that contribute much more delay than for a typical Internet path. include links that contribute much more delay than for a typical
Satellite links often have delays longer than is typical for wired Internet path. Satellite links often have delays longer than is
paths [RFC2488] and high-delay-bandwidth products [RFC3649]. typical for wired paths [RFC2488] and high-delay-bandwidth products
[RFC3649].
Paths can also present a variable delay as described in Section 7.3. Paths can also present a variable delay as described in Section 7.3.
7.6. Misbehaving Nodes 7.6. Misbehaving Nodes
A proposed congestion control algorithm SHOULD explore how the A proposal for a congestion control algorithm SHOULD explore how the
algorithm performs with non-compliant senders, receivers, or routers. algorithm performs with non-compliant senders, receivers, or routers.
In addition, the proposal should explore how a proposed congestion In addition, the proposal should explore how a proposed congestion
control algorithm performs with outside attackers. This can be control algorithm performs with outside attackers. This can be
particularly important for proposed congestion control algorithms particularly important for proposed congestion control algorithms
that involve explicit feedback from routers along the path. that involve explicit feedback from routers along the path.
As an example from an Experimental RFC, performance with misbehaving As an example from an Experimental RFC, performance with misbehaving
nodes and outside attackers is discussed in Sections 9.4, 9.5, and nodes and outside attackers is discussed in Sections 9.4, 9.5, and
9.6 of [RFC4782]. This includes discussion of: 9.6 of [RFC4782]. This includes discussion of:
skipping to change at line 828 skipping to change at line 829
* collusion between misbehaving routers; * collusion between misbehaving routers;
* misbehaving middleboxes; and * misbehaving middleboxes; and
* the potential use of Quick-Start to attack routers or to tie up * the potential use of Quick-Start to attack routers or to tie up
available Quick-Start bandwidth. available Quick-Start bandwidth.
7.7. Extreme Packet Reordering 7.7. Extreme Packet Reordering
A proposed congestion control algorithm ought not to presume that all Authors of a proposed congestion control algorithm ought not to
general Internet paths reliably deliver packets in order. [RFC4653] presume that all general Internet paths reliably deliver packets in
discusses the effect of extreme packet reordering. order. [RFC4653] discusses the effect of extreme packet reordering.
7.8. Transient Events 7.8. Transient Events
A proposed congestion control algorithm SHOULD consider how it would A proposal for a congestion control algorithm SHOULD consider how it
perform in the presence of transient events such as a sudden onset of would perform in the presence of transient events such as a sudden
congestion, a routing change, or a mobility event. Routing changes, onset of congestion, a routing change, or a mobility event. Routing
link disconnections, intermittent link connectivity, and mobility are changes, link disconnections, intermittent link connectivity, and
discussed in more detail in Section 16 of [TOOLS]. mobility are discussed in more detail in Section 16 of [TOOLS].
As an example from an Experimental RFC, a response to transient As an example from an Experimental RFC, a response to transient
events is discussed in Section 9.2 of [RFC4782]. events is discussed in Section 9.2 of [RFC4782].
7.9. Sudden Changes in the Path 7.9. Sudden Changes in the Path
An IETF transport is not tied to a specific Internet path or type of 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 with path. The set of routers that form a path can and do change with
time. This will cause the properties of the path to change with time. This will cause the properties of the path to change with
respect to time. A proposed congestion control algorithm MUST respect to time. A proposal for a congestion control algorithm MUST
evaluate the impact of changes in the path and be robust to changes evaluate the impact of changes in the path and be robust to changes
in path characteristics on the interval of common Internet rerouting in path characteristics on the interval of common Internet rerouting
intervals. intervals.
7.10. Multipath Transport 7.10. Multipath Transport
Multipath transport protocols permit more than one path to be Multipath transport protocols permit more than one path to be
differentiated and used by a single connection at the sender. A differentiated and used by a single connection at the sender. A
multipath sender can schedule which packets travel on which of its multipath sender can schedule which packets travel on which of its
active paths. This enables a trade-off in timeliness and active paths. This enables a trade-off in timeliness and
skipping to change at line 904 skipping to change at line 905
Data centers are characterized by very low latencies (< 2 ms). Many Data centers are characterized by very low latencies (< 2 ms). Many
workloads involve bursty traffic where many nodes complete a task at workloads involve bursty traffic where many nodes complete a task at
the same time. As a controlled environment, data centers often the same time. As a controlled environment, data centers often
deploy fabrics that employ rich signaling from switches to endpoints. deploy fabrics that employ rich signaling from switches to endpoints.
Furthermore, the operator can often limit the number of operating Furthermore, the operator can often limit the number of operating
congestion control algorithms. congestion control algorithms.
For these reasons, data center congestion controls are often distinct For these reasons, data center congestion controls are often distinct
from those running elsewhere on the Internet (see Section 4). A from those running elsewhere on the Internet (see Section 4). A
proposed congestion control need not coexist well with all other proposed congestion control algorithm need not coexist well with all
algorithms if it is intended for data centers, but the proposal other algorithms if it is intended for data centers, but the proposal
SHOULD indicate which are expected to safely coexist with it. SHOULD indicate which are expected to safely coexist with it.
8. Security Considerations 8. Security Considerations
This document does not represent a change to any aspect of the TCP/IP This document does not represent a change to any aspect of the TCP/IP
protocol suite; therefore, it does not directly impact Internet protocol suite; therefore, it does not directly impact Internet
security. The implementation of various facets of the Internet's security. The implementation of various facets of the Internet's
current congestion control algorithms do have security implications current congestion control algorithms do have security implications
(e.g., as outlined in [RFC5681]). (e.g., as outlined in [RFC5681]).
Proposed congestion control algorithms MUST examine any potential A proposal for a congestion control algorithm MUST examine any
security or privacy issues that may arise from their design. potential security or privacy issues that may arise from their
design.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at line 998 skipping to change at line 1000
[BBRv1-EVALUATION] [BBRv1-EVALUATION]
Hock, M., Bless, R., and M. Zitterbart, "Experimental Hock, M., Bless, R., and M. Zitterbart, "Experimental
evaluation of BBR congestion control", 2017 IEEE 25th evaluation of BBR congestion control", 2017 IEEE 25th
International Conference on Network Protocols (ICNP), International Conference on Network Protocols (ICNP),
DOI 10.1109/ICNP.2017.8117540, 2017, DOI 10.1109/ICNP.2017.8117540, 2017,
<https://ieeexplore.ieee.org/document/8117540>. <https://ieeexplore.ieee.org/document/8117540>.
[BUFFERBLOAT] [BUFFERBLOAT]
Nichols, K. and J. Gettys, "Bufferbloat: Dark Buffers in Nichols, K. and J. Gettys, "Bufferbloat: Dark Buffers in
the Internet", ACM Queue Volume 9, Issue 11, November the Internet", ACM Queue Volume 9, Issue 11,
2011, <https://queue.acm.org/detail.cfm?id=2071893>. DOI 10.1145/2063166.2071893, November 2011,
<https://dl.acm.org/doi/10.1145/2063166.2071893>.
[ECN-ENCAPS] [ECN-ENCAPS]
Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding
Congestion Notification to Protocols that Encapsulate IP", Congestion Notification to Protocols that Encapsulate IP",
BCP 89, RFC 9599, DOI 10.17487/RFC9599, August 2024, BCP 89, RFC 9599, DOI 10.17487/RFC9599, August 2024,
<https://www.rfc-editor.org/info/rfc9599>. <https://www.rfc-editor.org/info/rfc9599>.
[HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: a new TCP-friendly [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: a new TCP-friendly
high-speed TCP variant", ACM SIGOPS Operating Systems high-speed TCP variant", ACM SIGOPS Operating Systems
Review, vol. 42, no. 5, pp. 64-74, Review, vol. 42, no. 5, pp. 64-74,
skipping to change at line 1043 skipping to change at line 1046
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, DOI 10.17487/RFC3819, July 2004, RFC 3819, DOI 10.17487/RFC3819, July 2004,
<https://www.rfc-editor.org/info/rfc3819>. <https://www.rfc-editor.org/info/rfc3819>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>. <https://www.rfc-editor.org/info/rfc4340>.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification
Documents", RFC 4614, DOI 10.17487/RFC4614, September
2006, <https://www.rfc-editor.org/info/rfc4614>.
[RFC4653] Bhandarkar, S., Reddy, A. L. N., Allman, M., and E. [RFC4653] Bhandarkar, S., Reddy, A. L. N., Allman, M., and E.
Blanton, "Improving the Robustness of TCP to Non- Blanton, "Improving the Robustness of TCP to Non-
Congestion Events", RFC 4653, DOI 10.17487/RFC4653, August Congestion Events", RFC 4653, DOI 10.17487/RFC4653, August
2006, <https://www.rfc-editor.org/info/rfc4653>. 2006, <https://www.rfc-editor.org/info/rfc4653>.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
January 2007, <https://www.rfc-editor.org/info/rfc4782>. January 2007, <https://www.rfc-editor.org/info/rfc4782>.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
skipping to change at line 1183 skipping to change at line 1181
for Congestion Control in Interactive Multimedia for Congestion Control in Interactive Multimedia
Conferences", RFC 9392, DOI 10.17487/RFC9392, April 2023, Conferences", RFC 9392, DOI 10.17487/RFC9392, April 2023,
<https://www.rfc-editor.org/info/rfc9392>. <https://www.rfc-editor.org/info/rfc9392>.
[TOOLS] Floyd, S. and E. Kohler, "Tools for the Evaluation of [TOOLS] Floyd, S. and E. Kohler, "Tools for the Evaluation of
Simulation and Testbed Scenarios", Work in Progress, Simulation and Testbed Scenarios", Work in Progress,
Internet-Draft, draft-irtf-tmrg-tools-05, 23 February Internet-Draft, draft-irtf-tmrg-tools-05, 23 February
2008, <https://datatracker.ietf.org/doc/html/draft-irtf- 2008, <https://datatracker.ietf.org/doc/html/draft-irtf-
tmrg-tools-05>. tmrg-tools-05>.
Appendix A. Changes 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 Acknowledgments
Sally Floyd and Mark Allman were the authors of this document's Sally Floyd and Mark Allman were the authors of this document's
predecessor, [RFC5033], which served the community well for over a predecessor, [RFC5033], which served the community well for over a
decade. decade.
Thanks to Richard Scheffenegger for helping to get this revision Thanks to Richard Scheffenegger for helping to get this revision
process started. process started.
The editors would like to thank Mohamed Boucadair, Neal Cardwell, The editors would like to thank Mohamed Boucadair, Neal Cardwell,
 End of changes. 36 change blocks. 
109 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.48.