<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3551 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY rfc3611 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc4585 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc4588 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4588.xml">
<!ENTITY rfc5109 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5109.xml">
<!ENTITY rfc5506 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5506.xml">
<!ENTITY rfc5681 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY rfc6363 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6363.xml">
<!ENTITY rfc5725 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5725.xml">
<!ENTITY rfc7097 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7097.xml">
<!ENTITY rfc7509 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7509.xml">
<!ENTITY rfc6817 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6817.xml">
<!ENTITY I-D.ietf-rmcat-cc-requirements PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-cc-requirements.xml">
<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circuit-breakers.xml">
<!ENTITY I-D.ietf-rmcat-gcc PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-gcc.xml">
<!ENTITY I-D.ietf-rmcat-scream-cc PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-scream-cc.xml">
<!ENTITY I-D.ietf-rmcat-eval-test PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-test.xml">
<!ENTITY I-D.ietf-payload-flexible-fec-scheme PUBLIC ""
"http://xml2rfc.ietf.org//public/rfc/bibxml3/reference.I-D.ietf-payload-flexible-fec-scheme.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<rfc ipr="trust200902" docName="draft-singh-rmcat-adaptive-fec-03" category="exp">
  <!-- TODO: Experimental, right? -->
  <!-- What is the category field value-->
  <front>
    <title abbrev="Using FEC for Congestion Control">
      Congestion Control Using FEC for Conversational Media
    </title>

    <author fullname="Varun Singh" initials="V." surname="Singh">
      <organization abbrev="callstats.io">Nemu Dialogue Systems Oy</organization>
      <address>
        <postal>
          <street>Runeberginkatu 4c A 4 </street>
          <city>Helsinki</city>
          <code>00100</code>
          <country>Finland</country>
        </postal>
          <email>varun.singh@iki.fi</email>
        <uri>http://www.callstats.io/</uri>
      </address>
    </author>

    <author initials="M." surname="Nagy" fullname="Marcin Nagy">
      <organization>Aalto University</organization>
      <address>
        <postal>
          <street>School of Electrical Engineering</street>
          <street>Otakaari 5 A</street>
          <city>Espoo</city>
          <region>FIN</region>
          <code>02150</code>
          <country>Finland</country>
        </postal>
        <email>marcin.nagy@aalto.fi</email>
      </address>
    </author>

    <author initials="J." surname="Ott" fullname="Joerg Ott">
      <organization>Technical University of Munich</organization>
      <address>
        <postal>
          <street>Faculty of Informatics</street>
          <street>Boltzmannstrasse 3</street>
          <city>Garching bei München</city>
          <region>DE</region>
          <code>85748</code>
          <country>Germany</country>
        </postal>
        <email>ott@in.tum.de</email>
      </address>
    </author>

    <author initials="L." surname="Eggert" fullname="Lars Eggert">
      <organization abbrev="NetApp"> NetApp </organization>
      <address>
        <postal>
          <street>Sonnenallee 1</street>
          <code>85551</code> <city>Kirchheim</city>
          <country>Germany</country>
        </postal>
        <phone>+49 151 12055791</phone>
        <email>lars@netapp.com</email>
        <uri> http://eggert.org/ </uri>
      </address>
    </author>

    <date />
    <area>TSV</area>
    <workgroup>RMCAT WG</workgroup>
    <keyword>RTP</keyword>
    <keyword>RTCP</keyword>
    <keyword>Congestion Control</keyword>
    <abstract>
      <t>
        This document describes a new mechanism for conversational
        multimedia flows. The proposed mechanism uses Forward Error
        Correction (FEC) encoded RTP packets (redundant packets) along
        side the media packets to probe for available network capacity. A
        straightforward interpretation is, the sending endpoint
        increases the transmission rate by keeping the media rate constant
        but increases the amount of FEC. If no losses and discards occur,
        the endpoint can then increase the media rate. If losses occur,
        the redundant FEC packets help in recovering the lost packets.
        Consequently, the endpoint can vary the FEC bit rate to
        conservatively (by a small amount) or aggressively (by a large
        amount) probe for available network capacity.
      </t>

        <!-- and the measured RTT value is stable? -->
    </abstract>
  </front>
  <middle>
    <section title="Introduction">

      <t>
        The <xref target="RFC3550">Real-time Transport Protocol (RTP)</xref>
        is widely used in voice telephony and video conferencing systems.
        Many of these systems run over best-effort UDP/IP networks, and are
        required to implement congestion to adapt the transmission rate of
        the RTP streams to match the available network capacity, while
        maintaining the user-experience <xref target="I-D.ietf-rmcat-cc-requirements" />.
        The <xref target="I-D.ietf-avtcore-rtp-circuit-breakers">circuit breakers</xref>
        describe a minimal set of conditions when an RTP stream is causing
        severe congestion and should cease transmission. Consequently, the
        congestion control algorithm are expected to avoid triggering these
        conditions.
      </t>

      <t>
        Conversational multimedia systems use Negative Acknowledgment (NACK),
        Forward Error Correction (FEC), and Reference Picture Selection (RPS)
        to protect against packet loss. These are used in addition to the
        codec-dependent resilience methods (for e.g., full intra-refresh and
        error-concealment). In this way, the multimedia system is anyway
        trading off part of the transmission rate for redundancy or retransmissions
        to reduce the effects of packet loss. An endpoint often prefers using
        FEC in high latency networks where retransmissions may arrive later than
        the playout time of the packet (due to the size of the dejitter buffer)
        <xref target="Holmer13" />. Therefore, the endpoint needs to adapt the
        transmission rate to best fit the changing network capacity and the
        amount of redundancy based on the observed/expected loss rate and
        network latency. <xref target="fig-apply-er" /> shows the applicability
        of different error-resilience schemes based on the end-to-end latency
        and the observed packet loss <xref target="Devadoss08" />.
      </t>
