<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!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"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8836" category="info" docName="draft-ietf-rmcat-cc-requirements-09"
     submissionType="IETF" consensus="true" ipr="trust200902" obsoletes=""
     updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
     version="3" docName="draft-ietf-rmcat-cc-requirements-09">

  <!-- xml2rfc v2v3 conversion 2.34.0 -->
    <title abbrev="RTP Media Congestion Control Requirements ">Congestion
		   Requirements">Congestion Control Requirements for
    Interactive Real-Time Media</title>
    <seriesInfo name="RFC" value="8836"/>
    <author fullname="Randell Jesup" initials="R." surname="Jesup">
    <author fullname="Zaheduzzaman Sarker" initials="Z." role="editor" surname="Sarker">






    <date /> month="September" year="2020"/>

    <keyword>Interactive multimedia</keyword>
    <keyword>video communication</keyword>

      <t>Congestion control is needed for all data transported across the
      Internet, in order to promote fair usage and prevent congestion
      collapse. The requirements for interactive, point-to-point real-time
      multimedia, which needs low-delay, semi-reliable data delivery, are
      different from the requirements for bulk transfer like FTP or bursty
      transfers like Web 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 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

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>. The terms are presented in many cases
      using lowercase for readability.</t>
    <section title="Introduction"> numbered="true" toc="default">
      <t>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
      <t>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 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
      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 -- 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, data delivered late is commonly useless.</t>

      <t>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 particular protocol portfolio being developed for this use case
      is WebRTC <xref target="I-D.ietf-rtcweb-overview"></xref>, target="RFC8825" format="default"/>, where one
      envisions sending multiple flows using the Real-time Transport Protocol
      (RTP) <xref target="RFC3550"></xref> target="RFC3550" format="default"/> 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"/>,
      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
      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 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 terminology defined in <xref
      target="I-D.ietf-rtcweb-overview"></xref> target="RFC8825" format="default"/>
      is used in this memo.</t>

    <section title="Requirements">
      <t><list style="numbers"> numbered="true" toc="default">
      <ol spacing="normal" type="1">
          <t>The congestion control algorithm must 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.
          <ol spacing="normal" type="a">
            <li>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>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>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>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>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>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

            <li>Similarly, periodic bursty flows such as MPEG DASH <xref
	    target="MPEG_DASH" format="default"/> or proprietary media
              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> burst.</li>
          <t>The algorithm must 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
          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.
          <ol spacing="normal" type="a">
            <li>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> share.</li>
          <t>The algorithm should not starve competing TCP flows, flows and should should,
          as best as possible possible, avoid starvation by TCP flows.<list
              <t>The flows.</t>
          <ol spacing="normal" type="a">
            <li>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> conflict.</li>
          <t>The algorithm should adapt as quickly as possible adapt to initial
          network conditions at the start of a flow. This should occur both if whether
          the initial bandwidth is above or below the bottleneck bandwidth.
          <list style="letters">
          <ol spacing="normal" type="a">
            <li>The algorithm should allow different modes of adaptation adaptation; for
              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
              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> gap).</li>
          <t>The algorithm should be stable if the RTP streams are halted or
          discontinuous (for example - example, when using Voice Activity Detection). <list
              <t>After </t>
          <ol spacing="normal" type="a">
            <li>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>

          <t>The pause.</li>
          <t>Where possible, the algorithm should where possible 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">
            <li>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"/>, when

            <li>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> flow.</li>
          <t>The algorithm should not 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 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"/>; 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">
          <ol spacing="normal" type="a">
            <li>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> required.</li>
          <t>Since the assumption here is a set of RTP streams, the
          backchannel typically should be done via RTCP<xref
          target="RFC3550"></xref>; the RTP Control Protocol
	  (RTCP) <xref target="RFC3550" format="default"/>; instead, one alternative
	  would be to include it
          in a reverse RTP reverse-RTP channel using header extensions.<list
              <t>In extensions.</t>
          <ol spacing="normal" type="a">
            <li>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"/> or RTP/SAVPF <xref
              target="RFC5124"></xref> target="RFC5124" format="default"/> 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

            <li>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"/>, to allow RTCP
              without Sender Reports/Receiver Reports)</t>

              <t>Backchannel Sender/Receiver Reports.</li>
            <li>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> evaluated.</li>
          <t>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"/>
          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
          attempt to leverage DSCP markings when they're available.<list
              <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>

          <t>The available.</t>
        <li>The algorithm should 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

        <li>The algorithm should 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>
    <section title="Deficiencies numbered="true" toc="default">
      <name>Deficiencies of existing mechanisms "> Existing Mechanisms</name>
      <t>Among the existing congestion control mechanisms mechanisms, TCP Friendly Rate
      Control (TFRC) <xref target="RFC5348"></xref> target="RFC5348" format="default"/> 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 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"/>, 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> indication.
      <t>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
      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"/>, 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
      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
      <t>There are also some mismatches between TFRC's design assumptions and
      how the media sources in a typical real-time interactive application
      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
      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, 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> target="CH09" format="default"/>.</t>
      <t>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 anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>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 anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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 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 and need to be evaluated. Such attacks could result in
      starvation of competing flows and permit amplification attacks.</t>
      <t>Algorithm designers should consider the possibility of malicious
      on-path attackers.</t>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document is the result of discussions in various fora of the
      WebRTC effort, in particular on the rtp-congestion@alvestrand.no mailing
      list. Many people contributed their thoughts to this.</t>
    <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'?>

        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"/>

<!-- draft-ietf-rtcweb-overview: RFC 8825 -->
<reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825">
    <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
    <author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
      <organization />
    <date month="September" year="2020" />
  <seriesInfo name="RFC" value="8825" />
  <seriesInfo name="DOI" value="10.17487/RFC8825"/>


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

        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5506.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5865.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5348.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4828.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7295.xml"/>

<!-- draft-ietf-rtcweb-data-channel: 8831 -->
<reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
<title>WebRTC Data Channels</title>
<author initials="R" surname="Jesup" fullname="Randell Jesup">
<author initials="S" surname="Loreto" fullname="Salvatore Loreto">
<author initials="M" surname="Tüxen" fullname="Michael Tüxen">
<date month='September' year='2020'/>
<seriesInfo name="RFC" value="8831"/>
<seriesInfo name="DOI" value="10.17487/RFC8831"/>

<!-- draft-ietf-avtcore-rtp-circuit-breakers;  RFC 8083 (Published) -->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml"/>
        <reference anchor="MPEG_DASH"> anchor="MPEG_DASH" target="https://www.iso.org/standard/79329.html">
            <title>Information Technology -- Dynamic adaptive streaming over
	    HTTP (DASH) -- Part 1: Media presentation description and segment

            <date month="April" year="2012" /> month="December" year="2019"/>

        <format target="http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zip"
                type="TXT" />
          <seriesInfo name="ISO/IEC" value="23009-1:2019"/>

        <reference anchor="CH09">
            <title>Designing TCP-Friendly Window-based Congestion Control for
          Real-time Multimedia Applications</title>
            <author fullname="Soo-Hyun Choi" initials="S" surname="Choi">
            <author fullname="Mark Handley" initials="M" surname="Handley">









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

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

        <format target="www.hpcc.jp/pfldnet2009/Program_files/1569199301.pdf"
                type="PDF" />
         <refcontent>Proceedings of PFLDNeT</refcontent>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <t>This document is the result of discussions in various fora of the
      WebRTC effort, in particular on the &lt;rtp-congestion@alvestrand.no&gt; mailing
      list. Many people contributed their thoughts to this.</t>