<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-rmcat-cc-requirements-09"
     ipr="trust200902"> indexInclude="true" ipr="trust200902" number="8836" prepTime="2021-01-16T23:13:08" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements-09" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8836" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="RTP Media Congestion Control Requirements ">Congestion      Requirements">Congestion Control Requirements for Interactive Real-Time Media</title>
    <seriesInfo name="RFC" value="8836" stream="IETF"/>
    <author fullname="Randell Jesup" initials="R." surname="Jesup">
      <organization>Mozilla</organization>
      <organization showOnFrontPage="true">Mozilla</organization>
      <address>
        <postal>
          <street></street>

          <country>USA</country>
          <street/>
          <country>United States of America</country>
        </postal>
        <email>randell-ietf@jesup.org</email>
      </address>
    </author>
    <author fullname="Zaheduzzaman Sarker" initials="Z." role="editor" surname="Sarker">
      <organization>Ericsson</organization>
      <organization showOnFrontPage="true">Ericsson AB</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>
          <street>Torshamnsgatan 23</street>
          <city>Stockholm</city>
          <region/>
          <code>164 83</code>
          <country>Sweden</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>
        <phone>+46 10 717 37 43</phone>
        <email>zaheduzzaman.sarker@ericsson.com</email>

        <uri></uri>
      </address>
    </author>
    <date />

    <abstract>
      <t>Congestion month="01" year="2021"/>
    <keyword>Interactive multimedia</keyword>
    <keyword>webrtc</keyword>
    <keyword>video communication</keyword>
    <keyword>RTP/RTCP</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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 web pages. Due to an increasing amount of RTP-based
      real-time media traffic on the Internet (e.g. (e.g., with the introduction of
      the Web Real-Time Communication (WebRTC)), it is especially important to
      ensure that this kind of traffic is congestion controlled.</t>

      <t>This
      <t indent="0" pn="section-abstract-2">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>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    <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 document is not an Internet Standards Track specification; it is
            published for informational purposes.
        </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).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see 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 interpreted obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8836" 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) 2021 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 Simplified BSD License text as described in <xref
      target="RFC2119">RFC 2119</xref>. The terms
            Section 4.e of the Trust Legal Provisions and are presented provided without
            warranty as described in many cases
      using lowercase for readability.</t>
    </note> the Simplified 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>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </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-requirements">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-deficiencies-of-existing-me">Deficiencies of Existing Mechanisms</xref></t>
          </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-iana-considerations">IANA Considerations</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-security-considerations">Security Considerations</xref></t>
          </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-references">References</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-normative-references">Normative References</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-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section title="Introduction">
      <t>Most numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Most of today's TCP congestion control schemes were developed with a
      focus on an a use of the Internet for reliable bulk transfer of
      non-time-critical data, such as transfer of large files. They have also
      been used successfully to govern the reliable transfer of smaller chunks
      of data in as short a time as possible, such as when fetching Web web
      pages.</t>

      <t>These
      <t indent="0" pn="section-1-2">These algorithms have also been used for transfer of media streams
      that are viewed in a non-interactive manner, such as "streaming" video,
      where having the data ready when the viewer wants it is important, but
      the exact timing of the delivery is not.</t>

      <t>When doing
      <t indent="0" pn="section-1-3">When handling real-time interactive media, the requirements are
      different; one
      different. One needs to provide the data continuously, within a very
      limited time window (no more delay than 100s hundreds of milliseconds end-to-end
      delay),
      end-to-end). In addition, the sources of data may be able to adapt the
      amount of data that needs sending within fairly wide margins margins, but they can be rate limited by the
      application-
      application -- even not always have having data to send, and send. They may tolerate some
      amount of packet loss, but since the data is generated in real-time, real time,
      sending "future" data is impossible, and since it's consumed in
      real-time,
      real time, data delivered late is commonly useless.</t>

      <t>While
      <t indent="0" pn="section-1-4">While the requirements for real-time interactive media differ from
      the requirements for the other flow types, these other flow types will
      be present in the network. The congestion control algorithm for
      real-time interactive media must work properly when these other flow
      types are present as cross traffic on the network.</t>

      <t>One
      <t indent="0" pn="section-1-5">One particular protocol portfolio being developed for this use case
      is WebRTC <xref target="I-D.ietf-rtcweb-overview"></xref>, target="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825"/>, where one
      envisions sending multiple flows using the Real-time Transport Protocol
      (RTP) <xref target="RFC3550"></xref> target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/> between two peers, in conjunction
      with data flows, all at the same time, without having special
      arrangements with the intervening service providers. As RTP does not
      provide any congestion control mechanism; mechanism, a set of circuit breakers,
      such as those described in <xref target="I-D.ietf-avtcore-rtp-circuit-breakers"></xref>, target="RFC8083" format="default" sectionFormat="of" derivedContent="RFC8083"/>,
      are required to protect the network from excessive congestion caused by
      the non-congestion controlled
      non-congestion-controlled flows. When the real-time interactive
      media is congestion controlled, it is recommended that the
      congestion control mechanism operates operate within the constraints defined by
      these
      circuit breakers when a circuit breaker is present and that it should not
      cause congestion collapse when a circuit breaker is not implemented.</t>

      <t>Given
      <t indent="0" pn="section-1-6">Given that this use case is the focus of this document, use cases
      involving non-interactive media such as video streaming, streaming and use cases those
      using multicast/broadcast-type technologies, are out of scope.</t>

      <t>The
      <t indent="0" pn="section-1-7">The terminology defined in <xref
      target="I-D.ietf-rtcweb-overview"></xref> target="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825"/>
      is used in this memo.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-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>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"/>.</t>
      </section>
    </section>
    <section title="Requirements">
      <t><list style="numbers">
          <t>The numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements">Requirements</name>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-1">
        <li pn="section-2-1.1" derivedCounter="1.">
          <t indent="0" pn="section-2-1.1.1">The congestion control algorithm must <bcp14>MUST</bcp14> attempt to provide
          as-low-as-possible-delay transit for interactive real-time traffic
          while still providing a useful amount of bandwidth. There may be
          lower limits on the amount of bandwidth that is useful, but this is
          largely application-specific application specific, and the application may be able to
          modify or remove flows in order to allow some useful flows to get
          enough bandwidth. (Example: For example, although there might not be enough bandwidth
	  for low-latency video+audio, but there could be enough for audio-only.) <list style="letters">
              <t>Jitter audio only.
