<?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) --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ccwg-rfc5033bis-08" number="9743" category="bcp" consensus="true" submissionType="IETF" obsoletes="5033" updates="" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" version="3" xml:lang="en">

  <front>
    <title abbrev="New CC Algorithms">Specifying New Congestion Control Algorithms</title>
    <seriesInfo name="RFC" value="9743"/>
    <seriesInfo name="BCP" value="133"/>

<!--[rfced] *ADs - As this document obsoletes RFC 5033, should it be
     added to BCP 133?  We have updated as such; please let us know
     any objections. -->

<!--[rfced] While we understand RFC 5033 was published
with some of the text we are questioning below, the questions and
edits are aimed at making the text as correct and useful to the reader
as possible.  Please review carefully.

In addition, this document is in the current RFC format (a major change
was made in 2019), so various updates have been made in the source file.
Details are here: https://www.rfc-editor.org/pubprocess/how-we-update.
-->

    <author initials="M." surname="Duke" fullname="Martin Duke" role="editor">
      <organization>Google LLC</organization>
      <address>
        <email>martin.h.duke@gmail.com</email>
      </address>
    </author>
    <author initials="G." surname="Fairhurst" fullname="Godred Fairhurst" role="editor">
      <organization>University of Aberdeen</organization>
      <address>
        <email>gorry@erg.abdn.ac.uk</email>
      </address>
    </author>
    <date year="2024" month="August" day="21"/>

    <area>General</area>
    <workgroup>CCWG</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>

<?line 99?>

<t>This year="2025" month="March"/>

    <area>WIT</area>
    <workgroup>ccwg</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
     the title) for use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword>

<!--[rfced] Might this update to the Abstract be of interest?  It
     attempts to reduce redundancy and reorganize the sentences
     slightly.

Original:

   This document replaces RFC 5033, which discusses the principles and
   guidelines for standardzing standardizing new congestion control algorithms.  It
   seeks to ensure that proposed congestion control algorithms operate
   without harm and efficiently alongside other algorithms in the global
   Internet.  It emphasizes the need for comprehensive testing and
   validation to prevent adverse interactions with existing flows.  This
   document provides a framework for the development and assessment of
   congestion control mechanisms, promoting stability across diverse
   network environments.  It obsoletes RFC5033 to reflect changes in
   the congestion control landscape.</t>

    </abstract>

    <note title="About This Document" removeInRFC="true">
      <t>
        Status information landscape.

Perhaps:

   RFC 5033 discusses the principles and guidelines for this standardizing
   new congestion control algorithms.  This document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-ccwg-rfc5033bis/"/>.
      </t>
      <t>
        Discussion obsoletes RFC
   5033 to reflect changes in the congestion control landscape by
   providing a framework for the development and assessment of this
   congestion control mechanisms, promoting stability across diverse
   work environments.  This document takes place on aims to describe ways that
   proposed congestion control algorithms can operate both without
   harm and efficiently alongside other algorithms in the
        Congestion Control Working Group (ccwg) Working Group mailing list (<eref target="mailto:ccwg@ietf.org"/>), global
   Internet.  It emphasizes the need for comprehensive testing and
   validation to prevent adverse interactions with existing flows.
-->
    <abstract>
      <t>This document replaces RFC 5033, which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ccwg/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ccwg/"/>.
      </t>
      <t>Source discusses the principles and
      guidelines for this draft standardizing new congestion control algorithms. It seeks
      to ensure that proposed congestion control algorithms operate without
      harm and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-ccwg/rfc5033bis"/>.</t>
    </note> efficiently alongside other algorithms in the global
      Internet. It emphasizes the need for comprehensive testing and
      validation to prevent adverse interactions with existing flows. This
      document provides a framework for the development and assessment of
      congestion control mechanisms, promoting stability across diverse
      network environments. It obsoletes RFC 5033 to reflect changes in the
      congestion control landscape.</t>
    </abstract>
  </front>

  <middle>

<?line 111?>
    <section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>

      <t>This document provides guidelines for the IETF to use when evaluating
      a proposed congestion control algorithm that differs from the general
      congestion control 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 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 for publication in Experimental or Proposed Standard RFCs.</t>

      <t>The IETF specifies standard Internet congestion control algorithms in
      the RFC-series. RFC Series.  These congestion control algorithms can suffer
      performance challenges when used in differing environments (e.g.,
      high-speed networks, cellular and WiFi Wi-Fi wireless technologies, and long distance
      long-distance satellite links), and also when flows carry specific
      workloads (Voice (e.g., Voice over IP (VoIP), gaming, and videoconferencing).</t>

      <t>When <xref target="RFC5033"></xref> target="RFC5033"/> was published in 2007, published, TCP [RFC9293] <xref
      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) [RFC4340] <xref target="RFC4340"/> was
      developed to define new congestion control algorithms for datagram
      traffic, while the Stream Control Transmission Protocol (SCTP) [RFC9260] <xref
      target="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]
      <xref target="RFC9000"/> and RTP Media Congestion Avoidance Techniques
      (RMCAT) (e.g., <xref target="RFC8836"></xref>. target="RFC8836"/>). 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], <xref target="RFC8257"/>), and in
      supporting a variety of
upper layer 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, including at least two that saw large scale deployment: deployment. These
      include CUBIC <xref target="HRX08"/> and Bottleneck Bandwidth and
      Round-trip propagation time (BBR) <xref target="BBR-draft"/>.</t>
      target="I-D.cardwell-iccrg-bbr-congestion-control"/>.</t>

<!-- [rfced] We note that [HRX08] states it was published in 2008. May
     we update the text below accordingly?

Original:
   CUBIC was documented in a research publication in 2007 [HRX08], and
   was then adopted as the default congestion control algorithm for
   the TCP implementation in Linux.

Perhaps:
   CUBIC was documented in a research publication in 2008 [HRX08], and
   was then adopted as the default congestion control algorithm for
   the TCP implementation in Linux.

-->

<!--[rfced] Would one of the following suggestions be agreeable in
     order to clarify this document's journey?

Original:
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
[RFC8312] and then as a Proposed Standard in 2023 [RFC9438].

Perhaps A:
It was already used in a significant
fraction of TCP connections over the Internet before being published as an
Informational RFC in 2017 as [RFC8312] and then as a Proposed
Standard in 2023 [RFC9438].

Perhaps B:
It was already used in a significant fraction of TCP connections over
the Internet before being documented in an Internet-Draft with the
intended status of Informational in 2015, published as an
Informational RFC in 2017 as [RFC8312], and then published as a
Proposed Standard in 2023 [RFC9438].
-->

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

<!--[rfced] Note that we have removed "IRTF" from the following text.
     It doesn't appear to us that an IRTF RG adopted this draft (we
     see the first two versions as individual submissions and the last
     as an IETF document).  Please review.

Original:
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 [BBR-draft].

Current:
It was described in an Internet-Draft in 2018, which has been
regularly updated to document the evolving versions of the algorithm
[BBR].
-->

      <t>At the time of writing, BBR is being developed as an internal
      research project 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 which has been regularly updated to document the
      evolving versions of the algorithm <xref target="BBR-draft"/>.
      target="I-D.cardwell-iccrg-bbr-congestion-control"/>. BBR is currently
      widely used for Google services using either TCP or QUIC, QUIC and is also
      widely deployed outside of Google.</t>

      <t>We cannot say now whether the original authors of <xref
      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 teach us illustrate that deployment
      of new algorithms is not, in fact, gated by the publication of the
      algorithm as an RFC.</t>