<figure align="center" anchor="fig-apply-er" title="Applicability of Error
Resilience Schemes based on the network delay and observed packet loss">
<artwork align="center"><![CDATA[
   ^
   |            .__________.
   |            |          |
   |            |  UEP/FEC |
 l |____________|____.     |
 a |            |    |     |
 t |       RPS  |    |     |
 e |_______.    |    |     |
 n |       |    |    |     |
 c |       |    |____|_____|
 y | NACK  |         |
   |       |         |
   +------------------------------->
          Packet loss
]]></artwork>
</figure>

      <t>
        In this document, we describe the use of FEC packets not only
        for error-resilience but also as a probing mechanism for congestion control
        (ramping up the transmission rate).
      </t>

    </section>

    <section title="Terminology" anchor="sec-terminology">
      <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 BCP 14, <xref target="RFC2119" /> and indicate requirement
      levels for compliant implementations. </t>

      <!-- TODO: make terms consistent with taxonomy draft? -->
      <!-- Remember: media packets of an SSRC is called RTP stream. -->
      <t>
        The terminology defined in <xref target="RFC3550">RTP</xref>,
        <xref target="RFC3551">RTP Profile for Audio and Video Conferences
        with Minimal Control</xref>, <xref target="RFC3611">RTCP Extended
        Report (XR)</xref>, <xref target="RFC4585">Extended RTP Profile
        for RTCP-based Feedback (RTP/AVPF)</xref>, <xref target="RFC4588">
        RTP Retransmission Payload Format</xref>, <xref target="RFC6363">
        Forward Error Correction (FEC) Framework</xref>, and <xref
        target="RFC5506">Support for Reduced-Size RTCP</xref> apply.
      </t>
    </section>

    <section title="Concept: FEC for Congestion Control" anchor="fec-cc-concept">

      <t>
        FEC is one method for providing error-resilience, it improves
        reliability by adding redundant data to the primary media flow,
        which is used by received to recover packets that have been lost
        due to congestion or bit-errors. The congestion control algorithm
        on the other hand aims at maximizing the network path utilization,
        but risks over-estimating the available end-to-end network capacity
        leading to congestion (and therefore losses).
      </t>
      <t>
        <xref target="fig-fec-ts" />  shows the timeline of enabling and disabling FEC.
        The main idea behind using FEC for congestion control is as follows:
        the sending endpoint chooses a high FEC rate to aggressively probe for
        available capacity and conversely chooses a low FEC rate to conservatively
        probe for available capacity. During the ramp up, if a packet is lost and
        the FEC packet arrives in time for decoding, the receiver is be able to
        recover the lost packet; if no packet is lost, the sender is able to
        increase the media encoding rate by swapping out a part of the FEC rate.
        This method can be especially useful when the transmission rate is close to
        the bottleneck link rate: by choosing an appropriate FEC rate, the
        endpoint is able to probe for available capacity without changing the
        target media rate and therefore not affecting the user-experience.
      </t>
      <t>
        Hence, the congestion control algorithm is always able to probe for
        available capacity, as improved reliability compensates for possible errors
        resulting from probing for additional capacity (i.e., increase in observed
        latency and/or losses).
      </t>