</t>
          <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-2-1.1.2">
            <li pn="section-2-1.1.2.1" derivedCounter="a.">Jitter (variation in the bitrate over short time scales) also timescales) is also
              relevant, though moderate amounts of jitter will be absorbed
              by jitter buffers. Transit delay should be considered to track

              the short-term maximums of delay delay, including jitter.</t>

              <t>It jitter.</li>
            <li pn="section-2-1.1.2.2" derivedCounter="b.">The algorithm should provide this as-low-as-possible-delay transit and
              minimize self-induced latency even when faced with intermediate
              bottlenecks and competing flows. Competing flows may limit
              what's possible to achieve.</t>

              <t>It achieve.</li>
            <li pn="section-2-1.1.2.3" derivedCounter="c.">The algorithm should be resilience resilient to the effects of the events, such as
              routing changes, which may alter or remove bottlenecks or change
              the bandwidth available available, especially if there is a reduction in
              available bandwidth or increase in observed delay. It is
              expected that the mechanism reacts quickly to the such events to
              avoid delay buildup. In the context of this memo, a 'quick' "quick"
              reaction is on the order of a few RTTs, subject to the
              constraints of the media codec, but is likely within a second.
              Reaction on the next RTT is explicitly not required, since many
              codecs cannot adapt their sending rate that quickly, but equally
              at the same time a response cannot be arbitrarily delayed.</t>

              <t>It delayed.</li>
            <li pn="section-2-1.1.2.4" derivedCounter="d.">The algorithm should react quickly to handle both local and remote
              interface changes (WLAN (e.g., WLAN to 3G data, etc) which data) that may radically
              change the bandwidth available or bottlenecks, especially if
              there is a reduction in available bandwidth or an increase in
              bottleneck delay. It is assumed that an interface change can
              generate a notification to the algorithm.</t>

              <t>The algorithm.</li>
            <li pn="section-2-1.1.2.5" derivedCounter="e.">The real-time interactive media applications can be rate
              limited. This means the offered loads can be less than the
              available bandwidth at any given moment, moment and may vary
              dramatically over time, including dropping to no load and then
              resuming a high load, such as in a mute/unmute operation. Hence,
              the algorithm must be designed to handle such behavior from
              a media source or application. Note that the reaction time between
              a change in the bandwidth available from the algorithm and a
              change in the offered load is variable, and it may be different
              when increasing versus decreasing.</t>

              <t>The decreasing.</li>
            <li pn="section-2-1.1.2.6" derivedCounter="f.">The algorithm requires is required to avoid building up queues when
              competing with short-term bursts of traffic (for example,
              traffic generated by web-browsing) web browsing), which can quickly saturate a
              local-bottleneck router or link, link but also clear quickly. The
              algorithm should also react quickly to regain its previous share
              of the bandwidth when the local-bottleneck local bottleneck or link is
              cleared.</t>

              <t>Similarly
              cleared.</li>
            <li pn="section-2-1.1.2.7" derivedCounter="g.">Similarly, periodic bursty flows such as MPEG DASH <xref
              target="MPEG_DASH"></xref> target="MPEG_DASH" format="default" sectionFormat="of" derivedContent="MPEG_DASH"/> or proprietary media
	    streaming
              algorithms may compete in bursts with the algorithm, algorithm and may not
              be adaptive within a burst. They are often layered on top of TCP
              but use TCP in a bursty manner that can interact poorly with
              competing flows during the bursts. The algorithm must not
              increase the already existing delay buildup during those bursts.
              Note that this competing traffic may be on a shared access link,
              or the traffic burst may cause a shift in the location of the
              bottleneck for the duration of the burst.</t>
            </list></t>

          <t>The burst.</li>
          </ol>
        </li>
        <li pn="section-2-1.2" derivedCounter="2.">
          <t indent="0" pn="section-2-1.2.1">The algorithm must <bcp14>MUST</bcp14> be fair to other flows, both real-time flows
          (such as other instances of itself), itself) and TCP flows, both long-lived flows
          and bursts such as the traffic generated by a typical web browsing web-browsing
          session. Note that 'fair' "fair" is a rather hard-to-define term. It should <bcp14>SHOULD</bcp14>
          be fair with itself, giving a fair share of the bandwidth to multiple
          flows with similar RTTs, and if possible to multiple flows with
          different RTTs.<list style="letters">
              <t>Existing RTTs.