<!-- [rfced] May we update the third bullet below for consistency with
     the other bulleted items?

Original:

   Nevertheless, a specification for a congestion control algorithm
   provides a number of advantages:

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

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

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

Perhaps:

   Nevertheless, a specification for a congestion control algorithm
   provides a number of advantages:

   ...

   *  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>Nevertheless, a specification for a congestion control algorithm
      provides a number of advantages:</t>

<t><list style="symbols">
      <ul spacing="normal">
        <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>A specification that is accessible to anyone can circumvent the
          issue that some implementers may be unable to read open source open-source
          reference implementations due to the constraints of some open source open-source
          licenses.</t>
</list></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>

      <t>The evaluation guidelines in this document are intended to be
      consistent with the congestion control principles from <xref
      target="RFC2914"/> of 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>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 serious scientific study of the pros and cons that occurs occur when the
      proposal is considered for publication by the IETF, IETF or before it is
      deployed at a large scale.</t>

      <t>After initial studies, authors are encouraged to write a
      specification of their proposal for publication in the RFC series. 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, 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 anchor="specification-of-requirements">
      <name>Specification of Requirements</name>

<t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
    </section>

    <section anchor="guidelines-for-authors"><name>Guidelines anchor="guidelines-for-authors">
      <name>Guidelines for Authors</name>
      <section anchor="guidelines-for-authors-about-evaluation"><name>Guidelines for Authors about Evaluation</name> anchor="guidelines-for-authors-about-evaluation">
        <name>Evaluation Guidelines</name>
        <t>This document does not specify provide specific evaluation methods, short
        of internet-scale 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>For many algorithms, an initial evaluation will consider individual
        protocol mechanisms in a simulator to analyse analyze their stability and
        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>

<!--[rfced] Might this update reduce redundancy?

Original:
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.

Perhaps:
Any request for a working group to consider a specification for
publication ought to document evidence of results.

-->

        <t>Before a proposed congestion control algorithm is published as an
        Experimental or Standards Track RFC, the community SHOULD
        <bcp14>SHOULD</bcp14> gain practical experience with
implementation implementations
        and experience using the algorithm. Where there is implementation Implementations by independent teams, this
        teams 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, 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). the
        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>

<!--[rfced] May we make this update for accuracy/clarity?

Original:
   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.

Perhaps:
   A congestion control algorithm without multiple implementations
   might still be published as an RFC if a single implementation is
   widely used, open source, and shown to have a positive impact on
   the Internet, particularly if the target status is Experimental.
-->

        <t>Publication might occur without multiple implementations if a
        single implementation is widely used, open source, and shown to have
        a 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

<!--[rfced] Please carefully review our updates to Section 3.2. As
     much of this section is about Document Status</name>

<t>This RFCs themselves and the publication
     process, we have made a number of changes to attempt to improve
     clarity and to align the style of terminology with past RFCs and
     in-house guidance on such topics.  Please let us know any
     objections or further updates to be made.  -->

      <section anchor="guidelines-for-authors-about-document-status">
        <name>Document-Status Guidelines</name>

        <t>The guidelines in this document applies apply to proposals for specifications of congestion control
        algorithms that seek publication as an RFC via the IETF Stream with an Experimental or Standards Track
        status. Evaluation The evaluation of both cases either status involves the same questions, but with
        different expectations for both the answers and the degree of
        certainty of those answers.</t>

<t>Congestion

<!--[rfced] This text left us wondering what happens to algorithms
     that are not targeted at general use?  What status can they seek?
     Perhaps further info would be helpful to the reader?

Original:
Congestion control algorithms without empirical evidence of
Internet-scale deployment MUST seek Experimental status, unless they
are not targeted at general use.

-->

        <t>Specifications on congestion control algorithms without empirical evidence of
        Internet-scale deployment <bcp14>MUST</bcp14> seek Experimental
        status, unless they are not targeted for general use.</t>

<!--[rfced] In the following, we assume that RFC 4614 should remain as
     the cited document even though it has been obsoleted.
     Please note that we have added mention of the obsoleting document
     as well as an Informative References entry for the ease of the
     reader.

Original:
Section 4 of [RFC4614] provides other examples of extensions that were
considered experimental when the specification was
published.

Current:
Section 4 of [RFC4614] provides other examples of extensions that were
considered experimental when the specification was
published (note that [RFC4614] has since been obsoleted by
[RFC7414]).
-->

        <t>Specifications that seek to be published as Experimental IETF Stream RFCs ought to explain the
        reason for the status and what further information would be required
        to progress to
standards track. a Standards Track RFC. For example, section 12 of <xref target="RFC6928"/> target="RFC6928"
        section="12" sectionFormat="of"/> provides
“Usage "Usage and Deployment Recommendations”
        Recommendations" that describe the experiments expected by the TCPM working group. Section 4 of
        Working Group. <xref target="RFC4614"/> target="RFC4614" section="4" sectionFormat="of"/>
        provides other examples of extensions that were considered
        experimental when the specification was published.</t> published (note that <xref target="RFC4614" format="default"/> has since been obsoleted by <xref target="RFC7414" format="default"/>).</t>

        <t>Experimental specifications SHOULD NOT <bcp14>SHOULD NOT</bcp14> be deployed
        as a default. They SHOULD <bcp14>SHOULD</bcp14> only be deployed in
        situations where they are being actively measured, measured and where it is
        possible to deactivate them if there are signs of pathological
        behavior.</t>

<t>Congestion

        <t>Specifications on congestion control algorithms with a record of measured
        Internet-scale deployment MAY <bcp14>MAY</bcp14> directly seek the
        Standards Track status if there is solid data that reflects that it the algorithm is safe, safe
        and the design is stable, guided by the considerations in <xref
        target="general-use"/>. However, the existence of this data does not
        waive the other considerations in this document.</t>
        <t>Each published congestion control algorithm specification submitted for publication as an RFC is REQUIRED
        <bcp14>REQUIRED</bcp14> to include a statement 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 such specification is also REQUIRED <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 is not recommended for use because it does not perform well
        for the user.</t>

