rfc9743xml2.original.xml   rfc9743.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 2.
7.4) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-ccwg-rfc5033bis-08" category="bcp" co <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
nsensus="true" submissionType="IETF" obsoletes="5033" tocInclude="true" sortRefs -ietf-ccwg-rfc5033bis-08" number="9743" category="bcp" consensus="true" submissi
="true" symRefs="true"> onType="IETF" obsoletes="5033" updates="" tocInclude="true" sortRefs="true" symR
efs="true" version="3" xml:lang="en">
<front> <front>
<title abbrev="New CC Algorithms">Specifying New Congestion Control Algorith ms</title> <title abbrev="New CC Algorithms">Specifying New Congestion Control Algorith ms</title>
<seriesInfo name="RFC" value="9743"/>
<seriesInfo name="BCP" value="133"/>
<author initials="M." surname="Duke" fullname="Martin Duke" role="editor"> <author initials="M." surname="Duke" fullname="Martin Duke" role="editor">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<email>martin.h.duke@gmail.com</email> <email>martin.h.duke@gmail.com</email>
</address> </address>
</author> </author>
<author initials="G." surname="Fairhurst" fullname="Godred Fairhurst" role=" editor"> <author initials="G." surname="Fairhurst" fullname="Godred Fairhurst" role=" editor">
<organization>University of Aberdeen</organization> <organization>University of Aberdeen</organization>
<address> <address>
<email>gorry@erg.abdn.ac.uk</email> <email>gorry@erg.abdn.ac.uk</email>
</address> </address>
</author> </author>
<date year="2025" month="March"/>
<date year="2024" month="August" day="21"/> <area>WIT</area>
<workgroup>ccwg</workgroup>
<area>General</area> <keyword>Transport</keyword>
<workgroup>CCWG</workgroup> <keyword>CC</keyword>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>RFC 5033 discusses the principles and guidelines for standardizing
<?line 99?> new congestion control algorithms. This document obsoletes RFC 5033 to
reflect changes in the congestion control landscape by providing a
<t>This document replaces RFC 5033, which discusses the principles and framework for the development and assessment of congestion control
guidelines for standardzing new congestion control algorithms. It seeks to mechanisms, promoting stability across diverse network paths. This
ensure that proposed congestion control algorithms operate without harm and document seeks to ensure that proposed congestion control algorithms
efficiently alongside other algorithms in the global Internet. It emphasizes the operate efficiently and without harm when used in the global Internet.
need for comprehensive testing and validation to prevent adverse interactions It emphasizes the need for comprehensive testing and validation to
with existing flows. This document provides a framework for the development and prevent adverse interactions with existing flows.</t>
assessment of congestion control mechanisms, promoting stability across diverse
network environments. It obsoletes RFC5033 to reflect changes in the congestion
control landscape.</t>
</abstract> </abstract>
<note title="About This Document" removeInRFC="true">
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-ccwg-rfc5033bis/"/>.
</t>
<t>
Discussion of this document takes place on the
Congestion Control Working Group (ccwg) Working Group mailing list (<ere
f target="mailto:ccwg@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/ccwg/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ccwg/"/
>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ietf-wg-ccwg/rfc5033bis"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<name>Introduction</name>
<?line 111?> <t>This document provides guidelines for the IETF to use when evaluating
a proposed congestion control algorithm that differs from the general
<section anchor="introduction"><name>Introduction</name> congestion control principles outlined in <xref target="RFC2914"/>. The
guidance is intended to be useful to authors proposing congestion
<t>This document provides guidelines for the IETF to use when evaluating a propo control algorithms and for the IETF community when evaluating whether a
sed proposal is appropriate for publication in the RFC Series and for
congestion control algorithm that differs from the general congestion control deployment in the Internet.</t>
principles outlined in <xref target="RFC2914"/>. The guidance is intended to be
useful to
authors proposing congestion control algorithms and for the IETF community when
evaluating whether a proposal is appropriate for publication in the RFC series
and for deployment in the Internet.</t>
<t>This document obsoletes <xref target="RFC5033"/>, which was published in 2007
as a Best
Current Practice for evaluating proposed congestion control algorithms as
Experimental or Proposed Standard RFCs.</t>
<t>The IETF specifies standard Internet congestion control algorithms in the RFC
-series.
These congestion control algorithms can suffer performance challenges when used
in
differing environments (e.g., high-speed networks, cellular and WiFi wireless
technologies, and long distance satellite links), and also when flows carry
specific workloads (Voice over IP (VoIP), gaming, and videoconferencing).</t>
<t>When <xref target="RFC5033"></xref> was published in 2007, TCP [RFC9293] was
the primary focus of
IETF congestion control efforts, with proposals typically discussed within the
Internet Congestion Control Research Group (ICCRG). Concurrently, the Datagram
Congestion Control Protocol (DCCP) [RFC4340] was developed to define new
congestion control algorithms for datagram traffic, while the Stream Control
Transmission Protocol (SCTP) [RFC9260] reused TCP congestion control algorithms.
</t>
<t>Since then, several changes have occurred. The range of protocols utilizing
congestion control algorithms has expanded to include QUIC [RFC9000] and RTP
Media Congestion Avoidance Techniques (RMCAT) (e.g., <xref target="RFC8836"></xr
ef>. Additionally,
some alternative congestion control algorithms have been tested and deployed
at scale without full IETF review. There is increased interest in specialized
use cases, such as data centers (e.g., [RFC8257], and in supporting a variety of
upper layer protocols and applications, such as real-time protocols. Moreover,
the community has gained significant experience with congestion indications
beyond packet loss.</t>
<t>Multicast congestion control is a considerably less mature field of study and
is not in the scope of this document. However, <xref section="4" sectionFormat="
of" target="RFC8085"/> provides
additional guidelines for multicast and broadcast usage of UDP.</t>
<t>Congestion control algorithms have been developed outside of the IETF, includ
ing
at least two that saw large scale deployment: CUBIC <xref target="HRX08"/> and B
ottleneck
Bandwidth and Round-trip propagation time (BBR) <xref target="BBR-draft"/>.</t>
<t>CUBIC was documented in a research publication in 2007 <xref target="HRX08"/>
, and was then
adopted as the default congestion control algorithm for the TCP implementation
in Linux. It was already used in a significant fraction of TCP connections over
the Internet before being documented in an Informational Internet-Draft in
2015, published as an Informational RFC in 2017 as <xref target="RFC8312"/> and
then as a
Proposed Standard in 2023 <xref target="RFC9438"/>.</t>
<t>At the time of writing, BBR is being developed as an internal research projec
t
by Google, with the first implementation contributed to Linux kernel 4.19 in
2016. It was described in an IRTF Internet-Draft in 2018, and that Internet-
Draft is regularly updated to document the evolving versions of the algorithm
<xref target="BBR-draft"/>. BBR is currently widely used for Google services usi
ng either
TCP or QUIC, and is also widely deployed outside of Google.</t>
<t>We cannot say now whether the original authors of <xref target="RFC5033"/> ex
pected that
developers would be waiting for IETF review before widely deploying a
new congestion control algorithm over the Internet, but the examples of CUBIC
and BBR teach us that deployment of new algorithms is not, in fact, gated by the
publication of the algorithm as an RFC.</t>
<t>Nevertheless, a specification for a congestion control algorithm provides a n
umber of
advantages:</t>
<t><list style="symbols">
<t>It can help implementers, operators, and other interested parties
develop a shared understanding of how the algorithm works and how it is
expected to behave in various scenarios and configurations.</t>
<t>It can help potential contributors understand the algorithm,
which can make it easier for them to suggest improvements and/or identify
limitations. Furthermore, the specification can help multiple contributors
align on a consensus change to the algorithm.</t>
<t>A specification that is accessible to anyone can circumvent the issue that
some implementers may be unable to read open source reference implementations
due to the constraints of some open source licenses.</t>
</list></t>
<t>Beyond helping develop specific algorithm proposals, guidelines can also serv
e
as a reminder to potential inventors and developers of the multiple facets of
the congestion control problem.</t>
<t>The evaluation guidelines in this document are intended to be consistent with
the congestion control principles from <xref target="RFC2914"/> of preventing co
ngestion
collapse, considering fairness, and optimizing a flow's own performance in terms
of throughput, delay, and loss. <xref target="RFC2914"/> also discusses the goal
of avoiding
a congestion control "arms race" among competing transport protocols.</t>
<t>This document does not give hard-and-fast requirements for an appropriate
congestion control algorithm. Rather, the document provides a set of criteria
that should be considered and weighed by the developers of alternative
algorithms and by the IETF in the context of each proposal.</t>
<t>The high-order criterion for advancing any proposal within the IETF is a seri
ous
scientific study of the pros and cons that occurs when the proposal is
considered for publication by the IETF, or before it is deployed at large scale.
</t>
<t>After initial studies, authors are encouraged to write a specification of the
ir
proposal for publication in the RFC series. This allows others to understand and
investigate the wealth of proposals in this space.</t>
<t>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
algorithms ought not to interpret these criteria as a checklist of requirements
before approaching the IETF. Instead, proponents are encouraged to think about
these issues beforehand, and have the willingness to do the work implied by the
remainder of this document.</t>
</section>
<section anchor="specification-of-requirements"><name>Specification of Requireme
nts</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <
xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="guidelines-for-authors"><name>Guidelines for Authors</name>
<section anchor="guidelines-for-authors-about-evaluation"><name>Guidelines for A
uthors about Evaluation</name>
<t>This document does not specify specific evaluation methods, short of internet
-scale deployment and measurement, to test the criteria described below. There a
re multiple possible approaches to evaluation. Each has a role, and the most app
ropriate approach depends on the criteria being evaluated and the maturity of th
e specification.</t>
<t>For many algorithms, an initial evaluation will consider individual protocol
mechanisms in a simulator to analyse their stability and safety across a wide ra
nge of conditions, including overload. For example, <xref target="RFC8869"/> de
scribes evaluation test cases for interactive real-time media over wireless netw
orks. Such results could also be published or discussed in IRTF research groups,
such as ICCRG and MAPRG.</t>
<t>Before a proposed congestion control algorithm is published as an Experimenta
l
or Standards Track RFC, the community SHOULD gain practical experience with
implementation and experience using the algorithm. Where there is implementation
by independent teams, this can help provide assurance that a specification has
avoided assumptions or ambiguity. An independent evaluation by multiple teams
helps provide assurance that the design meets the evaluation criteria, and can
assess typical interactions with other traffic. This evaluation could use an
emulated laboratory environment or a controlled experiment (within a limited
domain or at Internet-scale). Evidence of results is normally considered by the
working group in deciding if a specification is ready for publication and ought
to be documented in any request for the working group to publish the
specification.</t>
<t>Publication might occur without multiple implementations if a single
implementation is widely used, open source, and shown to have positive impact on
the Internet, particularly if the target status is Experimental.</t>
</section>
<section anchor="guidelines-for-authors-about-document-status"><name>Guidelines
for Authors about Document Status</name>
<t>This document applies to proposals for congestion control algorithms that
seek Experimental or Standards Track status. Evaluation of both cases involves
the same questions, but with different expectations for both the answers and the
degree of certainty of those answers.</t>
<t>Congestion control algorithms without empirical evidence of Internet-scale
deployment MUST seek Experimental status, unless they are not targeted at
general use.</t>
<t>Specifications published as Experimental ought to explain the reason for
the status and what further information would be required to progress to
standards track. For example, section 12 of <xref target="RFC6928"/> provides
“Usage and Deployment Recommendations” that describe the experiments
expected by the TCPM working group. Section 4 of <xref target="RFC4614"/> provid
es other
examples of extensions that were considered experimental
when the specification was published.</t>
<t>Experimental specifications SHOULD NOT be deployed as a default. They SHOULD
only be deployed in situations where they are being actively measured, and where
it is possible to deactivate them if there are signs of pathological behavior.</
t>
<t>Congestion control algorithms with a
record of measured Internet-scale deployment MAY directly seek the Standards
Track if there is solid data that reflects that it is safe, and the design is
stable, guided by the considerations in <xref target="general-use"/>. However, t
he existence
of this data does not waive the other considerations in this document.</t>
<t>Each published congestion control algorithm is REQUIRED to include a statemen
t
in the abstract indicating whether or not there is IETF consensus that the
proposed congestion control algorithm is considered safe for use on the
Internet. Each published algorithm is also REQUIRED to include a statement in
the abstract describing environments where the protocol is not recommended for
deployment. There can be environments where the congestion control algorithm is
deemed safe for use, but it is still is not recommended for use because it
does not perform well for the user.</t>
<t>As examples of such statements, <xref target="RFC3649"/> specifies HighSpeed
TCP and
includes a statement in the abstract stating that the proposed congestion
control algorithm is Experimental, but may be deployed in the Internet. In
contrast, the Quick-Start document <xref target="RFC4782"/> includes a paragraph
in the
abstract stating that the mechanism is only being proposed for use in
controlled environments. The abstract specifies environments where the
Quick-Start request could give false positives (and therefore would be unsafe fo
r
incremental deployment where some routers forward, but do not process the
option). The abstract also specifies environments where packets containing the
Quick-Start request could be dropped in the network; in such an environment,
Quick-Start would not be unsafe to deploy, but deployment is not recommended
because it could lead to unnecessary delays for the connections attempting to
use Quick-Start. The Quick-Start method is discussed as an example in
<xref target="RFC9049"/>.</t>
<t>Strictly speaking, Informational RFCs in the IETF stream need not meet all of
the criteria in this document, as they do not carry a formal recommendation
from the community. Instead, the community judges the publication of
Informational RFCs based on the value of their addition to the RFC series.</t>
<t>Although out of the scope of this document, proponents of a new algorithm cou
ld
alternatively seek publication as an Informational or Experimental RFC via the
Internet Research Task Force (IRTF). In general, these algorithms are expected
to be less mature than ones that follow the procedures in this document. Authors
documenting deployed congestion control algorithms that cannot be changed by
IETF or IRTF review are invited to seek publication as an Informational RFC via
the Independent Stream Editor (ISE).</t>
</section>
</section>
<section anchor="controlled-environments"><name>Specifying Algorithms for Use in
Controlled Environments</name>
<t>Algorithms can be designed for general Internet deployment or for use in
controlled environments <xref target="RFC8799"/>. Within a controlled environmen
t,
an operator can ensure that flows
are isolated from other Internet flows, or they might
allow these flows to share resources with other Internet flows.
A data center is an example of a controlled environment, which often deploys
fabrics with rich signalling from switches to endpoints.</t>
<t>Algorithms that <t>This document obsoletes <xref target="RFC5033"/>, which was published
rely on specific functions or configurations in the network need to provide a in 2007 as a Best Current Practice for evaluating proposed congestion
reference or specification for these functions (an RFC or another stable control algorithms for publication in Experimental or Proposed Standard RF
specification). For publication to proceed, the IETF will need to assess whether Cs.</t>
a working group exists that can properly assess the network-layer aspects and
their interaction with the congestion control.</t>
<t>In evaluating a new proposal for use in a controlled environment, the IETF ne <t>The IETF specifies standard Internet congestion control algorithms in
eds the RFC Series. These congestion control algorithms can suffer
to understand the usage, e.g., how the usage is scoped to the controlled performance challenges when used in differing environments (e.g.,
environment, whether the algorithm will share resources with Internet traffic, high-speed networks, cellular and Wi-Fi wireless technologies, and
and consider what could happen if used in a protocol that is bridged across an long-distance satellite links), and also when flows carry specific
Internet path. Algorithms that are designed to be confined to a controlled workloads (e.g., Voice over IP (VoIP), gaming, and videoconferencing).</t>
environment and are not intended for use in the general Internet, might instead
seek real-world data for those environments. In such cases, the evaluation
criteria in the remainder of this document might not apply.</t>
</section> <t>When <xref target="RFC5033"/> was published, TCP <xref
<section anchor="evaluation-criteria"><name>Evaluation Criteria</name> target="RFC9293"/> was the primary focus of IETF congestion control
efforts, with proposals typically discussed within the Internet
Congestion Control Research Group (ICCRG). Concurrently, the Datagram
Congestion Control Protocol (DCCP) <xref target="RFC4340"/> was
developed to define new congestion control algorithms for datagram
traffic, while the Stream Control Transmission Protocol (SCTP) <xref
target="RFC9260"/> reused TCP congestion control algorithms.</t>
<t>As previously noted, authors are expected to conduct a comprehensive evaluati <t>Since then, several changes have occurred. The range of protocols
on utilizing congestion control algorithms has expanded to include QUIC
of the advantages and disadvantages of congestion control algorithms presented <xref target="RFC9000"/> and RTP Media Congestion Avoidance Techniques
to the IETF. The following guidelines are intended to assist authors and the (RMCAT) (e.g., <xref target="RFC8836"/>). Additionally, some alternative
IETF community in this endeavor. While these guidelines provide a helpful congestion control algorithms have been tested and deployed at scale
framework, they should not be regarded as an exhaustive checklist, as concerns without full IETF review. There is increased interest in specialized use
beyond the scope of these guidelines may also arise.</t> cases, such as data centers (e.g., <xref target="RFC8257"/>), and in
supporting a variety of upper-layer protocols and applications, such as
real-time protocols. Moreover, the community has gained significant
experience with congestion indications beyond packet loss.</t>
<t>When considering a proposed congestion control algorithm, the community MUST <t>Multicast congestion control is a considerably less mature field of
consider the following criteria. These criteria will be evaluated in various study and is not in the scope of this document. However, <xref
domains (see <xref target="general-use"/> and <xref target="special-cases"/>).</ section="4" sectionFormat="of" target="RFC8085"/> provides additional
t> guidelines for multicast and broadcast usage of UDP.</t>
<t>Some of the sections below will list criteria that SHOULD be met. It could <t>Congestion control algorithms have been developed outside of the
happen that these criteria are not in fact met by the proposal. In such cases, IETF, including at least two that saw large scale deployment. These
the community MUST document whether not meeting the criteria is acceptable, for include CUBIC <xref target="HRX08"/> and Bottleneck Bandwidth and
example because there are practical limitations on carrying out an evaluation of Round-trip propagation time (BBR) <xref
the criteria.</t> target="I-D.cardwell-iccrg-bbr-congestion-control"/>.</t>
<t>The requirement that the community consider a criterion does not imply that t <t>CUBIC was documented in a research publication in 2008 <xref
he target="HRX08"/>, and was then adopted as the default congestion control
result needs to be described in a resulting RFC. There is no formal requirement algorithm for the TCP implementation in Linux. It was already used in a
to document the results, although normal IETF policies for archiving proceedings significant fraction of TCP connections over the Internet before being
will provide a record.</t> documented in an Internet-Draft in 2015, and published as an
Informational RFC in 2017 as <xref target="RFC8312"/> and then as a
Proposed Standard in 2023 <xref target ="RFC9438"/>.</t>
<t>This document, except where otherwise noted, does not provide normative guida <t>At the time of writing, BBR is being developed as an internal
nce research project by Google, with the first implementation contributed to
on the acceptable thresholds for any of these criteria. Instead, the community Linux kernel 4.19 in 2016. BBR was described in an Internet-Draft in
will use these evaluations as an input when considering whether to progress the 2018 and was first presented in the IRTF Internet Congestion Control Resea
proposed algorithm.</t> rch Group. It has since been regularly updated to document the
evolving versions of the algorithm <xref
target="I-D.cardwell-iccrg-bbr-congestion-control"/>. BBR is currently
widely used for Google services using either TCP or QUIC and is also
widely deployed outside of Google.</t>
<section anchor="single-algorithm-behavior"><name>Single Algorithm Behavior</nam <t>We cannot say whether the original authors of <xref
e> target="RFC5033"/> expected that developers would be waiting for IETF
review before widely deploying a new congestion control algorithm over
the Internet, but the examples of CUBIC and BBR illustrate that deployment
of new algorithms is not, in fact, gated by the publication of the
algorithm as an RFC.</t>
<t>The criteria in this section evaluate the congestion control algorithm when o <t>Nevertheless, a specification for a congestion control algorithm
ne provides a number of advantages:</t>
or more flows using that algorithm share a bottleneck link (i.e., with no flows <ul spacing="normal">
using a differing congestion control algorithm).</t> <li>
<t>It can help implementers, operators, and other interested parties
develop a shared understanding of how the algorithm works and how it
is expected to behave in various scenarios and configurations.</t>
</li>
<li>
<t>It can help potential contributors understand the algorithm,
which can make it easier for them to suggest improvements and/or
identify limitations. Furthermore, the specification can help
multiple contributors align on a consensus change to the
algorithm.</t>
</li>
<li>
<t>It can help (by being accessible to anyone) to circumvent the
issue that some implementers may be unable to read open-source
reference implementations due to the constraints of some open-source
licenses.</t>
</li>
</ul>
<t>Beyond helping develop specific algorithm proposals, guidelines can
also serve as a reminder to potential inventors and developers of the
multiple facets of the congestion control problem.</t>
<section anchor="protection-against-congestion-collapse"><name>Protection Agains <t>The evaluation guidelines in this document are intended to be
t Congestion Collapse</name> consistent with the congestion control principles from <xref
target="RFC2914"/> related to preventing congestion collapse, considering
fairness, and optimizing a flow's own performance in terms of
throughput, delay, and loss. <xref target="RFC2914"/> also discusses the
goal of avoiding a congestion control "arms race" among competing
transport protocols.</t>
<t>A congestion control algorithm should either stop sending when the packet dro <t>This document does not give hard-and-fast requirements for an
p appropriate congestion control algorithm. Rather, the document provides
rate exceeds some threshold <xref target="RFC3714"/>, or should include some not a set of criteria that should be considered and weighed by the
ion of "full developers of alternative algorithms and by the IETF in the context of
backoff". For "full backoff", at some point the algorithm would reduce the each proposal.</t>
sending rate to one packet per round-trip time and then exponentially backoff
the time between single packet transmissions if the congestion persists. Exactly
when either "full backoff" or a pause in sending comes into play will be
algorithm-specific. However, as discussed in <xref target="RFC2914"/> and <xref
target="RFC8961"/>,
this requirement is crucial to protect the network in times of extreme
(persistent) congestion.</t>
<t>If full backoff is used, this test does not require that the mechanism must b <t>The high-order criterion for advancing any proposal within the IETF
e is a serious scientific study of the pros and cons that occur when the
identical to that of TCP (<xref target="RFC6298"/>, <xref target="RFC8961"/>). F proposal is considered for publication by the IETF or before it is
or example, this does deployed at a large scale.</t>
not preclude full backoff mechanisms that would give flows with different round-
trip times comparable capacity during backoff.</t>
</section> <t>After initial studies, authors are encouraged to write a
<section anchor="protection-against-bufferbloat"><name>Protection Against Buffer specification of their proposal for publication in the RFC Series. This
bloat</name> allows others to understand and investigate the wealth of proposals in
this space.</t>
<t>A congestion control algorithm should try to avoid maintaining excessive queu <t>This document is intended to reduce the barriers to entry for new
es congestion control work to the IETF. As such, proponents of new
in the network. Exactly how the algorithm achieves this is algorithm-specific, congestion control algorithms ought not to interpret these criteria as a
but see <xref target="RFC8961"/> and <xref target="RFC8085"/> for requirements.< checklist of requirements before approaching the IETF. Instead,
/t> proponents are encouraged to think about these issues beforehand and
have the willingness to do the work implied by the remainder of this
document.</t>
</section>
<t>Bufferbloat <xref target="Bufferbloat"/> refers to the building of excessive <section anchor="specification-of-requirements">
queues in the <name>Specification of Requirements</name>
network. Many network routers are configured with very large buffers. The <t>
standards-track Reno <xref target="RFC5681"/> and CUBIC <xref target="RFC9438"/> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
congestion control "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
algorithms send at progressively higher rates until a First-In First-Out (FIFO) ",
buffer completely fills, and packet losses then occur. Every connection passing "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
through that bottleneck experiences increased latency due to the high buffer "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
occupancy. This adds unwanted latency that negatively impacts highly interactive "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
applications such as videoconferencing or games, but it also affects routine web be
browsing and video playing.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
<t>This problem has been widely discussed since 2011 <xref target="Bufferbloat"/ <section anchor="guidelines-for-authors">
>, but was not <name>Guidelines for Authors</name>
discussed in the Congestion Control Principles published in September 2002
<xref target="RFC2914"/>. The Reno and CUBIC congestion control algorithms do no
t address
this problem, but a new congestion control algorithm has the opportunity to impr
ove the
state of the art.</t>
</section> <section anchor="guidelines-for-authors-about-evaluation">
<section anchor="protection-against-high-packet-loss"><name>Protection Against H <name>Evaluation Guidelines</name>
igh Packet Loss</name> <t>This document does not provide specific evaluation methods, short
of Internet-scale deployment and measurement, to test the criteria
described below. There are multiple possible approaches to
evaluation. Each has a role, and the most appropriate approach depends
on the criteria being evaluated and the maturity of the
specification.</t>
<t>A congestion control algorithm should try to avoid causing excessively high <t>For many algorithms, an initial evaluation will consider individual
rates of packet loss. To accomplish this, it should avoid excessive increases in protocol mechanisms in a simulator to analyze their stability and
sending rate, and reduce its sending rate if experiencing high packet loss.</t> safety across a wide range of conditions, including overload. For
example, <xref target="RFC8869"/> describes evaluation test cases for
interactive real-time media over wireless networks. Such results could
also be published or discussed in IRTF research groups, such as ICCRG
and MAPRG.</t>
<t>The first version of the BBR algorithm <xref target="BBRv1-draft"/> failed th <t>Before a proposed congestion control algorithm is published as an
is requirement. Experimental or Standards Track RFC, the community
Experimental evaluation <xref target="BBRv1-Evaluation"/> showed that it caused <bcp14>SHOULD</bcp14> gain practical experience with implementations
a sustained and experience using the algorithm. Implementations by independent
rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer teams can help provide assurance that a specification has avoided
size was less than roughly one and a half times the Bandwidth Delay Product assumptions or ambiguity. An independent evaluation by multiple teams
(BDP). This was unsatisfactory, and indeed further versions provided a fix for t helps provide assurance that the design meets the evaluation criteria
his and can assess typical interactions with other traffic. This
aspect of BBR <xref target="BBR-draft"/>.</t> evaluation could use an emulated laboratory environment or a
controlled experiment (within a limited domain or at Internet
scale). When a working group is trying to decide if a proposed
specification is ready for publication, it will normally consider
evidence of results. This ought to be documented in any request from
the working group to publish the specification.</t>
<t>This requirement does not imply that the algorithm should react to packet los <t>A congestion control algorithm without multiple implementations
ses might still be published as an RFC if a single implementation is
in exactly the same way as current standards-track congestion control algorithms widely used, open source, and shown to have a positive impact on the
(e.g., <xref target="RFC5681"/>).</t> Internet, particularly if the target status is Experimental.</t>
</section>
</section> <section anchor="guidelines-for-authors-about-document-status">
<section anchor="fairness-within-the-proposed-congestion-control-algorithm"><nam <name>Document-Status Guidelines</name>
e>Fairness within the Proposed Congestion Control Algorithm</name>
<t>When multiple competing flows all use the same proposed congestion control <t>The guidelines in this document apply to specifications of
algorithm, the proposal should explore how the capacity is shared among the congestion control algorithms that seek publication as an RFC via the
competing flows. Capacity fairness can be important when a small number of IETF Stream with an Experimental or Standards Track status. The
similar flows compete to fill a bottleneck. However, it can also not be useful, evaluation of either status involves the same questions, but with
for example, when comparing flows that seek to send at different rates, or if different expectations for both the answers and the degree of
some of the flows do not last sufficiently long to approach asymptotic behavior. certainty of those answers.</t>
</t>
</section> <t>Specifications of congestion control algorithms without empirical
<section anchor="short-flows"><name>Short Flows</name> evidence of Internet-scale deployment <bcp14>MUST</bcp14> seek
Experimental status, unless they are not targeted for general use.
Algorithms not targeted at general use do not require Internet-scale
data.</t>
<t>A great deal of congestion control analysis concerns the steady-state behavio <t>Specifications that seek to be published as Experimental IETF
r Stream RFCs ought to explain the reason for the status and what further
of long flows. However, many Internet flows are relatively short-lived. information would be required to progress to a Standards Track RFC. For
Many short-lived flows today remain in the "slow example, <xref target="RFC6928" section="12" sectionFormat="of"/> provide
start" mode of operation <xref target="RFC5681"/> that commonly features exponen s
tial "Usage and Deployment Recommendations" that describe the experiments expe
congestion window growth because the flow cted
never experiences congestion (e.g., packet loss).</t> by the TCPM Working Group. <xref target="RFC7414" section="4"
sectionFormat="of"/> provides other examples of extensions that were
considered experimental when the specification was published.</t>
<t>A proposed congestion control algorithm MUST consider how new and short-lived <t>Experimental specifications <bcp14>SHOULD NOT</bcp14> be deployed
flows affect long-lived flows, and vice versa.</t> as a default. They <bcp14>SHOULD</bcp14> only be deployed in
situations where they are being actively measured and where it is
possible to deactivate them if there are signs of pathological
behavior.</t>
</section> <t>Specifications of congestion control algorithms with a record of
</section> measured Internet-scale deployment <bcp14>MAY</bcp14> directly seek Stand
<section anchor="mixed-algorithm-behavior"><name>Mixed Algorithm Behavior</name> ards
Track status if there is solid data that reflects that the algorithm is s
afe
and the design is stable, guided by the considerations in <xref
target="general-use"/>. However, the existence of this data does not waiv
e the
other considerations in this document.</t>
<t>Mixed algorithm behavior criteria evaluate the interaction of the proposed <t>Each specification submitted for publication as an RFC is
congestion control algorithm with commonly deployed congestion control <bcp14>REQUIRED</bcp14> to include a statement in the abstract
algorithms.</t> indicating whether or not there is IETF consensus that the proposed
congestion control algorithm is considered safe for use on the
Internet. Each such specification is also <bcp14>REQUIRED</bcp14> to
include a statement in the abstract describing environments where the
protocol is not recommended for deployment. There can be environments
where the congestion control algorithm is deemed safe for use, but it
is still not recommended for use because it does not perform well
for the user.</t>
<t>In contexts where differing congestion control algorithms are used, it is <t>Examples of such statements exist in <xref target="RFC3649"/>, which
important to understand whether the proposed congestion control algorithm could specifies
result in more harm than previous standards-track algorithms (e.g., HighSpeed TCP and includes a statement in the abstract stating that
<xref target="RFC5681"/>, <xref target="RFC9002"/>, <xref target="RFC9438"/>) to the proposed congestion control algorithm is experimental but may be
flows sharing a common bottleneck. deployed in the Internet. In contrast, the Quick-Start document <xref
The measure of harm is not restricted to unequal capacity, but ought also to target="RFC4782"/> includes a paragraph in the abstract stating that
consider metrics such as the introduced latency, or an increase in packet loss. the mechanism is only being proposed for use in controlled
An evaluation MUST assess the potential to cause starvation, including environments. The abstract specifies environments where the
assurance that a loss of all feedback (e.g., detected by expiry of a Quick-Start request could give false positives (and therefore would be
retransmission time out) results in backoff.</t> unsafe for incremental deployment where some routers forward but do
not process the option). The abstract also specifies environments
where packets containing the Quick-Start request could be dropped in
the network; in such an environment, Quick-Start would not be unsafe
to deploy, but deployment is not recommended because it could lead to
unnecessary delays for the connections attempting to use
Quick-Start. The Quick-Start method is discussed as an example in
<xref target="RFC9049"/>.</t>
<section anchor="existing-general-purpose-congestion-control"><name>Existing Gen <t>Strictly speaking, documents for publication as Informational RFCs fr
eral-Purpose Congestion Control</name> om the IETF Stream need not
meet all of the criteria in this document, as they do not carry a
formal recommendation from the IETF community. Instead, the community
judges the publication of these Informational RFCs based on the value of
their addition to the information captured by the RFC Series.</t>
<t>A proposed congestion control algorithm MUST be evaluated when competing agai <t>Although it is out of scope for this document, proponents of a new
nst algorithm could alternatively seek publication of their specification as
standard IETF congestion controls, e.g. <xref target="RFC5681"/>, <xref target=" an Informational or
RFC9002"/>, Experimental RFC via the Internet Research Task Force (IRTF) Stream. In
<xref target="RFC9438"/>. A proposed congestion control algorithm that has a sig general, these algorithms are expected to be less mature than ones
nificantly that follow the procedures in this document for publication via the IETF
negative impact on flows using standard congestion control might be suspect, and Stream. Authors documenting
this aspect should be part of the community's decision making with regards to deployed congestion control algorithms that cannot be changed by IETF
the suitability of the proposed congestion control algorithm. The community or IRTF review are invited to seek publication of their specification as
should also consider other non-standard congestion control algorithms that are an Informational RFC
known to be widely deployed.</t> via the Independent Submission Stream.</t>
</section>
</section>
<t>Note that this guideline is not a requirement for strict Reno- or CUBIC- <section anchor="controlled-environments">
friendliness as a prerequisite for a proposed congestion control mechanism to <name>Specifying Algorithms for Use in Controlled Environments</name>
advance to Experimental or Standards Track status. As an example, HighSpeed TCP <t>Algorithms can be designed for general Internet deployment or for use
is a congestion control mechanism specified as Experimental, that is not TCP- in controlled environments <xref target="RFC8799"/>. Within a controlled
friendly in all environments. When a new congestion control algorithm is environment, an operator can ensure that flows are isolated from other
deployed, the existing major algorithm deployments need to be considered to Internet flows or they might allow these flows to share resources with
avoid severe performance degradation. Note that this guideline does not other Internet flows. A data center is an example of a controlled
constrain the interaction with non-best-effort flows.</t> environment that often deploys fabrics with rich signaling from
switches to endpoints.</t>
<t>As an example from an Experimental RFC, fairness with standard TCP is discuss <t>Algorithms that rely on specific functions or configurations in the
ed network need to provide a reference or specification for these functions
in Sections 4 and 6 of <xref target="RFC3649"/> (HighSpeed TCP) and using spare (such as an RFC or another stable specification). For publication of a spe
capacity is cification of one of these algorithms to proceed,
discussed in Sections 6, 11.1, and 12 of <xref target="RFC3649"/>.</t> the IETF will need to consider whether a working group exists that can
properly assess the network-layer aspects and their interaction with the
congestion control.</t>
</section> <t>In evaluating a new proposal for use in a controlled environment, the
<section anchor="real-time-congestion-control"><name>Real-Time Congestion Contro IETF community needs to understand the usage (e.g., how the usage is scope
l</name> d to
the controlled environment), whether the algorithm will share resources wi
th
Internet traffic, and what could happen if used in a protocol that is brid
ged
across an Internet path. Algorithms that are designed to be confined to a
controlled environment and are not intended for use in the general Interne
t
might instead seek real-world data for those environments. In such cases,
the
evaluation criteria in the remainder of this document might not apply.</t>
</section>
<t>General-purpose algorithms need to coexist in the Internet with real-time <section anchor="evaluation-criteria">
congestion control algorithms, which, in general, have finite throughput <name>Evaluation Criteria</name>
requirements (i.e., do not seek to utilize all available capacity) and more
strict latency bounds. See <xref target="RFC8836"/> for a description of the cha
racteristics
of this use case and the resulting requirements.</t>
<t><xref target="RFC8868"/> provides suggestions for real-time congestion contro <t>As previously noted, authors of a specification on a congestion
l design and control algorithm are expected to conduct a comprehensive evaluation of th
<xref target="RFC8867"/> suggests test cases. <xref target="RFC9392"/> describes e
some considerations advantages and disadvantages of any congestion control algorithms presente
for the RTP Control Protocol (RTCP). In particular, real-time flows d to
can use less frequent feedback (acknowledgement) than that provided by reliable the IETF community. The following guidelines are intended to assist author
transports. s
This document does not change the informational status of those RFCs.</t> and the community in this endeavor. While these guidelines provide a helpf
ul
framework, they should not be regarded as an exhaustive checklist as conce
rns
beyond the scope of these guidelines may also arise.</t>
<t>A proposed congestion control algorithm SHOULD consider coexistence with wide <t>When considering a proposed congestion control algorithm, the
ly community <bcp14>MUST</bcp14> consider the criteria in the following secti
deployed real-time congestion control algorithms. Regrettably, at the time of ons. These
writing (2024), many algorithms with detailed public specifications are not criteria will be evaluated in various domains (see Sections <xref
widely deployed, while many widely deployed real-time congestion control target="general-use" format="counter"/> and <xref target="special-cases"
algorithms have incomplete public specifications. It is hoped that this format="counter"/>).</t>
situation will change.</t>
<t>To the extent that behavior of widely deployed algorithms is understood, <t>Some of the sections below will list criteria that
proponents of a proposed congestion control algorithm can analyze and simulate <bcp14>SHOULD</bcp14> be met. It could happen that these criteria are
a proposal's interaction with those algorithms. To the extent they are not, expe not, in fact, met by the proposal. In such cases, the community
riments <bcp14>MUST</bcp14> document whether not meeting the criteria is
can be conducted where possible.</t> acceptable, for example, if there are practical limitations on
carrying out an evaluation of the criteria.</t>
<t>Real-time flows can be directed into distinct queues via Differentiated Servi <t>The requirement that the community consider a criterion does not
ces imply that the result needs to be described in an RFC: there is
Code Points (DSCP) or other mechanisms, which can substantially reduce the no formal requirement to document the results, although normal IETF
interplay with other traffic. However, a proposal targeting general Internet use policies for archiving proceedings will provide a record.</t>
can not assume this is always the case.</t>
<t><xref target="circuit-breakers"/> describes the impact of network transport c <t>This document, except where otherwise noted, does not provide
ircuit breaker normative guidance on the acceptable thresholds for any of these
algorithms. <xref target="RFC8083"/> also defines a minimal set of RTP circuit b criteria. Instead, the community will use these evaluations as an input
reakers that when considering whether to progress the proposed algorithm
operate end-to-end across a path. This identifies conditions under which a sende specification in the publication process.</t>
r needs to
stop transmitting media data to protect the network from excessive congestion.
It is expected that, in the absence of long-lived excessive congestion, RTP
applications running on best-effort IP networks will be able to operate without
triggering these circuit breakers.</t>
</section> <section anchor="single-algorithm-behavior">
<section anchor="short-and-long-flows"><name>Short and Long Flows</name> <name>Single Algorithm Behavior</name>
<t>The effect on short-lived and long-lived flows using other common congestion <t>The criteria in the following subsections evaluate the congestion con
control algorithms MUST be evaluated, as in <xref target="short-flows"/>.</t> trol
algorithm when one or more flows using that algorithm share a
bottleneck link (i.e., with no flows using a differing congestion
control algorithm).</t>
</section> <section anchor="protection-against-congestion-collapse">
</section> <name>Protection Against Congestion Collapse</name>
<section anchor="other-criteria"><name>Other Criteria</name>
<section anchor="differences-with-congestion-control-principles"><name>Differenc <t>A congestion control algorithm should either stop sending when
es with Congestion Control Principles</name> the packet drop rate exceeds some threshold <xref
target="RFC3714"/> or include some notion of "full
backoff". For "full backoff", at some point, the algorithm would
reduce the sending rate to one packet per round-trip time; then, it wo
uld
exponentially back off the time between single packet transmissions
if the congestion persists. Exactly when either "full backoff" or a
pause in sending comes into play will be algorithm specific.
However, as discussed in <xref target="RFC2914"/> and <xref
target="RFC8961"/>, this requirement is crucial to protect the
network in times of extreme (and persistent) congestion.</t>
<t>A proposed congestion control algorithm MUST clearly explain any deviations f <t>If full backoff is used, this test does not require that the
rom mechanism be identical to that of TCP (see <xref
<xref target="RFC2914"/> and <xref target="RFC7141"/>.</t> target="RFC6298"/> and <xref target="RFC8961"/>). For example, this
does not preclude full backoff mechanisms that would give flows with
different round-trip times comparable capacity during backoff.</t>
</section>
</section> <section anchor="protection-against-bufferbloat">
<section anchor="incremental-deployment"><name>Incremental Deployment</name> <name>Protection Against Bufferbloat</name>
<t>A congestion control algorithm ought to try to avoid maintaining
excessive queues in the network. Exactly how the algorithm achieves
this is algorithm specific; see <xref target="RFC8961"/> and
<xref target="RFC8085"/> for requirements.</t>
<t>A congestion control algorithm proposal MUST discuss whether it allows for <t>"Bufferbloat" refers to the building of excessive queues in the
incremental deployment in the targeted environment. For a mechanism targeted for network <xref target="BUFFERBLOAT"/>. Many network routers are
deployment in the current Internet, the proposal SHOULD discuss what is known configured with very large buffers. The Standards Track RFCs <xref
(if anything) about the correct operation of the mechanisms with some of the target="RFC5681"/> and <xref target="RFC9438"/> describe the Reno
equipment in the current Internet, e.g., routers, transparent proxies, WAN and CUBIC congestion control algorithms (respectively), which send
optimizers, intrusion detection systems, home routers, and the like.</t> at progressively higher rates until a First In, First Out (FIFO)
buffer completely fills; then packet losses occur. Every connection
passing through that bottleneck experiences 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 routine web browsing
and video playing.</t>
<t>Similarly, if the proposed congestion control algorithm is intended only for <t>This problem has been widely discussed since 2011 <xref
specific environments (and not the global Internet), the proposal SHOULD target="BUFFERBLOAT"/>, but was not discussed in the congestion
consider how this intention is to be realised. The community will have to control principles published in September 2002 <xref
address the question of whether the scope can be enforced by stating the target="RFC2914"/>. The Reno and CUBIC congestion control algorithms
restrictions, or whether additional protocol mechanisms are required to enforce do not address this problem, but a new congestion control algorithm
this scoping. The answer will necessarily depend on the proposed change.</t> has the opportunity to improve the state of the art.</t>
</section>
<t>As an example from an Experimental RFC, deployment issues are discussed in <section anchor="protection-against-high-packet-loss">
Sections 10.3 and 10.4 of <xref target="RFC4782"/> (Quick-Start).</t> <name>Protection Against High Packet Loss</name>
</section> <t>A congestion control algorithm needs to avoid causing
</section> excessively high rates of packet loss. To accomplish this, it should
</section> avoid excessive increases in sending rate and reduce its sending
<section anchor="general-use"><name>General Use</name> rate if experiencing high packet loss.</t>
<t>The criteria in <xref target="evaluation-criteria"/> will be evaluated in the <t>The first version of the BBR algorithm <xref
following target="BBRv1"/> failed this requirement. Experimental
scenarios. Unless a proposed congestion control specification explicitly forbids evaluation <xref target="BBRv1-EVALUATION"/> showed that it caused a
use on the public Internet, there MUST be IETF consensus that it meets the sustained rate of packet loss when multiple BBRv1 flows shared a
criteria in these scenarios for the proposed congestion control algorithm to bottleneck and the buffer size was less than roughly one and a half
progress.</t> times the Bandwidth Delay Product (BDP). This was unsatisfactory,
and, indeed, further versions provided a fix for this aspect of BBR
<xref target="I-D.cardwell-iccrg-bbr-congestion-control"/>.</t>
<t>The evaluation in each scenario SHOULD occur over a representative range of <t>This requirement does not imply that the algorithm should react
bandwidths, delays, and queue depths. Of course, the set of parameters to packet losses in exactly the same way as congestion control algorit
representative of the public Internet will change over time.</t> hms described in current Standards Track RFCs (e.g., <xref target="RFC5681"/>).<
/t>
</section>
<t>These criteria are intended to capture a statistically dominant set of Intern <section anchor="fairness-within-the-proposed-congestion-control-algorit
et hm">
conditions. In the case that a proposed congestion control algorithm has been <name>Fairness Within the Proposed Congestion Control Algorithm</name>
tested at Internet scale, the results from that deployment are often useful for <t>When multiple competing flows all use the same proposed
answering these questions.</t> congestion control algorithm, the evaluation should explore how the
capacity is shared among the competing flows. Capacity fairness can
be important when a small number of similar flows compete to fill a
bottleneck. However, it can also not be useful, for example, when
comparing flows that seek to send at different rates or if some of
the flows do not last sufficiently long to approach asymptotic
behavior.</t>
</section>
<section anchor="paths-with-tail-drop-queues"><name>Paths with Tail-drop Queues< <section anchor="short-flows">
/name> <name>Short Flows</name>
<t>A great deal of congestion control analysis concerns the
steady-state behavior of long flows. However, many Internet flows
are relatively short lived. Many short-lived flows today remain in
the "slow start" mode of operation <xref target="RFC5681"/> that
commonly features exponential congestion window growth because the
flow never experiences congestion (e.g., packet loss).</t>
<t>A proposal for a congestion control algorithm <bcp14>MUST</bcp14>
consider how new and short-lived flows affect long-lived flows, and
vice versa.</t>
</section>
</section>
<t>The performance of a congestion control algorithm is affected by the queue <section anchor="mixed-algorithm-behavior">
discipline applied at the bottleneck link. The drop-tail queue discipline (using <name>Mixed Algorithm Behavior</name>
a FIFO buffer) MUST be evaluated. See <xref target="aqm"/> for evaluation of oth <t>The mixed algorithm behavior criteria evaluate the interaction of the
er queue proposed congestion control algorithms being specified with commonly dep
disciplines.</t> loyed
congestion control algorithms.</t>
<t>In contexts where differing congestion control algorithms are used,
it is important to understand whether the proposed congestion control
algorithm could result in more harm than algorithms published in previou
s Standards Track RFCs (e.g., <xref target="RFC5681"/>, <xref target="RFC9002"/>
,
and <xref target="RFC9438"/>) to flows sharing a common bottleneck.
The measure of harm is not restricted to unequal capacity, but also
ought to consider metrics such as the introduced latency or an
increase in packet loss. An evaluation <bcp14>MUST</bcp14> assess the
potential to cause starvation, including assurance that a loss of all
feedback (e.g., detected by expiry of a retransmission time out)
results in backoff.</t>
</section> <section anchor="existing-general-purpose-congestion-control">
<section anchor="tunnel-behavior"><name>Tunnel Behavior</name> <name>Existing General-Purpose Congestion Control</name>
<t>A proposed congestion control algorithm <bcp14>MUST</bcp14> be
evaluated when competing against standard IETF congestion controls
(e.g., <xref target="RFC5681"/>, <xref target="RFC9002"/>, and <xref
target="RFC9438"/>). A proposed congestion control algorithm that
has a significantly negative impact on flows using standard
congestion control might be suspect, and this aspect should be part
of the community's decision making with regards to the suitability
of the proposed congestion control algorithm. The community should
also consider other non-standard congestion control algorithms that
are known to be widely deployed.</t>
<t>When a proposed congestion control algorithm relies on explicit signals from <t>Note that this guideline is not a requirement for strict Reno or
the CUBIC friendliness as a prerequisite for a proposed congestion
path, the proposal MUST consider the effect of traffic passing through a tunnel, control mechanism to advance to Experimental or Standards Track
where routers may not be aware of the flow.</t> status. As an example, HighSpeed TCP is a congestion control
mechanism that is specified in an Experimental RFC and is not Reno fri
endly
in all environments. When a new congestion control algorithm is
deployed, the existing major algorithm deployments need to be
considered to avoid severe performance degradation. Note that this
guideline does not constrain the interaction with flows that are not
best effort.</t>
<t>The design of tunnels and similar encapsulations might need to consider neste <t>As an example from an Experimental RFC, fairness with standard
d TCP is discussed in Sections <xref target="RFC3649"
congestion control interactions. For example, when ECN is used by both an sectionFormat="bare" section="4"/> and <xref target="RFC3649"
IP and lower layer technology <xref target="ECN-Encaps"/>.</t> sectionFormat="bare" section="6"/> of <xref target="RFC3649"
format="default"/>, and using spare capacity is
discussed in Sections <xref target="RFC3649" sectionFormat="bare"
section="6"/>, <xref target="RFC3649" sectionFormat="bare"
section="11.1"/>, and <xref target="RFC3649" sectionFormat="bare"
section="12"/> of <xref target="RFC3649"/>.</t>
</section>
</section> <section anchor="real-time-congestion-control">
<section anchor="wired-paths"><name>Wired Paths</name> <name>Real-Time Congestion Control</name>
<t>Wired networks are usually characterized by extremely low rates of packet los <t>General-purpose algorithms need to coexist in the Internet with
s real-time congestion control algorithms, which in general have
except for those due to queue drops. They tend to have stable aggregate finite throughput requirements (i.e., they do not seek to utilize all
capacity, usually higher than other types of links, and low non-queueing delay. available capacity) and more strict latency bounds. See <xref
Because the properties are relatively simple, wired links are typically used as target="RFC8836"/> for a description of the characteristics of this
a use case and the resulting requirements.</t>
"baseline" case even if they are not always the bottleneck link in the modern
Internet.</t>
</section> <t><xref target="RFC8868"/> provides suggestions for real-time
<section anchor="wireless-paths"><name>Wireless Paths</name> congestion control design and <xref target="RFC8867"/> suggests test
cases. <xref target="RFC9392"/> describes some considerations for
the RTP Control Protocol (RTCP). In particular, real-time flows can
use less frequent feedback (acknowledgment) than that provided by
reliable transports. This document does not change the
Informational status of those RFCs.</t>
<t>While the early Internet was dominated by wired links, the properties of <t>A proposal for a congestion control algorithm <bcp14>SHOULD</bcp14>
wireless links have become important to Internet performance. In consider coexistence with widely deployed real-time congestion
particular, a proposed congestion control algorithm should be evaluated in control algorithms. Regrettably, at the time of writing (2024), many
situations where some packet losses are due to radio effects, rather than router algorithms with detailed public specifications are not widely
queue drops; the link capacity varies over time due to changing link conditions; deployed, while many widely deployed real-time congestion control
and media access delays and link-layer retransmission lead to increased jitter algorithms have incomplete public specifications. It is hoped that
in round-trip times. See <xref target="RFC3819"/> and Section 16 of <xref target this situation will change.</t>
="Tools"/> for further
discussion of wireless properties.</t>
</section> <t>To the extent that behavior of widely deployed algorithms is
</section> understood, proponents of a proposed congestion control algorithm
<section anchor="special-cases"><name>Special Cases</name> can analyze and simulate a proposal's interaction with those
algorithms. To the extent that they are not, experiments can be
conducted where possible.</t>
<t>The criteria in <xref target="evaluation-criteria"/> will be evaluated in the <t>Real-time flows can be directed into distinct queues via
following Differentiated Services Code Points (DSCPs) or other mechanisms,
scenarios, unless the proposed congestion control algorithm specifically which can substantially reduce the interplay with other
excludes its use in a scenario. For these specific use-cases, the community MAY traffic. However, a proposal targeting general Internet use cannot
allow a proposal to progress even if the criteria indicate an unsatisfactory assume this is always the case.</t>
result for these scenarios.</t>
<t>In general, measurements from Internet-scale deployments might not expose the <t><xref target="circuit-breakers"/> describes the impact of network
properties of operation in each of these scenarios, because they are not as transport circuit breaker algorithms. <xref target="RFC8083"/> also
ubiquitous as the General Use scenarios.</t> defines a minimal set of RTP circuit breakers that operate
end-to-end across a path. This identifies conditions under which a
sender needs to stop transmitting media data to protect the network
from excessive congestion. It is expected that, in the absence of
long-lived excessive congestion, RTP applications running on
best-effort IP networks will be able to operate without triggering
these circuit breakers.</t>
</section>
<section anchor="aqm"><name>Active Queue Management (AQM)</name> <section anchor="short-and-long-flows">
<name>Short and Long Flows</name>
<t>The effect on short-lived and long-lived flows using other common
congestion control algorithms <bcp14>MUST</bcp14> be evaluated, as
in <xref target="short-flows"/>.</t>
</section>
</section>
<t>The proposed congestion control algorithm SHOULD be evaluated under a variety <section anchor="other-criteria">
of <name>Other Criteria</name>
bottleneck queue disciplines. The effect of an AQM discipline can be hard to <section anchor="differences-with-congestion-control-principles">
detect by Internet evaluation. At a minimum, a proposal should reason about an <name>Differences with Congestion Control Principles</name>
algorithm's response to various AQM disciplines. Simulation or empirical results <t>A proposal for a congestion control algorithm <bcp14>MUST</bcp14>
are, of course, valuable.</t> clearly explain any deviations from <xref target="RFC2914"/> and
<xref target="RFC7141"/>.</t>
</section>
<t>Among the AQM techniques that might have an impact on a proposed congestion <section anchor="incremental-deployment">
control algorithm are Flow Queue CoDel (FQ-CoDel) <xref target="RFC8290"/>; Prop <name>Incremental Deployment</name>
ortional Integral Controller <t>A congestion control algorithm proposal <bcp14>MUST</bcp14>
Enhanced (PIE) <xref target="RFC8033"/>; and Low Latency, Low Loss, and Scalable discuss whether it allows for incremental deployment in the targeted
Throughput environment. For a mechanism targeted for deployment in the current
(L4S) <xref target="RFC9332"/>.</t> Internet, the proposal <bcp14>SHOULD</bcp14> discuss what is known
(if anything) about the correct operation of the mechanisms with
some of the equipment in the current Internet (e.g., routers,
transparent proxies, WAN optimizers, intrusion detection systems,
home routers, and the like).</t>
<t>Similarly, if the proposed congestion control algorithm is
intended only for specific environments (and not the global
Internet), the proposal <bcp14>SHOULD</bcp14> consider how this
intention is to be realized. The IETF community will have to address
the
question of whether the scope can be enforced by stating the
restrictions or whether additional protocol mechanisms are required
to enforce this scoping. The answer will necessarily depend on the
proposed change.</t>
<t>As an example from an Experimental RFC, deployment issues of Quick-
Start are
discussed in Sections <xref target="RFC4782" section="10.3"
sectionFormat="bare"/> and <xref target="RFC4782" section="10.4"
sectionFormat="bare"/> of <xref target="RFC4782"/>.</t>
</section>
</section>
</section>
<t>A proposed congestion control algorithm that sets one of the two Explicit <section anchor="general-use">
Congestion Transport (ECT) codepoints in the IP header can gain the benefits of <name>General Use</name>
receiving Explicit Congestion Notification (ECN) Congestion Experienced (CE) <t>The criteria in <xref target="evaluation-criteria"/> will be
signals from an on-path AQM <xref target="RFC8087"/>. Use of ECN <xref target="R evaluated in the scenarios described in the following subsections. Unless
FC3168"/>, <xref target="RFC9332"/> a proposed congestion
requires the congestion control algorithm to react when it receives a packet control algorithm specification of the IETF Stream explicitly forbids use
with an ECN-CE marking. This reaction needs to be evaluated to confirm that the on the public Internet,
algorithm conforms with the requirements of the ECT codepoint that was used.</t> there <bcp14>MUST</bcp14> be IETF consensus that it meets the criteria
in these scenarios for the proposed congestion control algorithm to
progress.</t>
<t>Note that evaluation of AQM techniques -- as opposed to their impact on a <t>The evaluation of each scenario <bcp14>SHOULD</bcp14> occur over a
specific proposed congestion control algorithm -- is out of scope of this representative range of bandwidths, delays, and queue depths. Of course,
document. <xref target="RFC7567"/> describes design considerations for AQMs.</t> the set of parameters representative of the public Internet will change
over time.</t>
</section> <t>These criteria are intended to capture a statistically dominant set
<section anchor="circuit-breakers"><name>Operation with the Envelope set by Netw of Internet conditions. In the case that a proposed congestion control
ork Circuit Breakers</name> algorithm has been tested at Internet scale, the results from that
deployment are often useful for answering these questions.</t>
<t>Some equipment in the network uses an automatic mechanism to continuously <section anchor="paths-with-tail-drop-queues">
monitor the use of resources by a flow or aggregate set of flows <xref target="R <name>Paths with Tail-Drop Queues</name>
FC8084"/>. <t>The performance of a congestion control algorithm is affected by
Such a network transport circuit breaker can automatically detect excessive the queue discipline applied at the bottleneck link. The drop-tail
congestion, and when detected, it can terminate (or significantly reduce the queue discipline (using a FIFO buffer) <bcp14>MUST</bcp14> be
rate of) the flow(s). A well-designed congestion control algorithm ought to evaluated. See <xref target="aqm"/> for evaluation of other queue
react before the flow uses excessive resources, and therefore will operate disciplines.</t>
within the envelope set by network transport circuit breaker algorithms.</t> </section>
</section> <section anchor="tunnel-behavior">
<section anchor="delay"><name>Paths with Varying Delay</name> <name>Tunnel Behavior</name>
<t>When a proposed congestion control algorithm relies on explicit
signals from the path, the proposal <bcp14>MUST</bcp14> consider the
effect of traffic passing through a tunnel, where routers may not be
aware of the flow.</t>
<t>An Internet Path can include simple links, where the minimum delay is the <t>Designers of tunnels and similar encapsulations might need to
propagation delay, and any additional delay can be attributed to link buffering. consider nested congestion control interactions, for example, when the
This cannot be assumed. An Internet Path can also include complex subnetworks Explicit Congestion Notification (ECN) is used by both an IP and lower-l
where the minimum delay changes over various time scales, resulting in a non- ayer technology <xref target="RFC9599"/>.</t>
stationary minimum delay.</t> </section>
<t>Varying delay occurs when a subnet changes the forwarding path to optimise ca <section anchor="wired-paths">
pacity, <name>Wired Paths</name>
resilience, etc. It could also arise when a subnet uses a capacity management <t>Wired networks are usually characterized by extremely low rates of
method where the available resource is periodically distributed among the active packet loss except for those due to queue drops. They tend to have
nodes. A node might then have to buffer data until an assigned transmission stable aggregate capacity, usually higher than other types of links,
opportunity or until the physical path changes (e.g., when the length of a and low non-queueing delay. Because the properties are relatively
wireless path changes, or the physical layer changes its mode of operation). simple, wired links are typically used as a "baseline" case even if
Variation also arises when traffic with a higher priority DSCP pre-empts they are not always the bottleneck link in the modern Internet.</t>
transmission of traffic with a lower class. In these cases, the delay varies as </section>
a function of external factors, and attempting to infer congestion from an
increase in the delay results in reduced throughput. This variation in the
delay over short timescales (jitter) might not be distinguishable from jitter
that results from other effects.</t>
<t>A proposed congestion control algorithm SHOULD be evaluated to ensure its <section anchor="wireless-paths">
operation is robust when there is a significant change in the minimum delay.</t> <name>Wireless Paths</name>
<t>While the early Internet was dominated by wired links, the
properties of wireless links have become important to Internet
performance. In particular, a proposed congestion control algorithm
should be evaluated in situations where some packet losses are due to
radio effects rather than router queue drops. The link capacity
varies over time due to changing link conditions, and media-access
delays and link-layer retransmission lead to increased jitter in
round-trip times. See <xref target="RFC3819"/> and Section 16 of <xref
target="I-D.irtf-tmrg-tools"/> for further discussion of wireless
properties.</t>
</section>
</section>
</section> <section anchor="special-cases">
<section anchor="internet-of-things-and-constrained-nodes"><name>Internet of Thi <name>Special Cases</name>
ngs and Constrained Nodes</name> <t>The criteria in <xref target="evaluation-criteria"/> will be
evaluated in the scenarios described in the following subsections, unless
the proposed congestion
control algorithm specifically excludes its use in a scenario. For these
specific use cases, the IETF community <bcp14>MAY</bcp14> allow a proposal
to
progress even if the criteria indicate an unsatisfactory result for
these scenarios.</t>
<t>The "Internet of Things" (IoT) is a broad concept, but when evaluating a <t>In general, measurements from Internet-scale deployments might not
proposed congestion control algorithm, it is often associated with unique expose the properties of operation in each of these scenarios because
characteristics: they are not as ubiquitous as the general-use scenarios.</t>
IoT nodes might be more constrained in power, CPU, or other parameters than
conventional Internet hosts. This might place limits on the complexity of any
given algorithm. These power and radio constraints might make the volume of
control packets in a given algorithm a key evaluation metric.</t>
<t>Extremely low-power links can lead to very low throughput and a low bandwidth <section anchor="aqm">
- <name>Active Queue Management (AQM)</name>
delay product, well below the standard operating range of most Internet flows.</ <t>The proposed congestion control algorithm <bcp14>SHOULD</bcp14> be
t> evaluated under a variety of bottleneck-queue disciplines. The effect
of an AQM discipline can be hard to detect by Internet evaluation. At
a minimum, a proposal should reason about an algorithm's response to
various AQM disciplines. Simulation or empirical results are, of
course, valuable.</t>
<t>Furthermore, many IoT applications do not a have a human in the loop, and <t>Some of the AQM techniques that might have an impact on a proposed
therefore might have weaker latency constraints because they do not relate to a congestion control algorithm include:</t>
user experience. Congestion control algorithm can still need to share the <ul>
path with other flows with different constraints.</t> <li>Flow Queue CoDel (FQ-CoDel) <xref target="RFC8290"/>;</li>
<li>Proportional Integral controller Enhanced (PIE) <xref target="RFC80
33"/>; and</li>
<li>Low Latency, Low Loss, and Scalable Throughput (L4S) <xref target="
RFC9332"/>.</li>
</ul>
</section> <t>A proposed congestion control algorithm that sets one of the two
<section anchor="paths-with-high-delay"><name>Paths with High Delay</name> ECN-Capable Transport (ECT) codepoints in the IP header can gain the
benefits of receiving Explicit Congestion Notification-Congestion
Experienced (ECN-CE) signals from an on-path AQM <xref
target="RFC8087"/>. Use of ECN (see <xref target="RFC3168"/> and <xref
target="RFC9332"/>) requires the congestion control algorithm to react
when it receives a packet with an ECN-CE marking. This reaction needs
to be evaluated to confirm that the algorithm conforms with the
requirements of the ECT codepoint that was used.</t>
<t>A proposed congestion control algorithm ought not to presume that all general <t>Note that evaluation of AQM techniques -- as opposed to their
Internet paths have a low delay. Some paths include links that contribute much impact on a specific proposed congestion control algorithm -- is out
more delay than for a typical Internet path. Satellite links often have delays of scope of this document. <xref target="RFC7567"/> describes design
longer than typical for wired paths <xref target="RFC2488"/> and high delay band considerations for AQMs.</t>
width </section>
products <xref target="RFC3649"/>.</t>
<t>Paths can also present a variable delay as described in <xref target="delay"/ <section anchor="circuit-breakers">
>.</t> <name>Operation with the Envelope Set by Network Circuit Breakers</name>
<t>Some equipment in the network uses an automatic mechanism to
continuously monitor the use of resources by a flow or aggregate set
of flows <xref target="RFC8084"/>. Such a network transport circuit
breaker can automatically detect excessive congestion; when
detected, it can terminate (or significantly reduce the rate of) the
flow(s). A well-designed congestion control algorithm ought to react
before the flow uses excessive resources; therefore, it will operate
within the envelope set by network transport circuit breaker
algorithms.</t>
</section>
</section> <section anchor="delay">
<section anchor="misbehaving-nodes"><name>Misbehaving Nodes</name> <name>Paths with Varying Delay</name>
<t>A proposed congestion control algorithm SHOULD explore how the algorithm <t>An Internet path can include simple links, where the minimum delay
performs with non-compliant senders, receivers, or routers. In addition, the is the propagation delay, and any additional delay can be attributed
proposal should explore how a proposed congestion control algorithm performs to link buffering. This cannot be assumed. An Internet path can also
with outside attackers. This can be particularly important for proposed include complex subnetworks where the minimum delay changes over
congestion control algorithms that involve explicit feedback from routers along various time scales, resulting in a minimum delay that is not stationary
the path.</t> .</t>
<t>As an example from an Experimental RFC, performance with misbehaving nodes an <t>Varying delay occurs when a subnet changes the forwarding path to
d optimize capacity, resilience, etc. It could also arise when a subnet
outside attackers is discussed in Sections 9.4, 9.5, and 9.6 of <xref target="RF uses a capacity-management method where the available resource is
C4782"/>. periodically distributed among the active nodes. A node might then
This includes discussion of misbehaving senders and receivers; collusion between have to buffer data until an assigned transmission opportunity or
misbehaving routers; misbehaving middleboxes; and the potential use of Quick- until the physical path changes (e.g., when the length of a wireless
Start to attack routers or to tie up available Quick-Start bandwidth.</t> path changes or when the physical layer changes its mode of operation).
Variation also arises when traffic with a higher priority DSCP
preempts transmission of traffic with a lower class. In these cases,
the delay varies as a function of external factors, and attempting to
infer congestion from an increase in the delay results in reduced
throughput. This variation in the delay over short timescales (jitter)
might not be distinguishable from jitter that results from other
effects.</t>
<t>A proposed congestion control algorithm <bcp14>SHOULD</bcp14> be
evaluated to ensure its operation is robust when there is a
significant change in the minimum delay.</t>
</section>
</section> <section anchor="internet-of-things-and-constrained-nodes">
<section anchor="extreme-packet-reordering"><name>Extreme Packet Reordering</nam <name>Internet of Things and Constrained Nodes</name>
e> <t>The "Internet of Things" (IoT) is a broad concept, but when
evaluating a proposed congestion control algorithm, it is often
associated with unique characteristics. For example, IoT nodes might
be more constrained in power, CPU, or other parameters than
conventional Internet hosts. This might place limits on the complexity
of any given algorithm. These power and radio constraints might make
the volume of control packets in a given algorithm a key evaluation
metric.</t>
<t>A proposed congestion control algorithm ought not to presume that all general <t>Extremely low-power links can lead to very low throughput and a low
Internet paths reliably deliver packets in order. <xref target="RFC4653"/> discu bandwidth-delay product, which is well below the standard operating
sses the range of most Internet flows.</t>
effect of extreme packet reordering.</t>
</section> <t>Furthermore, many IoT applications do not a have a human in the
<section anchor="transient-events"><name>Transient Events</name> loop; therefore, they might have weaker latency constraints because they
do not relate to a user experience. Congestion control algorithms
still might need to share the path with other flows with different
constraints.</t>
</section>
<t>A proposed congestion control algorithm SHOULD consider how the proposed <section anchor="paths-with-high-delay">
congestion control algorithm would perform in the presence of transient events <name>Paths with High Delay</name>
such as sudden onset of congestion, a routing change, or a mobility event.
Routing changes, link disconnections, intermittent link connectivity, and
mobility are discussed in more detail in Section 16 of <xref target="Tools"/>.</
t>
<t>As an example from an Experimental RFC, response to transient events is <t>Authors of a proposed congestion control algorithm ought not to presu
discussed in <xref section="9.2" sectionFormat="of" target="RFC4782"/>.</t> me that
all general Internet paths have a low delay. Some paths include links
that contribute much more delay than for a typical Internet
path. Satellite links often have delays longer than is typical for wired
paths <xref target="RFC2488"/> and high-delay-bandwidth products <xref
target="RFC3649"/>.</t>
</section> <t>Paths can also present a variable delay as described in <xref
<section anchor="sudden-changes-in-the-path"><name>Sudden changes in the Path</n target="delay"/>.</t>
ame> </section>
<t>An IETF transport is not tied to a specific Internet path or type of path. Th <section anchor="misbehaving-nodes">
e <name>Misbehaving Nodes</name>
set of routers that form a path can and do change with time. This will cause the
properties of the path to change with respect to time. A proposed congestion
control algorithm MUST evaluate the impact of changes in the path, and be robust
to changes in path characteristics on the interval of common Internet re-routing
intervals.</t>
</section> <t>A proposal for a congestion control algorithm <bcp14>SHOULD</bcp14>
<section anchor="multipath-transport"><name>Multipath Transport</name> explore how the algorithm performs with non-compliant senders,
receivers, or routers. In addition, the proposal should explore how a
proposed congestion control algorithm performs with outside attackers.
This can be particularly important for proposed congestion control
algorithms that involve explicit feedback from routers along the
path.</t>
<t>Multipath transport protocols permit more than one path to be differentiated <t>As an example from an Experimental RFC, performance with
and misbehaving nodes and outside attackers is discussed in Sections <xref
used by a single connection at the sender. A multipath sender can schedule which target="RFC4782" section="9.4" sectionFormat="bare"/>, <xref
packets travel on which of its active paths. This enables a tradeoff in target="RFC4782" section="9.5" sectionFormat="bare"/>, and <xref
timeliness and reliability. There are various ways that multipath techniques can target="RFC4782" section="9.6" sectionFormat="bare"/> of <xref
be used.</t> target="RFC4782"/>. This includes discussion of:</t>
<ul>
<li>misbehaving senders and receivers;</li>
<li>collusion between misbehaving routers;</li>
<li>misbehaving middleboxes; and</li>
<li>the potential use of Quick-Start to attack routers or to tie up
available Quick-Start bandwidth.</li>
</ul>
</section>
<t>One example use is to provide fail-over from one path to another when the <section anchor="extreme-packet-reordering">
original path is no longer viable, or provides inferior performance. Designs <name>Extreme Packet Reordering</name>
need to independently track the congestion state of each path, and demonstrate <t>Authors of a proposed congestion control algorithm ought not to presu
independent congestion control for each path being used. Authors of a proposed me that
multipath congestion control algorithm that implements path fail-over MUST all general Internet paths reliably deliver packets in order. <xref
evaluate the harm to performance resulting from a change in the path, and show t target="RFC4653"/> discusses the effect of extreme packet
hat this does reordering.</t>
not result in flow starvation. Synchronisation of failover (e.g., where multiple </section>
flows change their path on similar timeframes) can also contribute to harm
and/or reduce fairness. These effects also ought to be evaluated.</t>
<t>Another example use is concurrent multipath, where the transport protocol <section anchor="transient-events">
simultaneously schedules a flow to aggregate the capacity across multiple paths. <name>Transient Events</name>
The Internet provides no guarantee that different paths (e.g., using different <t>A proposal for a congestion control algorithm <bcp14>SHOULD</bcp14>
endpoint addresses) are disjoint. This introduces additional implications: A con consider how it would perform in the presence of transient events such
gestion as a sudden onset of
control algorithm proposal MUST evaluate the potential harm to other flows when congestion, a routing change, or a mobility event. Routing changes,
the multiple paths share a common congested bottleneck or share resources that link disconnections, intermittent link connectivity, and mobility are
are coupled between different paths, such as an overall capacity limit). A propo discussed in more detail in Section 16 of <xref
sal target="I-D.irtf-tmrg-tools"/>.</t>
SHOULD consider the potential for harm to other flows. Synchronisation of
congestion control mechanisms (e.g., where multiple flows change their behaviour
on similar timeframes) can also contribute to harm and/or reduce fairness. These
effects also ought to be evaluated.</t>
<t>At the time of writing (2024), there are currently no Standards Track RFCs fo <t>As an example from an Experimental RFC, a response to transient
r events is discussed in <xref section="9.2" sectionFormat="of"
concurrent multipath, but there is an Experimental RFC <xref target="RFC6356"/> target="RFC4782"/>.</t>
that </section>
specifies a concurrent multipath congestion control algorithm for MPTCP
<xref target="RFC8684"/>.</t>
</section> <section anchor="sudden-changes-in-the-path">
<section anchor="data-centers"><name>Data Centers</name> <name>Sudden Changes in the Path</name>
<t>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
time. This will cause the properties of the path to change with
respect to time. A proposal for a congestion control algorithm
<bcp14>MUST</bcp14> evaluate the impact of changes in the path and be
robust to changes in path characteristics on the interval of common
Internet rerouting intervals.</t>
</section>
<t>Data centers are characterized by very low latencies (&lt; 2 ms). Many worklo <section anchor="multipath-transport">
ads <name>Multipath Transport</name>
involve bursty traffic where many nodes complete a task at the same time. As a <t>Multipath transport protocols permit more than one path to be
controlled environment, data centers often deploy fabrics that employ rich differentiated and used by a single connection at the sender. A
signalling from switches to endpoints. Furthermore, the operator can often limit multipath sender can schedule which packets travel on which of its
the number of operating congestion control algorithms.</t> active paths. This enables a trade-off in timeliness and
reliability. There are various ways that multipath techniques can be
used.</t>
<t>For these reasons, data center congestion controls are often distinct from th <t>One example use is to provide failover from one path to another
ose when the original path is no longer viable or provides inferior
running elsewhere on the Internet (see <xref target="controlled-environments"/>) performance. Designs need to independently track the congestion state
. A proposed of each path and demonstrate independent congestion control for each
congestion control need not coexist well with all other algorithms if it is path being used. Authors of a proposed multipath congestion control
intended for data centers, but the proposal SHOULD indicate which are expected algorithm that implements path failover <bcp14>MUST</bcp14> evaluate
to safely coexist with it.</t> the harm to performance resulting from a change in the path and show
that this does not result in flow starvation. Synchronization of
failover (e.g., where multiple flows change their path on similar
time frames) can also contribute to harm and/or reduce fairness. These
effects also ought to be evaluated.</t>
</section> <t>Another example use is concurrent multipath, where the transport
</section> protocol simultaneously schedules a flow to aggregate the capacity
<section anchor="security-considerations"><name>Security Considerations</name> across multiple paths. The Internet provides no guarantee that
different paths (e.g., using different endpoint addresses) are
disjoint. This introduces additional implications. A congestion
control algorithm proposal <bcp14>MUST</bcp14> evaluate the potential
harm to other flows when the multiple paths share a common congested
bottleneck or share resources that are coupled between different
paths, such as an overall capacity limit. A proposal
<bcp14>SHOULD</bcp14> consider the potential for harm to other
flows. Synchronization of congestion control mechanisms (e.g., where
multiple flows change their behavior on similar time frames) can also
contribute to harm and/or reduce fairness. These effects also ought to
be evaluated.</t>
<t>This document does not represent a change to any aspect of the TCP/IP protoco <t>At the time of writing (2024), there are currently no Standards
l Track RFCs for concurrent multipath, but there is an Experimental RFC
suite and therefore does not directly impact Internet security. The <xref target="RFC6356"/> that specifies a concurrent multipath
implementation of various facets of the Internet's current congestion control congestion control algorithm for Multipath TCP (MPTCP) <xref target="RFC
algorithms do have security implications (e.g., as outlined in <xref target="RFC 8684"/>.</t>
5681"/>).</t> </section>
<t>Proposed congestion control algorithms MUST examine any potential security or <section anchor="data-centers">
privacy issues that may arise from their design.</t> <name>Data Centers</name> <t>Data centers are characterized by very
low latencies (&lt; 2 ms). Many workloads involve bursty traffic where
many nodes complete a task at the same time. As a controlled
environment, data centers often deploy fabrics that employ rich
signaling from switches to endpoints. Furthermore, the operator can
often limit the number of operating congestion control algorithms.</t>
</section> <t>For these reasons, data center congestion controls are often
<section anchor="iana-considerations"><name>IANA Considerations</name> distinct from those running elsewhere on the Internet (see <xref
target="controlled-environments"/>). A proposed congestion control algo
rithm
need not coexist well with all other algorithms if it is intended for
data centers, but the proposal <bcp14>SHOULD</bcp14> indicate which
are expected to safely coexist with it.</t>
</section>
</section>
<t>This document has no IANA actions.</t> <section anchor="security-considerations">
<name>Security Considerations</name>
<t>This document does not represent a change to any aspect of the TCP/IP
protocol suite; therefore, it does not directly impact Internet security.
The implementation of various facets of the Internet's current
congestion control algorithms do have security implications (e.g., as
outlined in <xref target="RFC5681"/>).</t>
<t>A proposal for a congestion control algorithm <bcp14>MUST</bcp14> exami
ne
any potential security or privacy issues that may arise from their
design.</t>
</section>
</section> <section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9599" to="ECN-ENCAPS"/>
<displayreference target="I-D.cardwell-iccrg-bbr-congestion-control" to="BBR
"/>
<displayreference target="I-D.irtf-tmrg-tools" to="TOOLS"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
914.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
085.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
438.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
961.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
681.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
002.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
083.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
141.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
084.xml"/>
</references>
<references>
<name>Informative References</name>
<references title='Normative References'> <reference anchor="BBRv1" target="https://datatracker.ietf.org/doc/html/d
raft-cardwell-iccrg-bbr-congestion-control-00">
<reference anchor="RFC2914"> <front>
<front> <title>BBR Congestion Control</title>
<title>Congestion Control Principles</title> <author initials="N." surname="Cardwell" fullname="Neal Cardwell">
<author fullname="S. Floyd" initials="S." surname="Floyd"/> <organization>Google</organization>
<date month="September" year="2000"/> </author>
<abstract> <author initials="Y." surname="Cheng" fullname="Yuchung Cheng">
<t>The goal of this document is to explain the need for congestion control <organization>Google</organization>
in the Internet, and to discuss what constitutes correct congestion control. Th </author>
is document specifies an Internet Best Current Practices for the Internet Commun <author initials="S. H." surname="Yeganeh" fullname="Soheil Hassas Ye
ity, and requests discussion and suggestions for improvements.</t> ganeh">
</abstract> <organization>Google</organization>
</front> </author>
<seriesInfo name="BCP" value="41"/> <author initials="V." surname="Jacobson" fullname="Van Jacobson">
<seriesInfo name="RFC" value="2914"/> <organization>Google</organization>
<seriesInfo name="DOI" value="10.17487/RFC2914"/> </author>
</reference> <date month="July" day="3" year="2017"/>
</front>
<reference anchor="RFC8085"> <seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-conge
<front> stion-control-00"/>
<title>UDP Usage Guidelines</title> </reference>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="G. Shepherd" initials="G." surname="Shepherd"/>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-passing tra
nsport that has no inherent congestion control mechanisms. This document provide
s guidelines on the use of UDP for the designers of applications, tunnels, and o
ther protocols that use UDP. Congestion control guidelines are a primary focus,
but the document also provides guidance on other topics, including message sizes
, reliability, checksums, middlebox traversal, the use of Explicit Congestion No
tification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
<t>Because congestion control is critical to the stable operation of the I
nternet, applications and other protocols that choose to use UDP as an Internet
transport must employ mechanisms to prevent congestion collapse and to establish
some degree of fairness with concurrent traffic. They may also need to implemen
t additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protocols (e.g.
, protocols layered directly on IP or via IP-based tunnels), especially when the
se protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP
usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC9438">
<front>
<title>CUBIC for Fast and Long-Distance Networks</title>
<author fullname="L. Xu" initials="L." surname="Xu"/>
<author fullname="S. Ha" initials="S." surname="Ha"/>
<author fullname="I. Rhee" initials="I." surname="Rhee"/>
<author fullname="V. Goel" initials="V." surname="Goel"/>
<author fullname="L. Eggert" initials="L." role="editor" surname="Eggert"/>
<date month="August" year="2023"/>
<abstract>
<t>CUBIC is a standard TCP congestion control algorithm that uses a cubic
function instead of a linear congestion window increase function to improve scal
ability and stability over fast and long-distance networks. CUBIC has been adopt
ed as the default TCP congestion control algorithm by the Linux, Windows, and Ap
ple stacks.</t>
<t>This document updates the specification of CUBIC to include algorithmic
improvements based on these implementations and recent academic work. Based on
the extensive deployment experience with CUBIC, this document also moves the spe
cification to the Standards Track and obsoletes RFC 8312. This document also upd
ates RFC 5681, to allow for CUBIC's occasionally more aggressive sending behavio
r.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9438"/>
<seriesInfo name="DOI" value="10.17487/RFC9438"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the
requirements in the specification. These words are often capitalized. This docu
ment defines these words as they should be interpreted in IETF documents. This d
ocument specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specif
ications. This document aims to reduce the ambiguity by clarifying that only UPP
ERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8961">
<front>
<title>Requirements for Time-Based Loss Detection</title>
<author fullname="M. Allman" initials="M." surname="Allman"/>
<date month="November" year="2020"/>
<abstract>
<t>Many protocols must detect packet loss for various reasons (e.g., to en
sure reliability using retransmissions or to understand the level of congestion
along a network path). While many mechanisms have been designed to detect loss,
ultimately, protocols can only count on the passage of time without delivery con
firmation to declare a packet "lost". Each implementation of a time-based loss d
etection mechanism represents a balance between correctness and timeliness; ther
efore, no implementation suits all situations. This document provides high-level
requirements for time-based loss detectors appropriate for general use in unica
st communication across the Internet. Within the requirements, implementations h
ave latitude to define particulars that best address each situation.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="233"/>
<seriesInfo name="RFC" value="8961"/>
<seriesInfo name="DOI" value="10.17487/RFC8961"/>
</reference>
<reference anchor="RFC5681">
<front>
<title>TCP Congestion Control</title>
<author fullname="M. Allman" initials="M." surname="Allman"/>
<author fullname="V. Paxson" initials="V." surname="Paxson"/>
<author fullname="E. Blanton" initials="E." surname="Blanton"/>
<date month="September" year="2009"/>
<abstract>
<t>This document defines TCP's four intertwined congestion control algorit
hms: slow start, congestion avoidance, fast retransmit, and fast recovery. In ad
dition, the document specifies how TCP should begin transmission after a relativ
ely long idle period, as well as discussing various acknowledgment generation me
thods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5681"/>
<seriesInfo name="DOI" value="10.17487/RFC5681"/>
</reference>
<reference anchor="RFC9002">
<front>
<title>QUIC Loss Detection and Congestion Control</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/
>
<author fullname="I. Swett" initials="I." role="editor" surname="Swett"/>
<date month="May" year="2021"/>
<abstract>
<t>This document describes loss detection and congestion control mechanism
s for QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9002"/>
<seriesInfo name="DOI" value="10.17487/RFC9002"/>
</reference>
<reference anchor="RFC8083">
<front>
<title>Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessi
ons</title>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<author fullname="V. Singh" initials="V." surname="Singh"/>
<date month="March" year="2017"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) is widely used in telephony, vid
eo conferencing, and telepresence applications. Such applications are often run
on best-effort UDP/IP networks. If congestion control is not implemented in thes
e applications, then network congestion can lead to uncontrolled packet loss and
a resulting deterioration of the user's multimedia experience. The congestion c
ontrol algorithm acts as a safety measure by stopping RTP flows from using exces
sive resources and protecting the network from overload. At the time of this wri
ting, however, while there are several proprietary solutions, there is no standa
rd algorithm for congestion control of interactive RTP flows.</t>
<t>This document does not propose a congestion control algorithm. It inste
ad defines a minimal set of RTP circuit breakers: conditions under which an RTP
sender needs to stop transmitting media data to protect the network from excessi
ve congestion. It is expected that, in the absence of long-lived excessive conge
stion, RTP applications running on best-effort IP networks will be able to opera
te without triggering these circuit breakers. To avoid triggering the RTP circui
t breaker, any Standards Track congestion control algorithms defined for RTP wil
l need to operate within the envelope set by these RTP circuit breaker algorithm
s.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8083"/>
<seriesInfo name="DOI" value="10.17487/RFC8083"/>
</reference>
<reference anchor="RFC7141">
<front>
<title>Byte and Packet Congestion Notification</title>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<author fullname="J. Manner" initials="J." surname="Manner"/>
<date month="February" year="2014"/>
<abstract>
<t>This document provides recommendations of best current practice for dro
pping or marking packets using any active queue management (AQM) algorithm, incl
uding Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), an
d newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral
controller Enhanced). We give three strong recommendations: (1) packet size shou
ld be taken into account when transports detect and respond to congestion indica
tions, (2) packet size should not be taken into account when network equipment c
reates congestion signals (marking, dropping), and therefore (3) in the specific
case of RED, the byte- mode packet drop variant that drops fewer small packets
should not be used. This memo updates RFC 2309 to deprecate deliberate preferent
ial treatment of small packets in AQM algorithms.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="41"/>
<seriesInfo name="RFC" value="7141"/>
<seriesInfo name="DOI" value="10.17487/RFC7141"/>
</reference>
<reference anchor="RFC8084">
<front>
<title>Network Transport Circuit Breakers</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<date month="March" year="2017"/>
<abstract>
<t>This document explains what is meant by the term "network transport Cir
cuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunn
els and applications when using non-congestion- controlled traffic and explains
where CBs are, and are not, needed. It also defines requirements for building a
CB and the expected outcomes of using a CB within the Internet.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="208"/>
<seriesInfo name="RFC" value="8084"/>
<seriesInfo name="DOI" value="10.17487/RFC8084"/>
</reference>
</references>
<references title='Informative References'>
<reference anchor="BBR-draft">
<front>
<title>BBR Congestion Control</title>
<author fullname="Neal Cardwell" initials="N." surname="Cardwell">
<organization>Google</organization>
</author>
<author fullname="Yuchung Cheng" initials="Y." surname="Cheng">
<organization>Google</organization>
</author>
<author fullname="Soheil Hassas Yeganeh" initials="S. H." surname="Yeganeh
">
<organization>Google</organization>
</author>
<author fullname="Ian Swett" initials="I." surname="Swett">
<organization>Google</organization>
</author>
<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Google</organization>
</author>
<date day="7" month="March" year="2022"/>
<abstract>
<t> This document specifies the BBR congestion control algorithm. BBR
(&quot;Bottleneck Bandwidth and Round-trip propagation time&quot;) uses recen
t
measurements of a transport connection&#x27;s delivery rate, round-trip
time, and packet loss rate to build an explicit model of the network
path. BBR then uses this model to control both how fast it sends
data and the maximum volume of data it allows in flight in the
network at any time. Relative to loss-based congestion control
algorithms such as Reno [RFC5681] or CUBIC [RFC8312], BBR offers
substantially higher throughput for bottlenecks with shallow buffers
or random losses, and substantially lower queueing delays for
bottlenecks with deep buffers (avoiding &quot;bufferbloat&quot;). BBR can be
implemented in any transport protocol that supports packet-delivery
acknowledgment. Thus far, open source implementations are available
for TCP [RFC793] and QUIC [RFC9000]. This document specifies version
2 of the BBR algorithm, also sometimes referred to as BBRv2 or bbr2.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-congestion-
control-02"/>
</reference>
<reference anchor="BBRv1-draft">
<front>
<title>BBR Congestion Control</title>
<author fullname="Neal Cardwell" initials="N." surname="Cardwell">
<organization>Google, Inc</organization>
</author>
<author fullname="Yuchung Cheng" initials="Y." surname="Cheng">
<organization>Google, Inc</organization>
</author>
<author fullname="Soheil Hassas Yeganeh" initials="S. H." surname="Yeganeh
">
<organization>Google, Inc</organization>
</author>
<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Google, Inc</organization>
</author>
<date day="3" month="July" year="2017"/>
<abstract>
<t> This document specifies the BBR congestion control algorithm. BBR
uses recent measurements of a transport connection&#x27;s delivery rate
and round-trip time to build an explicit model that includes both the
maximum recent bandwidth available to that connection, and its
minimum recent round-trip delay. BBR then uses this model to control
both how fast it sends data and the maximum amount of data it allows
in flight in the network at any time. Relative to loss-based
congestion control algorithms such as Reno [RFC5681] or CUBIC
[draft-ietf-tcpm-cubic], BBR offers substantially higher throughput
for bottlenecks with shallow buffers or random losses, and
substantially lower queueing delays for bottlenecks with deep buffers
(avoiding &quot;bufferbloat&quot;). This algorithm can be implemented in any
transport protocol that supports packet-delivery acknowledgment (thus
far, open source implementations are available for TCP [RFC793] and
QUIC [draft-ietf-quic-transport-00]).
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-congestion-
control-00"/>
</reference>
<reference anchor="ECN-Encaps">
<front>
<title>Guidelines for Adding Congestion Notification to Protocols that Enc
apsulate IP</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization>
</author>
<author fullname="John Kaippallimalil" initials="J." surname="Kaippallimal
il">
<organization>Futurewei</organization>
</author>
<date day="5" month="December" year="2023"/>
<abstract>
<t> The purpose of this document is to guide the design of congestion
notification in any lower layer or tunnelling protocol that
encapsulates IP. The aim is for explicit congestion signals to
propagate consistently from lower layer protocols into IP. Then the
IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the
transport layer (L4). Following these guidelines should assure
interworking among IP layer and lower layer congestion notification
mechanisms, whether specified by the IETF or other standards bodies.
This document is included in BCP 89 and updates the single paragraph
of advice to subnetwork designers about ECN in Section 13 of RFC
3819, by replacing it with a reference to the whole of this document.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-ecn-encap-guideline
s-22"/>
</reference>
<reference anchor="HRX08" target="https://doi.org/10.1145/1400097.1400105">
<front>
<title>CUBIC: a new TCP-friendly high-speed TCP variant</title>
<author initials="S." surname="Ha" fullname="Sangtae Ha">
<organization></organization>
</author>
<author initials="I." surname="Rhee" fullname="Injong Rhee">
<organization></organization>
</author>
<author initials="L." surname="Xu" fullname="Lisong Xu">
<organization></organization>
</author>
<date year="2008" month="July"/>
</front>
<seriesInfo name="ACM SIGOPS Operating Systems Review, vol. 42, no. 5, pp. 64-
74" value=""/>
</reference>
<reference anchor="Tools" target="https://datatracker.ietf.org/doc/draft-irtf-tm
rg-tools">
<front>
<title>Tools for the Evaluation of Simulation and Testbed Scenarios</title>
<author initials="S." surname="Floyd">
<organization></organization>
</author>
<author initials="E." surname="Kohler">
<organization></organization>
</author>
<date year="2007" month="July"/>
</front>
<seriesInfo name="Work in Progress" value=""/>
</reference>
<reference anchor="Bufferbloat" target="https://queue.acm.org/detail.cfm?id=2071
893">
<front>
<title>Bufferbloat: Dark Buffers in the Internet</title>
<author initials="" surname="Kathleen Nichols">
<organization></organization>
</author>
<date year="2011"/>
</front>
<seriesInfo name="ACM Queue Volume 9, Issue 11" value=""/>
</reference>
<reference anchor="BBRv1-Evaluation" target="https://ieeexplore.ieee.org/documen
t/8117540">
<front>
<title>Experimental evaluation of BBR congestion control</title>
<author initials="M." surname="Zitterbart">
<organization></organization>
</author>
<date year="2017"/>
</front>
<seriesInfo name="2017 IEEE 25th International Conference on Network Protocols
(ICNP)" value=""/>
</reference>
<reference anchor="RFC5033">
<front>
<title>Specifying New Congestion Control Algorithms</title>
<author fullname="S. Floyd" initials="S." surname="Floyd"/>
<author fullname="M. Allman" initials="M." surname="Allman"/>
<date month="August" year="2007"/>
<abstract>
<t>The IETF's standard congestion control schemes have been widely shown t
o be inadequate for various environments (e.g., high-speed networks). Recent res
earch has yielded many alternate congestion control schemes that significantly d
iffer from the IETF's congestion control principles. Using these new congestion
control schemes in the global Internet has possible ramifications to both the tr
affic using the new congestion control and to traffic using the currently standa
rdized congestion control. Therefore, the IETF must proceed with caution when de
aling with alternate congestion control proposals. The goal of this document is
to provide guidance for considering alternate congestion control algorithms with
in the IETF. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.</t
>
</abstract>
</front>
<seriesInfo name="BCP" value="133"/>
<seriesInfo name="RFC" value="5033"/>
<seriesInfo name="DOI" value="10.17487/RFC5033"/>
</reference>
<reference anchor="RFC8312">
<front>
<title>CUBIC for Fast Long-Distance Networks</title>
<author fullname="I. Rhee" initials="I." surname="Rhee"/>
<author fullname="L. Xu" initials="L." surname="Xu"/>
<author fullname="S. Ha" initials="S." surname="Ha"/>
<author fullname="A. Zimmermann" initials="A." surname="Zimmermann"/>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="R. Scheffenegger" initials="R." surname="Scheffenegger"/>
<date month="February" year="2018"/>
<abstract>
<t>CUBIC is an extension to the current TCP standards. It differs from the
current TCP standards only in the congestion control algorithm on the sender si
de. In particular, it uses a cubic function instead of a linear window increase
function of the current TCP standards to improve scalability and stability under
fast and long-distance networks. CUBIC and its predecessor algorithm have been
adopted as defaults by Linux and have been used for many years. This document pr
ovides a specification of CUBIC to enable third-party implementations and to sol
icit community feedback through experimentation on the performance of CUBIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8312"/>
<seriesInfo name="DOI" value="10.17487/RFC8312"/>
</reference>
<reference anchor="RFC8869">
<front>
<title>Evaluation Test Cases for Interactive Real-Time Media over Wireless N
etworks</title>
<author fullname="Z. Sarker" initials="Z." surname="Sarker"/>
<author fullname="X. Zhu" initials="X." surname="Zhu"/>
<author fullname="J. Fu" initials="J." surname="Fu"/>
<date month="January" year="2021"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) is a common transport choice for
interactive multimedia communication applications. The performance of these app
lications typically depends on a well-functioning congestion control algorithm.
To ensure a seamless and robust user experience, a well-designed RTP-based conge
stion control algorithm should work well across all access network types. This d
ocument describes test cases for evaluating performances of candidate congestion
control algorithms over cellular and Wi-Fi networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8869"/>
<seriesInfo name="DOI" value="10.17487/RFC8869"/>
</reference>
<reference anchor="RFC6928">
<front>
<title>Increasing TCP's Initial Window</title>
<author fullname="J. Chu" initials="J." surname="Chu"/>
<author fullname="N. Dukkipati" initials="N." surname="Dukkipati"/>
<author fullname="Y. Cheng" initials="Y." surname="Cheng"/>
<author fullname="M. Mathis" initials="M." surname="Mathis"/>
<date month="April" year="2013"/>
<abstract>
<t>This document proposes an experiment to increase the permitted TCP init
ial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 s
egments with a fallback to the existing recommendation when performance issues a
re detected. It discusses the motivation behind the increase, the advantages and
disadvantages of the higher initial window, and presents results from several l
arge-scale experiments showing that the higher initial window improves the overa
ll performance of many web services without resulting in a congestion collapse.
The document closes with a discussion of usage and deployment for further experi
mental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TC
PM) working group.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6928"/>
<seriesInfo name="DOI" value="10.17487/RFC6928"/>
</reference>
<reference anchor="RFC4614">
<front>
<title>A Roadmap for Transmission Control Protocol (TCP) Specification Docum
ents</title>
<author fullname="M. Duke" initials="M." surname="Duke"/>
<author fullname="R. Braden" initials="R." surname="Braden"/>
<author fullname="W. Eddy" initials="W." surname="Eddy"/>
<author fullname="E. Blanton" initials="E." surname="Blanton"/>
<date month="September" year="2006"/>
<abstract>
<t>This document contains a "roadmap" to the Requests for Comments (RFC) d
ocuments relating to the Internet's Transmission Control Protocol (TCP). This ro
admap provides a brief summary of the documents defining TCP and various TCP ext
ensions that have accumulated in the RFC series. This serves as a guide and quic
k reference for both TCP implementers and other parties who desire information c
ontained in the TCP-related RFCs. This memo provides information for the Interne
t community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4614"/>
<seriesInfo name="DOI" value="10.17487/RFC4614"/>
</reference>
<reference anchor="RFC3649">
<front>
<title>HighSpeed TCP for Large Congestion Windows</title>
<author fullname="S. Floyd" initials="S." surname="Floyd"/>
<date month="December" year="2003"/>
<abstract>
<t>The proposals in this document are experimental. While they may be depl
oyed in the current Internet, they do not represent a consensus that this is the
best method for high-speed congestion control. In particular, we note that alte
rnative experimental proposals are likely to be forthcoming, and it is not well
understood how the proposals in this document will interact with such alternativ
e proposals. This document proposes HighSpeed TCP, a modification to TCP's conge
stion control mechanism for use with TCP connections with large congestion windo
ws. The congestion control mechanisms of the current Standard TCP constrains the
congestion windows that can be achieved by TCP in realistic environments. For e
xample, for a Standard TCP connection with 1500-byte packets and a 100 ms round-
trip time, achieving a steady-state throughput of 10 Gbps would require an avera
ge congestion window of 83,333 segments, and a packet drop rate of at most one c
ongestion event every 5,000,000,000 packets (or equivalently, at most one conges
tion event every 1 2/3 hours). This is widely acknowledged as an unrealistic con
straint. To address his limitation of TCP, this document proposes HighSpeed TCP,
and solicits experimentation and feedback from the wider community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3649"/>
<seriesInfo name="DOI" value="10.17487/RFC3649"/>
</reference>
<reference anchor="RFC4782">
<front>
<title>Quick-Start for TCP and IP</title>
<author fullname="S. Floyd" initials="S." surname="Floyd"/>
<author fullname="M. Allman" initials="M." surname="Allman"/>
<author fullname="A. Jain" initials="A." surname="Jain"/>
<author fullname="P. Sarolahti" initials="P." surname="Sarolahti"/>
<date month="January" year="2007"/>
<abstract>
<t>This document specifies an optional Quick-Start mechanism for transport
protocols, in cooperation with routers, to determine an allowed sending rate at
the start and, at times, in the middle of a data transfer (e.g., after an idle
period). While Quick-Start is designed to be used by a range of transport protoc
ols, in this document we only specify its use with TCP. Quick-Start is designed
to allow connections to use higher sending rates when there is significant unuse
d bandwidth along the path, and the sender and all of the routers along the path
approve the Quick-Start Request.</t>
<t>This document describes many paths where Quick-Start Requests would not
be approved. These paths include all paths containing routers, IP tunnels, MPLS
paths, and the like that do not support Quick- Start. These paths also include
paths with routers or middleboxes that drop packets containing IP options. Quick
-Start Requests could be difficult to approve over paths that include multi-acce
ss layer- two networks. This document also describes environments where the Quic
k-Start process could fail with false positives, with the sender incorrectly ass
uming that the Quick-Start Request had been approved by all of the routers along
the path. As a result of these concerns, and as a result of the difficulties an
d seeming absence of motivation for routers, such as core routers to deploy Quic
k-Start, Quick-Start is being proposed as a mechanism that could be of use in co
ntrolled environments, and not as a mechanism that would be intended or appropri
ate for ubiquitous deployment in the global Internet. This memo defines an Exper
imental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4782"/>
<seriesInfo name="DOI" value="10.17487/RFC4782"/>
</reference>
<reference anchor="RFC9049">
<front>
<title>Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads N
ot Taken)</title>
<author fullname="S. Dawkins" initials="S." role="editor" surname="Dawkins"/
>
<date month="June" year="2021"/>
<abstract>
<t>This document is a product of the Path Aware Networking Research Group
(PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog
and analyze past efforts to develop and deploy Path Aware techniques, most of w
hich were unsuccessful or at most partially successful, in order to extract insi
ghts and lessons for Path Aware networking researchers.</t>
<t>This document contains that catalog and analysis.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9049"/>
<seriesInfo name="DOI" value="10.17487/RFC9049"/>
</reference>
<reference anchor="RFC8799">
<front>
<title>Limited Domains and Internet Protocols</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
<author fullname="B. Liu" initials="B." surname="Liu"/>
<date month="July" year="2020"/>
<abstract>
<t>There is a noticeable trend towards network behaviors and semantics tha
t are specific to a particular set of requirements applied within a limited regi
on of the Internet. Policies, default parameters, the options supported, the sty
le of network management, and security requirements may vary between such limite
d regions. This document reviews examples of such limited domains (also known as
controlled environments), notes emerging solutions, and includes a related taxo
nomy. It then briefly discusses the standardization of protocols for limited dom
ains. Finally, it shows the need for a precise definition of "limited domain mem
bership" and for mechanisms to allow nodes to join a domain securely and to find
other members, including boundary nodes.</t>
<t>This document is the product of the research of the authors. It has bee
n produced through discussions and consultation within the IETF but is not the p
roduct of IETF consensus.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8799"/>
<seriesInfo name="DOI" value="10.17487/RFC8799"/>
</reference>
<reference anchor="RFC3714">
<front>
<title>IAB Concerns Regarding Congestion Control for Voice Traffic in the In
ternet</title>
<author fullname="S. Floyd" initials="S." role="editor" surname="Floyd"/>
<author fullname="J. Kempf" initials="J." role="editor" surname="Kempf"/>
<date month="March" year="2004"/>
<abstract>
<t>This document discusses IAB concerns about effective end-to-end congest
ion control for best-effort voice traffic in the Internet. These concerns have t
o do with fairness, user quality, and with the dangers of congestion collapse. T
he concerns are particularly relevant in light of the absence of a widespread Qu
ality of Service (QoS) deployment in the Internet, and the likelihood that this
situation will not change much in the near term. This document is not making any
recommendations about deployment paths for Voice over Internet Protocol (VoIP)
in terms of QoS support, and is not claiming that best-effort service can be rel
ied upon to give acceptable performance for VoIP. We are merely observing that v
oice traffic is occasionally deployed as best-effort traffic over some links in
the Internet, that we expect this occasional deployment to continue, and that we
have concerns about the lack of effective end-to-end congestion control for thi
s best-effort voice traffic. This memo provides information for the Internet com
munity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3714"/>
<seriesInfo name="DOI" value="10.17487/RFC3714"/>
</reference>
<reference anchor="RFC6298">
<front>
<title>Computing TCP's Retransmission Timer</title>
<author fullname="V. Paxson" initials="V." surname="Paxson"/>
<author fullname="M. Allman" initials="M." surname="Allman"/>
<author fullname="J. Chu" initials="J." surname="Chu"/>
<author fullname="M. Sargent" initials="M." surname="Sargent"/>
<date month="June" year="2011"/>
<abstract>
<t>This document defines the standard algorithm that Transmission Control
Protocol (TCP) senders are required to use to compute and manage their retransmi
ssion timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upg
rades the requirement of supporting the algorithm from a SHOULD to a MUST. This
document obsoletes RFC 2988. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6298"/>
<seriesInfo name="DOI" value="10.17487/RFC6298"/>
</reference>
<reference anchor="RFC8836">
<front>
<title>Congestion Control Requirements for Interactive Real-Time Media</titl
e>
<author fullname="R. Jesup" initials="R." surname="Jesup"/>
<author fullname="Z. Sarker" initials="Z." role="editor" surname="Sarker"/>
<date month="January" year="2021"/>
<abstract>
<t>Congestion control is needed for all data transported across the Intern
et, in order to promote fair usage and prevent congestion collapse. The requirem
ents for interactive, point-to-point real-time multimedia, which needs low-delay
, semi-reliable data delivery, are different from the requirements for bulk tran
sfer like FTP or bursty transfers like web pages. Due to an increasing amount of
RTP-based real-time media traffic on the Internet (e.g., with the introduction
of the Web Real-Time Communication (WebRTC)), it is especially important to ensu
re that this kind of traffic is congestion controlled.</t>
<t>This document describes a set of requirements that can be used to evalu
ate other congestion control mechanisms in order to figure out their fitness for
this purpose, and in particular to provide a set of possible requirements for a
real-time media congestion avoidance technique.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8836"/>
<seriesInfo name="DOI" value="10.17487/RFC8836"/>
</reference>
<reference anchor="RFC8868">
<front>
<title>Evaluating Congestion Control for Interactive Real-Time Media</title>
<author fullname="V. Singh" initials="V." surname="Singh"/>
<author fullname="J. Ott" initials="J." surname="Ott"/>
<author fullname="S. Holmer" initials="S." surname="Holmer"/>
<date month="January" year="2021"/>
<abstract>
<t>The Real-Time Transport Protocol (RTP) is used to transmit media in tel
ephony and video conferencing applications. This document describes the guidelin
es to evaluate new congestion control algorithms for interactive point-to-point
real-time media.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8868"/>
<seriesInfo name="DOI" value="10.17487/RFC8868"/>
</reference>
<reference anchor="RFC8867">
<front>
<title>Test Cases for Evaluating Congestion Control for Interactive Real-Tim
e Media</title>
<author fullname="Z. Sarker" initials="Z." surname="Sarker"/>
<author fullname="V. Singh" initials="V." surname="Singh"/>
<author fullname="X. Zhu" initials="X." surname="Zhu"/>
<author fullname="M. Ramalho" initials="M." surname="Ramalho"/>
<date month="January" year="2021"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) is used to transmit media in mul
timedia telephony applications. These applications are typically required to imp
lement congestion control. This document describes the test cases to be used in
the performance evaluation of such congestion control algorithms in a controlled
environment.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8867"/>
<seriesInfo name="DOI" value="10.17487/RFC8867"/>
</reference>
<reference anchor="RFC9392">
<front>
<title>Sending RTP Control Protocol (RTCP) Feedback for Congestion Control i
n Interactive Multimedia Conferences</title>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<date month="April" year="2023"/>
<abstract>
<t>This memo discusses the rate at which congestion control feedback can b
e sent using the RTP Control Protocol (RTCP) and the suitability of RTCP for imp
lementing congestion control for unicast multimedia applications.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9392"/>
<seriesInfo name="DOI" value="10.17487/RFC9392"/>
</reference>
<reference anchor="RFC3819">
<front>
<title>Advice for Internet Subnetwork Designers</title>
<author fullname="P. Karn" initials="P." role="editor" surname="Karn"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="D. Grossman" initials="D." surname="Grossman"/>
<author fullname="R. Ludwig" initials="R." surname="Ludwig"/>
<author fullname="J. Mahdavi" initials="J." surname="Mahdavi"/>
<author fullname="G. Montenegro" initials="G." surname="Montenegro"/>
<author fullname="J. Touch" initials="J." surname="Touch"/>
<author fullname="L. Wood" initials="L." surname="Wood"/>
<date month="July" year="2004"/>
<abstract>
<t>This document provides advice to the designers of digital communication
equipment, link-layer protocols, and packet-switched local networks (collective
ly referred to as subnetworks), who wish to support the Internet protocols but m
ay be unfamiliar with the Internet architecture and the implications of their de
sign choices on the performance and efficiency of the Internet. This document sp
ecifies an Internet Best Current Practices for the Internet Community, and reque
sts discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="89"/>
<seriesInfo name="RFC" value="3819"/>
<seriesInfo name="DOI" value="10.17487/RFC3819"/>
</reference>
<reference anchor="RFC8290">
<front>
<title>The Flow Queue CoDel Packet Scheduler and Active Queue Management Alg
orithm</title>
<author fullname="T. Hoeiland-Joergensen" initials="T." surname="Hoeiland-Jo
ergensen"/>
<author fullname="P. McKenney" initials="P." surname="McKenney"/>
<author fullname="D. Taht" initials="D." surname="Taht"/>
<author fullname="J. Gettys" initials="J." surname="Gettys"/>
<author fullname="E. Dumazet" initials="E." surname="Dumazet"/>
<date month="January" year="2018"/>
<abstract>
<t>This memo presents the FQ-CoDel hybrid packet scheduler and Active Queu
e Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reduc
ing latency.</t>
<t>FQ-CoDel mixes packets from multiple flows and reduces the impact of he
ad-of-line blocking from bursty traffic. It provides isolation for low-rate traf
fic such as DNS, web, and videoconferencing traffic. It improves utilisation acr
oss the networking fabric, especially for bidirectional traffic, by keeping queu
e lengths short, and it can be implemented in a memory- and CPU-efficient fashio
n across a wide range of hardware.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8290"/>
<seriesInfo name="DOI" value="10.17487/RFC8290"/>
</reference>
<reference anchor="RFC8033">
<front>
<title>Proportional Integral Controller Enhanced (PIE): A Lightweight Contro
l Scheme to Address the Bufferbloat Problem</title>
<author fullname="R. Pan" initials="R." surname="Pan"/>
<author fullname="P. Natarajan" initials="P." surname="Natarajan"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="G. White" initials="G." surname="White"/>
<date month="February" year="2017"/>
<abstract>
<t>Bufferbloat is a phenomenon in which excess buffers in the network caus
e high latency and latency variation. As more and more interactive applications
(e.g., voice over IP, real-time video streaming, and financial transactions) run
in the Internet, high latency and latency variation degrade application perform
ance. There is a pressing need to design intelligent queue management schemes th
at can control latency and latency variation, and hence provide desirable qualit
y of service to users.</t>
<t>This document presents a lightweight active queue management design cal
led "PIE" (Proportional Integral controller Enhanced) that can effectively contr
ol the average queuing latency to a target value. Simulation results, theoretica
l analysis, and Linux testbed results have shown that PIE can ensure low latency
and achieve high link utilization under various congestion situations. The desi
gn does not require per-packet timestamps, so it incurs very little overhead and
is simple enough to implement in both hardware and software.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8033"/>
<seriesInfo name="DOI" value="10.17487/RFC8033"/>
</reference>
<reference anchor="RFC9332">
<front>
<title>Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low
Loss, and Scalable Throughput (L4S)</title>
<author fullname="K. De Schepper" initials="K." surname="De Schepper"/>
<author fullname="B. Briscoe" initials="B." role="editor" surname="Briscoe"/
>
<author fullname="G. White" initials="G." surname="White"/>
<date month="January" year="2023"/>
<abstract>
<t>This specification defines a framework for coupling the Active Queue Ma
nagement (AQM) algorithms in two queues intended for flows with different respon
ses to congestion. This provides a way for the Internet to transition from the s
caling problems of standard TCP-Reno-friendly ('Classic') congestion controls to
the family of 'Scalable' congestion controls. These are designed for consistent
ly very low queuing latency, very low congestion loss, and scaling of per-flow t
hroughput by using Explicit Congestion Notification (ECN) in a modified way. Unt
il the Coupled Dual Queue (DualQ), these Scalable L4S congestion controls could
only be deployed where a clean-slate environment could be arranged, such as in p
rivate data centres.</t>
<t>This specification first explains how a Coupled DualQ works. It then gi
ves the normative requirements that are necessary for it to work well. All this
is independent of which two AQMs are used, but pseudocode examples of specific A
QMs are given in appendices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9332"/>
<seriesInfo name="DOI" value="10.17487/RFC9332"/>
</reference>
<reference anchor="RFC8087">
<front>
<title>The Benefits of Using Explicit Congestion Notification (ECN)</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="M. Welzl" initials="M." surname="Welzl"/>
<date month="March" year="2017"/>
<abstract>
<t>The goal of this document is to describe the potential benefits of appl
ications using a transport that enables Explicit Congestion Notification (ECN).
The document outlines the principal gains in terms of increased throughput, redu
ced delay, and other benefits when ECN is used over a network path that includes
equipment that supports Congestion Experienced (CE) marking. It also discusses
challenges for successful deployment of ECN. It does not propose new algorithms
to use ECN nor does it describe the details of implementation of ECN in endpoint
devices (Internet hosts), routers, or other network devices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8087"/>
<seriesInfo name="DOI" value="10.17487/RFC8087"/>
</reference>
<reference anchor="RFC3168"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<front> draft-cardwell-iccrg-bbr-congestion-control-02.xml"/>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan"/>
<author fullname="S. Floyd" initials="S." surname="Floyd"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="September" year="2001"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congestion Notif
ication) to TCP and IP, including ECN's use of two bits in the IP header. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
<reference anchor="RFC7567"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 599.xml"/>
<title>IETF Recommendations Regarding Active Queue Management</title>
<author fullname="F. Baker" initials="F." role="editor" surname="Baker"/>
<author fullname="G. Fairhurst" initials="G." role="editor" surname="Fairhur
st"/>
<date month="July" year="2015"/>
<abstract>
<t>This memo presents recommendations to the Internet community concerning
measures to improve and preserve Internet performance. It presents a strong rec
ommendation for testing, standardization, and widespread deployment of active qu
eue management (AQM) in network devices to improve the performance of today's In
ternet. It also urges a concerted effort of research, measurement, and ultimate
deployment of AQM mechanisms to protect the Internet from flows that are not suf
ficiently responsive to congestion notification.</t>
<t>Based on 15 years of experience and new research, this document replace
s the recommendations of RFC 2309.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="197"/>
<seriesInfo name="RFC" value="7567"/>
<seriesInfo name="DOI" value="10.17487/RFC7567"/>
</reference>
<reference anchor="RFC2488"> <reference anchor="HRX08" target="https://doi.org/10.1145/1400097.140010
<front> 5">
<title>Enhancing TCP Over Satellite Channels using Standard Mechanisms</titl <front>
e> <title>CUBIC: a new TCP-friendly high-speed TCP variant</title>
<author fullname="M. Allman" initials="M." surname="Allman"/> <author initials="S." surname="Ha" fullname="Sangtae Ha">
<author fullname="D. Glover" initials="D." surname="Glover"/> <organization/>
<author fullname="L. Sanchez" initials="L." surname="Sanchez"/> </author>
<date month="January" year="1999"/> <author initials="I." surname="Rhee" fullname="Injong Rhee">
<abstract> <organization/>
<t>The Transmission Control Protocol (TCP) provides reliable delivery of d </author>
ata across any network path, including network paths containing satellite channe <author initials="L." surname="Xu" fullname="Lisong Xu">
ls. While TCP works over satellite channels there are several IETF standardized <organization/>
mechanisms that enable TCP to more effectively utilize the available capacity of </author>
the network path. This document outlines some of these TCP mitigations. This do <date year="2008" month="July"/>
cument specifies an Internet Best Current Practices for the Internet Community, </front>
and requests discussion and suggestions for improvements.</t> <refcontent>ACM SIGOPS Operating Systems Review, vol. 42, no. 5, pp. 6
</abstract> 4-74</refcontent>
</front> <seriesInfo name="DOI" value="10.1145/1400097.1400105"/>
<seriesInfo name="BCP" value="28"/> </reference>
<seriesInfo name="RFC" value="2488"/>
<seriesInfo name="DOI" value="10.17487/RFC2488"/>
</reference>
<reference anchor="RFC4653"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ir
<front> tf-tmrg-tools-05.xml"/>
<title>Improving the Robustness of TCP to Non-Congestion Events</title>
<author fullname="S. Bhandarkar" initials="S." surname="Bhandarkar"/>
<author fullname="A. L. N. Reddy" initials="A. L. N." surname="Reddy"/>
<author fullname="M. Allman" initials="M." surname="Allman"/>
<author fullname="E. Blanton" initials="E." surname="Blanton"/>
<date month="August" year="2006"/>
<abstract>
<t>This document specifies Non-Congestion Robustness (NCR) for TCP. In the
absence of explicit congestion notification from the network, TCP uses loss as
an indication of congestion. One of the ways TCP detects loss is using the arriv
al of three duplicate acknowledgments. However, this heuristic is not always cor
rect, notably in the case when network paths reorder segments (for whatever reas
on), resulting in degraded performance. TCP-NCR is designed to mitigate this deg
raded performance by increasing the number of duplicate acknowledgments required
to trigger loss recovery, based on the current state of the connection, in an e
ffort to better disambiguate true segment loss from segment reordering. This doc
ument specifies the changes to TCP, as well as the costs and benefits of these m
odifications. This memo defines an Experimental Protocol for the Internet commun
ity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4653"/>
<seriesInfo name="DOI" value="10.17487/RFC4653"/>
</reference>
<reference anchor="RFC6356"> <reference anchor="BUFFERBLOAT" target="https://dl.acm.org/doi/10.1145/2
<front> 063166.2071893">
<title>Coupled Congestion Control for Multipath Transport Protocols</title> <front>
<author fullname="C. Raiciu" initials="C." surname="Raiciu"/> <title>Bufferbloat: Dark Buffers in the Internet</title>
<author fullname="M. Handley" initials="M." surname="Handley"/> <author initials="K." surname="Nichols">
<author fullname="D. Wischik" initials="D." surname="Wischik"/> <organization/>
<date month="October" year="2011"/> </author>
<abstract> <author initials="J." surname="Gettys">
<t>Often endpoints are connected by multiple paths, but communications are <organization/>
usually restricted to a single path per connection. Resource usage within the n </author>
etwork would be more efficient were it possible for these multiple paths to be u <date month="November" year="2011"/>
sed concurrently. Multipath TCP is a proposal to achieve multipath transport in </front>
TCP.</t> <seriesInfo name="DOI" value="10.1145/2063166.2071893"/>
<t>New congestion control algorithms are needed for multipath transport pr <refcontent>ACM Queue Volume 9, Issue 11</refcontent>
otocols such as Multipath TCP, as single path algorithms have a series of issues </reference>
in the multipath context. One of the prominent problems is that running existin
g algorithms such as standard TCP independently on each path would give the mult
ipath flow more than its fair share at a bottleneck link traversed by more than
one of its subflows. Further, it is desirable that a source with multiple paths
available will transfer more traffic using the least congested of the paths, ach
ieving a property called "resource pooling" where a bundle of links effectively
behaves like one shared link with bigger capacity. This would increase the overa
ll efficiency of the network and also its robustness to failure.</t>
<t>This document presents a congestion control algorithm that couples the
congestion control algorithms running on different subflows by linking their inc
rease functions, and dynamically controls the overall aggressiveness of the mult
ipath flow. The result is a practical algorithm that is fair to TCP at bottlenec
ks while moving traffic away from congested links. This document defines an Expe
rimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6356"/>
<seriesInfo name="DOI" value="10.17487/RFC6356"/>
</reference>
<reference anchor="RFC8684"> <reference anchor="BBRv1-EVALUATION" target="https://ieeexplore.ieee.org
<front> /document/8117540">
<title>TCP Extensions for Multipath Operation with Multiple Addresses</title <front>
> <title>Experimental evaluation of BBR congestion control</title>
<author fullname="A. Ford" initials="A." surname="Ford"/> <author initials="M." surname="Hock">
<author fullname="C. Raiciu" initials="C." surname="Raiciu"/> <organization/>
<author fullname="M. Handley" initials="M." surname="Handley"/> </author>
<author fullname="O. Bonaventure" initials="O." surname="Bonaventure"/> <author initials="R." surname="Bless">
<author fullname="C. Paasch" initials="C." surname="Paasch"/> <organization/>
<date month="March" year="2020"/> </author>
<abstract> <author initials="M." surname="Zitterbart">
<t>TCP/IP communication is currently restricted to a single path per conne <organization/>
ction, yet multiple paths often exist between peers. The simultaneous use of the </author>
se multiple paths for a TCP/IP session would improve resource usage within the n <date year="2017"/>
etwork and thus improve user experience through higher throughput and improved r </front>
esilience to network failure.</t> <refcontent>2017 IEEE 25th International Conference on Network Protoco
<t>Multipath TCP provides the ability to simultaneously use multiple paths ls (ICNP)</refcontent>
between peers. This document presents a set of extensions to traditional TCP to <seriesInfo name="DOI" value="10.1109/ICNP.2017.8117540"/>
support multipath operation. The protocol offers the same type of service to ap </reference>
plications as TCP (i.e., a reliable bytestream), and it provides the components
necessary to establish and use multiple TCP flows across potentially disjoint pa
ths.</t>
<t>This document specifies v1 of Multipath TCP, obsoleting v0 as specified
in RFC 6824, through clarifications and modifications primarily driven by deplo
yment experience.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8684"/>
<seriesInfo name="DOI" value="10.17487/RFC8684"/>
</reference>
<reference anchor="RFC5166"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<front> 033.xml"/>
<title>Metrics for the Evaluation of Congestion Control Mechanisms</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
<author fullname="S. Floyd" initials="S." role="editor" surname="Floyd"/> 12.xml"/>
<date month="March" year="2008"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<abstract> 869.xml"/>
<t>This document discusses the metrics to be considered in an evaluation o <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
f new or modified congestion control mechanisms for the Internet. These include 928.xml"/>
metrics for the evaluation of new transport protocols, of proposed modifications <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
to TCP, of application-level congestion control, and of Active Queue Management 649.xml"/>
(AQM) mechanisms in the router. This document is the first in a series of docum <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
ents aimed at improving the models that we use in the evaluation of transport pr 782.xml"/>
otocols.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>This document is a product of the Transport Modeling Research Group (TM 049.xml"/>
RG), and has received detailed feedback from many members of the Research Group <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
(RG). As the document tries to make clear, there is not necessarily a consensus 799.xml"/>
within the research community (or the IETF community, the vendor community, the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
operations community, or any other community) about the metrics that congestion 714.xml"/>
control mechanisms should be designed to optimize, in terms of trade-offs betwee <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
n throughput and delay, fairness between competing flows, and the like. However, 298.xml"/>
we believe that there is a clear consensus that congestion control mechanisms s <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
hould be evaluated in terms of trade-offs between a range of metrics, rather tha 836.xml"/>
n in terms of optimizing for a single metric. This memo provides information for <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
the Internet community.</t> 868.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</front> 867.xml"/>
<seriesInfo name="RFC" value="5166"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="DOI" value="10.17487/RFC5166"/> 392.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
819.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
290.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
033.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
332.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
087.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
168.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
567.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
488.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
653.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
356.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
414.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
684.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
166.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
93.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43
40.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
60.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
00.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
57.xml"/>
</references>
</references> </references>
<?line 824?> <section numbered="true" anchor="change-log">
<name>Changes Since RFC 5033</name>
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name> <ul>
<li>Examined BCP 14 keywords and consistency with other RFCs</li>
<t>Sally Floyd and Mark Allman were the authors of this document's predecessor, <li>Rewrote the "Document Status" section</li>
<xref target="RFC5033"/>, which served the community well for over a decade.</t> <li>Added QUIC and other more recent congestion control standards</li>
<li>Aligned motivation for this work with the CCWG charter</li>
<t>Thanks to Richard Scheffenegger for helping to get this revision process <li>Refined discussion of Quick-Start</li>
started.</t> <li>Added criterion for bufferbloat</li>
<li>Added text on constrained environments/limited domains and circuit
<t>The editors would like to thank Mohamed Boucadair, Neal Cardwell, Reese breakers and aligned with other RFCs</li>
Enghardt, Jonathan Lennox, Matt Mathis, Zahed Sarker, Juergen Schoenwaelder, <li>Added discussion of real-time protocols, short flows, AQM response, and
Dave Taht, Sean Turner, Michael Welzl, Magnus Westerlund, and Greg White for multipath transports</li>
suggesting improvements to this document.</t> <li>Listed properties of wired and wireless networks</li>
<li>Added sections addressing IoT and Multicast (noting this is out of scope
<t>Discussions with Lars Eggert and Aaron Falk seeded the original RFC5033. Bob )</li>
Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, Colin Perkins, Pekka </ul>
Savola, members of TSVWG, and participants at the TCP Workshop at Microsoft
Research all provided feedback and contributions to that document. It also drew
from <xref target="RFC5166"/>.</t>
</section>
<section numbered="false" anchor="evolution-of-rfc5033bis"><name>Evolution of RF
C5033bis</name>
<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-06"><name>Sin
ce draft-ietf-ccwg-rfc5033bis-06</name>
<t><list style="symbols">
<t>OPSDIR review</t>
<t>ARTART review</t>
</list></t>
</section>
<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-05"><name>Sin
ce draft-ietf-ccwg-rfc5033bis-05</name>
<t><list style="symbols">
<t>AD evaluation comments</t>
</list></t>
</section>
<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-04"><name>Sin
ce draft-ietf-ccwg-rfc5033bis-04</name>
<t><list style="symbols">
<t>Editorial pass after shepherd review.</t>
</list></t>
</section>
<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-03"><name>Sin
ce draft-ietf-ccwg-rfc5033bis-03</name>
<t><list style="symbols">
<t>Harmonised the "proposed congestion control algorithm"</t>
<t>Addressed issues.</t>
<t>Examined RFC-2119 keywords and consistency with other RFCs.</t>
<t>Added text on constrained environments/limited domains</t>
<t>Added text on circuit breakers and aligned with other RFCs.</t>
<t>Several editorial passes</t>
</list></t>
</section>
<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-02"><name>Sin
ce draft-ietf-ccwg-rfc5033bis-02</name>
<t><list style="symbols">
<t>Added discussion of real-time protocols</t>
<t>Added discussion of short flows</t>
<t>Listed properties of wired networks</t>
<t>Added IoT section</t>
<t>Added discussion of AQM response</t>
<t>Rewrote the "Document Status" section</t>
<t>Adding improved first sentence of abstract and intro.</t>
<t>Added section on Multicast, noting this is out of scope</t>
<t>Editorial changes</t>
</list></t>
</section>
<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-01"><name>Sin
ce draft-ietf-ccwg-rfc5033bis-01</name>
<t><list style="symbols">
<t>Added discussion of multipath transports</t>
<t>Totally reorganized central sections of the draft</t>
</list></t>
</section>
<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-00"><name>Sin
ce draft-ietf-ccwg-rfc5033bis-00</name>
<t><list style="symbols">
<t>Added QUIC, other congestion control standards</t>
<t>Added wireless environments</t>
<t>Aligned motivation for this work with the CCWG charter</t>
<t>Refined discussion of QuickStart</t>
</list></t>
</section>
<section numbered="false" anchor="since-draft-scheffenegger-congress-rfc5033bis-
00"><name>Since draft-scheffenegger-congress-rfc5033bis-00</name>
<t><list style="symbols">
<t>Renamed file to reflect WG adpotion</t>
<t>Updated authorship and acknowledgements.</t>
<t>Include updated text suggested by Dave Taht</t>
<t>Added criterion for bufferbloat</t>
<t>Mentioned CUBIC and BBR as motivation</t>
<t>Include section to track updates between revisions</t>
<t>Update references</t>
</list></t>
</section> </section>
<section numbered="false" anchor="since-rfc5033"><name>Since RFC5033</name>
<t><list style="symbols"> <section numbered="false" anchor="acknowledgments">
<t>converted to Markdown and xml2rfc v3</t> <name>Acknowledgments</name>
<t>various formatting changes.</t>
</list></t>
</section> <t><contact fullname="Sally Floyd"/> and <contact fullname="Mark
</section> Allman"/> were the authors of this document's predecessor, <xref
target="RFC5033"/>, which served the community well for over a
decade.</t>
<t>Thanks to <contact fullname="Richard Scheffenegger"/> for helping to
get this revision process started.</t>
<t>The editors would like to thank <contact fullname="Mohamed
Boucadair"/>, <contact fullname="Neal Cardwell"/>, <contact
fullname="Reese Enghardt"/>, <contact fullname="Jonathan Lennox"/>,
<contact fullname="Matt Mathis"/>, <contact fullname="Zahed Sarker"/>,
<contact fullname="Juergen Schoenwaelder"/>, <contact fullname="Dave
Taht"/>, <contact fullname="Sean Turner"/>, <contact fullname="Michael
Welzl"/>, <contact fullname="Magnus Westerlund"/>, and <contact
fullname="Greg White"/> for suggesting improvements to this
document.</t>
<t>Discussions with <contact fullname="Lars Eggert"/> and <contact
fullname="Aaron Falk"/> seeded the original <xref target="RFC5033"/>. <con
tact
fullname="Bob Briscoe"/>, <contact fullname="Gorry Fairhurst"/>,
<contact fullname="Doug Leith"/>, <contact fullname="Jitendra Padhye"/>,
<contact fullname="Colin Perkins"/>, <contact fullname="Pekka Savola"/>,
members of TSVWG, and participants at the TCP Workshop at Microsoft
Research all provided feedback and contributions to that document. It
also drew from <xref target="RFC5166"/>.</t>
</section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">
<name>Contributors</name> <name>Contributors</name>
<contact initials="C." surname="Huitema" fullname="Christian Huitema">
<organization>Private Octopus, Inc.</organization>
<address>
<email>huitema@huitema.net</email>
</address>
</contact>
</section>
<contact initials="C." surname="Huitema" fullname="Christian Huitema">
<organization>Private Octopus, Inc.</organization>
<address>
<email>huitema@huitema.net</email>
</address>
</contact>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA7V9627cSJLu/3wKHvWPkYCqast3u89iRpZlt2Z9UUvq8V4w
WLCKWVVss8gakiW52jCwD7Ln5fZJTnwRkTeqJKsX2MVi2pLIZGRk3G85Ho9N
X/aVfZntXaztrJxvy3qRfbDX2XFTL2zXl02Nf/ZtU2VH1aJpy3656vZMPp22
9ope42ePk78VzazOV7Rm0ebzflzafj6eza4X43Y+e/Lg0aNp2Y2rvKfVzYz+
Qy9uX2bT2dp0fWvz1cvs9OTyjWmmXVNZeuplhpeMKdfty6xvN13/8MGDFw8e
mpyefpm9tbVt88pcN+3nRdts1i8Jnk9vzWe7pV8VtFrd27a2/fg1wDH0lbwu
/iOvmppA3NrOdKu87f/jH5uGP1Y3Zl2+zP69b2ajrGtagmne0b+2K/zj78Zc
2XpjX5osc1+7ialPBAsQ+RZPZPvY/AG9sMrL6mWGn/4CpEyadoFlCG2b6cuM
8URYwt9/DKgyxuSbftm09MkxPZ5lZU1gvp9krzefLf9CsP2edlHW4be0el6X
v+eAjNDUNIvKZu/eHfMfrcCy4ncmy0lBb/1lgV9OZs2KH6GN0Kq2KPumTT79
dpK9yct2uWnpBMP33zZFa4vBn1Igfq3LK9t2Zb/Nmnl2NLVtYW0dA0TE0G7/
YtvFJJ8W9SSfTTafb0IzA57L6aYfYuV4kv28KXtaLALseNmWdD55nfwtheys
La+IFrOPs75Zb+i8T+vZJAZsKa/+Rf87IYIypm7aFS1wReRgynoe/ZRlr16d
j5kBiALHryezvC2ubVWNy9msXYyJfcYzTzjjmRCOvnd1+IffHD94gJdPjj+M
T+pZvu7kXaapvrsisrKzemzxp/FiUxa2KmsifXrl5/N/efD8JW/ViYLjX1+d
Hr/M8qwm5r48PhvP29LWRbXNluViOe7Wls6Zfp9d5S2htd/jtztLT3VAw8vs
6Ph9dnH69uPZRfZxTezZgxsuth2hrsvO7VVpr0fZVVNNsscPR8Ryk+zJKFuv
J9nTx+Nnj3m5go7jZUas/nz84JmAl7cLS0hZ9j3t78cfi6YEC/14+GByePj4
yY+Hjx+QYHg2wX8PHzzhdzzr8P+N9b9KLRdELbn/lRDLRV4v+tyGPwzeOZ1k
50trB2+d1r/RkcR/Gbz2bpL9y2bw0ruyw0v0e/rDZdNUXXIM/JuMiCrrlzY7
ucqrDRMrWOeiXG0q+YmEWXZJxDClM7mY2ZqOpOkSfO15hOV93rf57LNtJ04A
ERZnP6qgbkEsK6KxHp++eaoQa7QdYpZm0dquS8/p2fjZDZSPPaLfVM22iH93
Msn+uVlWtmWi38zntp1WTd6npBj/IXud0/flNx3gAF6cdN/bSSL/2NiNJSmy
kq3angXcfPXnsvinhw+eHT5/8WgHmTB8fy1XpFv6ftvd9sQ/5z3Bb+vsQzlb
EsISdBwe7mSKXwBQ9rem2qxs9oLETNfRz/Sw5/xw0CkmTr4QI5UrW/d5ldmE
GujFLIiETEXCboyU1tov66pp7QT/dCSwwcI/Pj88fPbk8YPbNkw65+dm9jn+
1fkke1U5UgiP/VvZ07FMSbukSHl2Ayn4JSn8k5Ps4ZN+qcfJO6Ntkj6lsyap
ZTPa1wfbQ8mD/Eg5gzn2T48/nB0YMx6Ps3zagbZJKl8uyy5ze8pau67ymSWx
8+aYLYlRdr2kA8uKspttuo7+Ajpat2U9K9e0F3CUCTKSOZBtBpLDv0OOQSre
RHeWexNokp32tEn7mZZujK27TWvpI3lPX2nWTUeceuf7WcMy02bX9GOz6bNl
3q4YLDuflzOSxT3JYlgwi47AzBraQBu/r7yxqJopYdGxCINlV+tl3pW/y7ZN
DVGOHZLWX7d2ScCSAstgnGGrEC5EamUhtNY3tAN7BbTmBTS5pU/R4oR2+nNn
AG9mv5Ty8rxqrgkX6XEQBq4IZsJyNm9JDPKJOiFX0NpVs+YHsd0cx9Pxj0Tm
O3C2srMlafFuRRqbVl41/GE6rWlZwcrIZ23T0dfZ7MBuhYJsfVW2TY2F5bC8
sQkqAZFgq2TvVXbWZ/gEfdhhNYBhHBgVAduRarUTocVVWRSVNeYH4L5tig3j
Z0iZHhUDYmOxRiYwYNgQiq/pVDzH41A8GZm7yEgorihFXM4JO0IUYi/vwKaJ
eICoDgAV2PTXr/+HsPLwxeHjb99wnJYBzsGVZccEUBf0JEE7tQB4vqlA9yJA
OgUWgN9N9KC1ZPtEkqtNjWMEBkyEAfpZSF4Xp+0QJPkaP5FFQpyDhdabaVXO
hHL17CADRPoY97mC5EOz5QMZqJTJ8MAClXz9+mcllG/fnDy5zjv5ZLcUvEEn
Zjko/RV8neNN22KVM2aXmcAYbeqesiHvTKIKaJEz9+aFiinss2PwFZUdO3e0
bS/J/C6/87mAuLEgboJVO/ud12ZkbXesqTOClS1j0AuxUlVZ5iam6k3HqDJC
pcBCzJrZvp0sJqPY6lQOJnafkUlMNlDLdPOpfFOStGwt66KepELdVM2CwB3x
3yEqIfB7hqIjCqlIPtiMaPxzdyDP5FXXCFQsuGgL5IoYxdwsw2fJDCkIqr81
OL6GZEp2eoYfT89ojUW+og3IWuBrUlGqvejXB3Qan7D2vyvd/H03vYzYrsZD
Lx6+0IdUPZGvtiWaIZ1FwtAoh9w4A9IQ5LPStlkWO/agRbZr4oWK9IbTewU/
IudrPDXs8GbP6bjzlihc3dnT4+PztwcT/H0mNF1tRwzlazIwFyTVzY5VnNbO
9l8fH58d8B4fP3r8QPaokl/ESGHnJHugZ+8UcCItC/1mRtof2pHZsbIMzwUH
FBwI5rLN625Vdh2WC/BcHF8qPC8ePiV4WstkiYO4W80bc1GCnuhT9YjkypUI
VlUXy5wUaTNjFBUiN1v8Baps7U2YTU+aCmbFd7ZKSps06zp3opY+XG1I9//y
6+mxwE7Oz9+Z+M4vz8x78pTz+DCPrhqV2ZfgjpIsY6Lk8/fHR5cHjs+wzPPn
j57+fZIdFeRpsxFGZ2u6hqzVvFLT7Op7zM87n8Iyhh1B8AIqkbOks0gpka6s
gnVD+qISMdWyZ8i4alW5zOgERUjQ12k1MArzJFklv9NqUJAzegIhmg3RKGiJ
KILEA17okq09fPLs78KfWGSzXjetKlQ4spajEoZ+TXxd5VuILn9MLCDWa6dP
oq8RfNW4J2kcnp5k78m+hnwYGbEYnCLDKS5yVqxduaghWMh/xsFCtuJ0mG0j
9JZ14b5ppnbbEBxreHA9ybQOJPh+U5E2ybudghxaET/ATGzzKXE/BGS2ynuY
pKQQqgLk2PWbYssWF71QN14TdjNiSTzQx3oQXsA1iH1EevDCsm2TPcZjUIrP
Hzx/8u2bN25M7ilpaOesPOTA7rQl4co/bbpcuOTX12e0weN70loQIURUYhfP
vTExUoYBoxEBVhYfIlUiRlKXX9OJk6OklBlsgpcZB0NooxwnoY0B1ldNT05Z
bckXekU/X5cFHRqzXrOpi3HflmsWvflC7WaQxz65aQe0kA8MkTVFu+PlWQQq
ekUZ5ERYKnYHdgybFR4eoWdVEzVhu1kzx3VqUM9zwvKd/OqNLgi8ckXmH1sW
bLHS596V9eYLG8n4SF4RvROtqOImMGM6nqsnAMyr+KyFPjpWlyY2r+jU6Ms4
PPDgYPc1PabxNCadNIgLk4EcR8SMvAIFcMO3YO4xxg7ZEBOr7fmjw4d6jkAZ
v2humlD83sNH+tKLx4+e83kd9YwrPlHa5TWhkLU+fHDiEd2MJ0WBqhSvtorO
tG1+I8yY6VYjs6qwsfa8bCHnkpPIfMhTxD+fSvYZOKmyx5PDF4qSp/6kiPdm
9ELA5zkJ2BtoBG6ejxQZxAn+AaNPQMAtYGeR7Nis4ciLinY2MQC2V011hX1z
cJcPWzjP05hJyd5hy5sPtHmSDEpWoEcNV5PJeVXCed+wA2FLmP0GpEXPQPWp
OO/UepNVnKqJBYEsCCsM+qKGkOvyLQm7a+9NAGICd1HipJz3Qq/Gxj6L6hkj
gdBl3EHTg9fNhoQpeUDXeSnuL4EYaTVH7gmMrH3M9wIKYmrGvDPKiBIE91/y
lXhscxFV7NgAv73NidA2nfqBwc2hJ/HF2MhnqQ8Zmc2Jg2HLYotEnLANY/kz
PFglcMIPofYDlAL9GTpmBNGgtrO8Cnzkd+8zCg7Um9WUNk0KOS+uSLaQSuhe
kncN8oZzQV9ZBx6hAxhp1KRp1eaXqIizGyz0Jql7i1CVHhtAXOZIWpDUpiXA
+jgR2uSS6CLdKLsdvDD+VoI1aKVADvB+WRkREmFONIT5zsVj+T34A+Vi04o2
nwz2sm7Ij+5L8cxddqOLIEvhGdHHxe/ECqv8swVMpNZK2rRK9BWg6jaLhRV5
Qti14ljRcj/SM4Rr+uR8S2tV5arsFbLszQbH2K6IXsWwT0/Sw8wanI4gAZkW
I9tsUSNkJ8YHImCd2sUAKdkI8HA0+ABTLJh6RrzfldOKX8trMn+Ye7NZ2ZL8
uXICqOQoKnNklrGxGlMGYWfLoYk615Wgw0AuZAU2m5asrta6OGMqdplYNh5o
bIbcjBIohNmEL8XLEJvQXuEjm1diqwFNkUbw+0yJXny0UWwgYZcs0yACreEw
QmvJwywgCpqIXMoaeACtiJntJZLyqj8kYm3LgJs0jOUZkSAhBK00cBDFmCO4
2DKMgyJ5a4cxIDY4O8DHSu32z/lwE0en4jiTOEkcakwjR+QmVVW+7ogwnV3L
wjYvSS52jvXXpJ/Zq0KYkbz5P9G2r+skFIGNEIl3htFEnu1iud6Q6KON5lsX
NSALOwWLjySNHC8aRGHmWQ4Pi+3LXZvdy+lb5ADO7F6Wrxre02pteXc9/FI4
I5ELMYw9FY0V03wB/4ukVjEmEMdz2LGt/cembJW1WczWcTDsTs9ykp3n4HXh
811h2s5K9JUeJ1znRizmpVN37hTUzbu25WLpdceAHCMX0gwif/o8K8wQaO3t
F/44qzLHKEqfHBVqWvCDwuaUDBTGTMLX2xAhDNEO/YpsjiW16TiqzpwpzpAy
D73thbdqUnbpNX6lj7gQpImQMYxARhscwXpRc4AVSbBY4JsERwT25rxnLVYy
rwM2CWqpeQLuI7lF4ocUJPMfLFJ7Q/nKdsrWeGi/GyHVyH1ecTSMtWnHIemg
kdhjJPFDtAWLgRe4Jn+YDFkJcmjwyQmNjlxXe4O0B0FkQt5GgirZNG8JEvks
Pcnxr3aQf/FBeI7sq6AGlifZUcde+kggqa2K7d3mVkyQEAY9cxtHWugESBax
qkG0QRlBQruzJXmB5IIwmcaMaPSAmRGJfJnRPWinpEhICSWg3TxLEOznLJ+S
HWvk46zpOiUeUqiFSCo2PBj7ZUVyegFRKGa6/JYTt6TZymDVtShsYG1yw79H
4uJiSD7n8d6YAT/bLVYuumzv/a8Xl3sj+W/24SP/+/yEDPTzk9f498XPR+/e
+X+4Jy5+/vjrO/q70X+FN48/vn9/8uG1vEy/zQa/en/0r3uy872PZ5enHz8c
vdtzVGYS1SQayZ+huGSJb/SKvInDx07MHx6+IDEvPzw/fEYy31xzeI/1Sl1J
MoKl5RZnS+4cO1gV2W35mkwo6HH6BAnIa1hJrWV0vk1DH0fCvvSX2/4kpx6l
/W9VCMLo22BaRIp7RZ5NUyBatYR6oWMsnYM3jHTwBldkQG7kkEdMgLAcWRY7
og+om5Jg97E6oNobGsT1YrQ52rfCwR6uSXYCgb4Uq6aB9+sM3FWDeFCUyXFr
AFSSEV3W1ClE4nLr4qqFeCUEubTU6IYNS4fyBiEoaIjA+CNx1kXWRmgEV3lF
xyE5Uo6bvPL6OkpEuqgIF2g0rRiuebXtrEjgODtJkHb53IZEZc7uYYgT0zcl
etZFASx2B5GKmGQZNqEu4MjFN54/BQm7g+rijfB5criUac0nb69sFMdcceyY
fU6XUvF5l0l2gbgneVR02GSlshXARhFxWQjGIC7v0wylBh988IML56IQKicU
GBvvj87O37L1LLLzfkkxaJBhICjOkRkCx8V1uuwSFTDQc6MsDc6qEEJ8lr7L
STqQQRqbNYO4DKCOHpE4RergZJ+YRXof1E5jbCSPIYdB3OzP2ByEyBI5OIdi
jtHeiD1zyTmQqTDU8sRQhs1QRkO3Wa019kZG0WpKvidtk9RinXwwIg8CxTMx
w2Hw9e62z4uBhwAg0Qxciz51GxyLCnfTZjSh75JRSfGAxL/EaddUjlog8YpM
b4j502KWWYy2WpGsZM9/G6cPMxdvALFU1h0T/2lfjcFc/F5bkNKAOuR3oigY
C8kDElfYPpehzD3tc9CEnAnk1CK7T9XrtZaAMq2DBQo6KObecn7j3DjKhrDq
0ChjpQNjxIgeG0ZJt2xygKldEDf9LhxFYQwGaigCz6JPrUrYPGzc+syMJ4aB
V6x7oO9UdsgQZRcH80axfyx0IJqRIGOjBaUBLH9oGaIEku5JkHgkUZuZRiBL
EeVS1ARJ2m/4IGJun3xfq752SvSCVxiqVk70iM4KNqwUydyViuD4A8p+smGC
fih8BPDJoKhv2iD1w8KZjOqmIruacdHlJJT5lEURIPTHzCJZc6sJpJk7HEDK
a7EYqrtrq7EBkEBhF60V3WLbHqEMVZBN5x/+btLF0YddrctWpGTEICn3mMjE
YPPwJoYEHSPyLFjXiGlFspINcD5q9oyMK10hwkLuNSbmgQJID4CteRggX9ZV
rn4O0oriLwqOhZTYg4Vom0sELCtDPiFEeNXML5RAuBYSFS+dP2auspyk2rnT
TNnhwxBUfvri4fM4Wfbf//lfv3L2C4C8Dog7t1BTJLBls//9n//PRXVFyWso
2G26Mz4uqW7n5fHZ+1Q2kCaPU3cCz+OnHOXw3j+LYxPHmMkhR42Y94avodQi
8Wdjvet95FTcJZUPdJIpMaTHGjwDln/eT4atpNkttkGd+jZso8ePItdb9htd
79rpYiExMR7FBKL31P5Vr4qfNeKhe5uW6xP4BfV4VyqV1AqGOmRMrXNiEhSh
gD84Nlw27b1YK8vJO5uRZ4VlHEgDtootd/KGSBbQK8ikMHtJ8YNSoxGh46GE
I95UZSGJcj5FLXXTM5UdwzINdrnqeXKvYL+Cnjko6AnMJ5lVQaBsTPl1TPyK
pI/PGguxcoRwZo13PwGN92qu81JdWjEJbq4/9FnZpQhS4HsGo3NP42KKnOUA
KzOjcsKVlfpEfFR+hlhE0wesupocDXg7G8nc24iN+AjYZ0kOY6dJi3TUfYok
XrwIW+Pf2R2yhcnuVJDcqMDy7BJcHS0RaJ1IklhXJOadTwjrdWpvW+87uKD1
CNIUD6L6lDp7+GS7YWGcTe0sx3/L3nii0vhvhnYKbzHRQ2DLoy7JpbFv4vHV
Oefq0dPHcK5CPd3PZDZd+IYICYgxursBvlNqwl/EU1A7egeNmJ00EgtLQYim
N2KBl5Qx0r9kqbzrhfl+2ZSzz2MSEG0frB7VAM+eIzsebYIMMBRYrZe6sLl9
E94LBqAqiJPSRnc4pd8cG+ZJOe5lgieP6N1kZOKtOFtYvAQOlM+JG4KR2WX7
Ks9aTcY6lb6pHaEZrjlSZRQJWfkkp3xIfXJeiZ6+JgErp1A0QmJtM1MjxjTs
fh0MtiRZnbv2JQU+LA5goalHecdWcfqE4nU4fPXXf5JKJ7jZdfylUbKYYAHQ
B0ywmsPmdXdRlewNnjOB1xSgCgk2jhXXFuhA6SInVkKFc1wbkvfEJmuhpYZL
uiLwBH0xvBLV4ri5DzKI168cDPrSuo0H4FdYiz0Zqqwf1zb/zCUbN2pFQlMJ
18xK8SBXyGPDcHE5zucSaC4ANdRFI62+2Tqa4EpSZKLYXQyYE//fV2b7SEQU
Hk4jFL9tioXrV0iS8mbHXqZcN6fRMjga1mcBMleU5eLlUdSfJGEF636xRPmE
D57trAQbRtbztLBAiMFEWR9nnyQ+7o7CHaKRxCgEfFdlnmjBUJd6mXefYWuT
+7GPSNMBEOgK3Ucato/zTa31iXt1rOOyOBJnSF5b1eDzBhkQJ6RntqBndhgg
PqbrfiNpX5XJ3/ccXVXK1GqmHKaVlPmikOQ8FJJIxvWq1LKDeyFUEai+dQj+
aIXsCfdVEvYuTg6i8D/Xpxyl9ba/svh2NbUQ3yexBPv6QxDs41i2fQNhJfXh
U2dVqmJw7p0/4Lhmpb2H7nAB0GcvwPPZJxfj2f34yOCYtWaEAYo7dbgG3DCq
yVjmMBMzqlijHkR+jPN5zPAcRDG5IxiCVmrJcUyoNEHwiEMhSbgrXW1ijuIS
VjbpgmRjLrtlQ1oQ0sx7LocE8jozz6ck+fR7Lf4OlOecJpItdfQnH6Ovi3WD
+oZJclwc2mjBvk0dEg3zTe2K+9pBdctAD4kUFXdZIokmlFygv+pGpZBiz39h
X6qMOEBXC9rEEUmDWgfidMfsIF+dWavilFmKI/oOKI1Kqllv8kEQjV2VwKQs
8yyiUS6aGfY5lrrhHDBJmY0RgRtFOkOh302hQFg/HfT6QKImSVvhgTuowG8S
++tMmrIVizdfkDGtzRUq26TqFpb1zNXhuyS8fMQMSC0UzUVFUkDrTkr3NO7K
9I3LqnNOhYMuYjsskVWr4a6GIlPvfLjKIKLpAiLS5U3qoBbgd0+yAfGy0PTS
xpepzEv9Mb9lo1L4rbEon6WOjqGPWqpC0FKCqaVocYkJcn6FaKRSv1uIHFG3
QTeaGmxa1J6G1E1qdADLt2VxFQbAjXjmlsV6FHA8dit9/SGsP3brf2OHCBU4
KI+oUCjZc1gkrjuIat+QqNrAuB00Ekagu9JBX84n9UplF/1md5dfpCnXSCLV
qrdDOh0WouhpZtsQ+x1WJxHLIlfvt6FR0UG/mVPueC2/alqkcLSnpLPx8l6c
cZpmvqmMb2rUFLEWyqhmb+2CHIbIXF2S3SwdFa6OgK1H2vmMSMmX/A9MsAEU
cADZq8jbkkOj3GkUl0fdM5E2tDcRr/U1Lfy3gGRHKYz8uCyCZcDURhnZUBGp
aRYS58QTwwgRn8bXr9rdMWYG+PYN9shFs/LV/J1zGjj/LF/j+gsPAPO7xg2n
cEql81WMUZUuzmVN6jk8m3MVLF500S1fejRgT3MTX4EBnYh0zoPLDAYelgrH
tQbU4Hw6Ne88qhBXDBnJqFQz42pM8i44LbzpmajipELiqWjhVFSlElz3sAl/
3nlUV+VDKMj2bENoS5JhomlUrKaF55ouA3woEg6tPXUT/CEPjxmWlmuybYTS
MXFKJOcmCm7dVGiH1qI3cgXKKw03QN3TP9GSXFURm0pcdViCRLrwC85B/W82
L66JlZzUCwEkXcgP/vCtsEYdrXCg9CNBv2yqwhXlbQP3Bu7Z7eoJ3EoBXSxH
O99TsN70UoUWc7rXy3FqIo5BRoW3yJNdcBIvqMvslUaqhVZuOLkui+G4+/ux
PAaR3Clk4VFRrCaxy5RDN/tnxXTIkb7SBhtu0cz2y4mdaIsECIeNc1khz0Lz
6F1wsF9DG0bfn+7hCKn+btDzKNWlpP7u3pXKdelIIFMUtb1WysdDZaA0aiE0
Y7ifH1QGRuEokicPF1p8htwL+xK6uAvc8uNEfpon3EPDnJnS4s18vicGL/8u
c78bIYnNb7ExPzTSePFQZmcc4AwjEQ6qrBV29MK1oamJ60N85wwZAOz7l5wD
14+zxOHnpmQTozFL8sRuxT5qwuxcQjdCNWpFYW9PspMvOSI2kkVSRKf7lBT/
OldbzO2DuIg9dPAAGeROI4UKv7HzGSZZyErkXVqzktb9smriorAXTw/pmAxz
QyxKEb9vN1Bdynwgs8QJKqUTzOXR8J7Z1/3SCgcRGuAIzLN4s1hfMur8Za7k
8XJJ4dgViV2RgYHNS63/TKCTQlZp0trXVOTDF9xOFu/yYJDCVAPTdkaEoRX6
TMCMKqEkQRgFY5nxB6lroS7jyatjCzJvWYTOcqIaKKViwwyuH7mdlaN5Mfdl
YZSVwjJE3QxGdPmYK7i1YyuWx8h0JvVpPYHuaBZBvae94ghS2UlSZkh6I4O4
qphBAeMxoUkjJVRHXFeK6qiwSfQThp/ocXarO+e9TTdl5Vpahttx4Xy/nffQ
UI5WXYw7b6137bVlHG1eWy1Tnso0HtbrIf897qXGypKsls08efrc7c41VIa2
uu9U44KtMxmewvpM4ogo/4ZwwiA5cnD7ko42e4PWuTHZaPKPj4Th/Tenbz4e
GAGUaQsjHGiBOUkF7ReIOmolvFpLIQwqNLDXEKumRzvIM6MtA0LjkboKtWBx
9zICSPVsG/eSAH5Fn8HH1mRFbF3NdVFgT9d53Ucv86dqu3CRVKmY6Xgl/BiK
+UzcquzL7G4MJYD4XJC70vnEmngRBBPWBQmgD//aTs20Jdb1E2GwEItW+o2z
pbR5hIs6uR/XNbp5mdpxszxGIw2pVmtachZmJpHCQNXOaQK+dySZoXBBxpfl
zrGHDx48NDdHlzBNBjK829vU+D0dB4+76qN9Csj5d4cBMT44jc3t5mJiIykr
7Viif5Em9K11bX+7eEO2MTsTan1H1Po/knHwLBL5ptxkhJe4dCF0mGeXDYxa
8I2UkZWoRfUdILJkkC2O5kH9iWEhnKZWR9l3WWJ1lPPAOfglc0fa6H7pW2O1
zdRhDM2OYcfcaeom6EF+5mXF7Zqpup6Y2wZquQVCrAQJX5Lx2vTJWa6cY1M5
8VbXcz+/GHgp7sQS9EV0vKwqQe07TCxdF55ToYAhTcwTWhRFNj+LHA7CihWW
E3VVc1WbjArfjf4a2TaQEMIyZv/V67MDFS5YEkm+vuzg5jbt1s1EKHgYlFY+
+V5e9XnwtXn5ReNWZWckyOnmjw372i+H5tEtHuRNWm1RXcMmVCyVoXyt6tve
FcVdI/Dh24izof65k7mNToaI9ZPzEd5oN1ncM+Q7xHdII+89aegl6ot0PV5y
7Hlw6mQHd4RlzCAs44PAzvWQMW7e+vC2UhnIixvNIGIGgEyyY/e065xzKRk6
HpJTea2+JZE4SlyjftyuXJWYu6NTcnhh1mpQqAlFRyU/ZR86Gl2imSdFjcw8
tjDVn4UBGLAmHWdc19R4ayCyICG22G8q5zKqRAWDvK1CvEKnHEYS+QFqPBQI
UtF1GOTddrXuyc+axfVaIIgLbp94w+t9/YGbKca8OuKkGVklXIsnfYC7qI4b
AMoQ1xMCgN+/HYv0dx9EmJQB03PyGORWhTRTlEmcvfKpVYaroh+KiWFrLvqN
z0QV+VbDxk6/7nX0J2ihtt8jF10a5iUzJgLxz8GCkyxIs1pxecfccsq0i13B
uN3wmoQKkeeCrAeSSVFQi6Eh0xNNBrHJFL2r/BlJAbDn0T1bAjgU50NZ4BFO
TUv9scOJUTSywcNoj3HlRjmRvoIwzCVg8r78Qg/sipfIXwII7khDECUJmsQp
odBteI+5bjoiRo/gjhRzZERLYkk7Kl2dyf0CJ0Jm4npK23sQEWluKc4J3e+U
JCarQUSiRo4P8bRD1ncu/3BDskfACZmYWIw7of6CTMDoJ/Y1DlhSeR0sESRB
Ziy52NrQ0kueBwCYfOVLx8UkVktcSMnllRe/YhhKzTGLu74JIfSV7TkZ60xy
pQPW0sHSH0mW09tSwExiCx0lUV4m9SgXGVrDkZhhjgNvX/HTySCcYTcJGy3c
p1sRa9sC7rbjw8L2vqKYOLZsOZqJPG4c0dHBKJv+IPRJ1AO3/cQNiNTR3eOz
TQta2aFZ/yC/J1kHr0pE7+ViQnsnNbtlglonidHsDoIyMUFNsvuCyEiWnrdo
aE61Nc6nCz0QSYzUQ7xjdUny0b7JEIU5NtKcM5xIsc9CpzY6KZyk8YHmP3Xc
mcJnt+LCKK0U4EwVl7WzrtqUvm1tIKzu3LQ4XSGs7bwGMIbnikbTJPX4rq0O
62VIKpnPtfaSTO1w+AvmkTS9D4mV0ZhNx8h5YqDKnFcwNjuJYzAhO4ljo/Ov
S7aT+ABJMvG7XanDJu/OsIVwHAZjcn86m0z3bRQ5imtARmnRqXFDvm7/qKs2
vNEbMfIJdeADo76Nn/WtXa1pdvqT2ITf9Xq5gFcOIqr3BnWt8t+aaFhtVOTT
+YKMdKwAUMZeJk/Ys8kUB7Sz5IU2ld563s73YEHMAzxuaGBNLdTjKe1pLFMU
XT2OSdAvRTODFkPpJ5zHfkPgWx6sFUWXDQcqNI35mK2Mp6EHQ0uM95NDPuCn
VB6sOSgXzP00YuJXfjrKDg8nh2LGxF0n8gWVxueoS7iE1N4lfp2IXquIjpjQ
Hdas4bMdlh07MaJdpXePN9TSJZ5A5Ov2uD9sjnZcTpbohA6TTLvQxJDa+M5H
kKGKluk3v8rJXYmDyYJLmBpG+d1F2KaIRaPHlaOyf9ZxiBqEdb3P69hiIw4D
BVm+YWDW+WYGN5bQO/UhDToI5vqm3bgRyE3t8f1coTt3Bx61NwOS36/2DEEL
WaSL2n4nLvD66MXDpEmY/aa0ycK4Ut3zy7MdYzzPQZacEA8teqMIUEnSwesD
MjiIMeeyZchab1zQ/5AMr2yxYIwciOHnhmVfuRYT8nJKSaq6WSk8iHZnQ7wb
NMQcHhdBapOXb3fTKbn31d9aUuDVlhJ+GNsoGsgLvrsPLR4Xfo6mvB5Z4y2n
7nwKjdxtnTCX7T988PDxwWjYsq7pFJ5sjxlXXPg2bKLSygYzUJFuVCovOZyd
dhfwcXReZ165wPpuCLgAgw5rKaVlTkQb35ilLfZ8cogeNao0el+k4L0pTN0b
wJqOMlOPpGmKkRnWJ9/TLUGoAj7778LA2s1vTRg4/aduV01fKiI5dprsIzQ2
jpJ2PY29aBWVLVwjgDadEUbOU77yBbTc9sWCv+fBREQrJNA0w4OS6dcuTlKy
VXyhE/XMMfz8M671zPZfX0DFNM4Ui8eqhyFj3WYKlabp3ih/LNM1JNN6s4c7
JFhDCEu6OrlWa1j0S8KC0cEGGnrYbZREu0YHgQS7uNDp61eeBFb24ynR62c6
9kSosQhQm3ruU1th3JK+nOnLsb8cknCP/NgnHksMY2tFSglFKDoaCfJxsJSW
zLpB/hYJ9GbMoSs36UHqFFmG6Ry2UgIgOvFB6Fjxn3PcC1ayVtoYLjlQ16sX
y4rnNkhT3+4ENFsuIVYfp5uFP5PphqOoa8n19kYxkl3rjHj4cJJ9ajc1Z1Ph
X0em1emZnynhK8bceLbB9QfIDZMia7V+Cpp1gOwkSgeGfYcIGofrdJaZRHhQ
vBxFxNxk8CRAJjaWazrkuMBdLVndTc+TSwm4gCAOFIq9lX3khV3xpcDtWNQX
y96Z8PqjMbDKcuu8a36GrC8sSQY1LogkzC2lDs8OHx96O/E0aosKncnfTUB5
lpfaODFUfaSIU46M9js6r5QKfSd45JFIfUIe+1fuqbQn0c8U01RBKNVNQuuq
4gOY4hyxm2n2MfWg3iIjsDjQSQLiS7ctU5ePmLrJe6EUQhyCEJs2MALXd0Mm
cRdNxI9UbOWtjmf7wnPAPh19MDrtjh9CMGnDzrzEa/CvTu5dQql3aF4Lnb1V
+Znb6SWsDwuk/AMOfjK9S2LChPgwiygZ549Pasfs8HKSg50nESJnkuVwH3OT
JsRXhKlSdhiynkYbRLDIbCy43YWrhvPTFNiYiKKWUmPrG1fn6Cli+zO0OnLN
I7sNJU9jaNpwHUUYdb1rMJBE68PoAF1fojX4MrLpsgUZxOC6FKSDrhSLx9a+
qSsckLOb7uuoJu18PFGM6+MjN9J4N/LwweSRuJAPJvGoAGkU3Y8a86R1SF1G
bhT6+kNc4XuzpPDr112159921xAn9cfGz1adZL/K3Ii7rbu0xQTSsCRnUOh1
WhadCY3WzoZNhAThx0n6XX3eZR9m4Ayr9BGA9ZNgnVN1z5hhY3zdy825nMiJ
InHlVnfyS6a48AQnxLi0aF5ijG62lJm6XHGnQy9VJrDtCAqhv0yyj0hobdrO
DYIViwf1WSsLOWIGy7vgYIrB2LzXacZEj7KhYQl2XK5PLju35EkrNfvYcodF
QyYYEhAKj/uOCeYTe6bOVHQB7vsh3ZWwGHd9QZDKMpdxFLn0/mqddMhyznmD
Xu44wY04EIvC1sGO8UNdxDY4I4tQVcUluXNjFI7KjWFqxsSRL9cIdqdklsxW
mNLAZ8vhIjIlEBmTUTeFczoHdbcSvQUYY/iXjjTC6/tsLZFbhCIrLVw4uGkR
uYhK/o+VBlPSC8zE2hoCp1i5RBNxFeXZNAZ5v7NE4MBynbxjee1/C1ciGVji
A/WTpg/7yIScO8/GlYK52BSB1DOoIyPemyuhW/GccY7S59dCFz4FqjytERz8
gZfonNvJmXa+trHTC/8619jjw28KZM3EuivOFo/ZGlR0cpLk5PiDqy4FofDs
IHRUnamFfO0vxPA362zpNMNlk864/cSqjcmYjol/8Ea+JBE3Mi7LR81+dwkl
roblpPx1tqsOyWiFfmib0lo6pUk6uE4HwUB8+PlS0iSY5YsFMhoYhuvzdA4a
rSSUtl8xBbZrAYDvB3LDgK85Pszfk95ewsnEvIqS2tIZiCHjN1LzpeKbkcLL
ynhKfy3PxnWxmz10boMB9kR2YQqy2mRhLlLkCw+L5VVVIpHfhr64cEKsLN0h
+btyxEsIAptvpICUVfERQT4abhZhKrew7E2v5ZjpLO6QLg5tekGW8YSKOIh4
X+YOua3YUDA3xv1IKXxS5Mn2jlBQmxekOoW/aW9t3ntyEBY2EY39pDYz4dlH
4Pn2mC7oNbcw6zuQijzuVdNPRmZtwl2XEeduOAITGj2sfaSD3KqbqhDqSn/j
exaRTxgU6SdB7EfPeagpFncznw414cCXjKpM1sovl01w5rE72HDeoUMcdzRy
sd/XH9K2rf8dUy8eEXZfEnFmH/EYZIhMNUH9oe+jdcuLaFR7zTkw9NQ4asWM
er2O/lUbveO4VtR1E7FtjAieIgQLf1CE56ogQvNzsHC5eMPnRaIhrarEbh0N
1UVdoCjRETllEtaN/FZnT/o2pQjzUfFOJIXIbJ6W5NL0qNLQgobYAYj3QOLn
SGaNyi2o7/M6l6h/tn/0y/sDIiIYCGrq/JGQfEI+EjZL7nSKJOTQhNGBM0G7
08EQMLGRo+4gZq7DHhfHGiLRy7J4su1R7wKEm1US8wzljRg8J+EDjMR0m/kT
6iW7NdwK0JG7QyIFBnwd7v6FJvcj+NQcxcyCkdShidnOsEkQ+cjVA/KqfbgI
jK1XIRWW3Cg+8bUIO6XxjuFEIArE3PR4j5vXZLbtv/llzP86cBm1hy8efPv2
k9RTtuouA5OLVm58lS7s1pzUSyiHIts/Oz3xb/MtLD9pkO86e+cqZviHxl0A
cEEIYb1/GfKG++8eXxz49Nejh3Kdzx+p3ej4+oTaG3C4P+pErcp4rNulDzDv
nxxfoq2HOFIi7S5JepYtSZhbmTuxcAnpKdHovJQ7Glpy+6Wd0X0iDgt+aPrg
zNJXPhzEfz3xFXWEveOTA5OYvDzdZAyjl8nAIfb5MxSzgGlpezAJVXkcPtW+
oIA4l4PVWPzdDqwW9LKlWfLcIMujmHLVyHJrbM5m6Pj4BHfSf+ZIiJYQa4Yl
bjENzC4G8LxsV76i2ER5nIbzf10YuZAkj/UY6YzCEckyXCPdDYpIUp9lwEG4
gbjjIv/OD0/A3IfARSEodj+SoxXLzs3gSebvmDB0Rk7l2RPO94bEh/oTaT5X
BqH+8l5l8Ucv9j12Tmq5rYHdahJw7sblY423v3LJja8/3Mi7aJf2jbimyz1s
2Oqq0XrfICM7S4pieP9lveFhA4bEFM+jwfubzk3d1XES061e6sFVcs6ud5EA
CeL75A36PgyPrM6/n/+RvJ+DTwINIux9riNyr/yMyNrXxvk6Z9wswqZzto+q
orjaK06cac/AgXcH97sD1JNhPt3YT6u4k0rccFMjXKaXDrj1BOshU+Ox6MO/
bhAarDDNu5io6t0OKOL7OExqTtOgxt9yaVSX3oSvP7DRiwrqOqhSPM4o9M2v
7Dk5xyPMD1QVK5Yzx4LVsHGX7kUXuXDKPARn5RVV63kf36vGlrrEMbi36VLH
cDv/nROSBc/QvgkyZwkd3JIQ/4KsqfOBzW3QuytD2YNwip89CTbo4JT48hE2
WeGIctsQNtRu0+UI7w7Tsnx8Y0muAPlviqnNg+y4dx6b4RwckgpdqJoZwUAt
K9Yqo8z2szBUIRo+MfiIMH3wlFbe5DM6xC2gJBTqOCrluauYP1CEq2v9Yfne
Bp3eamoS4SiVy/APNWZ6QKMJAD1WSZBqw2DNA0FkJkzkaZm4WQuzXvhpdjqW
246tLcaTw6GWyPrGb1xxLHeg5MExjt9wE6PCeuLw+avGYbkPC/EPJjjXUod8
eZS7q2g0KiXa1AU11oQ9vgQBGX5ULY4xaK8ziV8ZxbT0bYn5zKq883HUcM9q
zwErEJY6vpg670c1uSHBfN+h+DYqbZIpfyjNsclEbbVNTFz1HD4VVROLAC2i
mjC1Fa48drS1VckfXCUXYLBrzCyV7YvvfBB5SFxPwVWKm7JbMikyUOpl66Tc
KOgr0SKNHPzxSqKhJaPzx+jwTeSToRFziiZuR14yPyO9eVND6y70MxAHnL5V
aYWub2QwJdhw7AoiCYIPYCDxvvZuPr6X7Z82ZMzyp/myVulmWetlhDduqb/f
2FvtKdBYOdFbM5NCFabEDVtXZlBl99IQJMzmXSiA5taBWbQdFM2DjEfZ8dmv
o1DcEnIXHOOBRr+SjGJchrJsut5dgSTfWFc5X/G2YgPdXVHFQl6roknNGDS6
14P6Z55ACobiDkiONnlAvYvOV/hhzaum2kjpl0OWmwfKon/wAfoN7uFJ73wh
h5DHakdB1bFAINE5KCsXTJJmbs6uOnbS3kL80ieJxspMa+koHMkMXZnBw4kh
V+yqlMuNnXqLCd/pMhxyZ5JLBqW7iU41qR1x/bfqlGbLzSr3XUtV06xdubsz
YyIX9lrMEVfaGSM8CWXoNzhWK9cMIhMYdyVNYtdqd7GYTCN2IXmZYuIyC3FR
1M4JCBFoN0wmbvhle+n+0iW5vQrJOamhymV6qYaR0nlpncMwjlOkRnYhQVP8
0dk0Qj3aAubuo81WZF4bZj8hEY6cSsWsu+hjMJztglBdVajrlRWF+RkECYQa
lOW4IKxbBEtKFFqgEt/n4ePn7lpmbhoWGDzdGiXYblj7LEj2ZpsmMTVuxLJf
VhpeF/X1q5it31w7WCeViUTwKkD/oBYY9nGGS3M1RN6F4nRpw5bEJ1c5jpw/
3YpNoTmnSQat7UzekbeNb+sfvW/A3UEkPru7XpcUOyQUf9YZzK7hJFzd4bMA
fMnJfTrdXGpdLsMICTxfPcxK2E+qAM1wswoT2f2LIeKsKu9rFZ2paBlImRu7
TQcQx5X3LyaPR/Q/T8TueTGJqvulbEIdCz9lOw25x9/Xc9bmeT3qnzLcgil1
Pjplx8QvKUp+SlZalUVR2WnzxXY/+eKf0CumfraUcxgZtAxpyLv1SJYLrfqS
/PJ1ZLHH05k96wmDqBZyUwvOLV/ZiLD+/65A04pxnjsNpMValEFwwZPHT5+g
xDO51NOEeLCmJl36qPXwa3YahjQaijEqhK/G+5+Wky/DkOH7NIEyD7uB9qUr
CLK+UrP3gFkBzPUcdpui4Ilc7mLPOKKhQz8WalBKJyIpcG394qUm5jx5iCQP
u83AYBjqPZK0M4pTAYRLgfGfrzj/CqbyKw/rjzJVKFx3EHhrmLj6A2weB9eH
yLnRRPP1q/vgiwl3zsS8y3PTBIveYdMhAUR6Es9AiVAIkmiDVV+6aaM+FphQ
LbPXdm3d9SE6VkfOybGgDqVuV1pDrNXqBSwZdQMkoIcKGx35wNU3zuYZpH+c
xPQZS+tad6SBkPkdS+0k7B15AK6dSFudfQ32AF9SecH3v1p1c4wHo5O+V/Ga
Y/vfWd9MYFeu655LdT06ydNVUjbuMbWu3vNwBizr4/TGhF/uuIwXbLZCgVcT
TQf3OJvaYMuV7gZC44op3DVZWWANV2wjoh14Xfmva5U325SzJTm6lZUKcOPE
F8F3ZSugwE175miB3uLHss/dm8b3XcNdo3cKyzPEaoOzdJ2MrFMgJpkH47sc
XRBKiwzyPoIxinrjTjcZ5YBQ+cfa30cv2VV3hRbPTMQgljH74uI7Ryh0E52d
h2uIkhZl7cIsMi1STcKrUqZlihEh3VIcS0BvSFJUQHYzX8ZjnF0e3XqHKSLc
YTlIYPhRPHLjsCfPwq7ESu/R7hDmp++Q0Vze5N7WCzAYQf4SsqQTxQTEfj8D
5e9a03BSwCmPak2YTtrom8S8CWFEkZODuEHYbyfayLVS+plvoVWfw8uhr5yM
+m09IxeyLjufIwF4DF0IkEX3hOr0hdCuVbYqBWtf+gRq5ZG63UGw1SPfg8t8
2pXRC+01tu76MJ33rREaedtfB5ZUqEFqazgnpWAEObQ0259UHIe+KS8MtwuR
qWtldLJj5M7lLUDxPm/Rx6NbtDkk3KTK7MwhmaAoHNUTTyw2JBjpD2oOBZ9S
bCBFu7Q0+D8aN+TdDbYCclX//obfu64UN5igi4PnfI2wOugvs6O7VUFaT5eQ
Z7A8HaEmLvLSyg1FKSr8gNC0MwOiNqT4eYBmOoKcm3FklN1mjT45N5tygLFw
JymE/BXsyjDZQWI/B0ERktE5NOLSnUEU7NjdLl7ZZe1FteM7GSjbwUDaJrdp
zR/nouxOLjL346KkezEbdi/2XsMoU/Fo8V23s0pLyG7um26iW7d2GHvudr1H
T57qyBoTLtzJd7L03cIXB/n+DM32mi1/KplF2BOvkU845rsayPp/HW5u0OGJ
w1pHH3CT0BRA2v+/2cNshdwfT+1Bsgj3+2Lolbi+003b9dsQpRcy4HmN7J/6
7kvS9bgMxVkYGDGlxhsqC2e33BhQxEDH10dk7vYISYCv+He4RMLc7xKJLAny
AaTkwg35FLMVM7sfMhVFEe9unZVrnCU9IZU1XbKdHa93UW22b5jUWmBSyMY1
rNmqszoPetDZrsPLAzbTi04wNjUylndxtr9UyDXPczRVki9IxLKsiLta5270
TnwFQXxsniluNDP5kjPtJBxcfoPbnvgGWwUEMJR6B7ydyQ3ax2lf+G2N174V
IBgWbNxtszArDhASH/14ehbpy03Z20FC2i/qLzZUJyJU4it00jIzvIaWPuVs
2Hk+s6Haw73/pzA37u4G58JVEjtsxBrQCeacKzUql3gYDpU7u09EQFsJYX9w
aT7hLagS/3USiuu2vMpnW9e6I+Y5QpWcgXVl7aQMpISAz/L06MPRd85xyfM3
5UlXLW7MeDzm+T1Y5Mg360vb8teXwrG2+Kc9vmltD2UgnKp9Q5JCOizf5+3n
7KiqELq/9sneYAont1b8ia94KLjlqWlHKm6fcNWX60XuyJuzxaAc01/pp10v
tAT5PFxen3PQusnOyxnX8F2QnCJVVls0lYqOttVa05K4V1hnRV7JVBy90U3m
o9nCdeHwjUmdxmHQQ6dzlevP2ftmmePuwlfNhoAgLTrKPlgulW0LwDnKzi0U
6km9AEAkgP9KphU7lu9sXTdfRoS0vsf/8LTNf8sx3fSC8Ihs1l83tl2Q7KJt
NLa+zm1FJzoixUM0epkvabULSytdbojK6fH32DU5jJ9s9XuFhRc18cQnWE1t
tan1qtO3ZI3ikguZZmPc+AnUG8igUnE6eIvptZuvfehS49TvckLLCXAriaSj
nCRj9iavPmM+R6En5z08Pd4JYWtqXrWIIZGqeNvgyjTMYVxC9Y2y12RwEHZK
qP+/lhCCbZ6d5cVyS08fN8R52ZlF4Rjh68x+/pwTHZLuzFEuCxJlUru8+Nun
t27kL2LTpPqxLVWXmNPyCYUay2aN3xHqyBwnTWH8VWN5uE2gCHFovcpGzCnG
hJuxHSq1TnUcGFnc13Lnm9L24dOnYkpkJ0j9OemleJmWt7CZzO7HCBzM3ByX
tp+PZ7Prxbidz/TF8YOnO98dZx/PLl6fnuuFYvTz0fkl/b/7+X5rP7ll7aPX
6Y3tK5EV91v08S2LygVlJUcEELmY95zTt2tSGIXCPbnnNx7d8o2fyQSGSa4U
unevMO4edqxuVKESeQKARYoXOMfxw8PDF0jTkmFXdI5aZOr7LBmaIBNJeEVA
Yb9w6WCc1Y4tjR/18vpMb1W5+eJwKAEndispeNnx2QvLLo8KN4dte9/De7ib
Uh1UaZIjzBfxcbZbnpTSDRknM87elezvpTHM66TXyK+DhLJeWHHL2qjidIFh
euTcXreNOqh7g1vi99KlItlY6FxivpnI9eb56z55tC4RTThXd4cGZvfB/5jx
xay44IErmmTYRVz4mTCABkfveSaHf+RMVjejoEDmZdPryI+mXZBDCkcGZmcr
dolIPDWvGJZ7wvbgbth++fX0eBSuf77R0Ovvt3Yv+FKrmEnwV6X4VcO3dnOx
kU4xZl8rFMAeH396yx4b6n1ADnJBWIolTnZxruvGPrvYtBgDaAiG+2363NZs
NcxLmYKhd3JnBFFO/pRS3q/rQmLMYkAty7UwdTpGibn5VLP2G32FpYJqdnFF
vc3gURhu/AGGptFtCuPsvVTJWDc7Hd/l2dtdhNnou47MJd9CalIA6XzwxZlY
nd9X5m8FjOlbVeFtiOMCnlZrqGBtFhgKCOi+rKqHhPvs6hE95t0BnggV569I
cfx/75CP0AqvAAA=
</rfc> </rfc>
 End of changes. 136 change blocks. 
2403 lines changed or deleted 1103 lines changed or added

This html diff was produced by rfcdiff 1.48.