</t>
          <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-2-1.2.2">
            <li pn="section-2-1.2.2.1" derivedCounter="a.">Existing flows at a bottleneck must also be fair to new flows
              to that bottleneck, bottleneck and must allow new flows to ramp up to a
              useful share of the bottleneck bandwidth as quickly as possible.
              A useful share will depend on the media types involved, total
              bandwidth available available, and the user experience user-experience requirements of a
              particular service. Note that relative RTTs may affect the rate
	      at which new flows can ramp up to a reasonable share.</t>
            </list></t>

          <t>The share.</li>
          </ol>
        </li>
        <li pn="section-2-1.3" derivedCounter="3.">
          <t indent="0" pn="section-2-1.3.1">The algorithm should not <bcp14>SHOULD NOT</bcp14> starve competing TCP flows, flows and should <bcp14>SHOULD</bcp14>,
          as best as possible possible, avoid starvation by TCP flows.<list
              style="letters">
              <t>The flows.</t>
          <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-2-1.3.2">
            <li pn="section-2-1.3.2.1" derivedCounter="a.">The congestion control should prioritise prioritize achieving a useful
              share of the bandwidth depending on the media types and total
              available bandwidth over achieving as low as possible as-low-as-possible transit
              delay, when these two requirements are in conflict.</t>
            </list></t>

          <t>The conflict.</li>
          </ol>
        </li>
        <li pn="section-2-1.4" derivedCounter="4.">
          <t indent="0" pn="section-2-1.4.1">The algorithm should <bcp14>SHOULD</bcp14> adapt as quickly as possible adapt to initial
          network conditions at the start of a flow. This should <bcp14>SHOULD</bcp14> occur both if whether
          the initial bandwidth is above or below the bottleneck bandwidth.
          <list style="letters">
              <t>The
          </t>
          <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-2-1.4.2">
            <li pn="section-2-1.4.2.1" derivedCounter="a.">The algorithm should allow different modes of adaptation adaptation; for
              example,the
              example, the startup adaptation may be faster than adaptation
              later in a flow. It should allow for both slow-start operation
              (adapt up) and history-based startup (start at a point expected
              to be at or below channel bandwidth from historical information,
              which may need to adapt down quickly if the initial guess is
              wrong). Starting too low and/or adapting up too slowly can cause
              a critical point in a personal communication to be poor
              ("Hello!").
              Starting over-bandwidth too high above the available bandwidth causes other problems for
              user experience, so there's a tension here. Alternative methods
              to help startup like startup, such as probing during setup with dummy data data, may be
              useful in some applications; in some cases cases, there will be a
              considerable gap in time between flow creation and the initial
              flow of data. Again, A a flow may need to change adaptation rates
              due to network conditions or changes in the provided flows (such
              as un-muting unmuting or sending data after a gap).</t>
            </list></t>

          <t>The gap).</li>
          </ol>
        </li>
        <li pn="section-2-1.5" derivedCounter="5.">
          <t indent="0" pn="section-2-1.5.1">The algorithm should <bcp14>SHOULD</bcp14> be stable if the RTP streams are halted or
          discontinuous (for example - example, when using Voice Activity Detection). <list
              style="letters">
              <t>After </t>
          <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-2-1.5.2">
            <li pn="section-2-1.5.2.1" derivedCounter="a.">After stream resumption, the algorithm should attempt to
              rapidly regain its previous share of the bandwidth; the
              aggressiveness with which this is done will decay with the
              length of the pause.</t>
            </list></t>

          <t>The pause.</li>
          </ol>
        </li>
        <li pn="section-2-1.6" derivedCounter="6.">
          <t indent="0" pn="section-2-1.6.1">Where possible, the algorithm should where possible <bcp14>SHOULD</bcp14> merge information across
          multiple RTP streams sent between two endpoints, endpoints when those RTP
          streams share a common bottleneck, whether or not those streams are
          multiplexed onto the same ports, in order to ports. This will allow congestion
          control of the set of streams together instead of as multiple
          independent streams. This allows It will also allow better overall bandwidth
          management, faster response to changing conditions, and fairer
          sharing of bandwidth with other network users.<list style="letters">
              <t>The users.</t>
          <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-2-1.6.2">
            <li pn="section-2-1.6.2.1" derivedCounter="a.">The algorithm should also share information and adaptation
              with other non-RTP flows between the same endpoints, such as a
              WebRTC DataChannel data channel <xref
              target="I-D.ietf-rtcweb-data-channel"></xref>, target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/>, when
              possible.</t>

              <t>When
              possible.</li>
            <li pn="section-2-1.6.2.2" derivedCounter="b.">When there are multiple streams across the same 5-tuple
              coordinating their bandwidth use and congestion control, the
              algorithm should allow the application to control the relative
              split of available bandwidth. The most correlated bandwidth
              usage would be with other flows on the same 5-tuple, but there
              may be use in coordinating measurement and control of the local
              link(s). Use of information about previous flows, especially on
              the same 5-tuple, may be useful input to the algorithm,
              especially to regarding startup performance of a new flow.</t>
            </list></t>

          <t>The flow.</li>
          </ol>
        </li>
        <li pn="section-2-1.7" derivedCounter="7.">
          <t indent="0" pn="section-2-1.7.1">The algorithm should not <bcp14>SHOULD NOT</bcp14> require any special support from network
          elements to convey congestion related information to be functional. able to convey congestion-related information.
          As much as possible, it should <bcp14>SHOULD</bcp14> leverage available information about
          the incoming flow to provide feedback to the sender. Examples of
          this information are the packet arrival times, acknowledgements and
          feedback, packet timestamps, and packet losses, and Explicit Congestion
          Notification (ECN) <xref target="RFC3168"></xref>; target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>; all of these can
          provide information about the state of the path and any bottlenecks.
          However, the use of available information is algorithm
          dependent.<list style="letters">
              <t>Extra
          dependent.</t>
          <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-2-1.7.2">
            <li pn="section-2-1.7.2.1" derivedCounter="a.">Extra information could be added to the packets to provide
              more detailed information on actual send times (as opposed to
              sampling times), but such information should not be required.</t>
            </list></t>

          <t>Since required.</li>
          </ol>
        </li>
        <li pn="section-2-1.8" derivedCounter="8.">
          <t indent="0" pn="section-2-1.8.1">Since the assumption here is a set of RTP streams, the
          backchannel typically should <bcp14>SHOULD</bcp14> be done via RTCP<xref
          target="RFC3550"></xref>; the RTP Control Protocol
	  (RTCP) <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>; instead, one alternative
	  would be to include it
          instead
          in a reverse RTP reverse-RTP channel using header extensions.<list
              style="letters">
              <t>In extensions.</t>
          <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-2-1.8.2">
            <li pn="section-2-1.8.2.1" derivedCounter="a.">In order to react sufficiently quickly when using RTCP for a
              backchannel, an RTP profile such as RTP/AVPF <xref
              target="RFC4585"></xref> target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/> or RTP/SAVPF <xref
              target="RFC5124"></xref> target="RFC5124" format="default" sectionFormat="of" derivedContent="RFC5124"/> that allows sufficiently frequent
              feedback must be used. Note that in some cases, backchannel
              messages may be delayed until the RTCP channel can be allocated
              enough bandwidth, even under AVPF rules. This may also imply
              negotiating a higher maximum percentage for RTCP data or
              allowing solutions to violate or modify the rules specified for
              AVPF.</t>

              <t>Bandwidth
              AVPF.</li>
            <li pn="section-2-1.8.2.2" derivedCounter="b.">Bandwidth for the feedback messages should be minimized (such
	    using techniques such as via RFC 5506 those in <xref target="RFC5506"></xref>to target="RFC5506" format="default" sectionFormat="of" derivedContent="RFC5506"/>, to allow RTCP
              without Sender Reports/Receiver Reports)</t>

              <t>Backchannel Sender/Receiver Reports.</li>
            <li pn="section-2-1.8.2.3" derivedCounter="c.">Backchannel data should be minimized to avoid taking too much
              reverse-channel bandwidth (since this will often be used in a
              bidirectional set of flows). In areas of stability, backchannel
              data may be sent more infrequently so long as algorithm
              stability and fairness are maintained. When the channel is
              unstable or has not yet reached equilibrium after a change,
              backchannel feedback may be more frequent and use more
              reverse-channel bandwidth. This is an area with considerable
              flexibility of design, and different approaches to backchannel
              messages and frequency are expected to be evaluated.</t>
            </list></t>

          <t>Flows evaluated.</li>
          </ol>
        </li>
        <li pn="section-2-1.9" derivedCounter="9.">
          <t indent="0" pn="section-2-1.9.1">Flows managed by this algorithm and flows competing against each
	  other at a
          bottleneck may have different DSCP<xref target="RFC5865"></xref> Differentiated Services Code Point
	  (DSCP) <xref target="RFC5865" format="default" sectionFormat="of" derivedContent="RFC5865"/>
          markings depending on the type of traffic, traffic or may be subject to
          flow-based QoS. A particular bottleneck or section of the network
          path may or may not honor DSCP markings. The algorithm should <bcp14>SHOULD</bcp14>
          attempt to leverage DSCP markings when they're available.<list
              style="letters">
              <t>In WebRTC, a division of packets into 4 classes is envisioned
              in order of priority: faster-than-audio, audio, video,
              best-effort, and bulk-transfer. Typically the flows managed by
              this algorithm would be audio or video in that hierarchy, and
              feedback flows would be faster-than-audio.</t>
            </list></t>

          <t>The available.</t>
        </li>
        <li pn="section-2-1.10" derivedCounter="10.">The algorithm should <bcp14>SHOULD</bcp14> sense the unexpected lack of backchannel
          information as a possible indication of a channel overuse channel-overuse problem
          and react accordingly to avoid burst events causing a congestion
          collapse.</t>

          <t>The
          collapse.</li>
        <li pn="section-2-1.11" derivedCounter="11.">The algorithm should <bcp14>SHOULD</bcp14> be stable and maintain low-delay low delay when faced
          with Active Queue Management (AQM) algorithms. Also note that these
          algorithms may apply across multiple queues in the bottleneck, bottleneck or to
          a single queue</t>
        </list></t> queue.</li>
      </ol>
    </section>
    <section title="Deficiencies of existing mechanisms ">
      <t>Among numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-deficiencies-of-existing-me">Deficiencies of Existing Mechanisms</name>
      <t indent="0" pn="section-3-1">Among the existing congestion control mechanisms mechanisms, TCP Friendly Rate
      Control (TFRC) <xref target="RFC5348"></xref> target="RFC5348" format="default" sectionFormat="of" derivedContent="RFC5348"/> is the one which that claims to
      be suitable for real-time interactive media. TFRC is, is an equation based, equation-based
      congestion control mechanism which that provides a reasonably fair share of the
      bandwidth when competing with TCP flows and offers much lower throughput
      variations than TCP. This is achieved by a slower response to the
      available bandwidth change than TCP. TFRC is designed to perform best
      with applications which has that have a fixed packet size and does do not have a fixed
      period between sending packets.</t>

      <t>TFRC operates on detecting
      <t indent="0" pn="section-3-2">TFRC detects loss events and reacts to congestion-caused loss caused by
      congestion by
      reducing its sending rate. It allows applications to
      increase the sending rate until loss is observed in the flows. As it is
      noted in IAB/IRTF report <xref target="RFC7295"></xref> target="RFC7295" format="default" sectionFormat="of" derivedContent="RFC7295"/>, large buffers
      are available in the network elements elements, which introduces introduce additional delay
      in the communication, it communication. It becomes important to take all possible
      congestion indications into considerations. consideration. Looking at the current
      Internet deployment, TFRC's biggest deficiency is that it only consideration of considers
      loss events as a congestion indication can be considered as biggest lacking.</t>

      <t>A indication.