<t>As examples

        <t>Examples of such statements, statements exist in <xref target="RFC3649"/> target="RFC3649"/>, which specifies
        HighSpeed TCP and includes a statement in the abstract stating that
        the proposed congestion control algorithm is Experimental, 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 for incremental deployment where some routers forward, 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, documents for publication as Informational RFCs in from the IETF stream 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> Series.</t>

        <t>Although it is out of the scope of for this document, proponents of a new
        algorithm could alternatively seek publication of their specification as an Informational or
        Experimental RFC via the Internet Research Task Force (IRTF). (IRTF) Stream. In
        general, these algorithms are expected to be less mature than ones
        that follow the procedures in this document. document for publication via the IETF Stream. Authors documenting
        deployed congestion control algorithms that cannot be changed by IETF
        or IRTF review are invited to seek publication of their specification as an Informational RFC
        via the Independent Stream Editor (ISE).</t> Submission Stream.</t>
      </section>
    </section>

    <section anchor="controlled-environments"><name>Specifying 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
      environment, an operator can ensure that flows are isolated from other
      Internet flows, 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
      environment that often deploys fabrics with rich signalling signaling from
      switches to endpoints.</t>

      <t>Algorithms that rely on specific functions or configurations in the
      network need to provide a reference or specification for these functions (an
      (such as an RFC or another stable specification). For publication of a specification of one of these algorithms to proceed,
      the IETF will need to assess consider whether a working group exists that can
      properly assess the network-layer aspects and their interaction with the
      congestion control.</t>

<!-- [rfced] For readability, may we update this sentence as follows?

Original:
   In evaluating a new proposal for use in a controlled environment,
   the IETF needs to understand the usage, e.g., how the usage is
   scoped to the controlled environment, whether the algorithm will
   share resources with Internet traffic, and consider what could
   happen if used in a protocol that is bridged across an Internet
   path.

Perhaps:
   In evaluating a new proposal for use in a controlled environment,
   the IETF community needs to understand the usage (e.g., how the usage is
   scoped to the controlled environment), whether the algorithm will
   share resources with Internet traffic, and what could
   happen if used in a protocol that is bridged across an Internet
   path.

-->

      <t>In evaluating a new proposal for use in a controlled environment, the
      IETF needs to understand the usage, e.g., how the usage is scoped to the
      controlled environment, whether the algorithm will share resources with
      Internet traffic, and consider what could happen if used in a protocol
      that is bridged across an Internet path. Algorithms that are designed to
      be confined to a controlled environment and are not intended for use in
      the general Internet, 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>

    <section anchor="evaluation-criteria"><name>Evaluation anchor="evaluation-criteria">
      <name>Evaluation Criteria</name>
      <t>As previously noted, authors of a specification on a congestion control algorithm are expected to conduct a comprehensive
      evaluation of the advantages and disadvantages of any congestion control
      algorithms presented to the IETF. IETF community. The following guidelines are intended
      to assist authors and the
IETF community in this endeavor. While these
      guidelines provide a helpful framework, they should not be regarded as
      an exhaustive checklist, checklist as concerns beyond the scope of these
      guidelines may also arise.</t>

      <t>When considering a proposed congestion control algorithm, the
      community MUST <bcp14>MUST</bcp14> consider the criteria in the following criteria. sections. These
      criteria will be evaluated in various domains (see Sections <xref target="general-use"/>
      target="general-use" format="counter"/> and <xref target="special-cases"/>).</t> target="special-cases"
      format="counter"/>).</t>

      <t>Some of the sections below will list criteria that SHOULD
      <bcp14>SHOULD</bcp14> be met. It could happen that these criteria are not
      not, in fact fact, met by the proposal. In such cases, the community MUST
      <bcp14>MUST</bcp14> document whether not meeting the criteria is
      acceptable, for
example because example, if there are practical limitations on
      carrying out an evaluation of the criteria.</t>

      <t>The requirement that the community consider a criterion does not
      imply that the result needs to be described in a resulting RFC. There an RFC: there is
      no formal requirement to document the results, although normal IETF
      policies for archiving proceedings will provide a record.</t>

<!--[rfced] Does the suggested text capture your intended meaning?

Original:
Instead, the community will use these evaluations as an input when
considering whether to progress the proposed algorithm.