<figure align="center" anchor="fig-fec-ts" title="Congestion Control enabling FEC.">
<artwork align="center"><![CDATA[
  ^  .........
  | /         \                             /
t |/           \                           /
h |   +===+===+=\=+                       /
r |   | F |   |  \|           +===+   +==/+
o +===+---+   |   \...........|.F.|...|./F|===+
u |   |   |   |   |   +===+===+---+===+---+---+
g |   |   |   |   |   | F |   |   |   |   |   |
h |   |   |   |   |===+---+   |   |   |   |   |
p |   |   |   |   |   |   |   |   |   |   |   |
u |   |   |   |   |   |   |   |   |   |   |   |
t |   |   |   |   |   |   |   |   |   |   |   |
  | s | p | i | s | d | p | i | p | s | p | i |
  +---+---+---+---+---+---+---+---+---+---+---+-->
                      time

Key:
+===+ Media with minimal FEC for error protection

+===+
| F | Media with FEC for probing and error protection
+---+

 ....
/    \  Available capacity

d,s,p,i: are the states: Decrease, Stay, Probe, Increase
]]></artwork>
</figure>


<figure align="center" anchor="fig-fec-sm" title="State machine of a
  Congestion Control enabling FEC.">
<artwork align="center"><![CDATA[
   +------------+        (B) Good conditions          +-----------+
   |            |------------------------------------>|           |
   |   STEADY   |                                     |   PROBE   |
   |            |<------------------------------------|           |
   +------------+     Probed, but Loss recovered      +-----------+
     /\ |                                               |   /\ |
     |  |(A)                                            |   |  |
     |  |_______________________________________________|   |  |(C)
 (B) |  |                      (A)                          |  |
     |  \/                                              (B) |  \/
   +------------+                                     +------------+
   |            |       (A) Unstable conditions       |            |
   |   REDUCE   |<------------------------------------|  INCREASE  |
   |            |                                     |            |
   +------------+                                     +------------+
]]></artwork>
</figure>
      <section title="States" anchor="fec-sm">
        <t>
          The <xref target="fig-fec-sm" /> illustrates the the state machine of
          a congestion control algorithm incorporating FEC for probing.
          The state transitions occur based on the information reported in the
          feedback packet. In <xref target="fig-fec-sm" /> (A) indicates congestion,
          i.e., the congestion control observes increasing delay and/or packet loss,
          or any other congestion metric, and in response the congestion control
          reduces the transmission rate. In <xref target="fig-fec-sm" /> (B) occurs
          when the congestion cues report improvement in congestion metrics, and in
          response the congestion cue increases the transmission rate.
          For probing using FEC, the congestion control needs to map to the following
          4 states: STEADY, PROBE, INCREASE, and REDUCE.
        </t>
        <t><list style="symbols">
          <t>
            STEADY state: The congestion control keeps the same target media rate
            and no additional FEC packets are generated for probing. This is a
            transient state, after which the congestion control either attempts to
            increase the transmission rate, or observes congestion and reduces
            the transmission rate.
          </t>
          <t>
            REDUCE state: The congestion control reduces the transmission rate based
            on the observed congestion cues, and generated no additional
            FEC packets than the minimum required for error-resilience. If
            in subsequent reports the conditions improve, the congestion control
            can directly transition to the PROBE state.
          </t>
          <t>
            PROBE state: The congestion control observes no congestion for two
            reporting intervals (i.e., the transmission rate should be increased).
            The endpoint maintains the same target media bit rate, and instead
            increases the amount of FEC packets, thereby increasing the transmission
            rate.
          </t>
          <t>
            INCREASE state: The endpoint is sending FEC packets and the congestion control
            observes no congestion (as reported in RTCP feedback), the media transmission
            rate is increased while maintaining minimal amount of FEC for
            error protection. In this case, the combined transmission rate (FEC+media)
            may remain the same as in the PROBE state.
            If the feedback reports packet loss, but some of these lost packets are
            recovered by the FEC packets, the congestion control can keep the same media
            bit rate and adjust the amount of FEC (compared to the previous PROBE state).
            If congestion is observed (the target rate calculated by the congestion
            control is much lower than the current media rate), the congestion control
            can transition to the REDUCE state and decrease the transmission rate.
          </t>
        </list></t>
      </section>

      <section title="Framework" anchor="fec-fw">
      <t>
        The <xref target="fig-fec-int" /> shows the interaction between the
        rate control module, the RTP and the FEC module.
      </t>

      <t>
        At the sender,
        the rate control module calculates the new bit rate. If the new bit
        rate is higher than the previous than the previous bit rate indicates
        to the FEC module that the congestion control intends to probe.
        The FEC module depending on its internal state machine decides to
        add FEC for probing or not. Thereafter it indicates to the rate control
        module the bit rate remaining for the RTP media stream, which may be
        less than equal to the calculated bit rate.
      </t>
      <t>
        At the receiver,
        the FEC module reconstructs lost packets in the primary stream from the
        packets received in the repair stream. If packets are repair it generates
        the post-repair loss report (discussed in <xref target="fec-scheme" />)
        for the corresponding RTP packets.
      </t>
      <t>
        At the sender,
        The FEC module also receives the RTCP Feedback related to the primary stream
        and any post-repair loss report. It uses the information from these RTCP
        reports to calculate the effectiveness of FEC for congestion control and is
        also the basis for changing its internal state.
      </t>