</t>
      <t indent="0" pn="section-3-3">A typical real-time interactive communication includes live encoded live-encoded
      audio and video flow(s). In such a communication scenario scenario, an audio
      source typically needs a fixed interval between packets, packets and needs to
      vary
      their the segment size of the packets instead of their the packet rate in
      response to
      congestion and congestion; therefore, it sends smaller packets, a packets.
      A variant of TFRC , TFRC, Small-Packet
      TFRC (TFRC-SP) <xref target="RFC4828"></xref> target="RFC4828" format="default" sectionFormat="of" derivedContent="RFC4828"/>, addresses the issues
      related to such kind of sources ; a sources. A video source generally varies video
      frame sizes, can produce large frames which that need to be further
      fragmented to fit into path Maximum Transmission Unit (MTU) size, and
      have
      has an almost fixed interval between producing frames under a certain
      frame rate, rate. TFRC is known to be less optimal when using with such video
      sources.</t>

      <t>There
      <t indent="0" pn="section-3-4">There are also some mismatches between TFRC's design assumptions and
      how the media sources in a typical real-time interactive application
      works.
      work. TFRC is design designed to maintain a smooth sending rate however rate; however, media
      sources can change rates in steps for both rate increase and rate
      decrease. TFRC can operate in two modes - modes: i) Bytes bytes per second and ii)
      packets per second, where typical real-time interactive media sources
      operates
      operate on bit per second. There are also limitations on how quickly
      the media sources can adapt to specific sending rates. The modern Modern video
      encoders can operate on in a mode where in which they can vary the output bitrate a
      lot depending on the way there they are configured, the current scene it is
      encoding they are
      encoding, and more. Therefore, it is possible that the video source does will
      not always output at a bitrate they are allowed to. an allowable bitrate. TFRC tries to raise increase
      its sending rate when transmitting at the maximum allowed rate rate, and it increases
      only twice the current transmission rate hence rate; hence, it may create issues when
      the video source sources vary their bitrates.</t>

      <t>Moreover,
      <t indent="0" pn="section-3-5">Moreover, there are a number of studies on TFRC which shows it's
      limitations which includes that show its
      limitations, including TFRC's unfairness on to low statistically
      multiplexed links, oscillatory behavior, performance issue issues in highly
      dynamic loss rates conditions loss-rate conditions, and more <xref target="CH09"></xref>.</t>

      <t>Looking target="CH09" format="default" sectionFormat="of" derivedContent="CH09"/>.</t>
      <t indent="0" pn="section-3-6">Looking at all these deficiencies deficiencies, it can be concluded that the
      requirements of for a congestion control mechanism for real-time interactive
      media cannot be met by TFRC as defined in the standard.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">This document makes has no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t> IANA actions.</t>
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>An numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">An attacker with the ability to delete, delay delay, or insert messages in into
      the flow can fake congestion signals, unless they are passed on a
      tamper-proof path. Since some possible algorithms depend on the timing
      of packet arrival, even a traditional traditional, protected channel does not fully
      mitigate such attacks.</t>

      <t>An
      <t indent="0" pn="section-5-2">An attack that reduces bandwidth is not necessarily significant,
      since an on-path attacker could break the connection by discarding all
      packets. Attacks that increase the perceived available bandwidth are
      conceivable,
      conceivable and need to be evaluated. Such attacks could result in
      starvation of competing flows and permit amplification attacks.</t>

      <t>Algorithm
      <t indent="0" pn="section-5-3">Algorithm designers should consider the possibility of malicious
      on-path attackers.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document is the result of discussions in various fora of the
      WebRTC effort,
  </middle>
  <back>
    <references pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references pn="section-6.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 initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <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="RFC3550" target="https://www.rfc-editor.org/info/rfc3550" quoteTitle="true" derivedAnchor="RFC3550">
          <front>
            <title>RTP: A Transport Protocol for Real-Time Applications</title>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Casner" fullname="S. Casner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Frederick" fullname="R. Frederick">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Jacobson" fullname="V. Jacobson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="July"/>
            <abstract>
              <t indent="0">This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="64"/>
          <seriesInfo name="RFC" value="3550"/>
          <seriesInfo name="DOI" value="10.17487/RFC3550"/>
        </reference>
        <reference anchor="RFC4585" target="https://www.rfc-editor.org/info/rfc4585" quoteTitle="true" derivedAnchor="RFC4585">
          <front>
            <title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)</title>
            <author initials="J." surname="Ott" fullname="J. Ott">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Wenger" fullname="S. Wenger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Sato" fullname="N. Sato">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Burmeister" fullname="C. Burmeister">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Rey" fullname="J. Rey">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t indent="0">Real-time media streams that use RTP are, to some degree, resilient against packet losses.  Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term.  This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms).  This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented.  This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4585"/>
          <seriesInfo name="DOI" value="10.17487/RFC4585"/>
        </reference>
        <reference anchor="RFC5124" target="https://www.rfc-editor.org/info/rfc5124" quoteTitle="true" derivedAnchor="RFC5124">
          <front>
            <title>Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)</title>
            <author initials="J." surname="Ott" fullname="J. Ott">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Carrara" fullname="E. Carrara">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="February"/>
            <abstract>
              <t indent="0">An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively.  This memo specifies the combination of both profiles to enable secure RTP communications with feedback.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5124"/>
          <seriesInfo name="DOI" value="10.17487/RFC5124"/>
        </reference>
        <reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825" quoteTitle="true" derivedAnchor="RFC8825">
          <front>
            <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
            <author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8825"/>
          <seriesInfo name="DOI" value="10.17487/RFC8825"/>
        </reference>
      </references>
      <references pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="CH09" quoteTitle="true" derivedAnchor="CH09">
          <front>
            <title>Designing TCP-Friendly Window-based Congestion Control for Real-time Multimedia Applications</title>
            <author fullname="Soo-Hyun Choi" initials="S" surname="Choi">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Mark Handley" initials="M" surname="Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" year="2009"/>
          </front>
          <refcontent>Proceedings of PFLDNeT</refcontent>
        </reference>
        <reference anchor="MPEG_DASH" target="https://www.iso.org/standard/79329.html" quoteTitle="true" derivedAnchor="MPEG_DASH">
          <front>
            <title>Information Technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats</title>
            <author>
              <organization showOnFrontPage="true">ISO</organization>
            </author>
            <date month="December" year="2019"/>
          </front>
          <seriesInfo name="ISO/IEC" value="23009-1:2019"/>
        </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 initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Black" fullname="D. Black">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2001" month="September"/>
            <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="RFC4828" target="https://www.rfc-editor.org/info/rfc4828" quoteTitle="true" derivedAnchor="RFC4828">
          <front>
            <title>TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant</title>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Kohler" fullname="E. Kohler">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="April"/>
            <abstract>
              <t indent="0">This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.</t>
              <t indent="0">TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448).  TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size.  This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets.  The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes.  TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.</t>
              <t indent="0">Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates.  However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth.  This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4828"/>
          <seriesInfo name="DOI" value="10.17487/RFC4828"/>
        </reference>
        <reference anchor="RFC5348" target="https://www.rfc-editor.org/info/rfc5348" quoteTitle="true" derivedAnchor="RFC5348">
          <front>
            <title>TCP Friendly Rate Control (TFRC): Protocol Specification</title>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Padhye" fullname="J. Padhye">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Widmer" fullname="J. Widmer">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="September"/>
            <abstract>
              <t indent="0">This document specifies TCP Friendly Rate Control (TFRC).  TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment.  It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.</t>
              <t indent="0">This document obsoletes RFC 3448 and updates RFC 4342.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5348"/>
          <seriesInfo name="DOI" value="10.17487/RFC5348"/>
        </reference>
        <reference anchor="RFC5506" target="https://www.rfc-editor.org/info/rfc5506" quoteTitle="true" derivedAnchor="RFC5506">
          <front>
            <title>Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences</title>
            <author initials="I." surname="Johansson" fullname="I. Johansson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="April"/>
            <abstract>
              <t indent="0">This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size.  The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed.  Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5506"/>
          <seriesInfo name="DOI" value="10.17487/RFC5506"/>
        </reference>
        <reference anchor="RFC5865" target="https://www.rfc-editor.org/info/rfc5865" quoteTitle="true" derivedAnchor="RFC5865">
          <front>
            <title>A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic</title>
            <author initials="F." surname="Baker" fullname="F. Baker">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Polk" fullname="J. Polk">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Dolly" fullname="M. Dolly">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="May"/>
            <abstract>
              <t indent="0">This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic.  This traffic class conforms to the Expedited Forwarding Per-Hop Behavior.  This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission.  This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5865"/>
          <seriesInfo name="DOI" value="10.17487/RFC5865"/>
        </reference>
        <reference anchor="RFC7295" target="https://www.rfc-editor.org/info/rfc7295" quoteTitle="true" derivedAnchor="RFC7295">
          <front>
            <title>Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication</title>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Eggert" fullname="L. Eggert">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Z." surname="Sarker" fullname="Z. Sarker">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="July"/>
            <abstract>
              <t indent="0">This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012.  The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication.  This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community.</t>
              <t indent="0">The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7295"/>
          <seriesInfo name="DOI" value="10.17487/RFC7295"/>
        </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 initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Singh" fullname="V. Singh">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="March"/>
            <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="RFC8831" target="https://www.rfc-editor.org/info/rfc8831" quoteTitle="true" derivedAnchor="RFC8831">
          <front>
            <title>WebRTC Data Channels</title>
            <author initials="R" surname="Jesup" fullname="Randell Jesup">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Loreto" fullname="Salvatore Loreto">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Tüxen" fullname="Michael Tüxen">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8831"/>
          <seriesInfo name="DOI" value="10.17487/RFC8831"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">This document is the result of discussions in various fora of the
      WebRTC effort, in particular on the rtp-congestion@alvestrand.no &lt;rtp-congestion@alvestrand.no&gt; mailing
      list. Many people contributed their thoughts to this.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.3550'?>

      <?rfc include='reference.RFC.4585'?>

      <?rfc include='reference.RFC.5124'?>

      <?rfc include='reference.I-D.ietf-rtcweb-overview'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.3168'?>

      <?rfc include='reference.RFC.5506'?>

      <?rfc include='reference.RFC.5865'?>

      <?rfc include='reference.RFC.5348'?>

      <?rfc include='reference.RFC.4828'?>

      <?rfc include='reference.RFC.7295'?>

      <?rfc include='reference.I-D.ietf-rtcweb-data-channel'?>

      <?rfc include='reference.I-D.ietf-avtcore-rtp-circuit-breakers'?>

      <reference anchor="MPEG_DASH">
        <front>
          <title>Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media
          presentation description and segment formats</title>

          <author></author>

          <date month="April" year="2012" />
        </front>

        <format target="http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zip"
                type="TXT" />
      </reference>

      <reference anchor="CH09">
        <front>
          <title>Designing TCP-Friendly Window-based Congestion Control for
          Real-time Multimedia Applications</title>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Soo-Hyun Choi" initials="S" surname="Choi">
            <organization></organization> fullname="Randell Jesup" initials="R." surname="Jesup">
        <organization showOnFrontPage="true">Mozilla</organization>
        <address>
          <postal>
            <street/>
            <country>United States of America</country>
          </postal>
          <email>randell-ietf@jesup.org</email>
        </address>
      </author>
      <author fullname="Mark Handley" initials="M" surname="Handley">
            <organization></organization> fullname="Zaheduzzaman Sarker" initials="Z." role="editor" surname="Sarker">
        <organization showOnFrontPage="true">Ericsson AB</organization>
        <address>
          <postal>
                <street></street>

                <city></city>

                <region></region>

                <code></code>

                <country></country>
            <street>Torshamnsgatan 23</street>
            <city>Stockholm</city>
            <region/>
            <code>164 83</code>
            <country>Sweden</country>
          </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
          <phone>+46 10 717 37 43</phone>
          <email>zaheduzzaman.sarker@ericsson.com</email>
        </address>
      </author>

          <date day="21" month="May" year="2009" />
        </front>

        <seriesInfo name="PFLDNeT 2009 Workshop" value="" />

        <format target="www.hpcc.jp/pfldnet2009/Program_files/1569199301.pdf"
                type="PDF" />
      </reference>
    </references>
    </section>
  </back>
</rfc>