Perhaps:
Instead, the community will use these evaluations as an input when
considering whether to progress the proposed algorithm specification
in the publication process.
-->

      <t>This document, except where otherwise noted, does not provide
      normative guidance on the acceptable thresholds for any of these
      criteria. Instead, the community will use these evaluations as an input
      when considering whether to progress the proposed algorithm.</t>

      <section anchor="single-algorithm-behavior"><name>Single anchor="single-algorithm-behavior">
        <name>Single Algorithm Behavior</name>
        <t>The criteria in this section the following subsections evaluate the congestion control
        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 anchor="protection-against-congestion-collapse"><name>Protection anchor="protection-against-congestion-collapse">
          <name>Protection Against Congestion Collapse</name>

          <t>A congestion control algorithm should either stop sending when
          the packet drop rate exceeds some threshold <xref target="RFC3714"/>,
          target="RFC3714"/> or should include some notion of "full
          backoff". For "full backoff", at some point point, the algorithm would
          reduce the sending rate to one packet per round-trip time and then time; then, it would
          exponentially backoff 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. 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) (and persistent) congestion.</t>

          <t>If full backoff is used, this test does not require that the
          mechanism must be identical to that of TCP (<xref target="RFC6298"/>, (see <xref
          target="RFC6298"/> and <xref target="RFC8961"/>). For example, this
          does not preclude full backoff mechanisms that would give flows with
          different round-
trip round-trip times comparable capacity during backoff.</t>
        </section>

        <section anchor="protection-against-bufferbloat"><name>Protection anchor="protection-against-bufferbloat">
          <name>Protection Against Bufferbloat</name>
          <t>A congestion control algorithm should try to avoid maintaining
          excessive queues in the network. Exactly how the algorithm achieves
          this is algorithm-specific,
but algorithm specific; see <xref target="RFC8961"/> and
          <xref target="RFC8085"/> for requirements.</t>

<t>Bufferbloat <xref target="Bufferbloat"/>

<!-- [rfced] We were unable to find "Reno" explicitly mentioned in RFC
     5681 as seen in the text below:

Original:

   The standards-track Reno [RFC5681] and CUBIC [RFC9438]
   congestion control algorithms send at progressively higher rates
   until a First-In First-Out (FIFO) buffer completely fills...

However, it does appear in RFCs 5681 and 6582 in the reference
below. Should the reference to RFC 5681 be adjusted to [FF96]? [FF96]
is now available at this URL:
https://dl.acm.org/doi/10.1145/235160.235162

From RFC 5681:

   [FF96]    Fall, K. and S. Floyd, "Simulation-based Comparisons of
             Tahoe, Reno and SACK TCP", Computer Communication Review,
             July 1996, ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.

From RFC 6582:

   "For the typical implementation of the TCP fast recovery algorithm
   described in [RFC5681] (first implemented in the 1990 BSD Reno
   release, and referred to as the "Reno algorithm" in [FF96])..."

-->
          <t>"Bufferbloat" refers to the building of excessive queues in the
network.
          network <xref target="BUFFERBLOAT"/>. Many network routers are
          configured with very large buffers. The
standards-track Reno Standards Track RFCs <xref
          target="RFC5681"/> and CUBIC <xref target="RFC9438"/> describing the Reno and CUBIC congestion
          control algorithms (respectively) send at progressively higher rates until a First-In First-Out
          First In, First Out (FIFO) buffer completely fills, and fills; then packet
          losses then 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>This problem has been widely discussed since 2011 <xref target="Bufferbloat"/>,
          target="BUFFERBLOAT"/>, but was not discussed in the Congestion Control Principles congestion
          control principles published in September 2002 <xref
          target="RFC2914"/>. The Reno and CUBIC congestion control algorithms
          do not address this problem, but a new congestion control algorithm
          has the opportunity to improve the state of the art.</t>
        </section>

        <section anchor="protection-against-high-packet-loss"><name>Protection anchor="protection-against-high-packet-loss">
          <name>Protection Against High Packet Loss</name>

          <t>A congestion control algorithm should try to avoid causing
          excessively high rates of packet loss. To accomplish this, it should
          avoid excessive increases in sending rate, rate and reduce its sending
          rate if experiencing high packet loss.</t>

          <t>The first version of the BBR algorithm <xref target="BBRv1-draft"/>
          target="BBRv1"/> failed this requirement.  Experimental
          evaluation <xref target="BBRv1-Evaluation"/> target="BBRv1-EVALUATION"/> showed that it caused a
          sustained rate of packet loss when multiple BBRv1 flows shared a
          bottleneck and the buffer size was less than roughly one and a half
          times the Bandwidth Delay Product (BDP). This was unsatisfactory, and indeed
          and, indeed, further versions provided a fix for this aspect of BBR
          <xref target="BBR-draft"/>.</t> target="I-D.cardwell-iccrg-bbr-congestion-control"/>.</t>

          <t>This requirement does not imply that the algorithm should react
          to packet losses in exactly the same way as current standards-track congestion control algorithms described in current Standards Track RFCs (e.g., <xref target="RFC5681"/>).</t>
        </section>

        <section anchor="fairness-within-the-proposed-congestion-control-algorithm"><name>Fairness within anchor="fairness-within-the-proposed-congestion-control-algorithm">
          <name>Fairness Within the Proposed Congestion Control Algorithm</name>
          <t>When multiple competing flows all use the same proposed
          congestion control algorithm, the proposal specification 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, rates or if some of
          the flows do not last sufficiently long to approach asymptotic
          behavior.</t>
        </section>

        <section anchor="short-flows"><name>Short anchor="short-flows">
          <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. 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 proposed congestion control algorithm MUST <bcp14>MUST</bcp14>
          consider how new and short-lived flows affect long-lived flows, and
          vice versa.</t>
        </section>
      </section>

      <section anchor="mixed-algorithm-behavior"><name>Mixed anchor="mixed-algorithm-behavior">
        <name>Mixed Algorithm Behavior</name>

<t>Mixed
        <t>The mixed algorithm behavior criteria evaluate the interaction of the
        proposed congestion control algorithm algorithms being specified with commonly deployed
        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 previous standards-track algorithms published in previous 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 ought also
        ought to consider metrics such as the introduced latency, latency or an
        increase in packet loss.  An evaluation MUST <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 anchor="existing-general-purpose-congestion-control"><name>Existing anchor="existing-general-purpose-congestion-control">
          <name>Existing General-Purpose Congestion Control</name>
          <t>A proposed congestion control algorithm MUST <bcp14>MUST</bcp14> be
          evaluated when competing against standard IETF congestion controls, e.g. controls
          (e.g., <xref target="RFC5681"/>, <xref target="RFC9002"/>, and <xref target="RFC9438"/>.
          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>Note that this guideline is not a requirement for strict Reno- Reno or CUBIC-
          CUBIC friendliness as a prerequisite for a proposed congestion
          control mechanism to advance to Experimental or Standards Track
          status. As an example, HighSpeed TCP is a congestion control
          mechanism specified as Experimental, that is specified in an Experimental RFC and is not TCP- TCP friendly
          in all environments. When a new congestion control algorithm is
          deployed, the existing major algorithm deployments need to be
          considered to avoid severe performance degradation. Note that this
          guideline does not constrain the interaction with non-best-effort flows.</t> flows that are not
          best effort.</t>

          <t>As an example from an Experimental RFC, fairness with standard
          TCP is discussed in Sections 4 <xref target="RFC3649"
          sectionFormat="bare" section="4"/> and 6 <xref target="RFC3649"
          sectionFormat="bare" section="6"/> of <xref target="RFC3649"/> (HighSpeed TCP) target="RFC3649"
          format="default"/>, and using spare capacity is
          discussed in Sections 6, 11.1, <xref target="RFC3649" sectionFormat="bare"
          section="6"/>, <xref target="RFC3649" sectionFormat="bare"
          section="11.1"/>, and 12 <xref target="RFC3649" sectionFormat="bare"
          section="12"/> of <xref target="RFC3649"/>.</t>
        </section>

        <section anchor="real-time-congestion-control"><name>Real-Time anchor="real-time-congestion-control">
          <name>Real-Time Congestion Control</name>

          <t>General-purpose algorithms need to coexist in the Internet with
          real-time congestion control algorithms, which, which in general, general have
          finite throughput requirements (i.e., they do not seek to utilize all
          available capacity) and more strict latency bounds. See <xref
          target="RFC8836"/> for a description of the characteristics of this
          use case and the resulting requirements.</t>

          <t><xref target="RFC8868"/> provides suggestions for real-time
          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 (acknowledgement) (acknowledgment) than that provided by
          reliable transports.  This document does not change the informational
          Informational status of those RFCs.</t>

          <t>A proposed congestion control algorithm SHOULD <bcp14>SHOULD</bcp14>
          consider coexistence with widely deployed real-time congestion
          control algorithms. Regrettably, at the time of writing (2024), many
          algorithms with detailed public specifications are not widely
          deployed, while many widely deployed real-time congestion control
          algorithms have incomplete public specifications. It is hoped that
          this situation will change.</t>

          <t>To the extent that behavior of widely deployed algorithms is
          understood, proponents of a proposed congestion control algorithm
          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>Real-time flows can be directed into distinct queues via
          Differentiated Services Code Points (DSCP) (DSCPs) or other mechanisms,
          which can substantially reduce the interplay with other
          traffic. However, a proposal targeting general Internet use
can not cannot
          assume this is always the case.</t>

          <t><xref target="circuit-breakers"/> describes the impact of network
          transport circuit breaker algorithms. <xref target="RFC8083"/> also
          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="short-and-long-flows"><name>Short 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 MUST <bcp14>MUST</bcp14> be evaluated, as
          in <xref target="short-flows"/>.</t>
        </section>
      </section>

      <section anchor="other-criteria"><name>Other anchor="other-criteria">
        <name>Other Criteria</name>
        <section anchor="differences-with-congestion-control-principles"><name>Differences anchor="differences-with-congestion-control-principles">
          <name>Differences with Congestion Control Principles</name>
          <t>A proposed congestion control algorithm MUST <bcp14>MUST</bcp14>
          clearly explain any deviations from <xref target="RFC2914"/> and
          <xref target="RFC7141"/>.</t>
        </section>

        <section anchor="incremental-deployment"><name>Incremental anchor="incremental-deployment">
          <name>Incremental Deployment</name>
          <t>A congestion control algorithm proposal MUST <bcp14>MUST</bcp14>
          discuss whether it allows for incremental deployment in the targeted
          environment. For a mechanism targeted for deployment in the current
          Internet, the proposal SHOULD <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., Internet (e.g., routers,
          transparent proxies, WAN optimizers, intrusion detection systems,
          home routers, and the like.</t> like).</t>
          <t>Similarly, if the proposed congestion control algorithm is
          intended only for specific environments (and not the global
          Internet), the proposal SHOULD <bcp14>SHOULD</bcp14> consider how this
          intention is to be realised. realized.  The IETF community will have to address the
          question of whether the scope can be enforced by stating the
restrictions,
          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 10.3 <xref target="RFC4782" section="10.3"
          sectionFormat="bare"/> and 10.4 <xref target="RFC4782" section="10.4"
          sectionFormat="bare"/> of <xref target="RFC4782"/> (Quick-Start).</t> target="RFC4782"/>.</t>
        </section>
      </section>
    </section>

    <section anchor="general-use"><name>General anchor="general-use">
      <name>General Use</name>
      <t>The criteria in <xref target="evaluation-criteria"/> will be
      evaluated in the scenarios described in the following
scenarios. subsections. Unless a proposed congestion
      control algorithm specification of the IETF Stream explicitly forbids use on the public Internet,
      there MUST <bcp14>MUST</bcp14> be IETF consensus that it meets the criteria
      in these scenarios for the proposed congestion control algorithm to
      progress.</t>

      <t>The evaluation in of each scenario SHOULD <bcp14>SHOULD</bcp14> occur over a
      representative range of bandwidths, delays, and queue depths. Of course,
      the set of parameters representative of the public Internet will change
      over time.</t>

      <t>These criteria are intended to capture a statistically dominant set
      of Internet conditions. In the case that a proposed congestion control
      algorithm has been tested at Internet scale, the results from that
      deployment are often useful for answering these questions.</t>

      <section anchor="paths-with-tail-drop-queues"><name>Paths anchor="paths-with-tail-drop-queues">
        <name>Paths with Tail-drop Tail-Drop Queues</name>
        <t>The performance of a congestion control algorithm is affected by
        the queue discipline applied at the bottleneck link. The drop-tail
        queue discipline (using a FIFO buffer) MUST <bcp14>MUST</bcp14> be
        evaluated. See <xref target="aqm"/> for evaluation of other queue
        disciplines.</t>
      </section>

      <section anchor="tunnel-behavior"><name>Tunnel anchor="tunnel-behavior">
        <name>Tunnel Behavior</name>
        <t>When a proposed congestion control algorithm relies on explicit
        signals from the path, the proposal MUST <bcp14>MUST</bcp14> consider the
        effect of traffic passing through a tunnel, where routers may not be
        aware of the flow.</t>

<t>The design
<!-- Updated I-D.ietf-tsvwg-ecn-encap-guidelines to RFC 9599 -->
        <t>Designers of tunnels and similar encapsulations might need to
        consider nested congestion control interactions. For interactions, for example, when ECN the
        Explicit Congestion Notification (ECN) is used by both an IP and lower layer lower-layer technology <xref target="ECN-Encaps"/>.</t> target="RFC9599"/>.</t>
      </section>

      <section anchor="wired-paths"><name>Wired anchor="wired-paths">
        <name>Wired Paths</name>
        <t>Wired networks are usually characterized by extremely low rates of
        packet loss except for those due to queue drops. They tend to have
        stable aggregate capacity, usually higher than other types of links,
        and low non-queueing delay.  Because the properties are relatively
        simple, wired links are typically used as a "baseline" case even if
        they are not always the bottleneck link in the modern Internet.</t>
      </section>

      <section anchor="wireless-paths"><name>Wireless anchor="wireless-paths">
        <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, effects rather than router queue drops; the drops. The link capacity
        varies over time due to changing link conditions; conditions, and media access 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="Tools"/>
        target="I-D.irtf-tmrg-tools"/> for further discussion of wireless
        properties.</t>
      </section>
    </section>

    <section anchor="special-cases"><name>Special anchor="special-cases">
      <name>Special Cases</name>
      <t>The criteria in <xref target="evaluation-criteria"/> will be
      evaluated in the scenarios described in the following
scenarios, subsections, unless the proposed congestion
      control algorithm specifically excludes its use in a scenario. For these
      specific use-cases, use cases, the IETF community MAY <bcp14>MAY</bcp14> allow a proposal to
      progress even if the criteria indicate an unsatisfactory result for
      these scenarios.</t>

      <t>In general, measurements from Internet-scale deployments might not
      expose the properties of operation in each of these scenarios, scenarios because
      they are not as ubiquitous as the General Use general-use scenarios.</t>

      <section anchor="aqm"><name>Active anchor="aqm">
        <name>Active Queue Management (AQM)</name>
        <t>The proposed congestion control algorithm SHOULD <bcp14>SHOULD</bcp14> be
        evaluated under a variety of
bottleneck queue 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>Among

<!-- [rfced] FYI - We have reworked the text below into a bulleted
     list for ease of the reader and updated to use didactic
     caps. Please review and let us know any objections.

Original:

   Among the AQM techniques that might have an impact on a proposed
   congestion control algorithm are Flow Queue CoDel (FQ-CoDel) <xref target="RFC8290"/>;
   [RFC8290]; Proportional Integral Controller Enhanced (PIE) <xref target="RFC8033"/>; [RFC8033];
   and Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332].

Current:

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

   *  Flow Queue CoDel (FQ-CoDel) [RFC8290];

   *  Proportional Integral controller Enhanced (PIE) [RFC8033]; and

   *  Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332].