<figure align="center" anchor="fig-fec-int" title="Interaction
  of Congestion Control and FEC Module.">
<artwork align="center"><![CDATA[
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ |
  |            Media Encoder/Decoder           |
| +--------------------------------------------+ |
            |                           |
| +- -- -- -- -- -- -- -+        +- -- -- -- -+  |
  |    Rate Control     |        |     RTP    |
| |       Module        |        |            |  |
  +- -- -- -- -- -- -- -+        +- -- -- -- -+
|   ^        |                          |        |
    |        |                          | Source
|   | R      +--------------------+     |  RTP   |
    | T                           |     |
|   | C                           |     |        |
    | P                           |     |
|   |     +----------+     +----------------+    |
    | F   | FEC Code |<--->|   FEC Module   |
|   | B   +----------+     +----------------+    |
    |                        |        |  |
|   |------------------------+        |  |       |
    |        RTCP FB           Repair |  | Source
|   |                            RTP  |  |   RTP |
    |                                 |  |
| +--------------------------------------------+ |
  |           RTP Processing  Layer            |
| |                  (Queue)                   | |
  +--------------------------------------------+
|                        |                       |
  +--------------------------------------------+
| |             Transport Layer (UDP)          | |
  +--------------------------------------------+
|                        |                       |
  +--------------------------------------------+
| |                     IP                     | |
  +--------------------------------------------+
|                                                |
| Endpoint                                       |
+ - - - - - - - - - - - - - - -  - - - - - - - - +
]]></artwork>
</figure>
      </section>

      <section title="FEC Scheme" anchor="fec-scheme">
        <!--  <t>Block and Parity FEC</t> -->
        <t>
          <xref target="RFC6363" /> describes a framework for using Forward Error
          Correction (FEC) codes with RTP and allows any FEC code to be used with
          the framework. For this proposal, the FEC packets are created by
          XORing RTP media packets, the resulting redundant RTP packets are
          encoded using the scheme defined in <xref target="I-D.ietf-payload-flexible-fec-scheme" />.
        </t>
        <t>
          The endpoint  MAY use a single-frame FEC (1-dimensional) or a multi-frame
          FEC (2-dimensional) for protecting the primary RTP stream. A single-frame
          FEC protects against a single packet loss and fails when burst loss occurs.
          Using multi-frame FEC helps mitigate these issues at the cost of higher
          overhead and latency in recovering lost packets. <xref target="Holmer13" />
          shows examples of using a single- and multi-frame FEC.
         </t>
         <t>
          The receiving endpoint may report the post-repair loss (or residual
          loss) using either the report block defined in <xref target="RFC5725" />
          (Run-length encoding of packets repaired) or in
          <xref target="RFC7509" />
          (packet count of repaired packets).
         </t>
         <t>
          Additionally, the receiving may report the occurrence of losses and discards
          via a run-length encoding (RLE) of lost <xref target="RFC3611" /> (Section 4.1),
          which enables the sender to detect the burst loss length and apply appropriate
          FEC scheme.
        </t>
        <t>
          Packet that arrive too late to be played out by the receiver are discarded by
          the dejitter buffer. Typically, the dejitter buffer adjust the playout delay
          based on the observed frame inter-arrival delay, so that packets are played out
          smoothly. Reporting RLE of discarded packets <xref target="RFC7097" /> may
          further enable a sender to detect losses that occur after packet discards.
        </t>
      </section>

      <section title="Applicability to other RMCAT Schemes" anchor="fec-cc-apply">
        <t>
          [Open issue:
          The current implementation is delay based and is documented in
          <xref target="Nagy14" />. However, we would like to generalize
          the concept and apply it to different RMCAT algorithms for e.g.,
          <xref target="I-D.ietf-rmcat-gcc">Google's
          Congestion Control algorithm</xref>, <xref
          target="I-D.ietf-rmcat-scream-cc">SCReaM</xref>, etc.]
        </t>
      </section>

    </section>

    <section title="Security Considerations">
      <t>
         The security considerations of <xref target="RFC3550" />,
         <xref target="RFC4585">RTP/AVPF profile for rapid RTCP feedback</xref>,
         <xref target="I-D.ietf-avtcore-rtp-circuit-breakers">circuit breaker</xref>,
         and <xref target="RFC5109">Generic Forward Error Correction</xref> apply.
      </t>
      <t>
        If non-authenticated RTCP reports are used, an on-path attacker can send
        forged RTCP feedback packets that can disrupt the operation of the underlying
        congestion control. Additionally, the forged packets can either indicate no
        packet loss causing the congestion control to ramp-up quickly, or indicate
        high packet loss or RTT causing the circuit breaker to trigger.
      </t>
      <!-- <t>Security issues have not been discussed in this memo.</t> -->
      <!-- Congestion Collapse, Denial of Service -->
    </section>

    <section title="IANA Considerations">
      <t>There are no IANA impacts in this memo.</t>
    </section>


    <section title="Acknowledgements">
      <t>
        This document is based on the results published in <xref target="Nagy14" />.
      </t>
      <t>
        The work of Varun Singh, and Joerg Ott has been partially supported by
        the European Institute of Innovation and Technology (EIT) ICT Labs
        activity RCLD 11882 (2012-2014). The views expressed here are those of
        the author(s) only. Neither the European Commission nor the EITICT
        labs is liable for any use that may be made of the information in this
        document.
      </t>
      <t>
        Lars Eggert has received funding from the European Union's Horizon 2020 research
        and innovation program 2014-2018 under grant agreement No. 644866 ("SSICLOPS").
        This document reflects only the authors' views and the European Commission is not
        responsible for any use that may be made of the information it contains.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      &rfc2119;
      <!-- RTP related -->
      &rfc3550;
      &rfc3551;
      &rfc3611; <!-- Security + RLE loss-->
      &rfc4585;
      &rfc5506;
      <!--RMCAT related -->
      &I-D.ietf-avtcore-rtp-circuit-breakers;
      <!-- FEC related -->
      &I-D.ietf-payload-flexible-fec-scheme;
      &rfc7509;
    </references>

    <references title="Informative References">

      &rfc4588; <!-- RTP Retx payload -->
      &rfc6363; <!--  Forward Error Correction (FEC) Framework -->
      &I-D.ietf-rmcat-cc-requirements;
      &I-D.ietf-rmcat-gcc;
      &I-D.ietf-rmcat-scream-cc;
      &I-D.ietf-rmcat-eval-test;
      &rfc5109; <!-- RTP FEC payload -->
      &rfc5725; <!-- RLE post-repair -->
      &rfc7097; <!-- RLE discard-->


      <reference anchor="Nagy14">
        <front>
          <title>Congestion Control using FEC for Conversational Multimedia Communication</title>
          <author initials="M" surname="Nagy"></author>
          <author initials="V" surname="Singh"></author>
          <author initials="J"  surname="Ott"></author>
          <author initials="L" surname="Eggert"></author>
          <date month="3" year="2014" />
        </front>
        <seriesInfo name="Proc. of 5th ACM Internation Conference on  Multimedia Systems (MMSys 2014)" value="" />
        <!-- An earlier version of this document is available on Arxiv -->
      </reference>

      <reference anchor="Devadoss08">
        <front>
          <title>Evaluation of Error Resilience Mechanisms for 3G Conversational Video</title>
          <author initials="J" surname="Devadoss"></author>
          <author initials="V" surname="Singh"></author>
          <author initials="J"  surname="Ott"></author>
          <author initials="C" surname="Liu"></author>
          <author initials="Y-K" surname="Wang"></author>
          <author initials="I.D.D." surname="Curcio"></author>
          <date month="3" year="2014" />
        </front>
        <seriesInfo name="Proc. of IEEE International Symposium on Multimedia (ISM 2008)" value="" />
        <!-- An earlier version of this document is available on Arxiv -->
      </reference>

      <reference anchor="Holmer13">
        <front>
          <title>Handling Packet Loss in WebRTC</title>
          <author initials="S" surname="Holmer"></author>
          <author initials="M" surname="Shemer"></author>
          <author initials="M"  surname="Paniconi"></author>
          <date month="9" year="2013" />
        </front>
        <seriesInfo name="Proc. of IEEE International Conference on Image Processing (ICIP 2013)" value="" />
      </reference>
    </references>

    <section anchor="sim-res" title="Simulations">
      <t>
        This document is based on the results published in <xref target="Nagy14" />.
        See the paper for ns-2 and testbed results; more results based on the
        scenarios listed in <xref target="I-D.ietf-rmcat-eval-test" />
        will be published shorty.
      </t>
    </section>

    <!-- <section anchor="App-cl" title="Change Log">
      <t>Note to the RFC-Editor: please remove this section prior to
        publication as an RFC.</t>
      <section title="Changes in draft-singh-rmcat-adaptive-fec-01">
        <t><list style="symbols">
          <t></t>
        </list></t>
      </section>
    </section> -->
  </back>
</rfc>
