One document matched: draft-singh-rmcat-adaptive-fec-03.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 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>
| PAFTECH AB 2003-2026 | 2026-04-23 23:02:33 |