-->

        <t>Some of the AQM techniques that might have an impact on a proposed
        congestion control algorithm include:</t>
	<ul>
	  <li>Flow Queue CoDel (FQ-CoDel) <xref target="RFC9332"/>.</t>

<t>A target="RFC8290"/>;</li>
	  <li>Proportional Integral controller Enhanced (PIE) <xref target="RFC8033"/>; and</li>
	  <li>Low Latency, Low Loss, and Scalable Throughput (L4S) <xref target="RFC9332"/>.</li>
	</ul>

<!-- [rfced] We note that ECT is most often expanded to "ECN-Capable
     Transport (ECT)" (as was done in normative reference RFC 9902).
     Would you like to update this expansion to match the usage in
     RFC 9902?

Original:
   A proposed congestion control algorithm that sets one of the two
   Explicit Congestion Transport (ECT) codepoints in the IP header can
   gain the benefits of receiving Explicit Congestion Notification (ECN)
   Congestion Experienced (CE) signals from an on-path AQM [RFC8087].

Perhaps:
   A proposed congestion control algorithm that sets one of the two
   ECN-Capable Transport (ECT) codepoints in the IP header can gain the
   benefits of receiving Explicit Congestion Notification-Congestion
   Experienced (ECN-CE) signals from an on-path AQM [RFC8087].

-->

        <t>A proposed congestion control algorithm that sets one of the two
        Explicit Congestion 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"/>, target="RFC3168"/>
        and <xref target="RFC9332"/> 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>Note that evaluation of AQM techniques -- as opposed to their
        impact on a specific proposed congestion control algorithm -- is out
        of scope of this document. <xref target="RFC7567"/> describes design
        considerations for AQMs.</t>
      </section>

      <section anchor="circuit-breakers"><name>Operation anchor="circuit-breakers">
        <name>Operation with the Envelope set 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, and 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, and therefore resources; therefore, it will operate
        within the envelope set by network transport circuit breaker
        algorithms.</t>
      </section>

      <section anchor="delay"><name>Paths anchor="delay">
        <name>Paths with Varying Delay</name>

        <t>An Internet Path path can include simple links, where the minimum delay
        is the propagation delay, and any additional delay can be attributed
        to link buffering.  This cannot be assumed. An Internet Path path can also
        include complex subnetworks where the minimum delay changes over
        various time scales, resulting in a non-
stationary minimum delay.</t> delay that is not stationary.</t>

        <t>Varying delay occurs when a subnet changes the forwarding path to optimise
        optimize capacity, resilience, etc. It could also arise when a subnet
        uses a capacity management capacity-management method where the available resource is
        periodically distributed among the active nodes. A node might then
        have to buffer data until an assigned transmission opportunity or
        until the physical path changes (e.g., when the length of a wireless
        path changes, changes or when the physical layer changes its mode of operation).
        Variation also arises when traffic with a higher priority DSCP pre-empts
        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 SHOULD <bcp14>SHOULD</bcp14> be
        evaluated to ensure its operation is robust when there is a
        significant change in the minimum delay.</t>
      </section>

      <section anchor="internet-of-things-and-constrained-nodes"><name>Internet anchor="internet-of-things-and-constrained-nodes">
        <name>Internet of Things and Constrained Nodes</name>
        <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: 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>Extremely low-power links can lead to very low throughput and a low bandwidth-
