<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" 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" xml:lang="en" prepTime="2025-03-12T15:37:45" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-ccwg-rfc5033bis-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9743" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="New CC Algorithms">Specifying New Congestion Control Algorithms</title>
    <seriesInfo name="RFC" value="9743" stream="IETF"/>
    <seriesInfo name="BCP" value="133" stream="IETF"/>
    <author initials="M." surname="Duke" fullname="Martin Duke" role="editor">
      <organization showOnFrontPage="true">Google LLC</organization>
      <address>
        <email>martin.h.duke@gmail.com</email>
      </address>
    </author>
    <author initials="G." surname="Fairhurst" fullname="Godred Fairhurst" role="editor">
      <organization showOnFrontPage="true">University of Aberdeen</organization>
      <address>
        <email>gorry@erg.abdn.ac.uk</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>WIT</area>
    <workgroup>ccwg</workgroup>
    <keyword>Transport</keyword>
    <keyword>CC</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">RFC 5033 discusses the principles and guidelines for standardizing
      new congestion control algorithms.  This document obsoletes RFC 5033 to
      reflect changes in the congestion control landscape by providing a
      framework for the development and assessment of congestion control
      mechanisms, promoting stability across diverse network paths.  This
      document seeks to ensure that proposed congestion control algorithms
      operate efficiently and without harm when used in the global Internet.
      It emphasizes the need for comprehensive testing and validation to
      prevent adverse interactions with existing flows.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This memo documents an Internet Best Current Practice.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further information
            on BCPs is available in Section 2 of RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9743" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specification-of-requiremen">Specification of Requirements</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidelines-for-authors">Guidelines for Authors</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-evaluation-guidelines">Evaluation Guidelines</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-document-status-guidelines">Document-Status Guidelines</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specifying-algorithms-for-u">Specifying Algorithms for Use in Controlled Environments</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-evaluation-criteria">Evaluation Criteria</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-single-algorithm-behavior">Single Algorithm Behavior</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protection-against-congesti">Protection Against Congestion Collapse</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protection-against-bufferbl">Protection Against Bufferbloat</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protection-against-high-pac">Protection Against High Packet Loss</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.4.1"><xref derivedContent="5.1.4" format="counter" sectionFormat="of" target="section-5.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fairness-within-the-propose">Fairness Within the Proposed Congestion Control Algorithm</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.5.1"><xref derivedContent="5.1.5" format="counter" sectionFormat="of" target="section-5.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-short-flows">Short Flows</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mixed-algorithm-behavior">Mixed Algorithm Behavior</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-existing-general-purpose-co">Existing General-Purpose Congestion Control</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-real-time-congestion-contro">Real-Time Congestion Control</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-short-and-long-flows">Short and Long Flows</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-other-criteria">Other Criteria</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
                  <li pn="section-toc.1-1.5.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-differences-with-congestion">Differences with Congestion Control Principles</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-incremental-deployment">Incremental Deployment</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-use">General Use</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-paths-with-tail-drop-queues">Paths with Tail-Drop Queues</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tunnel-behavior">Tunnel Behavior</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wired-paths">Wired Paths</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wireless-paths">Wireless Paths</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-special-cases">Special Cases</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-active-queue-management-aqm">Active Queue Management (AQM)</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operation-with-the-envelope">Operation with the Envelope Set by Network Circuit Breakers</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-paths-with-varying-delay">Paths with Varying Delay</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-internet-of-things-and-cons">Internet of Things and Constrained Nodes</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-paths-with-high-delay">Paths with High Delay</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.6">
                <t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-misbehaving-nodes">Misbehaving Nodes</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.7">
                <t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extreme-packet-reordering">Extreme Packet Reordering</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.8">
                <t indent="0" pn="section-toc.1-1.7.2.8.1"><xref derivedContent="7.8" format="counter" sectionFormat="of" target="section-7.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transient-events">Transient Events</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.9">
                <t indent="0" pn="section-toc.1-1.7.2.9.1"><xref derivedContent="7.9" format="counter" sectionFormat="of" target="section-7.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sudden-changes-in-the-path">Sudden Changes in the Path</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.10">
                <t indent="0" pn="section-toc.1-1.7.2.10.1"><xref derivedContent="7.10" format="counter" sectionFormat="of" target="section-7.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-multipath-transport">Multipath Transport</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.11">
                <t indent="0" pn="section-toc.1-1.7.2.11.1"><xref derivedContent="7.11" format="counter" sectionFormat="of" target="section-7.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-data-centers">Data Centers</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-since-rfc-5033">Changes Since RFC 5033</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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" format="default" sectionFormat="of" derivedContent="RFC2914"/>. The
      guidance is intended to be useful to authors proposing congestion
      control algorithms and for the IETF community when evaluating whether a
      proposal is appropriate for publication in the RFC Series and for
      deployment in the Internet.</t>
      <t indent="0" pn="section-1-2">This document obsoletes <xref target="RFC5033" format="default" sectionFormat="of" derivedContent="RFC5033"/>, which was published
      in 2007 as a Best Current Practice for evaluating proposed congestion
      control algorithms for publication in Experimental or Proposed Standard RFCs.</t>
      <t indent="0" pn="section-1-3">The IETF specifies standard Internet congestion control algorithms in
      the RFC Series.  These congestion control algorithms can suffer
      performance challenges when used in differing environments (e.g.,
      high-speed networks, cellular and Wi-Fi wireless technologies, and
      long-distance satellite links), and also when flows carry specific
      workloads (e.g., Voice over IP (VoIP), gaming, and videoconferencing).</t>
      <t indent="0" pn="section-1-4">When <xref target="RFC5033" format="default" sectionFormat="of" derivedContent="RFC5033"/> was published, TCP <xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/> was the primary focus of IETF congestion control
      efforts, with proposals typically discussed within the Internet
      Congestion Control Research Group (ICCRG). Concurrently, the Datagram
      Congestion Control Protocol (DCCP) <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> was
      developed to define new congestion control algorithms for datagram
      traffic, while the Stream Control Transmission Protocol (SCTP) <xref target="RFC9260" format="default" sectionFormat="of" derivedContent="RFC9260"/> reused TCP congestion control algorithms.</t>
      <t indent="0" pn="section-1-5">Since then, several changes have occurred. The range of protocols
      utilizing congestion control algorithms has expanded to include QUIC
      <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/> and RTP Media Congestion Avoidance Techniques
      (RMCAT) (e.g., <xref target="RFC8836" format="default" sectionFormat="of" derivedContent="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., <xref target="RFC8257" format="default" sectionFormat="of" derivedContent="RFC8257"/>), and in
      supporting a variety of upper-layer protocols and applications, such as
      real-time protocols. Moreover, the community has gained significant
      experience with congestion indications beyond packet loss.</t>
      <t indent="0" pn="section-1-6">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8085#section-4" derivedContent="RFC8085"/> provides additional
      guidelines for multicast and broadcast usage of UDP.</t>
      <t indent="0" pn="section-1-7">Congestion control algorithms have been developed outside of the
      IETF, including at least two that saw large scale deployment. These
      include CUBIC <xref target="HRX08" format="default" sectionFormat="of" derivedContent="HRX08"/> and Bottleneck Bandwidth and
      Round-trip propagation time (BBR) <xref target="I-D.cardwell-iccrg-bbr-congestion-control" format="default" sectionFormat="of" derivedContent="BBR"/>.</t>
      <t indent="0" pn="section-1-8">CUBIC was documented in a research publication in 2008 <xref target="HRX08" format="default" sectionFormat="of" derivedContent="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 Internet-Draft in 2015, and published as an
      Informational RFC in 2017 as <xref target="RFC8312" format="default" sectionFormat="of" derivedContent="RFC8312"/> and then as a
      Proposed Standard in 2023 <xref target="RFC9438" format="default" sectionFormat="of" derivedContent="RFC9438"/>.</t>
      <t indent="0" pn="section-1-9">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. BBR was described in an Internet-Draft in
      2018 and was first presented in the IRTF Internet Congestion Control Research Group. It has since been regularly updated to document the
      evolving versions of the algorithm <xref target="I-D.cardwell-iccrg-bbr-congestion-control" format="default" sectionFormat="of" derivedContent="BBR"/>. BBR is currently
      widely used for Google services using either TCP or QUIC and is also
      widely deployed outside of Google.</t>
      <t indent="0" pn="section-1-10">We cannot say whether the original authors of <xref target="RFC5033" format="default" sectionFormat="of" derivedContent="RFC5033"/> expected that developers would be waiting for IETF
      review before widely deploying a new congestion control algorithm over
      the Internet, but the examples of CUBIC and BBR illustrate that deployment
      of new algorithms is not, in fact, gated by the publication of the
      algorithm as an RFC.</t>
      <t indent="0" pn="section-1-11">Nevertheless, a specification for a congestion control algorithm
      provides a number of advantages:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-12">
        <li pn="section-1-12.1">
          <t indent="0" pn="section-1-12.1.1">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 pn="section-1-12.2">
          <t indent="0" pn="section-1-12.2.1">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 pn="section-1-12.3">
          <t indent="0" pn="section-1-12.3.1">It can help (by being accessible to anyone) to circumvent the
          issue that some implementers may be unable to read open-source
          reference implementations due to the constraints of some open-source
          licenses.</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-13">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 indent="0" pn="section-1-14">The evaluation guidelines in this document are intended to be
      consistent with the congestion control principles from <xref target="RFC2914" format="default" sectionFormat="of" derivedContent="RFC2914"/> related to preventing congestion collapse, considering
      fairness, and optimizing a flow's own performance in terms of
      throughput, delay, and loss. <xref target="RFC2914" format="default" sectionFormat="of" derivedContent="RFC2914"/> also discusses the
      goal of avoiding a congestion control "arms race" among competing
      transport protocols.</t>
      <t indent="0" pn="section-1-15">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 indent="0" pn="section-1-16">The high-order criterion for advancing any proposal within the IETF
      is a serious scientific study of the pros and cons that occur when the
      proposal is considered for publication by the IETF or before it is
      deployed at a large scale.</t>
      <t indent="0" pn="section-1-17">After initial studies, authors are encouraged to write a
      specification of their proposal for publication in the RFC Series. This
      allows others to understand and investigate the wealth of proposals in
      this space.</t>
      <t indent="0" pn="section-1-18">This document is intended to reduce the barriers to entry for new
      congestion control work to the IETF. As such, proponents of new
      congestion control algorithms ought not to interpret these criteria as a
      checklist of requirements before approaching the IETF. Instead,
      proponents are encouraged to think about these issues beforehand and
      have the willingness to do the work implied by the remainder of this
      document.</t>
    </section>
    <section anchor="specification-of-requirements" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-specification-of-requiremen">Specification of Requirements</name>
      <t indent="0" pn="section-2-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
      </t>
    </section>
    <section anchor="guidelines-for-authors" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-guidelines-for-authors">Guidelines for Authors</name>
      <section anchor="guidelines-for-authors-about-evaluation" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-evaluation-guidelines">Evaluation Guidelines</name>
        <t indent="0" pn="section-3.1-1">This document does not provide specific evaluation methods, short
        of Internet-scale deployment and measurement, to test the criteria
        described below. There are multiple possible approaches to
        evaluation. Each has a role, and the most appropriate approach depends
        on the criteria being evaluated and the maturity of the
        specification.</t>
        <t indent="0" pn="section-3.1-2">For many algorithms, an initial evaluation will consider individual
        protocol mechanisms in a simulator to analyze their stability and
        safety across a wide range of conditions, including overload.  For
        example, <xref target="RFC8869" format="default" sectionFormat="of" derivedContent="RFC8869"/> describes evaluation test cases for
        interactive real-time media over wireless networks. Such results could
        also be published or discussed in IRTF research groups, such as ICCRG
        and MAPRG.</t>
        <t indent="0" pn="section-3.1-3">Before a proposed congestion control algorithm is published as an
        Experimental or Standards Track RFC, the community
        <bcp14>SHOULD</bcp14> gain practical experience with implementations
        and experience using the algorithm. Implementations by independent
        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
        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).  When a working group is trying to decide if a proposed
        specification is ready for publication, it will normally consider
        evidence of results. This ought to be documented in any request from
        the working group to publish the specification.</t>
        <t indent="0" pn="section-3.1-4">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>
      </section>
      <section anchor="guidelines-for-authors-about-document-status" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-document-status-guidelines">Document-Status Guidelines</name>
        <t indent="0" pn="section-3.2-1">The guidelines in this document apply to specifications of
	congestion control algorithms that seek publication as an RFC via the
	IETF Stream with an Experimental or Standards Track status. The
	evaluation of either status involves the same questions, but with
	different expectations for both the answers and the degree of
	certainty of those answers.</t>
        <t indent="0" pn="section-3.2-2">Specifications of congestion control algorithms without empirical
	evidence of Internet-scale deployment <bcp14>MUST</bcp14> seek
	Experimental status, unless they are not targeted for general use.
	Algorithms not targeted at general use do not require Internet-scale
	data.</t>
        <t indent="0" pn="section-3.2-3">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 a Standards Track RFC. For
	example, <xref target="RFC6928" section="12" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6928#section-12" derivedContent="RFC6928"/> provides
	"Usage and Deployment Recommendations" that describe the experiments expected
	by the TCPM Working Group. <xref target="RFC7414" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7414#section-4" derivedContent="RFC7414"/> provides other examples of extensions that were
	considered experimental when the specification was published.</t>
        <t indent="0" pn="section-3.2-4">Experimental specifications <bcp14>SHOULD NOT</bcp14> be deployed
        as a default. They <bcp14>SHOULD</bcp14> only be deployed in
        situations where they are being actively measured and where it is
        possible to deactivate them if there are signs of pathological
        behavior.</t>
        <t indent="0" pn="section-3.2-5">Specifications of congestion control algorithms with a record of
	measured Internet-scale deployment <bcp14>MAY</bcp14> directly seek Standards
	Track status if there is solid data that reflects that the algorithm is safe
	and the design is stable, guided by the considerations in <xref target="general-use" format="default" sectionFormat="of" derivedContent="Section 6"/>. However, the existence of this data does not waive the
	other considerations in this document.</t>
        <t indent="0" pn="section-3.2-6">Each specification submitted for publication as an RFC is
        <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 such specification is also <bcp14>REQUIRED</bcp14> to
        include a statement in the abstract describing environments where the
        protocol is not recommended for deployment. There can be environments
        where the congestion control algorithm is deemed safe for use, but it
        is still not recommended for use because it does not perform well
        for the user.</t>
        <t indent="0" pn="section-3.2-7">Examples of such statements exist in <xref target="RFC3649" format="default" sectionFormat="of" derivedContent="RFC3649"/>, which specifies
        HighSpeed TCP and includes a statement in the abstract stating that
        the proposed congestion control algorithm is experimental but may be
        deployed in the Internet. In contrast, the Quick-Start document <xref target="RFC4782" format="default" sectionFormat="of" derivedContent="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 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" format="default" sectionFormat="of" derivedContent="RFC9049"/>.</t>
        <t indent="0" pn="section-3.2-8">Strictly speaking, documents for publication as Informational RFCs from the IETF Stream need not
        meet all of the criteria in this document, as they do not carry a
        formal recommendation from the IETF community. Instead, the community
        judges the publication of these Informational RFCs based on the value of
        their addition to the information captured by the RFC Series.</t>
        <t indent="0" pn="section-3.2-9">Although it is out of scope 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) Stream. In
        general, these algorithms are expected to be less mature than ones
        that follow the procedures in this document for publication via the IETF Stream. Authors documenting
        deployed congestion control algorithms that cannot be changed by IETF
        or IRTF review are invited to seek publication of their specification as an Informational RFC
        via the Independent Submission Stream.</t>
      </section>
    </section>
    <section anchor="controlled-environments" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-specifying-algorithms-for-u">Specifying Algorithms for Use in Controlled Environments</name>
      <t indent="0" pn="section-4-1">Algorithms can be designed for general Internet deployment or for use
      in controlled environments <xref target="RFC8799" format="default" sectionFormat="of" derivedContent="RFC8799"/>. Within a controlled
      environment, an operator can ensure that flows are isolated from other
      Internet flows or they might allow these flows to share resources with
      other Internet flows.  A data center is an example of a controlled
      environment that often deploys fabrics with rich signaling from
      switches to endpoints.</t>
      <t indent="0" pn="section-4-2">Algorithms that rely on specific functions or configurations in the
      network need to provide a reference or specification for these functions
      (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 consider whether a working group exists that can
      properly assess the network-layer aspects and their interaction with the
      congestion control.</t>
      <t indent="0" pn="section-4-3">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.  Algorithms that are designed to be confined to a
      controlled environment and are not intended for use in the general Internet
      might instead seek real-world data for those environments. In such cases, the
      evaluation criteria in the remainder of this document might not apply.</t>
    </section>
    <section anchor="evaluation-criteria" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-evaluation-criteria">Evaluation Criteria</name>
      <t indent="0" pn="section-5-1">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 community. The following guidelines are intended to assist authors
      and the community in this endeavor. While these guidelines provide a helpful
      framework, they should not be regarded as an exhaustive checklist as concerns
      beyond the scope of these guidelines may also arise.</t>
      <t indent="0" pn="section-5-2">When considering a proposed congestion control algorithm, the
      community <bcp14>MUST</bcp14> consider the criteria in the following sections. These
      criteria will be evaluated in various domains (see Sections <xref target="general-use" format="counter" sectionFormat="of" derivedContent="6"/> and <xref target="special-cases" format="counter" sectionFormat="of" derivedContent="7"/>).</t>
      <t indent="0" pn="section-5-3">Some of the sections below will list criteria that
      <bcp14>SHOULD</bcp14> be met. It could happen that these criteria are
      not, in fact, met by the proposal. In such cases, the community
      <bcp14>MUST</bcp14> document whether not meeting the criteria is
      acceptable, for example, if there are practical limitations on
      carrying out an evaluation of the criteria.</t>
      <t indent="0" pn="section-5-4">The requirement that the community consider a criterion does not
      imply that the result needs to be described in an RFC: there is
      no formal requirement to document the results, although normal IETF
      policies for archiving proceedings will provide a record.</t>
      <t indent="0" pn="section-5-5">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
      specification in the publication process.</t>
      <section anchor="single-algorithm-behavior" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-single-algorithm-behavior">Single Algorithm Behavior</name>
        <t indent="0" pn="section-5.1-1">The criteria in 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" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.1">
          <name slugifiedName="name-protection-against-congesti">Protection Against Congestion Collapse</name>
          <t indent="0" pn="section-5.1.1-1">A congestion control algorithm should either stop sending when
          the packet drop rate exceeds some threshold <xref target="RFC3714" format="default" sectionFormat="of" derivedContent="RFC3714"/> or include some notion of "full
          backoff". For "full backoff", at some point, the algorithm would
          reduce the sending rate to one packet per round-trip time; then, it would
          exponentially back off the time between single packet transmissions
          if the congestion persists. Exactly when either "full backoff" or a
          pause in sending comes into play will be algorithm specific.
          However, as discussed in <xref target="RFC2914" format="default" sectionFormat="of" derivedContent="RFC2914"/> and <xref target="RFC8961" format="default" sectionFormat="of" derivedContent="RFC8961"/>, this requirement is crucial to protect the
          network in times of extreme (and persistent) congestion.</t>
          <t indent="0" pn="section-5.1.1-2">If full backoff is used, this test does not require that the
          mechanism be identical to that of TCP (see <xref target="RFC6298" format="default" sectionFormat="of" derivedContent="RFC6298"/> and <xref target="RFC8961" format="default" sectionFormat="of" derivedContent="RFC8961"/>). For example, this
          does not preclude full backoff mechanisms that would give flows with
          different round-trip times comparable capacity during backoff.</t>
        </section>
        <section anchor="protection-against-bufferbloat" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.2">
          <name slugifiedName="name-protection-against-bufferbl">Protection Against Bufferbloat</name>
          <t indent="0" pn="section-5.1.2-1">A congestion control algorithm ought to try to avoid maintaining
          excessive queues in the network. Exactly how the algorithm achieves
          this is algorithm specific; see <xref target="RFC8961" format="default" sectionFormat="of" derivedContent="RFC8961"/> and
          <xref target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC8085"/> for requirements.</t>
          <t indent="0" pn="section-5.1.2-2">"Bufferbloat" refers to the building of excessive queues in the
          network <xref target="BUFFERBLOAT" format="default" sectionFormat="of" derivedContent="BUFFERBLOAT"/>. Many network routers are
          configured with very large buffers. The Standards Track RFCs <xref target="RFC5681" format="default" sectionFormat="of" derivedContent="RFC5681"/> and <xref target="RFC9438" format="default" sectionFormat="of" derivedContent="RFC9438"/> describe the Reno
          and CUBIC congestion control algorithms (respectively), which send
          at progressively higher rates until a First In, First Out (FIFO)
          buffer completely fills; then packet losses occur. Every connection
          passing through that bottleneck experiences increased latency due to
          the high buffer occupancy. This adds unwanted latency that
          negatively impacts highly interactive applications such as
          videoconferencing or games, but it also affects routine web browsing
          and video playing.</t>
          <t indent="0" pn="section-5.1.2-3">This problem has been widely discussed since 2011 <xref target="BUFFERBLOAT" format="default" sectionFormat="of" derivedContent="BUFFERBLOAT"/>, but was not discussed in the congestion
          control principles published in September 2002 <xref target="RFC2914" format="default" sectionFormat="of" derivedContent="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" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.3">
          <name slugifiedName="name-protection-against-high-pac">Protection Against High Packet Loss</name>
          <t indent="0" pn="section-5.1.3-1">A congestion control algorithm needs to avoid causing
          excessively high rates of packet loss. To accomplish this, it should
          avoid excessive increases in sending rate and reduce its sending
          rate if experiencing high packet loss.</t>
          <t indent="0" pn="section-5.1.3-2">The first version of the BBR algorithm <xref target="BBRv1" format="default" sectionFormat="of" derivedContent="BBRv1"/> failed this requirement.  Experimental
          evaluation <xref target="BBRv1-EVALUATION" format="default" sectionFormat="of" derivedContent="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, further versions provided a fix for this aspect of BBR
          <xref target="I-D.cardwell-iccrg-bbr-congestion-control" format="default" sectionFormat="of" derivedContent="BBR"/>.</t>
          <t indent="0" pn="section-5.1.3-3">This requirement does not imply that the algorithm should react
          to packet losses in exactly the same way as congestion control algorithms described in current Standards Track RFCs (e.g., <xref target="RFC5681" format="default" sectionFormat="of" derivedContent="RFC5681"/>).</t>
        </section>
        <section anchor="fairness-within-the-proposed-congestion-control-algorithm" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.4">
          <name slugifiedName="name-fairness-within-the-propose">Fairness Within the Proposed Congestion Control Algorithm</name>
          <t indent="0" pn="section-5.1.4-1">When multiple competing flows all use the same proposed
          congestion control algorithm, the evaluation should explore how the
          capacity is shared among the competing flows. Capacity fairness can
          be important when a small number of similar flows compete to fill a
          bottleneck. However, it can also not be useful, for example, when
          comparing flows that seek to send at different rates or if some of
          the flows do not last sufficiently long to approach asymptotic
          behavior.</t>
        </section>
        <section anchor="short-flows" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.5">
          <name slugifiedName="name-short-flows">Short Flows</name>
          <t indent="0" pn="section-5.1.5-1">A great deal of congestion control analysis concerns the
          steady-state behavior of long flows. However, many Internet flows
          are relatively short lived.  Many short-lived flows today remain in
          the "slow start" mode of operation <xref target="RFC5681" format="default" sectionFormat="of" derivedContent="RFC5681"/> that
          commonly features exponential congestion window growth because the
          flow never experiences congestion (e.g., packet loss).</t>
          <t indent="0" pn="section-5.1.5-2">A proposal for a congestion control algorithm <bcp14>MUST</bcp14>
          consider how new and short-lived flows affect long-lived flows, and
          vice versa.</t>
        </section>
      </section>
      <section anchor="mixed-algorithm-behavior" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-mixed-algorithm-behavior">Mixed Algorithm Behavior</name>
        <t indent="0" pn="section-5.2-1">The mixed algorithm behavior criteria evaluate the interaction of the
        proposed congestion control algorithms being specified with commonly deployed
        congestion control algorithms.</t>
        <t indent="0" pn="section-5.2-2">In contexts where differing congestion control algorithms are used,
        it is important to understand whether the proposed congestion control
        algorithm could result in more harm than algorithms published in previous Standards Track RFCs (e.g., <xref target="RFC5681" format="default" sectionFormat="of" derivedContent="RFC5681"/>, <xref target="RFC9002" format="default" sectionFormat="of" derivedContent="RFC9002"/>,
        and <xref target="RFC9438" format="default" sectionFormat="of" derivedContent="RFC9438"/>) to flows sharing a common bottleneck.
        The measure of harm is not restricted to unequal capacity, but also
        ought to consider metrics such as the introduced latency or an
        increase in packet loss.  An evaluation <bcp14>MUST</bcp14> assess the
        potential to cause starvation, including assurance that a loss of all
        feedback (e.g., detected by expiry of a retransmission time out)
        results in backoff.</t>
        <section anchor="existing-general-purpose-congestion-control" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.1">
          <name slugifiedName="name-existing-general-purpose-co">Existing General-Purpose Congestion Control</name>
          <t indent="0" pn="section-5.2.1-1">A proposed congestion control algorithm <bcp14>MUST</bcp14> be
          evaluated when competing against standard IETF congestion controls
          (e.g., <xref target="RFC5681" format="default" sectionFormat="of" derivedContent="RFC5681"/>, <xref target="RFC9002" format="default" sectionFormat="of" derivedContent="RFC9002"/>, and <xref target="RFC9438" format="default" sectionFormat="of" derivedContent="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 indent="0" pn="section-5.2.1-2">Note that this guideline is not a requirement for strict Reno or
          CUBIC friendliness as a prerequisite for a proposed congestion
          control mechanism to advance to Experimental or Standards Track
          status. As an example, HighSpeed TCP is a congestion control
          mechanism that is specified in an Experimental RFC and is not Reno friendly
          in all environments. When a new congestion control algorithm is
          deployed, the existing major algorithm deployments need to be
          considered to avoid severe performance degradation. Note that this
          guideline does not constrain the interaction with flows that are not
          best effort.</t>
          <t indent="0" pn="section-5.2.1-3">As an example from an Experimental RFC, fairness with standard
          TCP is discussed in Sections <xref target="RFC3649" sectionFormat="bare" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3649#section-4" derivedContent="RFC3649"/> and <xref target="RFC3649" sectionFormat="bare" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3649#section-6" derivedContent="RFC3649"/> of <xref target="RFC3649" format="default" sectionFormat="of" derivedContent="RFC3649"/>, and using spare capacity is
          discussed in Sections <xref target="RFC3649" sectionFormat="bare" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3649#section-6" derivedContent="RFC3649"/>, <xref target="RFC3649" sectionFormat="bare" section="11.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3649#section-11.1" derivedContent="RFC3649"/>, and <xref target="RFC3649" sectionFormat="bare" section="12" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3649#section-12" derivedContent="RFC3649"/> of <xref target="RFC3649" format="default" sectionFormat="of" derivedContent="RFC3649"/>.</t>
        </section>
        <section anchor="real-time-congestion-control" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.2">
          <name slugifiedName="name-real-time-congestion-contro">Real-Time Congestion Control</name>
          <t indent="0" pn="section-5.2.2-1">General-purpose algorithms need to coexist in the Internet with
          real-time congestion control algorithms, which in 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" format="default" sectionFormat="of" derivedContent="RFC8836"/> for a description of the characteristics of this
          use case and the resulting requirements.</t>
          <t indent="0" pn="section-5.2.2-2"><xref target="RFC8868" format="default" sectionFormat="of" derivedContent="RFC8868"/> provides suggestions for real-time
          congestion control design and <xref target="RFC8867" format="default" sectionFormat="of" derivedContent="RFC8867"/> suggests test
          cases. <xref target="RFC9392" format="default" sectionFormat="of" derivedContent="RFC9392"/> describes some considerations for
          the RTP Control Protocol (RTCP). In particular, real-time flows can
          use less frequent feedback (acknowledgment) than that provided by
          reliable transports.  This document does not change the
          Informational status of those RFCs.</t>
          <t indent="0" pn="section-5.2.2-3">A proposal for a congestion control algorithm <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 indent="0" pn="section-5.2.2-4">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 indent="0" pn="section-5.2.2-5">Real-time flows can be directed into distinct queues via
          Differentiated Services Code Points (DSCPs) or other mechanisms,
          which can substantially reduce the interplay with other
          traffic. However, a proposal targeting general Internet use cannot
          assume this is always the case.</t>
          <t indent="0" pn="section-5.2.2-6"><xref target="circuit-breakers" format="default" sectionFormat="of" derivedContent="Section 7.2"/> describes the impact of network
          transport circuit breaker algorithms. <xref target="RFC8083" format="default" sectionFormat="of" derivedContent="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" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.3">
          <name slugifiedName="name-short-and-long-flows">Short and Long Flows</name>
          <t indent="0" pn="section-5.2.3-1">The effect on short-lived and long-lived flows using other common
          congestion control algorithms <bcp14>MUST</bcp14> be evaluated, as
          in <xref target="short-flows" format="default" sectionFormat="of" derivedContent="Section 5.1.5"/>.</t>
        </section>
      </section>
      <section anchor="other-criteria" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-other-criteria">Other Criteria</name>
        <section anchor="differences-with-congestion-control-principles" numbered="true" removeInRFC="false" toc="include" pn="section-5.3.1">
          <name slugifiedName="name-differences-with-congestion">Differences with Congestion Control Principles</name>
          <t indent="0" pn="section-5.3.1-1">A proposal for a congestion control algorithm <bcp14>MUST</bcp14>
          clearly explain any deviations from <xref target="RFC2914" format="default" sectionFormat="of" derivedContent="RFC2914"/> and
          <xref target="RFC7141" format="default" sectionFormat="of" derivedContent="RFC7141"/>.</t>
        </section>
        <section anchor="incremental-deployment" numbered="true" removeInRFC="false" toc="include" pn="section-5.3.2">
          <name slugifiedName="name-incremental-deployment">Incremental Deployment</name>
          <t indent="0" pn="section-5.3.2-1">A congestion control algorithm proposal <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 <bcp14>SHOULD</bcp14> discuss what is known
          (if anything) about the correct operation of the mechanisms with
          some of the equipment in the current Internet (e.g., routers,
          transparent proxies, WAN optimizers, intrusion detection systems,
          home routers, and the like).</t>
          <t indent="0" pn="section-5.3.2-2">Similarly, if the proposed congestion control algorithm is
          intended only for specific environments (and not the global
          Internet), the proposal <bcp14>SHOULD</bcp14> consider how this
          intention is to be realized.  The IETF community will have to address the
          question of whether the scope can be enforced by stating the
          restrictions or whether additional protocol mechanisms are required
          to enforce this scoping.  The answer will necessarily depend on the
          proposed change.</t>
          <t indent="0" pn="section-5.3.2-3">As an example from an Experimental RFC, deployment issues of Quick-Start are
          discussed in Sections <xref target="RFC4782" section="10.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4782#section-10.3" derivedContent="RFC4782"/> and <xref target="RFC4782" section="10.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4782#section-10.4" derivedContent="RFC4782"/> of <xref target="RFC4782" format="default" sectionFormat="of" derivedContent="RFC4782"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="general-use" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-general-use">General Use</name>
      <t indent="0" pn="section-6-1">The criteria in <xref target="evaluation-criteria" format="default" sectionFormat="of" derivedContent="Section 5"/> will be
      evaluated in the scenarios described in the following subsections. Unless a proposed congestion
      control algorithm specification of the IETF Stream explicitly forbids use on the public Internet,
      there <bcp14>MUST</bcp14> be IETF consensus that it meets the criteria
      in these scenarios for the proposed congestion control algorithm to
      progress.</t>
      <t indent="0" pn="section-6-2">The evaluation of each scenario <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 indent="0" pn="section-6-3">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" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-paths-with-tail-drop-queues">Paths with Tail-Drop Queues</name>
        <t indent="0" pn="section-6.1-1">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) <bcp14>MUST</bcp14> be
        evaluated. See <xref target="aqm" format="default" sectionFormat="of" derivedContent="Section 7.1"/> for evaluation of other queue
        disciplines.</t>
      </section>
      <section anchor="tunnel-behavior" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-tunnel-behavior">Tunnel Behavior</name>
        <t indent="0" pn="section-6.2-1">When a proposed congestion control algorithm relies on explicit
        signals from the path, the proposal <bcp14>MUST</bcp14> consider the
        effect of traffic passing through a tunnel, where routers may not be
        aware of the flow.</t>
        <t indent="0" pn="section-6.2-2">Designers of tunnels and similar encapsulations might need to
        consider nested congestion control interactions, for example, when the
        Explicit Congestion Notification (ECN) is used by both an IP and lower-layer technology <xref target="RFC9599" format="default" sectionFormat="of" derivedContent="ECN-ENCAPS"/>.</t>
      </section>
      <section anchor="wired-paths" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-wired-paths">Wired Paths</name>
        <t indent="0" pn="section-6.3-1">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" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-wireless-paths">Wireless Paths</name>
        <t indent="0" pn="section-6.4-1">While the early Internet was dominated by wired links, the
        properties of wireless links have become important to Internet
        performance. In particular, a proposed congestion control algorithm
        should be evaluated in situations where some packet losses are due to
        radio effects rather than router queue drops. The link capacity
        varies over time due to changing link conditions, and media-access
        delays and link-layer retransmission lead to increased jitter in
        round-trip times. See <xref target="RFC3819" format="default" sectionFormat="of" derivedContent="RFC3819"/> and Section 16 of <xref target="I-D.irtf-tmrg-tools" format="default" sectionFormat="of" derivedContent="TOOLS"/> for further discussion of wireless
        properties.</t>
      </section>
    </section>
    <section anchor="special-cases" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-special-cases">Special Cases</name>
      <t indent="0" pn="section-7-1">The criteria in <xref target="evaluation-criteria" format="default" sectionFormat="of" derivedContent="Section 5"/> will be
      evaluated in the scenarios described in the following subsections, unless the proposed congestion
      control algorithm specifically excludes its use in a scenario. For these
      specific use cases, the IETF community <bcp14>MAY</bcp14> allow a proposal to
      progress even if the criteria indicate an unsatisfactory result for
      these scenarios.</t>
      <t indent="0" pn="section-7-2">In general, measurements from Internet-scale deployments might not
      expose the properties of operation in each of these scenarios because
      they are not as ubiquitous as the general-use scenarios.</t>
      <section anchor="aqm" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-active-queue-management-aqm">Active Queue Management (AQM)</name>
        <t indent="0" pn="section-7.1-1">The proposed congestion control algorithm <bcp14>SHOULD</bcp14> be
        evaluated under a variety of bottleneck-queue disciplines. The effect
        of an AQM discipline can be hard to detect by Internet evaluation. At
        a minimum, a proposal should reason about an algorithm's response to
        various AQM disciplines. Simulation or empirical results are, of
        course, valuable.</t>
        <t indent="0" pn="section-7.1-2">Some of the AQM techniques that might have an impact on a proposed
        congestion control algorithm include:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.1-3">
          <li pn="section-7.1-3.1">Flow Queue CoDel (FQ-CoDel) <xref target="RFC8290" format="default" sectionFormat="of" derivedContent="RFC8290"/>;</li>
          <li pn="section-7.1-3.2">Proportional Integral controller Enhanced (PIE) <xref target="RFC8033" format="default" sectionFormat="of" derivedContent="RFC8033"/>; and</li>
          <li pn="section-7.1-3.3">Low Latency, Low Loss, and Scalable Throughput (L4S) <xref target="RFC9332" format="default" sectionFormat="of" derivedContent="RFC9332"/>.</li>
        </ul>
        <t indent="0" pn="section-7.1-4">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 <xref target="RFC8087" format="default" sectionFormat="of" derivedContent="RFC8087"/>. Use of ECN (see <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/> and <xref target="RFC9332" format="default" sectionFormat="of" derivedContent="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 indent="0" pn="section-7.1-5">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" format="default" sectionFormat="of" derivedContent="RFC7567"/> describes design
        considerations for AQMs.</t>
      </section>
      <section anchor="circuit-breakers" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-operation-with-the-envelope">Operation with the Envelope Set by Network Circuit Breakers</name>
        <t indent="0" pn="section-7.2-1">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" format="default" sectionFormat="of" derivedContent="RFC8084"/>.  Such a network transport circuit
        breaker can automatically detect excessive congestion; when
        detected, it can terminate (or significantly reduce the rate of) the
        flow(s). A well-designed congestion control algorithm ought to react
        before the flow uses excessive resources; therefore, it will operate
        within the envelope set by network transport circuit breaker
        algorithms.</t>
      </section>
      <section anchor="delay" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-paths-with-varying-delay">Paths with Varying Delay</name>
        <t indent="0" pn="section-7.3-1">An Internet 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 can also
        include complex subnetworks where the minimum delay changes over
        various time scales, resulting in a minimum delay that is not stationary.</t>
        <t indent="0" pn="section-7.3-2">Varying delay occurs when a subnet changes the forwarding path to
        optimize capacity, resilience, etc. It could also arise when a subnet
        uses a 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 or when the physical layer changes its mode of operation).
        Variation also arises when traffic with a higher priority DSCP
        preempts transmission of traffic with a lower class. In these cases,
        the delay varies as a function of external factors, and attempting to
        infer congestion from an increase in the delay results in reduced
        throughput. This variation in the delay over short timescales (jitter)
        might not be distinguishable from jitter that results from other
        effects.</t>
        <t indent="0" pn="section-7.3-3">A proposed congestion control algorithm <bcp14>SHOULD</bcp14> be
        evaluated to ensure its operation is robust when there is a
        significant change in the minimum delay.</t>
      </section>
      <section anchor="internet-of-things-and-constrained-nodes" numbered="true" removeInRFC="false" toc="include" pn="section-7.4">
        <name slugifiedName="name-internet-of-things-and-cons">Internet of Things and Constrained Nodes</name>
        <t indent="0" pn="section-7.4-1">The "Internet of Things" (IoT) is a broad concept, but when
        evaluating a proposed congestion control algorithm, it is often
        associated with unique characteristics. For example, IoT nodes might
        be more constrained in power, CPU, or other parameters than
        conventional Internet hosts. This might place limits on the complexity
        of any given algorithm. These power and radio constraints might make
        the volume of control packets in a given algorithm a key evaluation
        metric.</t>
        <t indent="0" pn="section-7.4-2">Extremely low-power links can lead to very low throughput and a low
        bandwidth-delay product, which is well below the standard operating
        range of most Internet flows.</t>
        <t indent="0" pn="section-7.4-3">Furthermore, many IoT applications do not a have a human in the
        loop; therefore, they might have weaker latency constraints because they
        do not relate to a user experience. Congestion control algorithms
        still might need to share the path with other flows with different
        constraints.</t>
      </section>
      <section anchor="paths-with-high-delay" numbered="true" removeInRFC="false" toc="include" pn="section-7.5">
        <name slugifiedName="name-paths-with-high-delay">Paths with High Delay</name>
        <t indent="0" pn="section-7.5-1">Authors of a proposed congestion control algorithm ought not to presume that
        all general Internet paths have a low delay. Some paths include links
        that 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" format="default" sectionFormat="of" derivedContent="RFC2488"/> and high-delay-bandwidth products <xref target="RFC3649" format="default" sectionFormat="of" derivedContent="RFC3649"/>.</t>
        <t indent="0" pn="section-7.5-2">Paths can also present a variable delay as described in <xref target="delay" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.</t>
      </section>
      <section anchor="misbehaving-nodes" numbered="true" removeInRFC="false" toc="include" pn="section-7.6">
        <name slugifiedName="name-misbehaving-nodes">Misbehaving Nodes</name>
        <t indent="0" pn="section-7.6-1">A proposal for a congestion control algorithm <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 indent="0" pn="section-7.6-2">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4782#section-9.4" derivedContent="RFC4782"/>, <xref target="RFC4782" section="9.5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4782#section-9.5" derivedContent="RFC4782"/>, and <xref target="RFC4782" section="9.6" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4782#section-9.6" derivedContent="RFC4782"/> of <xref target="RFC4782" format="default" sectionFormat="of" derivedContent="RFC4782"/>. This includes discussion of:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.6-3">
          <li pn="section-7.6-3.1">misbehaving senders and receivers;</li>
          <li pn="section-7.6-3.2">collusion between misbehaving routers;</li>
          <li pn="section-7.6-3.3">misbehaving middleboxes; and</li>
          <li pn="section-7.6-3.4">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" numbered="true" removeInRFC="false" toc="include" pn="section-7.7">
        <name slugifiedName="name-extreme-packet-reordering">Extreme Packet Reordering</name>
        <t indent="0" pn="section-7.7-1">Authors of a proposed congestion control algorithm ought not to presume that
        all general Internet paths reliably deliver packets in order. <xref target="RFC4653" format="default" sectionFormat="of" derivedContent="RFC4653"/> discusses the effect of extreme packet
        reordering.</t>
      </section>
      <section anchor="transient-events" numbered="true" removeInRFC="false" toc="include" pn="section-7.8">
        <name slugifiedName="name-transient-events">Transient Events</name>
        <t indent="0" pn="section-7.8-1">A proposal for a congestion control algorithm <bcp14>SHOULD</bcp14>
        consider how it  would perform in the presence of transient events such as a sudden onset of
        congestion, a routing change, or a mobility event.  Routing changes,
        link disconnections, intermittent link connectivity, and mobility are
        discussed in more detail in Section 16 of <xref target="I-D.irtf-tmrg-tools" format="default" sectionFormat="of" derivedContent="TOOLS"/>.</t>
        <t indent="0" pn="section-7.8-2">As an example from an Experimental RFC, a response to transient
        events is discussed in <xref section="9.2" sectionFormat="of" target="RFC4782" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4782#section-9.2" derivedContent="RFC4782"/>.</t>
      </section>
      <section anchor="sudden-changes-in-the-path" numbered="true" removeInRFC="false" toc="include" pn="section-7.9">
        <name slugifiedName="name-sudden-changes-in-the-path">Sudden Changes in the Path</name>
        <t indent="0" pn="section-7.9-1">An IETF transport is not tied to a specific Internet path or type
        of path. The set of routers that form a path can and do change with
        time. This will cause the properties of the path to change with
        respect to time. A proposal for a congestion control algorithm
        <bcp14>MUST</bcp14> evaluate the impact of changes in the path and be
        robust to changes in path characteristics on the interval of common
        Internet rerouting intervals.</t>
      </section>
      <section anchor="multipath-transport" numbered="true" removeInRFC="false" toc="include" pn="section-7.10">
        <name slugifiedName="name-multipath-transport">Multipath Transport</name>
        <t indent="0" pn="section-7.10-1">Multipath transport protocols permit more than one path to be
        differentiated and used by a single connection at the sender. A
        multipath sender can schedule which packets travel on which of its
        active paths. This enables a trade-off in timeliness and
        reliability. There are various ways that multipath techniques can be
        used.</t>
        <t indent="0" pn="section-7.10-2">One example use is to provide failover from one path to another
        when the original path is no longer viable or provides inferior
        performance.  Designs need to independently track the congestion state
        of each path and demonstrate independent congestion control for each
        path being used. Authors of a proposed multipath congestion control
        algorithm that implements path failover <bcp14>MUST</bcp14> evaluate
        the harm to performance resulting from a change in the path and show
        that this does not result in flow starvation. Synchronization of
        failover (e.g., where multiple flows change their path on similar
        time frames) can also contribute to harm and/or reduce fairness. These
        effects also ought to be evaluated.</t>
        <t indent="0" pn="section-7.10-3">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. A congestion
        control algorithm proposal <bcp14>MUST</bcp14> evaluate the potential
        harm to other flows when the multiple paths share a common congested
        bottleneck or share resources that are coupled between different
        paths, such as an overall capacity limit. A proposal
        <bcp14>SHOULD</bcp14> consider the potential for harm to other
        flows. Synchronization of congestion control mechanisms (e.g., where
        multiple flows change their behavior on similar time frames) can also
        contribute to harm and/or reduce fairness. These effects also ought to
        be evaluated.</t>
        <t indent="0" pn="section-7.10-4">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" format="default" sectionFormat="of" derivedContent="RFC6356"/> that specifies a concurrent multipath
        congestion control algorithm for Multipath TCP (MPTCP) <xref target="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/>.</t>
      </section>
      <section anchor="data-centers" numbered="true" removeInRFC="false" toc="include" pn="section-7.11">
        <name slugifiedName="name-data-centers">Data Centers</name>
        <t indent="0" pn="section-7.11-1">Data centers are characterized by very
        low latencies (&lt; 2 ms). Many workloads involve bursty traffic where
        many nodes complete a task at the same time. As a controlled
        environment, data centers often deploy fabrics that employ rich
        signaling from switches to endpoints. Furthermore, the operator can
        often limit the number of operating congestion control algorithms.</t>
        <t indent="0" pn="section-7.11-2">For these reasons, data center congestion controls are often
        distinct from those running elsewhere on the Internet (see <xref target="controlled-environments" format="default" sectionFormat="of" derivedContent="Section 4"/>).  A proposed congestion control algorithm
        need not coexist well with all other algorithms if it is intended for
        data centers, but the proposal <bcp14>SHOULD</bcp14> indicate which
        are expected to safely coexist with it.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">This document does not represent a change to any aspect of the TCP/IP
      protocol suite; therefore, it does not directly impact Internet security.
      The implementation of various facets of the Internet's current
      congestion control algorithms do have security implications (e.g., as
      outlined in <xref target="RFC5681" format="default" sectionFormat="of" derivedContent="RFC5681"/>).</t>
      <t indent="0" pn="section-8-2">A proposal for a congestion control algorithm <bcp14>MUST</bcp14> examine
      any potential security or privacy issues that may arise from their
      design.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <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 pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC2914" target="https://www.rfc-editor.org/info/rfc2914" quoteTitle="true" derivedAnchor="RFC2914">
          <front>
            <title>Congestion Control Principles</title>
            <author fullname="S. Floyd" initials="S." surname="Floyd"/>
            <date month="September" year="2000"/>
            <abstract>
              <t indent="0">The goal of this document is to explain the need for congestion control in the Internet, and 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="RFC5681" target="https://www.rfc-editor.org/info/rfc5681" quoteTitle="true" derivedAnchor="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 indent="0">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, 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="RFC7141" target="https://www.rfc-editor.org/info/rfc7141" quoteTitle="true" derivedAnchor="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 indent="0">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 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 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. 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="RFC8083" target="https://www.rfc-editor.org/info/rfc8083" quoteTitle="true" derivedAnchor="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 indent="0">The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented 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 indent="0">This document does 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="RFC8084" target="https://www.rfc-editor.org/info/rfc8084" quoteTitle="true" derivedAnchor="RFC8084">
          <front>
            <title>Network Transport Circuit Breakers</title>
            <author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
            <date month="March" year="2017"/>
            <abstract>
              <t indent="0">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 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>
        <reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8085" quoteTitle="true" derivedAnchor="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 indent="0">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, 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 indent="0">Because congestion control is critical to the stable operation of 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 to implement additional mechanisms, depending on how they use UDP.</t>
              <t indent="0">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 indent="0">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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8961" quoteTitle="true" derivedAnchor="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 indent="0">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 have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation 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="RFC9002" target="https://www.rfc-editor.org/info/rfc9002" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC9438" target="https://www.rfc-editor.org/info/rfc9438" quoteTitle="true" derivedAnchor="RFC9438">
          <front>
            <title>CUBIC for Fast and Long-Distance Networks</title>
            <author fullname="L. Xu" initials="L." surname="Xu"/>
            <author fullname="S. Ha" initials="S." surname="Ha"/>
            <author fullname="I. Rhee" initials="I." surname="Rhee"/>
            <author fullname="V. Goel" initials="V." surname="Goel"/>
            <author fullname="L. Eggert" initials="L." role="editor" surname="Eggert"/>
            <date month="August" year="2023"/>
            <abstract>
              <t indent="0">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 indent="0">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 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>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.cardwell-iccrg-bbr-congestion-control" target="https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02" quoteTitle="true" derivedAnchor="BBR">
          <front>
            <title>BBR Congestion Control</title>
            <author fullname="Neal Cardwell" initials="N." surname="Cardwell">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author fullname="Yuchung Cheng" initials="Y." surname="Cheng">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author fullname="Soheil Hassas Yeganeh" initials="S. H." surname="Yeganeh">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author fullname="Ian Swett" initials="I." surname="Swett">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author fullname="Van Jacobson" initials="V." surname="Jacobson">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <date day="7" month="March" year="2022"/>
            <abstract>
              <t indent="0">This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection'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 "bufferbloat"). 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"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="BBRv1" target="https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-00" quoteTitle="true" derivedAnchor="BBRv1">
          <front>
            <title>BBR Congestion Control</title>
            <author initials="N." surname="Cardwell" fullname="Neal Cardwell">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author initials="Y." surname="Cheng" fullname="Yuchung Cheng">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author initials="S. H." surname="Yeganeh" fullname="Soheil Hassas Yeganeh">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author initials="V." surname="Jacobson" fullname="Van Jacobson">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <date month="July" day="3" year="2017"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-congestion-control-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="BBRv1-EVALUATION" target="https://ieeexplore.ieee.org/document/8117540" quoteTitle="true" derivedAnchor="BBRv1-EVALUATION">
          <front>
            <title>Experimental evaluation of BBR congestion control</title>
            <author initials="M." surname="Hock">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Bless">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Zitterbart">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017"/>
          </front>
          <refcontent>2017 IEEE 25th International Conference on Network Protocols (ICNP)</refcontent>
          <seriesInfo name="DOI" value="10.1109/ICNP.2017.8117540"/>
        </reference>
        <reference anchor="BUFFERBLOAT" target="https://dl.acm.org/doi/10.1145/2063166.2071893" quoteTitle="true" derivedAnchor="BUFFERBLOAT">
          <front>
            <title>Bufferbloat: Dark Buffers in the Internet</title>
            <author initials="K." surname="Nichols">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Gettys">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="November" year="2011"/>
          </front>
          <seriesInfo name="DOI" value="10.1145/2063166.2071893"/>
          <refcontent>ACM Queue Volume 9, Issue 11</refcontent>
        </reference>
        <reference anchor="RFC9599" target="https://www.rfc-editor.org/info/rfc9599" quoteTitle="true" derivedAnchor="ECN-ENCAPS">
          <front>
            <title>Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP</title>
            <author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
            <author fullname="J. Kaippallimalil" initials="J." surname="Kaippallimalil"/>
            <date month="August" year="2024"/>
            <abstract>
              <t indent="0">The purpose of this document is to guide the design of congestion notification in any lower-layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower-layer protocols into IP. Then, the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Specifications that follow these guidelines, whether produced by the IETF or other standards bodies, should assure interworking among IP-layer and lower-layer congestion notification mechanisms. This document is included in BCP 89 and updates the single paragraph of advice to subnetwork designers about Explicit Congestion Notification (ECN) in Section 13 of RFC 3819 by replacing it with a reference to this document.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="89"/>
          <seriesInfo name="RFC" value="9599"/>
          <seriesInfo name="DOI" value="10.17487/RFC9599"/>
        </reference>
        <reference anchor="HRX08" target="https://doi.org/10.1145/1400097.1400105" quoteTitle="true" derivedAnchor="HRX08">
          <front>
            <title>CUBIC: a new TCP-friendly high-speed TCP variant</title>
            <author initials="S." surname="Ha" fullname="Sangtae Ha">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I." surname="Rhee" fullname="Injong Rhee">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Xu" fullname="Lisong Xu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="July"/>
          </front>
          <refcontent>ACM SIGOPS Operating Systems Review, vol. 42, no. 5, pp. 64-74</refcontent>
          <seriesInfo name="DOI" value="10.1145/1400097.1400105"/>
        </reference>
        <reference anchor="RFC2488" target="https://www.rfc-editor.org/info/rfc2488" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC3168" target="https://www.rfc-editor.org/info/rfc3168" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC3649" target="https://www.rfc-editor.org/info/rfc3649" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC3714" target="https://www.rfc-editor.org/info/rfc3714" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC3819" target="https://www.rfc-editor.org/info/rfc3819" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC4340" target="https://www.rfc-editor.org/info/rfc4340" quoteTitle="true" derivedAnchor="RFC4340">
          <front>
            <title>Datagram Congestion Control Protocol (DCCP)</title>
            <author fullname="E. Kohler" initials="E." surname="Kohler"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="S. Floyd" initials="S." surname="Floyd"/>
            <date month="March" year="2006"/>
            <abstract>
              <t indent="0">The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4340"/>
          <seriesInfo name="DOI" value="10.17487/RFC4340"/>
        </reference>
        <reference anchor="RFC4653" target="https://www.rfc-editor.org/info/rfc4653" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC4782" target="https://www.rfc-editor.org/info/rfc4782" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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="RFC5033" target="https://www.rfc-editor.org/info/rfc5033" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC5166" target="https://www.rfc-editor.org/info/rfc5166" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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"/>
        </reference>
        <reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6298" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC6356" target="https://www.rfc-editor.org/info/rfc6356" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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 indent="0">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="RFC6928" target="https://www.rfc-editor.org/info/rfc6928" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC7414" target="https://www.rfc-editor.org/info/rfc7414" quoteTitle="true" derivedAnchor="RFC7414">
          <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"/>
            <author fullname="A. Zimmermann" initials="A." surname="Zimmermann"/>
            <date month="February" year="2015"/>
            <abstract>
              <t indent="0">This document contains a roadmap to the Request 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.</t>
              <t indent="0">This document obsoletes RFC 4614.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7414"/>
          <seriesInfo name="DOI" value="10.17487/RFC7414"/>
        </reference>
        <reference anchor="RFC7567" target="https://www.rfc-editor.org/info/rfc7567" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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="RFC8033" target="https://www.rfc-editor.org/info/rfc8033" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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="RFC8087" target="https://www.rfc-editor.org/info/rfc8087" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC8257" target="https://www.rfc-editor.org/info/rfc8257" quoteTitle="true" derivedAnchor="RFC8257">
          <front>
            <title>Data Center TCP (DCTCP): TCP Congestion Control for Data Centers</title>
            <author fullname="S. Bensley" initials="S." surname="Bensley"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <author fullname="P. Balasubramanian" initials="P." surname="Balasubramanian"/>
            <author fullname="L. Eggert" initials="L." surname="Eggert"/>
            <author fullname="G. Judd" initials="G." surname="Judd"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8257"/>
          <seriesInfo name="DOI" value="10.17487/RFC8257"/>
        </reference>
        <reference anchor="RFC8290" target="https://www.rfc-editor.org/info/rfc8290" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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="RFC8312" target="https://www.rfc-editor.org/info/rfc8312" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC8684" target="https://www.rfc-editor.org/info/rfc8684" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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 indent="0">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="RFC8799" target="https://www.rfc-editor.org/info/rfc8799" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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="RFC8836" target="https://www.rfc-editor.org/info/rfc8836" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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="RFC8867" target="https://www.rfc-editor.org/info/rfc8867" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC8868" target="https://www.rfc-editor.org/info/rfc8868" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC8869" target="https://www.rfc-editor.org/info/rfc8869" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC9000" target="https://www.rfc-editor.org/info/rfc9000" quoteTitle="true" derivedAnchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC9049" target="https://www.rfc-editor.org/info/rfc9049" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">This document contains that catalog and analysis.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9049"/>
          <seriesInfo name="DOI" value="10.17487/RFC9049"/>
        </reference>
        <reference anchor="RFC9260" target="https://www.rfc-editor.org/info/rfc9260" quoteTitle="true" derivedAnchor="RFC9260">
          <front>
            <title>Stream Control Transmission Protocol</title>
            <author fullname="R. Stewart" initials="R." surname="Stewart"/>
            <author fullname="M. Tüxen" initials="M." surname="Tüxen"/>
            <author fullname="K. Nielsen" initials="K." surname="Nielsen"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.</t>
              <t indent="0">SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.</t>
              <t indent="0">SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users:</t>
              <t indent="0">The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9260"/>
          <seriesInfo name="DOI" value="10.17487/RFC9260"/>
        </reference>
        <reference anchor="RFC9293" target="https://www.rfc-editor.org/info/rfc9293" quoteTitle="true" derivedAnchor="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
        <reference anchor="RFC9332" target="https://www.rfc-editor.org/info/rfc9332" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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="RFC9392" target="https://www.rfc-editor.org/info/rfc9392" quoteTitle="true" derivedAnchor="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 indent="0">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="I-D.irtf-tmrg-tools" target="https://datatracker.ietf.org/doc/html/draft-irtf-tmrg-tools-05" quoteTitle="true" derivedAnchor="TOOLS">
          <front>
            <title>Tools for the Evaluation of Simulation and Testbed Scenarios</title>
            <author fullname="Sally Floyd" initials="S." surname="Floyd">
              <organization showOnFrontPage="true">Editors</organization>
            </author>
            <author fullname="Eddie Kohler" initials="E." surname="Kohler">
              <organization showOnFrontPage="true">Editors</organization>
            </author>
            <date day="23" month="February" year="2008"/>
            <abstract>
              <t indent="0">This document describes tools for the evaluation of simulation and testbed scenarios used in research on Internet congestion control mechanisms. We believe that research in congestion control mechanisms has been seriously hampered by the lack of good models underpinning analysis, simulation, and testbed experiments, and that tools for the evaluation of simulation and testbed scenarios can help in the construction of better scenarios, based on better underlying models. One use of the tools described in this document is in comparing key characteristics of test scenarios with known characteristics from the diverse and ever-changing real world. Tools characterizing the aggregate traffic on a link include the distribution of per-packet round-trip times, the distribution of connection sizes, and the like. Tools characterizing end-to-end paths include drop rates as a function of packet size and of burst size, the synchronization ratio between two end-to-end TCP flows, and the like. For each characteristic, we describe what aspects of the scenario determine this characteristic, how the characteristic can affect the results of simulations and experiments for the evaluation of congestion control mechanisms, and what is known about this characteristic in the real world. We also explain why the use of such tools can add considerable power to our understanding and evaluation of simulation and testbed scenarios.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-tmrg-tools-05"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="true" anchor="change-log" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-changes-since-rfc-5033">Changes Since RFC 5033</name>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.a-1">
        <li pn="section-appendix.a-1.1">Examined BCP 14 keywords and consistency with other RFCs</li>
        <li pn="section-appendix.a-1.2">Rewrote the "Document Status" section</li>
        <li pn="section-appendix.a-1.3">Added QUIC and other more recent congestion control standards</li>
        <li pn="section-appendix.a-1.4">Aligned motivation for this work with the CCWG charter</li>
        <li pn="section-appendix.a-1.5">Refined discussion of Quick-Start</li>
        <li pn="section-appendix.a-1.6">Added criterion for bufferbloat</li>
        <li pn="section-appendix.a-1.7">Added text on constrained environments/limited domains and circuit
    breakers and aligned with other RFCs</li>
        <li pn="section-appendix.a-1.8">Added discussion of real-time protocols, short flows, AQM response, and multipath transports</li>
        <li pn="section-appendix.a-1.9">Listed properties of wired and wireless networks</li>
        <li pn="section-appendix.a-1.10">Added sections addressing IoT and Multicast (noting this is out of scope)</li>
      </ul>
    </section>
    <section numbered="false" anchor="acknowledgments" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.b-1"><contact fullname="Sally Floyd"/> and <contact fullname="Mark       Allman"/> were the authors of this document's predecessor, <xref target="RFC5033" format="default" sectionFormat="of" derivedContent="RFC5033"/>, which served the community well for over a
      decade.</t>
      <t indent="0" pn="section-appendix.b-2">Thanks to <contact fullname="Richard Scheffenegger"/> for helping to
      get this revision process started.</t>
      <t indent="0" pn="section-appendix.b-3">The editors would like to thank <contact fullname="Mohamed       Boucadair"/>, <contact fullname="Neal Cardwell"/>, <contact fullname="Reese Enghardt"/>, <contact fullname="Jonathan Lennox"/>,
      <contact fullname="Matt Mathis"/>, <contact fullname="Zahed Sarker"/>,
      <contact fullname="Juergen Schoenwaelder"/>, <contact fullname="Dave       Taht"/>, <contact fullname="Sean Turner"/>, <contact fullname="Michael       Welzl"/>, <contact fullname="Magnus Westerlund"/>, and <contact fullname="Greg White"/> for suggesting improvements to this
      document.</t>
      <t indent="0" pn="section-appendix.b-4">Discussions with <contact fullname="Lars Eggert"/> and <contact fullname="Aaron Falk"/> seeded the original <xref target="RFC5033" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="RFC5166"/>.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact initials="C." surname="Huitema" fullname="Christian Huitema">
        <organization showOnFrontPage="true">Private Octopus, Inc.</organization>
        <address>
          <email>huitema@huitema.net</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M." surname="Duke" fullname="Martin Duke" role="editor">
        <organization showOnFrontPage="true">Google LLC</organization>
        <address>
          <email>martin.h.duke@gmail.com</email>
        </address>
      </author>
      <author initials="G." surname="Fairhurst" fullname="Godred Fairhurst" role="editor">
        <organization showOnFrontPage="true">University of Aberdeen</organization>
        <address>
          <email>gorry@erg.abdn.ac.uk</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
