One document matched: draft-singh-rmcat-adaptive-fec-00.xml
<?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 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://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circuit-breakers.xml">
<!ENTITY I-D.ietf-ledbat-congestion PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ledbat-congestion.xml">
<!ENTITY I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count.xml">
<!ENTITY I-D.alvestrand-rmcat-congestion PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.alvestrand-rmcat-congestion.xml">
<!ENTITY I-D.johansson-rmcat-scream-cc PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.johansson-rmcat-scream-cc.xml">
<!ENTITY I-D.sarker-rmcat-eval-test PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.sarker-rmcat-eval-test.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-00" 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>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>varun@comnet.tkk.fi</email>
<uri>http://www.netlab.tkk.fi/~varun/</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>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>jo@comnet.tkk.fi</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 year="2014"/>
<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
maintaing 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 Acknowlegment (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 applicatbility
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 avaiable end-to-end network capacity
leading to congestion (and therefore losses).
</t>
<t>
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.
Therefore, the congestion control algorithm is always able to probe for
available capacity, as improved reliability compensates for possible errors
resulting from overuse (i.e., increase in observed latency and/or losses).
</t>
<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-machine includes 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 attempts to
increase 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 (i.e.,
the transmission rate should be increased). The endpoint maintains
the same target media bit rate, and instead increases the amount of
FEC.
</t>
<t>
INCREASE state: Depending on the congestion feedback, i.e., if no
congestion is observed, the media transmission rate can be increased while
maintaining minimal amount of FEC for error protection. If packets are lost,
but the lost packets are recovered by the FEC packets, the congestion control
can keep the same media bit rate and reduce the amount of FEC (compared to
the previous PROBE state). If congestion is observed, 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 reciver,
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 | | Queue | |
+- -- -- -- -- -- -- -+ +- -- -- -- -+
| ^ | | |
| | | Source
| | R +--------------------+ | RTP |
| T | |
| | C | | |
| P | |
| | +----------+ +----------------+ |
| F | FEC Code |<--->| FEC Module |
| | B +----------+ +----------------+ |
| | | |
| |------------------------+ | | |
| RTCP FB Repair | | Source
| | RTP | | RTP |
| | |
| +--------------------------------------------+ |
| 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="RFC5109" />.
</t>
<t>
The endpoint MAY use a single-frame FEC or a multi-frame FEC 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="I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count" />
(packet count of repaired packets).
</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.alvestrand-rmcat-congestion">Google's
Congestion Control algorithm</xref>, <xref
target="I-D.johansson-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. 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>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
<!-- RTP related -->
&rfc3550;
&rfc3551;
&rfc3611;
&rfc4585;
&rfc5506;
<!--RMCAT related -->
&I-D.ietf-avtcore-rtp-circuit-breakers;
<!-- FEC related -->
&rfc5109; <!-- RTP FEC payload -->
&rfc5725; <!-- RTP FEC payload -->
&I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count;
</references>
<references title="Informative References">
&rfc4588; <!-- RTP Retx payload -->
&rfc6363; <!-- Forward Error Correction (FEC) Framework -->
&I-D.ietf-rmcat-cc-requirements;
&I-D.alvestrand-rmcat-congestion;
&I-D.johansson-rmcat-scream-cc;
&I-D.sarker-rmcat-eval-test;
<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 -->
<!-- TODO: there is possibly a IPR from Nokia, ask Lars/Nokia to report it.-->
</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 -->
<!-- TODO: there is possibly a IPR from Nokia, ask Lars/Nokia to report it.-->
</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.sarker-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>
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:43 |