delay
        bandwidth-delay product, which is well below the standard operating
        range of most Internet flows.</t>

        <t>Furthermore, many IoT applications do not a have a human in the loop, and
therefore
        loop; therefore, they might have weaker latency constraints because they
        do not relate to a user experience. Congestion control algorithm can algorithms
        still may need to share the path with other flows with different
        constraints.</t>
      </section>

      <section anchor="paths-with-high-delay"><name>Paths anchor="paths-with-high-delay">
        <name>Paths with High Delay</name>

        <t>A proposed congestion control algorithm ought not to presume 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 high-delay-bandwidth products <xref
        target="RFC3649"/>.</t>

        <t>Paths can also present a variable delay as described in <xref
        target="delay"/>.</t>
      </section>

      <section anchor="misbehaving-nodes"><name>Misbehaving anchor="misbehaving-nodes">
        <name>Misbehaving Nodes</name>
        <t>A proposed congestion control algorithm SHOULD <bcp14>SHOULD</bcp14>
        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>As

<!-- [rfced] FYI - For readability, we have reformatted the text below to read
as a bulleted list. Please review and let us know any objections.

Original:

   As an example from an Experimental RFC, performance with misbehaving
   nodes and outside attackers is discussed in Sections 9.4, 9.5, and
   9.6 of <xref target="RFC4782"/>. [RFC4782].  This includes discussion of misbehaving senders
   and receivers; collusion between misbehaving routers; misbehaving
   middleboxes; and the potential use of Quick- Start to attack routers
   or to tie up available Quick-Start bandwidth.</t> bandwidth.

Current:

   As an example from an Experimental RFC, performance with misbehaving
   nodes and outside attackers is discussed in Sections 9.4, 9.5, and
   9.6 of [RFC4782].  This includes discussion of:

   *  misbehaving senders and receivers;

   *  collusion between misbehaving routers;

   *  misbehaving middleboxes; and

   *  the potential use of Quick-Start to attack routers or to tie up
      available Quick-Start bandwidth.

-->

        <t>As an example from an Experimental RFC, performance with
        misbehaving nodes and outside attackers is discussed in Sections <xref
        target="RFC4782" section="9.4" sectionFormat="bare"/>, <xref
        target="RFC4782" section="9.5" sectionFormat="bare"/>, and <xref
        target="RFC4782" section="9.6" sectionFormat="bare"/> of <xref
        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>

      <section anchor="extreme-packet-reordering"><name>Extreme anchor="extreme-packet-reordering">
        <name>Extreme Packet Reordering</name>
        <t>A proposed congestion control algorithm ought not to presume that
        all general Internet paths reliably deliver packets in order. <xref
        target="RFC4653"/> discusses the effect of extreme packet
        reordering.</t>
      </section>

      <section anchor="transient-events"><name>Transient anchor="transient-events">
        <name>Transient Events</name>
        <t>A proposed congestion control algorithm SHOULD <bcp14>SHOULD</bcp14>
        consider how the proposed
congestion control algorithm it  would perform
        in the presence of transient events such as a sudden onset of
        congestion, a routing change, or a mobility event.  Routing changes,
        link disconnections, intermittent link connectivity, and mobility are
        discussed in more detail in Section 16 of <xref target="Tools"/>.</t>
        target="I-D.irtf-tmrg-tools"/>.</t>

        <t>As an example from an Experimental RFC, a response to transient
        events is discussed in <xref section="9.2" sectionFormat="of"
        target="RFC4782"/>.</t>
      </section>

      <section anchor="sudden-changes-in-the-path"><name>Sudden changes anchor="sudden-changes-in-the-path">
        <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 proposed congestion control algorithm MUST
        <bcp14>MUST</bcp14> evaluate the impact of changes in the path, path and be
        robust to changes in path characteristics on the interval of common
        Internet re-routing rerouting intervals.</t>
      </section>

      <section anchor="multipath-transport"><name>Multipath anchor="multipath-transport">
        <name>Multipath Transport</name>
        <t>Multipath transport protocols permit more than one path to be
        differentiated and used by a single connection at the sender. A
        multipath sender can schedule which packets travel on which of its
        active paths. This enables a tradeoff trade-off in timeliness and
        reliability. There are various ways that multipath techniques can be
        used.</t>

        <t>One example use is to provide fail-over failover from one path to another
        when the original path is no longer viable, viable or provides inferior
        performance.  Designs need to independently track the congestion state
        of each path, path and demonstrate independent congestion control for each
        path being used. Authors of a proposed multipath congestion control
        algorithm that implements path fail-over MUST failover <bcp14>MUST</bcp14> evaluate
        the harm to performance resulting from a change in the path, path and show
        that this does not result in flow starvation. Synchronisation Synchronization of
        failover (e.g., where multiple flows change their path on similar timeframes)
        time frames) 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 simultaneously schedules a flow to aggregate the capacity
        across multiple paths.  The Internet provides no guarantee that
        different paths (e.g., using different endpoint addresses) are
        disjoint. This introduces additional implications: implications. A congestion
        control algorithm proposal MUST <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). limit. A proposal
SHOULD
        <bcp14>SHOULD</bcp14> consider the potential for harm to other
        flows. Synchronisation Synchronization of congestion control mechanisms (e.g., where
        multiple flows change their behaviour behavior on similar timeframes) time frames) 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 for concurrent multipath, but there is an Experimental RFC
        <xref target="RFC6356"/> that specifies a concurrent multipath
        congestion control algorithm for MPTCP Multipath TCP (MPTCP) <xref target="RFC8684"/>.</t>
      </section>

      <section anchor="data-centers"><name>Data anchor="data-centers">
        <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
signalling
        signaling from switches to endpoints. Furthermore, the operator can
        often limit the number of operating congestion control algorithms.</t>

        <t>For these reasons, data center congestion controls are often
        distinct from those running elsewhere on the Internet (see <xref
        target="controlled-environments"/>).  A proposed congestion control
        need not coexist well with all other algorithms if it is intended for
        data centers, but the proposal SHOULD <bcp14>SHOULD</bcp14> indicate which
        are expected to safely coexist with it.</t>
      </section>
    </section>

    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document does not represent a change to any aspect of the TCP/IP
      protocol
suite and therefore 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>Proposed congestion control algorithms MUST <bcp14>MUST</bcp14> examine
      any potential security or privacy issues that may arise from their
      design.</t>
    </section>

    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="RFC2914">
  <front>
    <title>Congestion Control Principles</title>
    <author fullname="S. Floyd" initials="S." surname="Floyd"/>
    <date month="September" year="2000"/>
    <abstract>
      <t>The goal of this document is to explain the need for congestion control in

<!-- [rfced] We had the Internet, and following additional questions related to discuss what constitutes correct congestion control. 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="41"/>
  <seriesInfo name="RFC" value="2914"/>
  <seriesInfo name="DOI" value="10.17487/RFC2914"/>
</reference>

<reference anchor="RFC8085">
  <front>
    <title>UDP Usage Guidelines</title>
    <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 transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels,
     references and other 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 Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
      <t>Because congestion control is critical to the stable operation of citations in the Internet, 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 document:

