rfc9743.original   rfc9743.txt 
CCWG M. Duke, Ed. Internet Engineering Task Force (IETF) M. Duke, Ed.
Internet-Draft Google LLC Request for Comments: 9743 Google LLC
Obsoletes: 5033 (if approved) G. Fairhurst, Ed. BCP: 133 G. Fairhurst, Ed.
Intended status: Best Current Practice University of Aberdeen Obsoletes: 5033 University of Aberdeen
Expires: 22 February 2025 21 August 2024 Category: Best Current Practice March 2025
ISSN: 2070-1721
Specifying New Congestion Control Algorithms Specifying New Congestion Control Algorithms
draft-ietf-ccwg-rfc5033bis-08
Abstract Abstract
This document replaces RFC 5033, which discusses the principles and This document replaces RFC 5033, which discusses the principles and
guidelines for standardzing new congestion control algorithms. It guidelines for standardizing new congestion control algorithms. It
seeks to ensure that proposed congestion control algorithms operate seeks to ensure that proposed congestion control algorithms operate
without harm and efficiently alongside other algorithms in the global without harm and efficiently alongside other algorithms 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. This
document provides a framework for the development and assessment of document provides a framework for the development and assessment of
congestion control mechanisms, promoting stability across diverse congestion control mechanisms, promoting stability across diverse
network environments. It obsoletes RFC5033 to reflect changes in the network environments. It obsoletes RFC 5033 to reflect changes in
congestion control landscape. the congestion control landscape.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-ccwg-rfc5033bis/.
Discussion of this document takes place on the Congestion Control
Working Group (ccwg) Working Group mailing list
(mailto:ccwg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/ccwg/. Subscribe at
https://www.ietf.org/mailman/listinfo/ccwg/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-ccwg/rfc5033bis.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 22 February 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9743.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Specification of Requirements . . . . . . . . . . . . . . . . 6 2. Specification of Requirements
3. Guidelines for Authors . . . . . . . . . . . . . . . . . . . 6 3. Guidelines for Authors
3.1. Guidelines for Authors about Evaluation . . . . . . . . . 6 3.1. Evaluation Guidelines
3.2. Guidelines for Authors about Document Status . . . . . . 7 3.2. Document-Status Guidelines
4. Specifying Algorithms for Use in Controlled Environments . . 9 4. Specifying Algorithms for Use in Controlled Environments
5. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . 9 5. Evaluation Criteria
5.1. Single Algorithm Behavior . . . . . . . . . . . . . . . . 10 5.1. Single Algorithm Behavior
5.1.1. Protection Against Congestion Collapse . . . . . . . 10 5.1.1. Protection Against Congestion Collapse
5.1.2. Protection Against Bufferbloat . . . . . . . . . . . 10 5.1.2. Protection Against Bufferbloat
5.1.3. Protection Against High Packet Loss . . . . . . . . . 11 5.1.3. Protection Against High Packet Loss
5.1.4. Fairness within the Proposed Congestion Control 5.1.4. Fairness Within the Proposed Congestion Control
Algorithm . . . . . . . . . . . . . . . . . . . . . . 11 Algorithm
5.1.5. Short Flows . . . . . . . . . . . . . . . . . . . . . 12 5.1.5. Short Flows
5.2. Mixed Algorithm Behavior . . . . . . . . . . . . . . . . 12 5.2. Mixed Algorithm Behavior
5.2.1. Existing General-Purpose Congestion Control . . . . . 12 5.2.1. Existing General-Purpose Congestion Control
5.2.2. Real-Time Congestion Control . . . . . . . . . . . . 13 5.2.2. Real-Time Congestion Control
5.2.3. Short and Long Flows . . . . . . . . . . . . . . . . 14 5.2.3. Short and Long Flows
5.3. Other Criteria . . . . . . . . . . . . . . . . . . . . . 14 5.3. Other Criteria
5.3.1. Differences with Congestion Control Principles . . . 14 5.3.1. Differences with Congestion Control Principles
5.3.2. Incremental Deployment . . . . . . . . . . . . . . . 14 5.3.2. Incremental Deployment
6. General Use . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. General Use
6.1. Paths with Tail-drop Queues . . . . . . . . . . . . . . . 15 6.1. Paths with Tail-Drop Queues
6.2. Tunnel Behavior . . . . . . . . . . . . . . . . . . . . . 15 6.2. Tunnel Behavior
6.3. Wired Paths . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Wired Paths
6.4. Wireless Paths . . . . . . . . . . . . . . . . . . . . . 16 6.4. Wireless Paths
7. Special Cases . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Special Cases
7.1. Active Queue Management (AQM) . . . . . . . . . . . . . . 16 7.1. Active Queue Management (AQM)
7.2. Operation with the Envelope set by Network Circuit 7.2. Operation with the Envelope Set by Network Circuit Breakers
Breakers . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. Paths with Varying Delay
7.3. Paths with Varying Delay . . . . . . . . . . . . . . . . 17 7.4. Internet of Things and Constrained Nodes
7.4. Internet of Things and Constrained Nodes . . . . . . . . 18 7.5. Paths with High Delay
7.5. Paths with High Delay . . . . . . . . . . . . . . . . . . 18 7.6. Misbehaving Nodes
7.6. Misbehaving Nodes . . . . . . . . . . . . . . . . . . . . 18 7.7. Extreme Packet Reordering
7.7. Extreme Packet Reordering . . . . . . . . . . . . . . . . 19 7.8. Transient Events
7.8. Transient Events . . . . . . . . . . . . . . . . . . . . 19 7.9. Sudden Changes in the Path
7.9. Sudden changes in the Path . . . . . . . . . . . . . . . 19 7.10. Multipath Transport
7.10. Multipath Transport . . . . . . . . . . . . . . . . . . . 19 7.11. Data Centers
7.11. Data Centers . . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 22 Acknowledgments
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 Contributors
Evolution of RFC5033bis . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses
Since draft-ietf-ccwg-rfc5033bis-06 . . . . . . . . . . . . . . 26
Since draft-ietf-ccwg-rfc5033bis-05 . . . . . . . . . . . . . . 26
Since draft-ietf-ccwg-rfc5033bis-04 . . . . . . . . . . . . . . 26
Since draft-ietf-ccwg-rfc5033bis-03 . . . . . . . . . . . . . . 26
Since draft-ietf-ccwg-rfc5033bis-02 . . . . . . . . . . . . . . 27
Since draft-ietf-ccwg-rfc5033bis-01 . . . . . . . . . . . . . . 27
Since draft-ietf-ccwg-rfc5033bis-00 . . . . . . . . . . . . . . 27
Since draft-scheffenegger-congress-rfc5033bis-00 . . . . . . . 27
Since RFC5033 . . . . . . . . . . . . . . . . . . . . . . . . . 28
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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
algorithms and for the IETF community when evaluating whether a algorithms and for the IETF community when evaluating whether a
proposal is appropriate for publication in the RFC series and for proposal is appropriate for publication in the RFC Series and for
deployment in the Internet. deployment in the Internet.
This document obsoletes [RFC5033], which was published in 2007 as a This document obsoletes [RFC5033], which was published in 2007 as a
Best Current Practice for evaluating proposed congestion control Best Current Practice for evaluating proposed congestion control
algorithms as Experimental or Proposed Standard RFCs. algorithms for publication in Experimental or Proposed Standard RFCs.
The IETF specifies standard Internet congestion control algorithms in The IETF specifies standard Internet congestion control algorithms in
the RFC-series. These congestion control algorithms can suffer the RFC Series. These congestion control algorithms can suffer
performance challenges when used in differing environments (e.g., performance challenges when used in differing environments (e.g.,
high-speed networks, cellular and WiFi wireless technologies, and high-speed networks, cellular and Wi-Fi wireless technologies, and
long distance satellite links), and also when flows carry specific long-distance satellite links), and also when flows carry specific
workloads (Voice over IP (VoIP), gaming, and videoconferencing). workloads (e.g., Voice over IP (VoIP), gaming, and
videoconferencing).
When [RFC5033] was published in 2007, TCP [RFC9293] was the primary When [RFC5033] was published, TCP [RFC9293] was the primary focus of
focus of IETF congestion control efforts, with proposals typically IETF congestion control efforts, with proposals typically discussed
discussed within the Internet Congestion Control Research Group within the Internet Congestion Control Research Group (ICCRG).
(ICCRG). Concurrently, the Datagram Congestion Control Protocol Concurrently, the Datagram Congestion Control Protocol (DCCP)
(DCCP) [RFC4340] was developed to define new congestion control [RFC4340] was developed to define new congestion control algorithms
algorithms for datagram traffic, while the Stream Control for datagram traffic, while the Stream Control Transmission Protocol
Transmission Protocol (SCTP) [RFC9260] reused TCP congestion control (SCTP) [RFC9260] reused TCP congestion control algorithms.
algorithms.
Since then, several changes have occurred. The range of protocols Since then, several changes have occurred. The range of protocols
utilizing congestion control algorithms has expanded to include QUIC utilizing congestion control algorithms has expanded to include QUIC
[RFC9000] and RTP Media Congestion Avoidance Techniques (RMCAT) [RFC9000] and RTP Media Congestion Avoidance Techniques (RMCAT)
(e.g., [RFC8836]. Additionally, some alternative congestion control (e.g., [RFC8836]). Additionally, some alternative congestion control
algorithms have been tested and deployed at scale without full IETF algorithms have been tested and deployed at scale without full IETF
review. There is increased interest in specialized use cases, such review. There is increased interest in specialized use cases, such
as data centers (e.g., [RFC8257], and in supporting a variety of as data centers (e.g., [RFC8257]), and in supporting a variety of
upper layer protocols and applications, such as real-time protocols. upper-layer protocols and applications, such as real-time protocols.
Moreover, the community has gained significant experience with Moreover, the community has gained significant experience with
congestion indications beyond packet loss. congestion indications beyond packet loss.
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: CUBIC IETF, including at least two that saw large scale deployment. These
[HRX08] and Bottleneck Bandwidth and Round-trip propagation time include CUBIC [HRX08] and Bottleneck Bandwidth and Round-trip
(BBR) [BBR-draft]. propagation time (BBR) [BBR].
CUBIC was documented in a research publication in 2007 [HRX08], and CUBIC was documented in a research publication in 2007 [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 Informational Internet-Draft in 2015, published as an
Informational RFC in 2017 as [RFC8312] and then as a Proposed Informational RFC in 2017 as [RFC8312] and then as a Proposed
Standard in 2023 [RFC9438]. Standard in 2023 [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 IRTF Internet- to Linux kernel 4.19 in 2016. It was described in an Internet-Draft
Draft in 2018, and that Internet- Draft is regularly updated to in 2018, which has been regularly updated to document the evolving
document the evolving versions of the algorithm [BBR-draft]. BBR is versions of the algorithm [BBR]. BBR is currently widely used for
currently widely used for Google services using either TCP or QUIC, Google services using either TCP or QUIC and is also widely deployed
and is also widely deployed outside of Google. outside of Google.
We cannot say now whether the original authors of [RFC5033] expected We cannot say whether the original authors of [RFC5033] expected that
that developers would be waiting for IETF review before widely developers would be waiting for IETF review before widely deploying a
deploying a new congestion control algorithm over the Internet, but new congestion control algorithm over the Internet, but the examples
the examples of CUBIC and BBR teach us that deployment of new of CUBIC and BBR illustrate that deployment of new algorithms is not,
algorithms is not, in fact, gated by the publication of the algorithm in fact, gated by the publication of the algorithm as an RFC.
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 * A specification that is accessible to anyone can 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] of consistent with the congestion control principles from [RFC2914]
preventing congestion collapse, considering fairness, and optimizing related to preventing congestion collapse, considering fairness, and
a flow's own performance in terms of throughput, delay, and loss. optimizing a flow's own performance in terms of throughput, delay,
[RFC2914] also discusses the goal of avoiding a congestion control and loss. [RFC2914] also discusses the goal of avoiding a congestion
"arms race" among competing transport protocols. control "arms race" among competing transport protocols.
This document does not give hard-and-fast requirements for an This document does not give hard-and-fast requirements for an
appropriate congestion control algorithm. Rather, the document appropriate congestion control algorithm. Rather, the document
provides a set of criteria that should be considered and weighed by provides a set of criteria that should be considered and weighed by
the developers of alternative algorithms and by the IETF in the the developers of alternative algorithms and by the IETF in the
context of each proposal. context of each proposal.
The high-order criterion for advancing any proposal within the IETF The high-order criterion for advancing any proposal within the IETF
is a serious scientific study of the pros and cons that occurs when is a serious scientific study of the pros and cons that occur when
the proposal is considered for publication by the IETF, or before it the proposal is considered for publication by the IETF or before it
is deployed at large scale. is deployed at a large scale.
After initial studies, authors are encouraged to write a After initial studies, authors are encouraged to write a
specification of their proposal for publication in the RFC series. specification of their proposal for publication in the RFC Series.
This allows others to understand and investigate the wealth of This allows others to understand and investigate the wealth of
proposals in this space. proposals in this space.
This document is intended to reduce the barriers to entry for new This document is intended to reduce the barriers to entry for new
congestion control work to the IETF. As such, proponents of new congestion control work to the IETF. As such, proponents of new
congestion control algorithms ought not to interpret these criteria congestion control algorithms ought not to interpret these criteria
as a checklist of requirements before approaching the IETF. Instead, as a checklist of requirements before approaching the IETF. Instead,
proponents are encouraged to think about these issues beforehand, and proponents are encouraged to think about these issues beforehand and
have the willingness to do the work implied by the remainder of this have the willingness to do the work implied by the remainder of this
document. document.
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Guidelines for Authors 3. Guidelines for Authors
3.1. Guidelines for Authors about Evaluation 3.1. Evaluation Guidelines
This document does not specify specific evaluation methods, short of This document does not provide specific evaluation methods, short of
internet-scale deployment and measurement, to test the criteria Internet-scale deployment and measurement, to test the criteria
described below. There are multiple possible approaches to described below. There are multiple possible approaches to
evaluation. Each has a role, and the most appropriate approach evaluation. Each has a role, and the most appropriate approach
depends on the criteria being evaluated and the maturity of the depends on the criteria being evaluated and the maturity of the
specification. specification.
For many algorithms, an initial evaluation will consider individual For many algorithms, an initial evaluation will consider individual
protocol mechanisms in a simulator to analyse their stability and protocol mechanisms in a simulator to analyze their stability and
safety across a wide range of conditions, including overload. For safety across a wide range of conditions, including overload. For
example, [RFC8869] describes evaluation test cases for interactive example, [RFC8869] describes evaluation test cases for interactive
real-time media over wireless networks. Such results could also be real-time media over wireless networks. Such results could also be
published or discussed in IRTF research groups, such as ICCRG and published or discussed in IRTF research groups, such as ICCRG and
MAPRG. MAPRG.
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 implementation and experience using the practical experience with implementations and experience using the
algorithm. Where there is implementation by independent teams, this algorithm. Implementations by independent teams can help provide
can help provide assurance that a specification has avoided assurance that a specification has avoided assumptions or ambiguity.
assumptions or ambiguity. An independent evaluation by multiple An independent evaluation by multiple teams helps provide assurance
teams helps provide assurance that the design meets the evaluation that the design meets the evaluation criteria and can assess typical
criteria, and can assess typical interactions with other traffic. interactions with other traffic. This evaluation could use an
This evaluation could use an emulated laboratory environment or a emulated laboratory environment or a controlled experiment (within a
controlled experiment (within a limited domain or at Internet-scale). limited domain or at the Internet scale). Evidence of results is
Evidence of results is normally considered by the working group in normally considered by the working group in deciding if a
deciding if a specification is ready for publication and ought to be specification is ready for publication and ought to be documented in
documented in any request for the working group to publish the any request for the working group to publish the specification.
specification.
Publication might occur without multiple implementations if a single Publication might occur without multiple implementations if a single
implementation is widely used, open source, and shown to have implementation is widely used, open source, and shown to have a
positive impact on the Internet, particularly if the target status is positive impact on the Internet, particularly if the target status is
Experimental. Experimental.
3.2. Guidelines for Authors about Document Status 3.2. Document-Status Guidelines
This document applies to proposals for congestion control algorithms The guidelines in this document apply to specifications of congestion
that seek Experimental or Standards Track status. Evaluation of both control algorithms that seek publication as an RFC via the IETF
cases involves the same questions, but with different expectations Stream with an Experimental or Standards Track status. The
for both the answers and the degree of certainty of those answers. evaluation of either status involves the same questions, but with
different expectations for both the answers and the degree of
certainty of those answers.
Congestion control algorithms without empirical evidence of Internet- Specifications on congestion control algorithms without empirical
scale deployment MUST seek Experimental status, unless they are not evidence of Internet-scale deployment MUST seek Experimental status,
targeted at general use. unless they are not targeted for general use.
Specifications published as Experimental ought to explain the reason Specifications that seek to be published as Experimental IETF Stream
for the status and what further information would be required to RFCs ought to explain the reason for the status and what further
progress to standards track. For example, section 12 of [RFC6928] information would be required to progress to a Standards Track RFC.
provides “Usage and Deployment Recommendations” that describe the For example, Section 12 of [RFC6928] provides "Usage and Deployment
experiments expected by the TCPM working group. Section 4 of Recommendations" that describe the experiments expected by the TCPM
[RFC4614] provides other examples of extensions that were considered Working Group. Section 4 of [RFC4614] provides other examples of
experimental when the specification was published. extensions that were considered experimental when the specification
was published (note that [RFC4614] has since been obsoleted by
[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.
Congestion control algorithms with a record of measured Internet- Specifications on congestion control algorithms with a record of
scale deployment MAY directly seek the Standards Track if there is measured Internet-scale deployment MAY directly seek Standards Track
solid data that reflects that it is safe, and the design is stable, status if there is solid data that reflects that the algorithm is
guided by the considerations in Section 6. However, the existence of safe and the design is stable, guided by the considerations in
this data does not waive the other considerations in this document. Section 6. However, the existence of this data does not waive the
other considerations in this document.
Each published congestion control algorithm is REQUIRED to include a Each specification submitted for publication as an RFC is REQUIRED to
statement in the abstract indicating whether or not there is IETF include a statement in the abstract indicating whether or not there
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 published algorithm is considered safe for use on the Internet. Each such specification is
also REQUIRED to include a statement in the abstract describing also REQUIRED to include a statement in the abstract describing
environments where the protocol is not recommended for deployment. environments where the protocol is not recommended for deployment.
There can be environments where the congestion control algorithm is There can be environments where the congestion control algorithm is
deemed safe for use, but it is still is not recommended for use deemed safe for use, but it is still not recommended for use because
because it does not perform well for the user. it does not perform well for the user.
As examples of such statements, [RFC3649] specifies HighSpeed TCP and Examples of such statements exist in [RFC3649], which specifies
includes a statement in the abstract stating that the proposed HighSpeed TCP and includes a statement in the abstract stating that
congestion control algorithm is Experimental, but may be deployed in the proposed congestion control algorithm is experimental but may be
the Internet. In contrast, the Quick-Start document [RFC4782] deployed in the Internet. In contrast, the Quick-Start document
includes a paragraph in the abstract stating that the mechanism is [RFC4782] includes a paragraph in the abstract stating that the
only being proposed for use in controlled environments. The abstract mechanism is only being proposed for use in controlled environments.
specifies environments where the Quick-Start request could give false The abstract specifies environments where the Quick-Start request
positives (and therefore would be unsafe for incremental deployment could give false positives (and therefore would be unsafe for
where some routers forward, but do not process the option). The incremental deployment where some routers forward but do not process
abstract also specifies environments where packets containing the the option). The abstract also specifies environments where packets
Quick-Start request could be dropped in the network; in such an containing the Quick-Start request could be dropped in the network;
environment, Quick-Start would not be unsafe to deploy, but in such an environment, Quick-Start would not be unsafe to deploy,
deployment is not recommended because it could lead to unnecessary but deployment is not recommended because it could lead to
delays for the connections attempting to use Quick-Start. The Quick- unnecessary delays for the connections attempting to use Quick-Start.
Start method is discussed as an example in [RFC9049]. The Quick-Start method is discussed as an example in [RFC9049].
Strictly speaking, Informational RFCs in the IETF stream need not Strictly speaking, documents for publication as Informational RFCs
meet all of the criteria in this document, as they do not carry a from the IETF Stream need not meet all of the criteria in this
formal recommendation from the community. Instead, the community document, as they do not carry a formal recommendation from the IETF
judges the publication of Informational RFCs based on the value of community. Instead, the community judges the publication of these
their addition to the RFC series. Informational RFCs based on the value of their addition to the
information captured by the RFC Series.
Although out of the scope of this document, proponents of a new Although it is out of scope for this document, proponents of a new
algorithm could alternatively seek publication as an Informational or algorithm could alternatively seek publication of their specification
Experimental RFC via the Internet Research Task Force (IRTF). In as an Informational or Experimental RFC via the Internet Research
general, these algorithms are expected to be less mature than ones Task Force (IRTF) Stream. In general, these algorithms are expected
that follow the procedures in this document. Authors documenting to be less mature than ones that follow the procedures in this
document for publication via the IETF Stream. Authors documenting
deployed congestion control algorithms that cannot be changed by IETF deployed congestion control algorithms that cannot be changed by IETF
or IRTF review are invited to seek publication as an Informational or IRTF review are invited to seek publication of their specification
RFC via the Independent Stream Editor (ISE). as an Informational RFC via the Independent Submission Stream.
4. Specifying Algorithms for Use in Controlled Environments 4. Specifying Algorithms for Use in Controlled Environments
Algorithms can be designed for general Internet deployment or for use Algorithms can be designed for general Internet deployment or for use
in controlled environments [RFC8799]. Within a controlled in controlled environments [RFC8799]. Within a controlled
environment, an operator can ensure that flows are isolated from environment, an operator can ensure that flows are isolated from
other Internet flows, or they might allow these flows to share other Internet flows or they might allow these flows to share
resources with other Internet flows. A data center is an example of resources with other Internet flows. A data center is an example of
a controlled environment, which often deploys fabrics with rich a controlled environment that often deploys fabrics with rich
signalling from switches to endpoints. signaling from switches to endpoints.
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 (an RFC or another stable specification). For publication functions (such as an RFC or another stable specification). For
to proceed, the IETF will need to assess whether a working group publication of a specification of one of these algorithms to proceed,
exists that can properly assess the network-layer aspects and their the IETF will need to consider whether a working group exists that
interaction with the congestion control. can properly assess the network-layer aspects and their interaction
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 needs to understand the usage, e.g., how the usage is scoped to
the controlled environment, whether the algorithm will share the controlled environment, whether the algorithm will share
resources with Internet traffic, and consider what could happen if resources with Internet traffic, and consider what could happen if
used in a protocol that is bridged across an Internet path. used in a protocol that is bridged across an Internet path.
Algorithms that are designed to be confined to a controlled Algorithms that are designed to be confined to a controlled
environment and are not intended for use in the general Internet, environment and are not intended for use in the general Internet
might instead seek real-world data for those environments. In such might instead seek real-world data for those environments. In such
cases, the evaluation criteria in the remainder of this document cases, the evaluation criteria in the remainder of this document
might not apply. might not apply.
5. Evaluation Criteria 5. Evaluation Criteria
As previously noted, authors are expected to conduct a comprehensive As previously noted, authors of a specification on a congestion
evaluation of the advantages and disadvantages of congestion control control algorithm are expected to conduct a comprehensive evaluation
algorithms presented to the IETF. The following guidelines are of the advantages and disadvantages of any congestion control
intended to assist authors and the IETF community in this endeavor. algorithms presented to the IETF community. The following guidelines
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
of these guidelines may also arise. of these guidelines may also arise.
When considering a proposed congestion control algorithm, the When considering a proposed congestion control algorithm, the
community MUST consider the following criteria. These criteria will community MUST consider the criteria in the following sections.
be evaluated in various domains (see Section 6 and Section 7). These criteria will be evaluated in various domains (see Sections 6
and 7).
Some of the sections below will list criteria that SHOULD be met. It Some of the sections below will list criteria that SHOULD be met. It
could happen that these criteria are not in fact met by the proposal. could happen that these criteria are not, in fact, met by the
In such cases, the community MUST document whether not meeting the proposal. In such cases, the community MUST document whether not
criteria is acceptable, for example because there are practical meeting the criteria is acceptable, for example, if there are
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 a resulting RFC. imply that the result needs to be described in an RFC: there is no
There is no formal requirement to document the results, although formal requirement to document the results, although normal IETF
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.
5.1. Single Algorithm Behavior 5.1. Single Algorithm Behavior
The criteria in this section evaluate the congestion control The criteria in the following subsections evaluate the congestion
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
A congestion control algorithm should either stop sending when the A congestion control algorithm should either stop sending when the
packet drop rate exceeds some threshold [RFC3714], or should include packet drop rate exceeds some threshold [RFC3714] or include some
some notion of "full backoff". For "full backoff", at some point the notion of "full backoff". For "full backoff", at some point, the
algorithm would reduce the sending rate to one packet per round-trip algorithm would reduce the sending rate to one packet per round-trip
time and then exponentially backoff the time between single packet time; then, it would exponentially back off the time between single
transmissions if the congestion persists. Exactly when either "full packet transmissions if the congestion persists. Exactly when either
backoff" or a pause in sending comes into play will be algorithm- "full backoff" or a pause in sending comes into play will be
specific. However, as discussed in [RFC2914] and [RFC8961], this algorithm specific. However, as discussed in [RFC2914] and
requirement is crucial to protect the network in times of extreme [RFC8961], this requirement is crucial to protect the network in
(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 must be identical to that of TCP ([RFC6298], [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 should 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, but see [RFC8961] and [RFC8085] for this is algorithm specific; see [RFC8961] and [RFC8085] for
requirements. requirements.
Bufferbloat [Bufferbloat] refers to the building of excessive queues "Bufferbloat" refers to the building of excessive queues in the
in the network. Many network routers are configured with very large network [BUFFERBLOAT]. Many network routers are configured with very
buffers. The standards-track Reno [RFC5681] and CUBIC [RFC9438] large buffers. The Standards Track RFCs [RFC5681] and [RFC9438]
congestion control algorithms send at progressively higher rates describing the Reno and CUBIC congestion control algorithms
until a First-In First-Out (FIFO) buffer completely fills, and packet (respectively) send at progressively higher rates until a First In,
losses then occur. Every connection passing through that bottleneck First Out (FIFO) buffer completely fills; then packet losses occur.
experiences increased latency due to the high buffer occupancy. This Every connection passing through that bottleneck experiences
adds unwanted latency that negatively impacts highly interactive increased latency due to the high buffer occupancy. This 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 should try to avoid causing
excessively high rates of packet loss. To accomplish this, it should excessively high rates of packet loss. To accomplish this, it should
avoid excessive increases in sending rate, and reduce its sending avoid excessive increases in sending rate and reduce its sending rate
rate if experiencing high packet loss. if experiencing high packet loss.
The first version of the BBR algorithm [BBRv1-draft] 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-draft]. 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 current standards-track packet losses in exactly the same way as congestion control
congestion control algorithms (e.g., [RFC5681]). algorithms described in current Standards Track RFCs (e.g.,
[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 proposal should explore how the capacity is control algorithm, the specification should explore how the capacity
shared among the competing flows. Capacity fairness can be important is shared among the competing flows. Capacity fairness can be
when a small number of similar flows compete to fill a bottleneck. important when a small number of similar flows compete to fill a
However, it can also not be useful, for example, when comparing flows bottleneck. However, it can also not be useful, for example, when
that seek to send at different rates, or if some of the flows do not comparing flows that seek to send at different rates or if some of
last sufficiently long to approach asymptotic behavior. the flows do not last sufficiently long to approach asymptotic
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 proposed congestion control algorithm MUST consider how new and
short-lived flows affect long-lived flows, and vice versa. short-lived flows affect long-lived flows, and vice versa.
5.2. Mixed Algorithm Behavior 5.2. Mixed Algorithm Behavior
Mixed algorithm behavior criteria evaluate the interaction of the The mixed algorithm behavior criteria evaluate the interaction of the
proposed congestion control algorithm with commonly deployed proposed congestion control algorithms being specified with commonly
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 previous standards-track algorithm could result in more harm than algorithms published in
algorithms (e.g., [RFC5681], [RFC9002], [RFC9438]) to flows sharing a previous Standards Track RFCs (e.g., [RFC5681], [RFC9002], and
common bottleneck. The measure of harm is not restricted to unequal [RFC9438]) to flows sharing a common bottleneck. The measure of harm
capacity, but ought also to consider metrics such as the introduced is not restricted to unequal capacity, but also ought to consider
latency, or an increase in packet loss. An evaluation MUST assess metrics such as the introduced latency or an increase in packet loss.
the potential to cause starvation, including assurance that a loss of An evaluation MUST assess the potential to cause starvation,
all feedback (e.g., detected by expiry of a retransmission time out) including assurance that a loss of all feedback (e.g., detected by
results in backoff. expiry of a retransmission time out) results in backoff.
5.2.1. Existing General-Purpose Congestion Control 5.2.1. Existing General-Purpose Congestion Control
A proposed congestion control algorithm MUST be evaluated when A proposed congestion control algorithm MUST be evaluated when
competing against standard IETF congestion controls, e.g. [RFC5681], competing against standard IETF congestion controls (e.g., [RFC5681],
[RFC9002], [RFC9438]. A proposed congestion control algorithm that [RFC9002], and [RFC9438]). A proposed congestion control algorithm
has a significantly negative impact on flows using standard that has a significantly negative impact on flows using standard
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 specified as Experimental, that is not TCP- friendly in all mechanism that is specified in an Experimental RFC and is not TCP
environments. When a new congestion control algorithm is deployed, friendly in all environments. When a new congestion control
the existing major algorithm deployments need to be considered to algorithm is deployed, the existing major algorithm deployments need
avoid severe performance degradation. Note that this guideline does to be considered to avoid severe performance degradation. Note that
not constrain the interaction with non-best-effort flows. this guideline does not constrain the interaction with flows that are
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] (HighSpeed TCP) and using discussed in Sections 4 and 6 of [RFC3649], and using spare capacity
spare capacity is discussed in Sections 6, 11.1, and 12 of [RFC3649]. is discussed in Sections 6, 11.1, and 12 of [RFC3649].
5.2.2. Real-Time Congestion Control 5.2.2. Real-Time Congestion Control
General-purpose algorithms need to coexist in the Internet with real- General-purpose algorithms need to coexist in the Internet with real-
time congestion control algorithms, which, in general, have finite time congestion control algorithms, which in general have finite
throughput requirements (i.e., do not seek to utilize all available throughput requirements (i.e., they do not seek to utilize all
capacity) and more strict latency bounds. See [RFC8836] for a available capacity) and more strict latency bounds. See [RFC8836]
description of the characteristics of this use case and the resulting for a description of the characteristics of this use case and the
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 (acknowledgement) 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 proposed congestion control algorithm SHOULD consider coexistence
with widely deployed real-time congestion control algorithms. with widely deployed real-time congestion control algorithms.
Regrettably, at the time of writing (2024), many algorithms with Regrettably, at the time of writing (2024), many algorithms with
detailed public specifications are not widely deployed, while many detailed public specifications are not widely deployed, while many
widely deployed real-time congestion control algorithms have widely deployed real-time congestion control algorithms have
incomplete public specifications. It is hoped that this situation incomplete public specifications. It is hoped that this situation
will change. 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 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 (DSCP) or other mechanisms, which Differentiated Services Code Points (DSCPs) or other mechanisms,
can substantially reduce the interplay with other traffic. However, which can substantially reduce the interplay with other traffic.
a proposal targeting general Internet use can not assume this is However, a proposal targeting general Internet use cannot assume this
always the case. is always the case.
Section 7.2 describes the impact of network transport circuit breaker Section 7.2 describes the impact of network transport circuit breaker
algorithms. [RFC8083] also defines a minimal set of RTP circuit algorithms. [RFC8083] also defines a minimal set of RTP circuit
breakers that operate end-to-end across a path. This identifies breakers that operate end-to-end across a path. This identifies
conditions under which a sender needs to stop transmitting media data conditions under which a sender needs to stop transmitting media data
to protect the network from excessive congestion. It is expected to protect the network from excessive congestion. It is expected
that, in the absence of long-lived excessive congestion, RTP that, in the absence of long-lived excessive congestion, RTP
applications running on best-effort IP networks will be able to applications running on best-effort IP networks will be able to
operate without triggering these circuit breakers. operate without triggering these circuit breakers.
skipping to change at page 14, line 39 skipping to change at line 615
A proposed congestion control algorithm MUST clearly explain any A proposed congestion control algorithm MUST clearly explain any
deviations from [RFC2914] and [RFC7141]. 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).
Similarly, if the proposed congestion control algorithm is intended Similarly, if the proposed congestion control algorithm is intended
only for specific environments (and not the global Internet), the only for specific environments (and not the global Internet), the
proposal SHOULD consider how this intention is to be realised. The proposal SHOULD consider how this intention is to be realized. The
community will have to address the question of whether the scope can IETF community will have to address the question of whether the scope
be enforced by stating the restrictions, or whether additional can be enforced by stating the restrictions or whether additional
protocol mechanisms are required to enforce this scoping. The answer protocol mechanisms are required to enforce this scoping. The answer
will necessarily depend on the proposed change. will necessarily depend on the proposed change.
As an example from an Experimental RFC, deployment issues are As an example from an Experimental RFC, deployment issues of Quick-
discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start). Start are discussed in Sections 10.3 and 10.4 of [RFC4782].
6. General Use 6. General Use
The criteria in Section 5 will be evaluated in the following The criteria in Section 5 will be evaluated in the scenarios
scenarios. Unless a proposed congestion control specification described in the following subsections. Unless a proposed congestion
explicitly forbids use on the public Internet, there MUST be IETF control algorithm specification of the IETF Stream explicitly forbids
consensus that it meets the criteria in these scenarios for the use on the public Internet, there MUST be IETF consensus that it
proposed congestion control algorithm to progress. meets the criteria in these scenarios for the proposed congestion
control algorithm to progress.
The evaluation in each scenario SHOULD occur over a representative The evaluation of each scenario SHOULD occur over a representative
range of bandwidths, delays, and queue depths. Of course, the set of range of bandwidths, delays, and queue depths. Of course, the set of
parameters representative of the public Internet will change over parameters representative of the public Internet will change over
time. time.
These criteria are intended to capture a statistically dominant set These criteria are intended to capture a statistically dominant set
of Internet conditions. In the case that a proposed congestion of Internet conditions. In the case that a proposed congestion
control algorithm has been tested at Internet scale, the results from control algorithm has been tested at Internet scale, the results from
that deployment are often useful for answering these questions. that deployment are often useful for answering these questions.
6.1. Paths with Tail-drop Queues 6.1. Paths with Tail-Drop Queues
The performance of a congestion control algorithm is affected by the The performance of a congestion control algorithm is affected by the
queue discipline applied at the bottleneck link. The drop-tail queue queue discipline applied at the bottleneck link. The drop-tail queue
discipline (using a FIFO buffer) MUST be evaluated. See Section 7.1 discipline (using a FIFO buffer) MUST be evaluated. See Section 7.1
for evaluation of other queue disciplines. for evaluation of other queue disciplines.
6.2. Tunnel Behavior 6.2. Tunnel Behavior
When a proposed congestion control algorithm relies on explicit When a proposed congestion control algorithm relies on explicit
signals from the path, the proposal MUST consider the effect of signals from the path, the proposal MUST consider the effect of
traffic passing through a tunnel, where routers may not be aware of traffic passing through a tunnel, where routers may not be aware of
the flow. the flow.
The design of tunnels and similar encapsulations might need to Designers of tunnels and similar encapsulations might need to
consider nested congestion control interactions. For example, when consider nested congestion control interactions, for example, when
ECN is used by both an IP and lower layer technology [ECN-Encaps]. the Explicit Congestion Notification (ECN) is used by both an IP and
lower-layer technology [ECN-ENCAPS].
6.3. Wired Paths 6.3. Wired Paths
Wired networks are usually characterized by extremely low rates of Wired networks are usually characterized by extremely low rates of
packet loss except for those due to queue drops. They tend to have packet loss except for those due to queue drops. They tend to have
stable aggregate capacity, usually higher than other types of links, stable aggregate capacity, usually higher than other types of links,
and low non-queueing delay. Because the properties are relatively and low non-queueing delay. Because the properties are relatively
simple, wired links are typically used as a "baseline" case even if simple, wired links are typically used as a "baseline" case even if
they are not always the bottleneck link in the modern Internet. they are not always the bottleneck link in the modern Internet.
6.4. Wireless Paths 6.4. Wireless Paths
While the early Internet was dominated by wired links, the properties While the early Internet was dominated by wired links, the properties
of wireless links have become important to Internet performance. In of wireless links have become important to Internet performance. In
particular, a proposed congestion control algorithm should be particular, a proposed congestion control algorithm should be
evaluated in situations where some packet losses are due to radio evaluated in situations where some packet losses are due to radio
effects, rather than router queue drops; the link capacity varies effects rather than router queue drops. The link capacity varies
over time due to changing link conditions; and media access delays over time due to changing link conditions, and media-access delays
and link-layer retransmission lead to increased jitter in round-trip and link-layer retransmission lead to increased jitter in round-trip
times. See [RFC3819] and Section 16 of [Tools] for further times. See [RFC3819] and Section 16 of [TOOLS] for further
discussion of wireless properties. discussion of wireless properties.
7. Special Cases 7. Special Cases
The criteria in Section 5 will be evaluated in the following The criteria in Section 5 will be evaluated in the scenarios
scenarios, unless the proposed congestion control algorithm described in the following subsections, unless the proposed
specifically excludes its use in a scenario. For these specific use- congestion control algorithm specifically excludes its use in a
cases, the community MAY allow a proposal to progress even if the scenario. For these specific use cases, the IETF community MAY allow
criteria indicate an unsatisfactory result for these scenarios. a proposal to progress even if the criteria indicate an
unsatisfactory result for these scenarios.
In general, measurements from Internet-scale deployments might not In general, measurements from Internet-scale deployments might not
expose the properties of operation in each of these scenarios, expose the properties of operation in each of these scenarios because
because they are not as ubiquitous as the General Use scenarios. they are not as ubiquitous as the general-use scenarios.
7.1. Active Queue Management (AQM) 7.1. Active Queue Management (AQM)
The proposed congestion control algorithm SHOULD be evaluated under a The proposed congestion control algorithm SHOULD be evaluated under a
variety of bottleneck queue disciplines. The effect of an AQM variety of bottleneck-queue disciplines. The effect of an AQM
discipline can be hard to detect by Internet evaluation. At a discipline can be hard to detect by Internet evaluation. At a
minimum, a proposal should reason about an algorithm's response to minimum, a proposal should reason about an algorithm's response to
various AQM disciplines. Simulation or empirical results are, of various AQM disciplines. Simulation or empirical results are, of
course, valuable. course, valuable.
Among 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 are Flow Queue CoDel (FQ-CoDel) congestion control algorithm include:
[RFC8290]; Proportional Integral Controller Enhanced (PIE) [RFC8033];
and Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332]. * 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 A proposed congestion control algorithm that sets one of the two
Explicit Congestion Transport (ECT) codepoints in the IP header can Explicit Congestion Transport (ECT) codepoints in the IP header can
gain the benefits of receiving Explicit Congestion Notification (ECN) gain the benefits of receiving Explicit Congestion Notification -
Congestion Experienced (CE) signals from an on-path AQM [RFC8087]. Congestion Experienced (ECN-CE) signals from an on-path AQM
Use of ECN [RFC3168], [RFC9332] requires the congestion control [RFC8087]. Use of ECN (see [RFC3168] and [RFC9332]) requires the
algorithm to react when it receives a packet with an ECN-CE marking. congestion control algorithm to react when it receives a packet with
This reaction needs to be evaluated to confirm that the algorithm an ECN-CE marking. This reaction needs to be evaluated to confirm
conforms with the requirements of the ECT codepoint that was used. that the algorithm conforms with the requirements of the ECT
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
of flows [RFC8084]. Such a network transport circuit breaker can of flows [RFC8084]. Such a network transport circuit breaker can
automatically detect excessive congestion, and when detected, it can automatically detect excessive congestion; when detected, it can
terminate (or significantly reduce the rate of) the flow(s). A well- terminate (or significantly reduce the rate of) the flow(s). A well-
designed congestion control algorithm ought to react before the flow designed congestion control algorithm ought to react before the flow
uses excessive resources, and therefore will operate within the uses excessive resources; therefore, it will operate within the
envelope set by network transport circuit breaker algorithms. envelope set by network transport circuit breaker algorithms.
7.3. Paths with Varying Delay 7.3. Paths with Varying Delay
An Internet Path can include simple links, where the minimum delay is An Internet path can include simple links, where the minimum delay is
the propagation delay, and any additional delay can be attributed to the propagation delay, and any additional delay can be attributed to
link buffering. This cannot be assumed. An Internet Path can also link buffering. This cannot be assumed. An Internet path can also
include complex subnetworks where the minimum delay changes over include complex subnetworks where the minimum delay changes over
various time scales, resulting in a non- stationary minimum delay. various time scales, resulting in a minimum delay that is not
stationary.
Varying delay occurs when a subnet changes the forwarding path to Varying delay occurs when a subnet changes the forwarding path to
optimise capacity, resilience, etc. It could also arise when a optimize capacity, resilience, etc. It could also arise when a
subnet uses a capacity management method where the available resource subnet uses a capacity-management method where the available resource
is periodically distributed among the active nodes. A node might is periodically distributed among the active nodes. A node might
then have to buffer data until an assigned transmission opportunity then have to buffer data until an assigned transmission opportunity
or until the physical path changes (e.g., when the length of a or until the physical path changes (e.g., when the length of a
wireless path changes, or the physical layer changes its mode of wireless path changes or when the physical layer changes its mode of
operation). Variation also arises when traffic with a higher operation). Variation also arises when traffic with a higher
priority DSCP pre-empts transmission of traffic with a lower class. priority DSCP preempts transmission of traffic with a lower class.
In these cases, the delay varies as a function of external factors, In these cases, the delay varies as a function of external factors,
and attempting to infer congestion from an increase in the delay and attempting to infer congestion from an increase in the delay
results in reduced throughput. This variation in the delay over results in reduced throughput. This variation in the delay over
short timescales (jitter) might not be distinguishable from jitter short timescales (jitter) might not be distinguishable from jitter
that results from other effects. that results from other effects.
A proposed congestion control algorithm SHOULD be evaluated to ensure A proposed congestion control algorithm SHOULD be evaluated to ensure
its operation is robust when there is a significant change in the its operation is robust when there is a significant change in the
minimum delay. minimum delay.
7.4. Internet of Things and Constrained Nodes 7.4. Internet of Things and Constrained Nodes
The "Internet of Things" (IoT) is a broad concept, but when The "Internet of Things" (IoT) is a broad concept, but when
evaluating a proposed congestion control algorithm, it is often evaluating a proposed congestion control algorithm, it is often
associated with unique characteristics: IoT nodes might be more associated with unique characteristics. For example, IoT nodes might
constrained in power, CPU, or other parameters than conventional be more constrained in power, CPU, or other parameters than
Internet hosts. This might place limits on the complexity of any conventional Internet hosts. This might place limits on the
given algorithm. These power and radio constraints might make the complexity of any given algorithm. These power and radio constraints
volume of control packets in a given algorithm a key evaluation might make the volume of control packets in a given algorithm a key
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, well below the standard operating range of bandwidth-delay product, which is well below the standard operating
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;
and therefore 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 algorithm can not relate to a user experience. Congestion control algorithms still
still need to share the path with other flows with different may 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 A proposed congestion control algorithm ought not to presume that all
general Internet paths have a low delay. Some paths include links general Internet paths have a low delay. Some paths include links
that contribute much more delay than for a typical Internet path. that contribute much more delay than for a typical Internet path.
Satellite links often have delays longer than typical for wired paths Satellite links often have delays longer than is typical for wired
[RFC2488] and high delay bandwidth products [RFC3649]. 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 proposed 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 misbehaving senders 9.6 of [RFC4782]. This includes discussion of:
and receivers; collusion between misbehaving routers; misbehaving
middleboxes; and the potential use of Quick- Start to attack routers * misbehaving senders and receivers;
or to tie up available Quick-Start bandwidth.
* 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 7.7. Extreme Packet Reordering
A proposed congestion control algorithm ought not to presume that all A proposed congestion control algorithm ought not to presume that all
general Internet paths reliably deliver packets in order. [RFC4653] general Internet paths reliably deliver packets in order. [RFC4653]
discusses the effect of extreme packet reordering. discusses the effect of extreme packet reordering.
7.8. Transient Events 7.8. Transient Events
A proposed congestion control algorithm SHOULD consider how the A proposed congestion control algorithm SHOULD consider how it would
proposed congestion control algorithm would perform in the presence perform in the presence of transient events such as a sudden onset of
of transient events such as sudden onset of congestion, a routing congestion, a routing change, or a mobility event. Routing changes,
change, or a mobility event. Routing changes, link disconnections, link disconnections, intermittent link connectivity, and mobility are
intermittent link connectivity, and mobility are discussed in more discussed in more detail in Section 16 of [TOOLS].
detail in Section 16 of [Tools].
As an example from an Experimental RFC, response to transient events As an example from an Experimental RFC, a response to transient
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 proposed 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 re-routing 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 tradeoff in timeliness and reliability. active paths. This enables a trade-off in timeliness and
There are various ways that multipath techniques can be used. reliability. There are various ways that multipath techniques can be
used.
One example use is to provide fail-over from one path to another when One example use is to provide failover from one path to another when
the original path is no longer viable, or provides inferior the original path is no longer viable or provides inferior
performance. Designs need to independently track the congestion performance. Designs need to independently track the congestion
state of each path, and demonstrate independent congestion control state of each path and demonstrate independent congestion control for
for each path being used. Authors of a proposed multipath congestion each path being used. Authors of a proposed multipath congestion
control algorithm that implements path fail-over MUST evaluate the control algorithm that implements path failover MUST evaluate the
harm to performance resulting from a change in the path, and show harm to performance resulting from a change in the path and show that
that this does not result in flow starvation. Synchronisation of this does not result in flow starvation. Synchronization of failover
failover (e.g., where multiple flows change their path on similar (e.g., where multiple flows change their path on similar time frames)
timeframes) can also contribute to harm and/or reduce fairness. can also contribute to harm and/or reduce fairness. These effects
These effects also ought to be evaluated. also ought to be evaluated.
Another example use is concurrent multipath, where the transport Another example use is concurrent multipath, where the transport
protocol simultaneously schedules a flow to aggregate the capacity protocol simultaneously schedules a flow to aggregate the capacity
across multiple paths. The Internet provides no guarantee that across multiple paths. The Internet provides no guarantee that
different paths (e.g., using different endpoint addresses) are different paths (e.g., using different endpoint addresses) are
disjoint. This introduces additional implications: A congestion disjoint. This introduces additional implications. A congestion
control algorithm proposal MUST evaluate the potential harm to other control algorithm proposal MUST evaluate the potential harm to other
flows when the multiple paths share a common congested bottleneck or flows when the multiple paths share a common congested bottleneck or
share resources that are coupled between different paths, such as an share resources that are coupled between different paths, such as an
overall capacity limit). A proposal SHOULD consider the potential overall capacity limit. A proposal SHOULD consider the potential for
for harm to other flows. Synchronisation of congestion control harm to other flows. Synchronization of congestion control
mechanisms (e.g., where multiple flows change their behaviour on mechanisms (e.g., where multiple flows change their behavior on
similar timeframes) can also contribute to harm and/or reduce similar time frames) can also contribute to harm and/or reduce
fairness. These effects also ought to be evaluated. fairness. These effects also ought to be evaluated.
At the time of writing (2024), there are currently no Standards Track At the time of writing (2024), there are currently no Standards Track
RFCs for concurrent multipath, but there is an Experimental RFC RFCs for concurrent multipath, but there is an Experimental RFC
[RFC6356] that specifies a concurrent multipath congestion control [RFC6356] that specifies a concurrent multipath congestion control
algorithm for MPTCP [RFC8684]. algorithm for Multipath TCP (MPTCP) [RFC8684].
7.11. Data Centers 7.11. Data Centers
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 signalling from switches to deploy fabrics that employ rich signaling from switches to endpoints.
endpoints. Furthermore, the operator can often limit the number of Furthermore, the operator can often limit the number of operating
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 need not coexist well with all other
algorithms if it is intended for data centers, but the proposal 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 and therefore 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 Proposed congestion control algorithms MUST examine any potential
security or privacy issues that may arise from their design. 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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/rfc/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/rfc/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion [RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion
Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141, Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141,
February 2014, <https://www.rfc-editor.org/rfc/rfc7141>. February 2014, <https://www.rfc-editor.org/info/rfc7141>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083, Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017, DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/rfc/rfc8083>. <https://www.rfc-editor.org/info/rfc8083>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/rfc/rfc8084>. <https://www.rfc-editor.org/info/rfc8084>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/rfc/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8961] Allman, M., "Requirements for Time-Based Loss Detection", [RFC8961] Allman, M., "Requirements for Time-Based Loss Detection",
BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020, BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020,
<https://www.rfc-editor.org/rfc/rfc8961>. <https://www.rfc-editor.org/info/rfc8961>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/rfc/rfc9002>. May 2021, <https://www.rfc-editor.org/info/rfc9002>.
[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed., [RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
"CUBIC for Fast and Long-Distance Networks", RFC 9438, "CUBIC for Fast and Long-Distance Networks", RFC 9438,
DOI 10.17487/RFC9438, August 2023, DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/rfc/rfc9438>. <https://www.rfc-editor.org/info/rfc9438>.
10.2. Informative References 10.2. Informative References
[BBR-draft] [BBR] Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
Jacobson, "BBR Congestion Control", Work in Progress, Jacobson, "BBR Congestion Control", Work in Progress,
Internet-Draft, draft-cardwell-iccrg-bbr-congestion- Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
control-02, 7 March 2022, control-02, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-cardwell- <https://datatracker.ietf.org/doc/html/draft-cardwell-
iccrg-bbr-congestion-control-02>. iccrg-bbr-congestion-control-02>.
[BBRv1-draft] [BBRv1] Cardwell, N., Cheng, Y., Yeganeh, S. H., and V. Jacobson,
Cardwell, N., Cheng, Y., Yeganeh, S. H., and V. Jacobson,
"BBR Congestion Control", Work in Progress, Internet- "BBR Congestion Control", Work in Progress, Internet-
Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3 Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3
July 2017, <https://datatracker.ietf.org/doc/html/draft- July 2017, <https://datatracker.ietf.org/doc/html/draft-
cardwell-iccrg-bbr-congestion-control-00>. cardwell-iccrg-bbr-congestion-control-00>.
[BBRv1-Evaluation] [BBRv1-EVALUATION]
Zitterbart, M., "Experimental evaluation of BBR congestion Hock, M., Bless, R., and M. Zitterbart, "Experimental
control", 2017 IEEE 25th International Conference on evaluation of BBR congestion control", 2017 IEEE 25th
Network Protocols (ICNP) , 2017, International Conference on Network Protocols (ICNP),
DOI 10.1109/ICNP.2017.8117540, 2017,
<https://ieeexplore.ieee.org/document/8117540>. <https://ieeexplore.ieee.org/document/8117540>.
[Bufferbloat] [BUFFERBLOAT]
Kathleen Nichols, "Bufferbloat: Dark Buffers in the Nichols, K. and J. Gettys, "Bufferbloat: Dark Buffers in
Internet", ACM Queue Volume 9, Issue 11 , 2011, the Internet", ACM Queue Volume 9, Issue 11, November
<https://queue.acm.org/detail.cfm?id=2071893>. 2011, <https://queue.acm.org/detail.cfm?id=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",
Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn- BCP 89, RFC 9599, DOI 10.17487/RFC9599, August 2024,
encap-guidelines-22, 5 December 2023, <https://www.rfc-editor.org/info/rfc9599>.
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
ecn-encap-guidelines-22>.
[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 , July 2008, Review, vol. 42, no. 5, pp. 64-74,
DOI 10.1145/1400097.1400105, July 2008,
<https://doi.org/10.1145/1400097.1400105>. <https://doi.org/10.1145/1400097.1400105>.
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
Over Satellite Channels using Standard Mechanisms", Over Satellite Channels using Standard Mechanisms",
BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999,
<https://www.rfc-editor.org/rfc/rfc2488>. <https://www.rfc-editor.org/info/rfc2488>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/rfc/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, DOI 10.17487/RFC3649, December 2003, RFC 3649, DOI 10.17487/RFC3649, December 2003,
<https://www.rfc-editor.org/rfc/rfc3649>. <https://www.rfc-editor.org/info/rfc3649>.
[RFC3714] Floyd, S., Ed. and J. Kempf, Ed., "IAB Concerns Regarding [RFC3714] Floyd, S., Ed. and J. Kempf, Ed., "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet", Congestion Control for Voice Traffic in the Internet",
RFC 3714, DOI 10.17487/RFC3714, March 2004, RFC 3714, DOI 10.17487/RFC3714, March 2004,
<https://www.rfc-editor.org/rfc/rfc3714>. <https://www.rfc-editor.org/info/rfc3714>.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
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/rfc/rfc3819>. <https://www.rfc-editor.org/info/rfc3819>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification for Transmission Control Protocol (TCP) Specification
Documents", RFC 4614, DOI 10.17487/RFC4614, September Documents", RFC 4614, DOI 10.17487/RFC4614, September
2006, <https://www.rfc-editor.org/rfc/rfc4614>. 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/rfc/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/rfc/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
Control Algorithms", BCP 133, RFC 5033, Control Algorithms", BCP 133, RFC 5033,
DOI 10.17487/RFC5033, August 2007, DOI 10.17487/RFC5033, August 2007,
<https://www.rfc-editor.org/rfc/rfc5033>. <https://www.rfc-editor.org/info/rfc5033>.
[RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion [RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion
Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March
2008, <https://www.rfc-editor.org/rfc/rfc5166>. 2008, <https://www.rfc-editor.org/info/rfc5166>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/rfc/rfc6298>. <https://www.rfc-editor.org/info/rfc6298>.
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
Congestion Control for Multipath Transport Protocols", Congestion Control for Multipath Transport Protocols",
RFC 6356, DOI 10.17487/RFC6356, October 2011, RFC 6356, DOI 10.17487/RFC6356, October 2011,
<https://www.rfc-editor.org/rfc/rfc6356>. <https://www.rfc-editor.org/info/rfc6356>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, "Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/rfc/rfc6928>. <https://www.rfc-editor.org/info/rfc6928>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015,
<https://www.rfc-editor.org/info/rfc7414>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/rfc/rfc7567>. <https://www.rfc-editor.org/info/rfc7567>.
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A "Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/rfc/rfc8033>. <https://www.rfc-editor.org/info/rfc8033>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087, Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017, DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/rfc/rfc8087>. <https://www.rfc-editor.org/info/rfc8087>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler
and Active Queue Management Algorithm", RFC 8290, and Active Queue Management Algorithm", RFC 8290,
DOI 10.17487/RFC8290, January 2018, DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/rfc/rfc8290>. <https://www.rfc-editor.org/info/rfc8290>.
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018, RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/rfc/rfc8312>. <https://www.rfc-editor.org/info/rfc8312>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/rfc/rfc8684>. 2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/rfc/rfc8799>. <https://www.rfc-editor.org/info/rfc8799>.
[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control [RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control
Requirements for Interactive Real-Time Media", RFC 8836, Requirements for Interactive Real-Time Media", RFC 8836,
DOI 10.17487/RFC8836, January 2021, DOI 10.17487/RFC8836, January 2021,
<https://www.rfc-editor.org/rfc/rfc8836>. <https://www.rfc-editor.org/info/rfc8836>.
[RFC8867] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test [RFC8867] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating Congestion Control for Interactive Cases for Evaluating Congestion Control for Interactive
Real-Time Media", RFC 8867, DOI 10.17487/RFC8867, January Real-Time Media", RFC 8867, DOI 10.17487/RFC8867, January
2021, <https://www.rfc-editor.org/rfc/rfc8867>. 2021, <https://www.rfc-editor.org/info/rfc8867>.
[RFC8868] Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion [RFC8868] Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion
Control for Interactive Real-Time Media", RFC 8868, Control for Interactive Real-Time Media", RFC 8868,
DOI 10.17487/RFC8868, January 2021, DOI 10.17487/RFC8868, January 2021,
<https://www.rfc-editor.org/rfc/rfc8868>. <https://www.rfc-editor.org/info/rfc8868>.
[RFC8869] Sarker, Z., Zhu, X., and J. Fu, "Evaluation Test Cases for [RFC8869] Sarker, Z., Zhu, X., and J. Fu, "Evaluation Test Cases for
Interactive Real-Time Media over Wireless Networks", Interactive Real-Time Media over Wireless Networks",
RFC 8869, DOI 10.17487/RFC8869, January 2021, RFC 8869, DOI 10.17487/RFC8869, January 2021,
<https://www.rfc-editor.org/rfc/rfc8869>. <https://www.rfc-editor.org/info/rfc8869>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049, Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021, DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/rfc/rfc9049>. <https://www.rfc-editor.org/info/rfc9049>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, "Dual- [RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, "Dual-
Queue Coupled Active Queue Management (AQM) for Low Queue Coupled Active Queue Management (AQM) for Low
Latency, Low Loss, and Scalable Throughput (L4S)", Latency, Low Loss, and Scalable Throughput (L4S)",
RFC 9332, DOI 10.17487/RFC9332, January 2023, RFC 9332, DOI 10.17487/RFC9332, January 2023,
<https://www.rfc-editor.org/rfc/rfc9332>. <https://www.rfc-editor.org/info/rfc9332>.
[RFC9392] Perkins, C., "Sending RTP Control Protocol (RTCP) Feedback [RFC9392] Perkins, C., "Sending RTP Control Protocol (RTCP) Feedback
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/rfc/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 , July Simulation and Testbed Scenarios", Work in Progress,
2007, Internet-Draft, draft-irtf-tmrg-tools-05, 23 February
<https://datatracker.ietf.org/doc/draft-irtf-tmrg-tools>. 2008, <https://datatracker.ietf.org/doc/html/draft-irtf-
tmrg-tools-05>.
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,
Reese Enghardt, Jonathan Lennox, Matt Mathis, Zahed Sarker, Juergen Reese Enghardt, Jonathan Lennox, Matt Mathis, Zahed Sarker, Juergen
Schoenwaelder, Dave Taht, Sean Turner, Michael Welzl, Magnus Schoenwaelder, Dave Taht, Sean Turner, Michael Welzl, Magnus
Westerlund, and Greg White for suggesting improvements to this Westerlund, and Greg White for suggesting improvements to this
document. document.
Discussions with Lars Eggert and Aaron Falk seeded the original Discussions with Lars Eggert and Aaron Falk seeded the original
RFC5033. Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, [RFC5033]. Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra
Colin Perkins, Pekka Savola, members of TSVWG, and participants at Padhye, Colin Perkins, Pekka Savola, members of TSVWG, and
the TCP Workshop at Microsoft Research all provided feedback and participants at the TCP Workshop at Microsoft Research all provided
contributions to that document. It also drew from [RFC5166]. feedback and contributions to that document. It also drew from
[RFC5166].
Evolution of RFC5033bis
Since draft-ietf-ccwg-rfc5033bis-06
* OPSDIR review
* ARTART review
Since draft-ietf-ccwg-rfc5033bis-05
* AD evaluation comments
Since draft-ietf-ccwg-rfc5033bis-04
* Editorial pass after shepherd review.
Since draft-ietf-ccwg-rfc5033bis-03
* Harmonised the "proposed congestion control algorithm"
* Addressed issues.
* Examined RFC-2119 keywords and consistency with other RFCs.
* Added text on constrained environments/limited domains
* Added text on circuit breakers and aligned with other RFCs.
* Several editorial passes
Since draft-ietf-ccwg-rfc5033bis-02
* Added discussion of real-time protocols
* Added discussion of short flows
* Listed properties of wired networks
* Added IoT section
* Added discussion of AQM response
* Rewrote the "Document Status" section
* Adding improved first sentence of abstract and intro.
* Added section on Multicast, noting this is out of scope
* Editorial changes
Since draft-ietf-ccwg-rfc5033bis-01
* Added discussion of multipath transports
* Totally reorganized central sections of the draft
Since draft-ietf-ccwg-rfc5033bis-00
* Added QUIC, other congestion control standards
* Added wireless environments
* Aligned motivation for this work with the CCWG charter
* Refined discussion of QuickStart
Since draft-scheffenegger-congress-rfc5033bis-00
* Renamed file to reflect WG adpotion
* Updated authorship and acknowledgements.
* Include updated text suggested by Dave Taht
* Added criterion for bufferbloat
* Mentioned CUBIC and BBR as motivation
* Include section to track updates between revisions
* Update references
Since RFC5033
* converted to Markdown and xml2rfc v3
* various formatting changes.
Contributors Contributors
Christian Huitema Christian Huitema
Private Octopus, Inc. Private Octopus, Inc.
Email: huitema@huitema.net Email: huitema@huitema.net
Authors' Addresses Authors' Addresses
Martin Duke (editor) Martin Duke (editor)
 End of changes. 165 change blocks. 
564 lines changed or deleted 504 lines changed or added

This html diff was produced by rfcdiff 1.48.