a.) [BUFFERBLOAT] Would you like to implement 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 these 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 following URL 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 scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple 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 specification to the Standards Track
reference (as this URL has a DOI and obsoletes RFC 8312. This document also updates RFC 5681, to allow for CUBIC's occasionally more aggressive sending behavior.</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 document defines these words as they should be interpreted in IETF documents. 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="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 specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE 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 ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms open access PDF)?

https://dl.acm.org/doi/10.1145/2063166.2071893

b.) FYI - We have been designed to detect loss, ultimately, protocols can only count on added the passage of time without delivery confirmation following RFCs to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness; therefore, no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. Within the requirements, implementations have 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 algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, Informative
References section, as well as discussing various acknowledgment generation methods. 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 mechanisms 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 Sessions</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, video conferencing, and telepresence applications. Such applications they are often run on best-effort UDP/IP networks. If congestion control is not implemented included in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows.</t>
      <t>This document does text but were not propose a congestion control algorithm. It instead 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 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. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.</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 dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), and newer schemes such
cited as CoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond references.

-->

  <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.2914.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9438.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8961.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9002.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7141.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8084.xml"/>
      </references>
      <references>
        <name>Informative References</name>

<!-- [-00] [BBRv1] [I-D.cardwell-iccrg-bbr-congestion-control]
Note to congestion indications, (2) packet size should not be taken into account when network equipment creates 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. PE: This memo updates RFC 2309 to deprecate deliberate preferential 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 Circuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels 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 first version 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'> [BBRv1]. -->

	<reference anchor="BBR-draft"> anchor="BBRv1" target="https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-00">
	  <front>
	    <title>BBR Congestion Control</title>
	    <author fullname="Neal Cardwell" initials="N." surname="Cardwell"> surname="Cardwell" fullname="Neal Cardwell">
	      <organization>Google</organization>
	    </author>
	    <author fullname="Yuchung Cheng" initials="Y." surname="Cheng"> surname="Cheng" fullname="Yuchung 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 recent
   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 surname="Yeganeh" fullname="Soheil Hassas Yeganeh" initials="S. H." surname="Yeganeh">
         <organization>Google, Inc</organization> Yeganeh">
	      <organization>Google</organization>
	    </author>
	    <author fullname="Van Jacobson" initials="V." surname="Jacobson">
         <organization>Google, Inc</organization> surname="Jacobson" fullname="Van Jacobson">
	      <organization>Google</organization>
	    </author>
	    <date day="3" month="July" day="3" 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 Encapsulate IP</title>
      <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
         <organization>Independent</organization>
      </author>
      <author fullname="John Kaippallimalil" initials="J." surname="Kaippallimalil">
         <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

<!--  [-02] [BBR-DRAFT] [I-D.cardwell-iccrg-bbr-congestion-control] -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-cardwell-iccrg-bbr-congestion-control-02.xml"/>

<!-- [ECN-ENCAPS] I-D was published 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 RFC9599. Replaced I-D with a reference to the whole of this document.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-ecn-encap-guidelines-22"/>

</reference> RFC 9599. -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9599.xml"/>

<!-- [HRX08] -->
        <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>
              <organization/>
            </author>
            <author initials="I." surname="Rhee" fullname="Injong Rhee">
      <organization></organization>
              <organization/>
            </author>
            <author initials="L." surname="Xu" fullname="Lisong Xu">
      <organization></organization>
              <organization/>
            </author>
            <date year="2008" month="July"/>
          </front>
  <seriesInfo name="ACM
          <refcontent>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-tmrg-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> 64-74</refcontent>
	  <seriesInfo name="Work in Progress" value=""/> name="DOI" value="10.1145/1400097.1400105"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-irtf-tmrg-tools-05.xml"/>

        <reference anchor="Bufferbloat" anchor="BUFFERBLOAT" target="https://queue.acm.org/detail.cfm?id=2071893">
          <front>
            <title>Bufferbloat: Dark Buffers in the Internet</title>
            <author initials="" surname="Kathleen Nichols">
      <organization></organization> initials="K." surname="Nichols">
              <organization/>
            </author>
            <author initials="J." surname="Gettys">
              <organization/>
            </author>
            <date month="November" year="2011"/>
          </front>
  <seriesInfo name="ACM
          <refcontent>ACM Queue Volume 9, Issue 11" value=""/> 11</refcontent>
        </reference>

<!-- [BBRv1-EVALUATION] -->
        <reference anchor="BBRv1-Evaluation" anchor="BBRv1-EVALUATION" target="https://ieeexplore.ieee.org/document/8117540">
          <front>
            <title>Experimental evaluation of BBR congestion control</title>
             <author initials="M." surname="Hock">
              <organization/>
            </author>
            <author initials="R." surname="Bless">
              <organization/>
            </author>
            <author initials="M." surname="Zitterbart">
      <organization></organization>
              <organization/>
            </author>
            <date year="2017"/>
          </front>
  <seriesInfo name="2017
          <refcontent>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 to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within 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 side. 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 provides a specification of CUBIC to enable third-party implementations and to solicit 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 Networks</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 applications typically depends on a well-functioning congestion control algorithm. To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types. This document 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 initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) 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 Documents</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) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This memo provides information for the Internet 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 deployed 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 alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, 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 average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. 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 protocols, 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 unused 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-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming 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 and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental 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 Not 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 which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers.</t>
      <t>This document contains that catalog and analysis.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9049"/> (ICNP)</refcontent>
	  <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 that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" 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 been produced through discussions and consultation within the IETF but is not the product 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 Internet</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 congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality 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 relied upon to give acceptable performance for VoIP. We are merely observing that voice 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 this best-effort voice traffic. This memo provides information for the Internet community.</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 retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades 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</title>
    <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 Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer 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 ensure that this kind of traffic is congestion controlled.</t>
      <t>This document describes a set of requirements that can be used to evaluate 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 telephony and video conferencing applications. This document describes the guidelines 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-Time 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 multimedia telephony applications. These applications are typically required to implement 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 in 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 be sent using the RTP Control Protocol (RTCP) and the suitability of RTCP for implementing 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 (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet. 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="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 Algorithm</title>
    <author fullname="T. Hoeiland-Joergensen" initials="T." surname="Hoeiland-Joergensen"/>
    <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 Queue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.</t>
      <t>FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short, and it can be implemented in a memory- and CPU-efficient fashion 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 Control 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 cause 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 performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users.</t>
      <t>This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value. Simulation results, theoretical analysis, and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design 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 Management (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for the Internet to transition from the scaling problems of standard TCP-Reno-friendly ('Classic') congestion controls to the family of 'Scalable' congestion controls. These are designed for consistently very low queuing latency, very low congestion loss, and scaling of per-flow throughput by using Explicit Congestion Notification (ECN) in a modified way. Until 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 private data centres.</t>
      <t>This specification first explains how a Coupled DualQ works. It then gives 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 AQMs 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 applications using a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced 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">
  <front>
    <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 Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3168"/>
  <seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>

<reference anchor="RFC7567">
  <front>
    <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="Fairhurst"/>
    <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 recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.</t>
      <t>Based on 15 years of experience and new research, this document replaces 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">
  <front>
    <title>Enhancing TCP Over Satellite Channels using Standard Mechanisms</title>
    <author fullname="M. Allman" initials="M." surname="Allman"/>
    <author fullname="D. Glover" initials="D." surname="Glover"/>
    <author fullname="L. Sanchez" initials="L." surname="Sanchez"/>
    <date month="January" year="1999"/>
    <abstract>
      <t>The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. 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="28"/>
  <seriesInfo name="RFC" value="2488"/>
  <seriesInfo name="DOI" value="10.17487/RFC2488"/>
</reference>

<reference anchor="RFC4653">
  <front>
    <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 arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. This memo defines an Experimental Protocol for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4653"/>
  <seriesInfo name="DOI" value="10.17487/RFC4653"/>
</reference>

<reference anchor="RFC6356">
  <front>
    <title>Coupled Congestion Control for Multipath Transport Protocols</title>
    <author fullname="C. Raiciu" initials="C." surname="Raiciu"/>
    <author fullname="M. Handley" initials="M." surname="Handley"/>
    <author fullname="D. Wischik" initials="D." surname="Wischik"/>
    <date month="October" year="2011"/>
    <abstract>
      <t>Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.</t>
      <t>New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath 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, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall 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 increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6356"/>
  <seriesInfo name="DOI" value="10.17487/RFC6356"/>
</reference>

<reference anchor="RFC8684">
  <front>
    <title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
    <author fullname="A. Ford" initials="A." surname="Ford"/>
    <author fullname="C. Raiciu" initials="C." surname="Raiciu"/>
    <author fullname="M. Handley" initials="M." surname="Handley"/>
    <author fullname="O. Bonaventure" initials="O." surname="Bonaventure"/>
    <author fullname="C. Paasch" initials="C." surname="Paasch"/>
    <date month="March" year="2020"/>
    <abstract>
      <t>TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.</t>
      <t>Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.</t>
      <t>This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8684"/>
  <seriesInfo name="DOI" value="10.17487/RFC8684"/>
</reference>

<reference anchor="RFC5166">
  <front>
    <title>Metrics for the Evaluation of Congestion Control Mechanisms</title>
    <author fullname="S. Floyd" initials="S." role="editor" surname="Floyd"/>
    <date month="March" year="2008"/>
    <abstract>
      <t>This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.</t>
      <t>This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5166"/>
  <seriesInfo name="DOI" value="10.17487/RFC5166"/> value="10.1109/ICNP.2017.8117540"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5033.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8312.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8869.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6928.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4614.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3649.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4782.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9049.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8799.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3714.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6298.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8836.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8868.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8867.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9392.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3819.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8290.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8033.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9332.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8087.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2488.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4653.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6356.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7414.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8684.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5166.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8257.xml"/>

      </references>
    </references>

<?line 824?>

    <section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>

<t>Sally Floyd anchor="acknowledgments">
      <name>Acknowledgments</name>

      <t><contact fullname="Sally Floyd"/> and Mark Allman <contact fullname="Mark
      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 Richard Scheffenegger <contact fullname="Richard Scheffenegger"/> for helping to
      get this revision process started.</t>
      <t>The editors would like to thank Mohamed Boucadair, Neal Cardwell, Reese
Enghardt, Jonathan Lennox, Matt Mathis, Zahed Sarker, Juergen Schoenwaelder,
Dave Taht, Sean Turner, Michael Welzl, Magnus Westerlund, <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 Greg White <contact
      fullname="Greg White"/> for suggesting improvements to this
      document.</t>
      <t>Discussions with Lars Eggert <contact fullname="Lars Eggert"/> and Aaron Falk <contact
      fullname="Aaron Falk"/> seeded the original RFC5033. Bob
Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, Colin Perkins, Pekka
Savola, <xref target="RFC5033"/>. <contact
      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" anchor="evolution-of-rfc5033bis"><name>Evolution of RFC5033bis</name>

<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-06"><name>Since 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>Since 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>Since draft-ietf-ccwg-rfc5033bis-04</name>
<t><list style="symbols">
  <t>Editorial pass after shepherd review.</t>
</list></t> toc="include" removeInRFC="false">
      <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>
<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-03"><name>Since draft-ietf-ccwg-rfc5033bis-03</name>
<t><list style="symbols">
  <t>Harmonised
  </back>

<!--[rfced] Note that we have cut the "Evolution of RFC5033bis"
     section.  Generally, change logs only exist in published RFCs in
     obsoleting documents as a "Changes Since RFC ####" section, which
     highlights the substantive changes that took place between the
     last published RFC and this one (i.e., mentions errata addressed or
     a security consideration that has changed, etc.).  If the section
     should be kept, may we suggest something like:

Perhaps:
Changes Since RFC 5033

   *  Harmonized the "proposed congestion control algorithm"</t>
  <t>Addressed issues.</t>
  <t>Examined RFC-2119 algorithm"

   *  Examined BCP 14 keywords and consistency with other RFCs.</t>
  <t>Added RFCs

   *  Added text on constrained environments/limited domains</t>
  <t>Added text on domains and 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>Since draft-ietf-ccwg-rfc5033bis-02</name>

<t><list style="symbols">
  <t>Added RFCs

   *  Added discussion of real-time protocols</t>
  <t>Added discussion of protocols, short flows</t>
  <t>Listed flows, AQM response,
      multipath transports

   *  Listed properties of wired networks</t>
  <t>Added networks

   *  Added sections addressing IoT section</t>
  <t>Added discussion and Multicast (noting this is out of AQM response</t>
  <t>Rewrote scope)

   *  Rewrote the "Document Status" section</t>
  <t>Adding section

   *  Added improved first sentence of abstract 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>Since draft-ietf-ccwg-rfc5033bis-01</name>

<t><list style="symbols">
  <t>Added discussion of multipath transports</t>
  <t>Totally reorganized Introduction

   *  Reorganized central sections of the draft</t>
</list></t>

</section>
<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-00"><name>Since draft-ietf-ccwg-rfc5033bis-00</name>

<t><list style="symbols">
  <t>Added document

   *  Added QUIC, other congestion control standards</t>
  <t>Added standards

   *  Added wireless environments</t>
  <t>Aligned environments

   *  Aligned motivation for this work with the CCWG charter</t>
  <t>Refined charter

   *  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 Quick-Start

   *  Included updated text suggested by Dave Taht</t>
  <t>Added Taht

   *  Added criterion for bufferbloat</t>
  <t>Mentioned bufferbloat

   *  Mentioned CUBIC and BBR as motivation</t>
  <t>Include section to track motivation

-->

<!--[rfced] We note that there are a number of instances in which an
     algorithm or a proposed algorithm takes on human abilities.
     Please review the text with this in mind and let us know if any
     updates between revisions</t>
  <t>Update references</t>
</list></t>

</section>
<section numbered="false" anchor="since-rfc5033"><name>Since RFC5033</name>

<t><list style="symbols">
  <t>converted to Markdown and xml2rfc v3</t>
  <t>various formatting changes.</t>
</list></t>

</section>
</section>

    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
        <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>

  </back> should be made.  Some examples below (not exhaustive):

Original:
A proposed congestion control algorithm SHOULD explore...

Perhaps:
A proposal for a congestion control algorithm SHOULD explore...

Original:
A proposed congestion control algorithm ought not to presume...

Perhaps:
Authors of a proposed congestion control algorithm ought not to presume...

Original:
A proposed congestion control algorithm MUST clearly explain any
deviations from [RFC2914] and [RFC7141].

Perhaps:
A proposal for a congestion control algorithm MUST clearly explain any
deviations from [RFC2914] and [RFC7141].
-->

<!-- ##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= [rfced] FYI - We have added expansions for abbreviations upon
     first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
     review each expansion in the document carefully to ensure
     correctness.

Explicit Congestion Notification (ECN)
Multipath TCP (MPTCP)

-->

<!-- [rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed.  Updates of this
     nature typically result in more precise language, which is
     helpful for readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->

</rfc>