rfc8680xml2.original.xml   rfc8680.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC nsus="true" docName="draft-ietf-tsvwg-fecframe-ext-08" indexInclude="true" ipr="
.2119.xml"> trust200902" number="8680" prepTime="2020-01-08T15:18:32" scripts="Common,Latin"
<!-- <!ENTITY rfc3095 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="t
e.RFC.3095.xml"> --> rue" updates="6363" xml:lang="en">
<!ENTITY rfc5052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <link href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext-08"
.5052.xml"> rel="prev"/>
<!-- <!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc <link href="https://dx.doi.org/10.17487/rfc8680" rel="alternate"/>
e.RFC.3550.xml"> --> <link href="urn:issn:2070-1721" rel="alternate"/>
<!-- <!ENTITY rfc5725 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5725.xml"> -->
<!-- <!ENTITY rfc4588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.4588.xml"> -->
<!ENTITY rfc2736 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2736.xml">
<!-- <!ENTITY rfc4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.4566.xml"> -->
<!-- <!ENTITY rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5226.xml"> -->
<!-- <!ENTITY rfc5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5234.xml"> -->
<!-- <!ENTITY rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.3711.xml"> -->
<!-- <!ENTITY rfc5740 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5740.xml"> -->
<!-- <!ENTITY rfc4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.4303.xml"> -->
<!-- <!ENTITY rfc4383 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.4383.xml"> -->
<!-- <!ENTITY rfc5775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5775.xml"> -->
<!-- <!ENTITY rfc5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5424.xml"> -->
<!-- <!ENTITY rfc3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.3411.xml"> -->
<!-- <!ENTITY rfc5675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5675.xml"> -->
<!-- <!ENTITY rfc5676 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5676.xml"> -->
<!ENTITY rfc6363 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6363.xml">
<!ENTITY rfc6364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6364.xml">
<!ENTITY rfc6681 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6681.xml">
<!-- <!ENTITY rfc6773 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.6773.xml"> -->
<!ENTITY rfc6816 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6816.xml">
<!ENTITY rfc6865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6865.xml">
<!ENTITY rfc8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY rfc8406 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8406.xml">
]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc rfcedstyle="yes" ?>
<!-- <rfc category="std" number="6363"
ipr="pre5378Trust200902" submissionType="IETF" consensus="yes"> -->
<rfc category="std" docName="draft-ietf-tsvwg-fecframe-ext-08" ipr="trust200902"
updates="6363">
<front> <front>
<title abbrev="FEC Framework Extension">Forward Error Correction (FEC) Frame work Extension to Sliding Window Codes</title> <title abbrev="FEC Framework Extension">Forward Error Correction (FEC) Frame work Extension to Sliding Window Codes</title>
<seriesInfo name="RFC" value="8680" stream="IETF"/>
<author fullname="Vincent Roca" initials="V" surname="Roca"> <author fullname="Vincent Roca" initials="V" surname="Roca">
<organization>INRIA</organization> <organization showOnFrontPage="true">INRIA</organization>
<address> <address>
<postal> <postal>
<!-- <street/>
<street>655, av. de l'Europe</street> <city/>
<street>Inovallee; Montbonnot</street> <extaddr>Univ. Grenoble Alpes</extaddr>
<city>ST ISMIER cedex</city>
<code>38334</code>
-->
<street></street>
<city>Univ. Grenoble Alpes</city>
<country>France</country> <country>France</country>
</postal> </postal>
<email>vincent.roca@inria.fr</email> <email>vincent.roca@inria.fr</email>
</address> </address>
</author> </author>
<author fullname="Ali Begen" initials="A." surname="Begen"> <author fullname="Ali Begen" initials="A." surname="Begen">
<organization>Networked Media</organization> <organization showOnFrontPage="true">Networked Media</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Konya</city> <city>Konya</city>
<region></region> <region/>
<code></code> <code/>
<country>Turkey</country> <country>Turkey</country>
</postal> </postal>
<email>ali.begen@networked.media</email> <email>ali.begen@networked.media</email>
</address> </address>
</author> </author>
<date month="01" year="2020"/>
<!-- <date month="July" year="2017" /> -->
<date/>
<workgroup>TSVWG</workgroup> <workgroup>TSVWG</workgroup>
<keyword>FEC</keyword>
<abstract> <keyword>FECFRAME</keyword>
<t> <keyword>packet loss recovery</keyword>
<keyword>RLC</keyword>
<keyword>Sliding Window FEC Codes</keyword>
<abstract pn="section-abstract">
<t pn="section-abstract-1">
RFC 6363 describes a framework for using Forward Error Correction (FEC) RFC 6363 describes a framework for using Forward Error Correction (FEC)
codes to provide protection against packet loss. The framework codes to provide protection against packet loss. The framework
supports applying FEC to arbitrary packet flows over unreliable supports applying FEC to arbitrary packet flows over unreliable
transport and is primarily intended for real-time, or streaming, media. transport and is primarily intended for real-time, or streaming, media.
However, FECFRAME as per RFC 6363 is restricted to block FEC codes. However, FECFRAME as per RFC 6363 is restricted to block FEC codes.
This document updates RFC 6363 to support FEC Codes based on a This document updates RFC 6363 to support FEC codes based on a
sliding encoding window, in addition to Block FEC Codes, in a sliding encoding window, in addition to block FEC codes, in a
backward-compatible way. backward-compatible way.
During multicast/broadcast real-time content delivery, the use of During multicast/broadcast real-time content delivery, the use of
sliding window codes significantly improves robustness in harsh sliding window codes significantly improves robustness in harsh
environments, with less repair traffic and lower FEC-related added latency. environments, with less repair traffic and lower FEC-related added latency.
</t> </t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8680" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
n</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-terminology">Terminology<
/xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derive
dContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-definitions-a
nd-abbreviatio">Definitions and Abbreviations</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derive
dContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-requirements-
language">Requirements Language</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-summary-of-architecture-o
ve">Summary of Architecture Overview</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-procedural-overview">Proc
edural Overview</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derive
dContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-general">Gene
ral</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derive
dContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-sender-operat
ion-with-slidi">Sender Operation with Sliding Window FEC Codes</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derive
dContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-receiver-oper
ation-with-sli">Receiver Operation with Sliding Window FEC Codes</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-protocol-specification">P
rotocol Specification</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t keepWithNext="true" pn="section-toc.1-1.5.2.1.1"><xref derive
dContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-general-2">Ge
neral</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t keepWithNext="true" pn="section-toc.1-1.5.2.2.1"><xref derive
dContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-fec-framework
-configuration">FEC Framework Configuration Information</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t keepWithNext="true" pn="section-toc.1-1.5.2.3.1"><xref derive
dContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-fec-scheme-re
quirements">FEC Scheme Requirements</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-feedback">Feedback</xref>
</t>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-transport-protocols">Tran
sport Protocols</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-congestion-control">Conge
stion Control</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-security-considerations">
Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
t="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedC
ontent="" format="title" sectionFormat="of" target="name-operations-and-manageme
nt-c">Operations and Management Considerations</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedConten
t="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedC
ontent="" format="title" sectionFormat="of" target="name-iana-considerations">IA
NA Considerations</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedConten
t="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedC
ontent="" format="title" sectionFormat="of" target="name-references">References<
/xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t keepWithNext="true" pn="section-toc.1-1.12.2.1.1"><xref deriv
edContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-normative-
references">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2">
<t keepWithNext="true" pn="section-toc.1-1.12.2.2.1"><xref deriv
edContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-informativ
e-references">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedConten
t="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>
.  <xref derivedContent="" format="title" sectionFormat="of" target="name-about-
sliding-encoding-wind">About Sliding Encoding Window Management (Informational)<
/xref></t>
</li>
<li pn="section-toc.1-1.14">
<t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derived
Content="" format="title" sectionFormat="of" target="name-acknowledgments">Ackno
wledgments</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t keepWithNext="true" pn="section-toc.1-1.15.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derived
Content="" format="title" sectionFormat="of" target="name-authors-addresses">Aut
hors' Addresses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
<!-- ====================== --> lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t> Many applications need to transport a continuous stream <t pn="section-1-1"> Many applications need to transport a continuous stre
am
of packetized data from a source (sender) to one or more destinations of packetized data from a source (sender) to one or more destinations
(receivers) over networks that do not provide guaranteed packet delivery. (receivers) over networks that do not provide guaranteed packet delivery.
In particular packets may be lost, which is strictly the focus of this In particular, packets may be lost, which is strictly the focus of this
document: we assume that transmitted packets are either lost (e.g., document: we assume that transmitted packets are either lost (e.g.,
because of a congested router, of a poor signal-to-noise ratio in a because of a congested router, a poor signal-to-noise ratio in a
wireless network, or because the number of bit errors exceeds the wireless network, or because the number of bit errors exceeds the
correction capabilities of the physical-layer error correcting code) or received correction capabilities of the physical-layer error-correcting code) or
by the transport protocol without any corruption (i.e., the bit-errors, were received by the transport protocol without any corruption (i.e., the bit er
if any, have been fixed by the physical-layer error correcting code and therefor rors,
e if any, have been fixed by the physical-layer error-correcting code and therefor
e
are hidden to the upper layers). are hidden to the upper layers).
</t> </t>
<t pn="section-1-2">For these use cases, Forward Error Correction (FEC) ap
<t>For these use-cases, Forward Error Correction (FEC) applied within plied within
the transport or application layer is an efficient the transport or application layer is an efficient
technique to improve packet transmission robustness in presence of packet technique to improve packet transmission robustness in the presence of packet
losses (or "erasures"), without going through packet retransmissions that losses (or "erasures") without going through packet retransmissions that
create a delay often incompatible with real-time constraints. create a delay often incompatible with real-time constraints.
The FEC Building Block defined in <xref target="RFC5052"/> provides a The FEC Building Block defined in <xref target="RFC5052" format="default" sectio nFormat="of" derivedContent="RFC5052"/> provides a
framework for the definition of Content Delivery Protocols (CDPs) framework for the definition of Content Delivery Protocols (CDPs)
that make use of separately-defined FEC schemes. Any CDP that make use of separately defined FEC schemes. Any CDP
defined according to the requirements of the FEC Building Block can then defined according to the requirements of the FEC Building Block can then
easily be used with any FEC Scheme that is also defined according to easily be used with any FEC scheme that is also defined according to
the requirements of the FEC Building Block. the requirements of the FEC Building Block.
</t> </t>
<t pn="section-1-3">
<t> Then, FECFRAME <xref target="RFC6363" format="default" sectionFormat="of" derive
Then FECFRAME <xref target="RFC6363"/> provides a framework to define dContent="RFC6363"/> provides a framework to define
Content Delivery Protocols (CDPs) that provide FEC protection for arbitrary Content Delivery Protocols (CDPs) that provide FEC protection for arbitrary
packet flows over an unreliable datagram service transport such as UDP. packet flows over an unreliable datagram service transport, such as UDP.
It is primarily intended for real-time or streaming media applications, It is primarily intended for real-time or streaming media applications
using broadcast, multicast, or on-demand delivery. that are using broadcast, multicast, or on-demand delivery. A subset of
FECFRAME is currently part of the 3GPP Evolved Multimedia Broadcast/Multicast Se
rvice
(eMBMS) standard <xref target="MBMSTS" format="default" sectionFormat="of" deriv
edContent="MBMSTS"/>.
</t> </t>
<t pn="section-1-4">
<t> However, <xref target="RFC6363" format="default" sectionFormat="of" derivedConte
However, <xref target="RFC6363"/> only considers block FEC schemes defined in nt="RFC6363"/> only considers block FEC schemes defined in
accordance with the FEC Building Block <xref target="RFC5052"/> accordance with the FEC Building Block <xref target="RFC5052" format="default" s
(e.g., <xref target="RFC6681"/>, <xref target="RFC6816"/> or <xref target="RFC68 ectionFormat="of" derivedContent="RFC5052"/>
65"/>). (e.g., <xref target="RFC6681" format="default" sectionFormat="of" derivedContent
="RFC6681"/>, <xref target="RFC6816" format="default" sectionFormat="of" derived
Content="RFC6816"/>, or <xref target="RFC6865" format="default" sectionFormat="o
f" derivedContent="RFC6865"/>).
These codes require the input flow(s) to be segmented into a sequence of blocks. These codes require the input flow(s) to be segmented into a sequence of blocks.
Then FEC encoding (at a sender or an encoding middlebox) and decoding (at a rece iver Then, FEC encoding (at a sender or an encoding middlebox) and decoding (at a rec eiver
or a decoding middlebox) are both performed on a per-block basis. or a decoding middlebox) are both performed on a per-block basis.
For instance, if the current block encompasses the 100's to 119's source symbols For instance, if the current block encompasses the 100's to 119's source symbols
(i.e., a block of size 20 symbols) of an input flow, encoding (and decoding) wil l (i.e., a block of size 20 symbols) of an input flow, encoding (and decoding) wil l
be performed on this block independently of other blocks. be performed on this block independently of other blocks.
This approach has major impacts on FEC encoding and decoding delays. This approach has major impacts on FEC encoding and decoding delays.
The data packets of continuous media flow(s) may be passed to the transport laye r The data packets of continuous media flow(s) may be passed to the transport laye r
immediately, without delay. immediately, without delay.
But the block creation time, that depends on the number of source symbols in But the block creation time, which depends on the number of source symbols in
this block, impacts both the FEC encoding delay (since encoding requires that al l this block, impacts both the FEC encoding delay (since encoding requires that al l
source symbols be known), and mechanically the packet loss recovery delay at a source symbols be known) and, mechanically, the packet loss recovery delay at a
receiver (since no repair symbol for the current block can be generated and receiver (since no repair symbol for the current block can be generated and
therefore received before that time). therefore received before that time).
Therefore a good value for the block size is necessarily a balance between the Therefore, a good value for the block size is necessarily a balance between the
maximum FEC decoding latency at the receivers (which must be in line with the mo st maximum FEC decoding latency at the receivers (which must be in line with the mo st
stringent real-time requirement of the protected flow(s), hence an incentive to stringent real-time requirement of the protected flow(s), hence an incentive to
reduce the block size), and the desired robustness against long loss bursts (whi ch reduce the block size) and the desired robustness against long loss bursts (whic h
increases with the block size, hence an incentive to increase this size). increases with the block size, hence an incentive to increase this size).
</t> </t>
<t pn="section-1-5">
<t> This document updates <xref target="RFC6363" format="default" sectionFormat="of"
This document updates <xref target="RFC6363"/> in order to also support FEC code derivedContent="RFC6363"/> in order to also support FEC codes
s based on a sliding encoding window (a.k.a., convolutional codes) <xref target="R
based on a sliding encoding window (A.K.A. convolutional codes) <xref target="RF FC8406" format="default" sectionFormat="of" derivedContent="RFC8406"/>.
C8406"/>. This encoding window, either fixed or variable size, slides over the set of
This encoding window, either of fixed or variable size, slides over the set of
source symbols. source symbols.
FEC encoding is launched whenever needed, from the set of source symbols present FEC encoding is launched whenever needed from the set of source symbols present
in the sliding encoding window at that time. in the sliding encoding window at that time.
This approach significantly reduces FEC-related latency, since repair symbols ca n This approach significantly reduces FEC-related latency, since repair symbols ca n
be generated and passed to the transport layer on-the-fly, at any time, and can be be generated and passed to the transport layer on the fly at any time and can be
regularly received by receivers to quickly recover packet losses. regularly received by receivers to quickly recover packet losses.
Using sliding window FEC codes is therefore highly beneficial to real-time flows , Using sliding window FEC codes is therefore highly beneficial to real-time flows ,
one of the primary targets of FECFRAME. one of the primary targets of FECFRAME.
<xref target="RLC-ID"/> provides an example of such FEC Scheme for FECFRAME, <xref target="RFC8681" format="default" sectionFormat="of" derivedContent="RFC86
built upon the simple sliding window Random Linear Codes (RLC). 81"/> provides an example of such a FEC scheme for FECFRAME,
which is built upon the simple sliding window Random Linear Code (RLC).
</t> </t>
<t pn="section-1-6">
<t> This document is fully backward compatible with <xref target="RFC6363" format="d
This document is fully backward compatible with <xref target="RFC6363"/>. Indeed efault" sectionFormat="of" derivedContent="RFC6363"/>. Indeed:
: </t>
<list style="symbols"> <ul spacing="normal" bare="false" empty="false" pn="section-1-7">
<t> this FECFRAME update does not prevent nor compromise in any way the s <li pn="section-1-7.1"> This FECFRAME update does not prevent or comprom
upport ise in any way the support
of block FEC codes. Both types of codes can nicely co-exist, just like di of block FEC codes. Both types of codes can nicely coexist, just like dif
fferent ferent
block FEC schemes can co-exist;</t> block FEC schemes can coexist.</li>
<li pn="section-1-7.2"> Each sliding window FEC scheme is associated wit
<t> each sliding window FEC Scheme is associated to a specific FEC Encodi h a specific FEC Encoding ID subject
ng ID subject to IANA registration, just like block FEC schemes.</li>
to IANA registration, just like block FEC Schemes;</t> <li pn="section-1-7.3"> Any receiver -- for instance, a legacy receiver
that only supports
<t> any receiver, for instance a legacy receiver that only supports block block FEC schemes -- can easily identify the FEC scheme used in a FECFRAM
FEC schemes, E session.
can easily identify the FEC Scheme used in a FECFRAME session. Indeed, the FEC Encoding ID that identifies the FEC scheme is carried in
Indeed, the FEC Encoding ID that identifies the FEC Scheme is carried in FEC Framework Configuration Information (see <xref target="RFC6363" forma
the t="default" sectionFormat="of" section="5.5" derivedLink="https://rfc-editor.org
FEC Framework Configuration Information (see section 5.5 of <xref target= /rfc/rfc6363#section-5.5" derivedContent="RFC6363"/>).
"RFC6363"/>).
For instance, when the Session Description Protocol (SDP) is used to carr y the For instance, when the Session Description Protocol (SDP) is used to carr y the
FEC Framework Configuration Information, the FEC Encoding ID can be commu nicated FEC Framework Configuration Information, the FEC Encoding ID can be commu nicated
in the "encoding-id=" parameter of a "fec-repair-flow" attribute <xref ta rget="RFC6364"/>. in the "encoding-id=" parameter of a "fec-repair-flow" attribute <xref ta rget="RFC6364" format="default" sectionFormat="of" derivedContent="RFC6364"/>.
This mechanism is the basic approach for a FECFRAME receiver to determine This mechanism is the basic approach for a FECFRAME receiver to determine
whether or not it supports the FEC Scheme used in a given FECFRAME sessio whether or not it supports the FEC scheme used in a given FECFRAME sessio
n; </t> n. </li>
</ul>
</list> <t pn="section-1-8">
This document leverages on <xref target="RFC6363"></xref> and re-uses its struct This document leverages on <xref target="RFC6363" format="default" sectionFormat
ure. ="of" derivedContent="RFC6363"/> and reuses its structure.
It proposes new sections specific to sliding window FEC codes whenever required. It proposes new sections specific to sliding window FEC codes whenever required.
The only exception is <xref target="ArchitectureOverview"/> that provides a quic k The only exception is <xref target="ArchitectureOverview" format="default" secti onFormat="of" derivedContent="Section 3"/>, which provides a quick
summary of FECFRAME in order to facilitate the understanding of this document to readers summary of FECFRAME in order to facilitate the understanding of this document to readers
not familiar with the concepts and terminology. not familiar with the concepts and terminology.
</t> </t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<section anchor="definitionsAndAbbreviations" title="Definitions and Abbrevi <name slugifiedName="name-terminology">Terminology</name>
ations"> <section anchor="definitionsAndAbbreviations" numbered="true" toc="include
<!-- ====================== --> " removeInRFC="false" pn="section-2.1">
<name slugifiedName="name-definitions-and-abbreviatio">Definitions and A
<t>The following list of definitions and abbreviations is copied from <xref targ bbreviations</name>
et="RFC6363"/>, <t pn="section-2.1-1">The following list of definitions and abbreviation
adding only the Block/sliding window FEC Code and Encoding/Decoding Window defin s is copied from <xref target="RFC6363" format="default" sectionFormat="of" deri
itions (tagged vedContent="RFC6363"/>,
adding only the Block FEC Code, Sliding Window FEC Code, and Encoding/Decoding W
indow definitions (tagged
with "ADDED"): with "ADDED"):
<list hangIndent="4" style="hanging">
<t hangText="Application Data Unit (ADU):"> The unit of source data provided as
payload to the transport layer.
For instance, it can be a payload containing the result of the RTP packetization
of a compressed video frame.
</t> </t>
<dl newline="true" spacing="normal" pn="section-2.1-2">
<t hangText="ADU Flow:"> A sequence of ADUs associated with a transport-la <dt pn="section-2.1-2.1">Application Data Unit (ADU):</dt>
yer flow <dd pn="section-2.1-2.2"> The unit of source data provided as
a payload to the transport layer.
For instance, it can be a payload containing the result of the RTP packetization
of a compressed video frame.
</dd>
<dt pn="section-2.1-2.3">ADU Flow:</dt>
<dd pn="section-2.1-2.4"> A sequence of ADUs associated with a transpo
rt-layer flow
identifier (such as the standard 5-tuple {source IP address, source identifier (such as the standard 5-tuple {source IP address, source
port, destination IP address, destination port, transport port, destination IP address, destination port, transport
protocol}).</t> protocol}).</dd>
<dt pn="section-2.1-2.5">AL-FEC:</dt>
<t hangText="AL-FEC:"> Application-layer Forward Error Correction.</t> <dd pn="section-2.1-2.6"> Application-Layer Forward Error Correction.<
/dd>
<t hangText="Application Protocol:"> Control protocol used to establish an <dt pn="section-2.1-2.7">Application Protocol:</dt>
d control <dd pn="section-2.1-2.8"> Control protocol used to establish and contr
ol
the source flow being protected, e.g., the Real-Time Streaming Protocol the source flow being protected, e.g., the Real-Time Streaming Protocol
(RTSP).</t> (RTSP).</dd>
<dt pn="section-2.1-2.9">Content Delivery Protocol (CDP):</dt>
<t hangText="Content Delivery Protocol (CDP):"> A complete application pro <dd pn="section-2.1-2.10"> A complete application protocol
tocol
specification that, through the use of the framework defined in this specification that, through the use of the framework defined in this
document, is able to make use of FEC schemes to provide FEC document, is able to make use of FEC schemes to provide FEC
capabilities.</t> capabilities.</dd>
<dt pn="section-2.1-2.11">FEC Code:</dt>
<t hangText="FEC Code:"> An algorithm for encoding data such that the enco <dd pn="section-2.1-2.12"> An algorithm for encoding data such that th
ded data e encoded data
flow is resilient to data loss. Note that, in general, FEC codes may also flow is resilient to data loss. Note that, in general, FEC codes may also
be used to make a data flow resilient to corruption, but that is not be used to make a data flow resilient to corruption, but that is not
considered in this document.</t> considered in this document.</dd>
<dt pn="section-2.1-2.13">Block FEC Code: (ADDED)</dt>
<t hangText="Block FEC Code: (ADDED)"> An FEC Code that operates on blocks, i.e. <dd pn="section-2.1-2.14"> A FEC code that operates on blocks, i.e., f
, for or
which the input flow MUST be segmented into a sequence of blocks, which the input flow <bcp14>MUST</bcp14> be segmented into a sequence of blocks,
FEC encoding and decoding being performed independently on a with FEC encoding and decoding being performed independently on a
per-block basis.</t> per-block basis.</dd>
<dt pn="section-2.1-2.15">Sliding Window FEC Code: (ADDED)</dt>
<t hangText="Sliding Window FEC Code: (ADDED)"> An FEC Code that can generate re <dd pn="section-2.1-2.16"> A FEC code that can generate repair symbols
pair symbols on the fly, at any time, from the set of source symbols present in the sliding
on-the-fly, at any time, from the set of source symbols present in the sliding
encoding window at that time. encoding window at that time.
These codes are also known as convolutional codes.</t> These codes are also known as convolutional codes.</dd>
<dt pn="section-2.1-2.17">FEC Framework:</dt>
<t hangText="FEC Framework:"> A protocol framework for the definition of C <dd pn="section-2.1-2.18"> A protocol framework for the definition of
ontent Content
Delivery Protocols using FEC, such as the framework defined in this Delivery Protocols using FEC, such as the framework defined in this
document.</t> document.</dd>
<dt pn="section-2.1-2.19">FEC Framework Configuration Information:</dt
<t hangText="FEC Framework Configuration Information:"> Information that c >
ontrols <dd pn="section-2.1-2.20"> Information that controls
the operation of the FEC Framework.</t> the operation of the FEC Framework.</dd>
<dt pn="section-2.1-2.21">FEC Payload ID:</dt>
<t hangText="FEC Payload ID:"> Information that identifies the contents and prov <dd pn="section-2.1-2.22"> Information that identifies the contents an
ides positional information of a packet d provides positional information of a packet
with respect to the FEC Scheme.</t> with respect to the FEC scheme.</dd>
<dt pn="section-2.1-2.23">FEC Repair Packet:</dt>
<t hangText="FEC Repair Packet:"> At a sender (respectively, at a receiver <dd pn="section-2.1-2.24"> At a sender (respectively, at a receiver),
), a a
payload submitted to (respectively, received from) the transport payload submitted to (respectively, received from) the transport
protocol containing one or more repair symbols along with a Repair FEC protocol containing one or more repair symbols along with a Repair FEC
Payload ID and possibly an RTP header.</t> Payload ID and possibly an RTP header.</dd>
<dt pn="section-2.1-2.25">FEC Scheme:</dt>
<t hangText="FEC Scheme:"> A specification that defines the additional pro <dd pn="section-2.1-2.26"> A specification that defines the additional
tocol protocol
aspects required to use a particular FEC code with the FEC aspects required to use a particular FEC code with the FEC
Framework.</t> Framework.</dd>
<dt pn="section-2.1-2.27">FEC Source Packet:</dt>
<t hangText="FEC Source Packet:"> At a sender (respectively, at a receiver <dd pn="section-2.1-2.28"> At a sender (respectively, at a receiver),
), a a
payload submitted to (respectively, received from) the transport payload submitted to (respectively, received from) the transport
protocol containing an ADU along with an optional Explicit Source FEC protocol containing an ADU along with an optional Explicit Source FEC
Payload ID.</t> Payload ID.</dd>
<dt pn="section-2.1-2.29">Repair Flow:</dt>
<!-- <dd pn="section-2.1-2.30"> The packet flow carrying FEC data.</dd>
<t hangText="Protection Amount:"> The relative increase in data sent due t <dt pn="section-2.1-2.31">Repair FEC Payload ID:</dt>
o the use <dd pn="section-2.1-2.32"> A FEC Payload ID specifically for use with
of FEC.</t> repair packets.</dd>
<dt pn="section-2.1-2.33">Source Flow:</dt>
<t hangText="Repair Flow:"> The packet flow carrying FEC data.</t> <dd pn="section-2.1-2.34"> The packet flow to which FEC protection is
to be
<t hangText="Repair FEC Payload ID:"> A FEC Payload ID specifically for us applied. A source flow consists of ADUs.</dd>
e with <dt pn="section-2.1-2.35">Source FEC Payload ID:</dt>
repair packets.</t> <dd pn="section-2.1-2.36"> A FEC Payload ID specifically for use with
source packets.</dd>
<t hangText="Source Flow:"> The packet flow to which FEC protection is to <dt pn="section-2.1-2.37">Source Protocol:</dt>
be <dd pn="section-2.1-2.38"> A protocol used for the source flow being p
applied. A source flow consists of ADUs.</t> rotected,
e.g., RTP.</dd>
<t hangText="Source FEC Payload ID:"> A FEC Payload ID specifically for us <dt pn="section-2.1-2.39">Transport Protocol:</dt>
e with <dd pn="section-2.1-2.40"> The protocol used for the transport of the
source packets.</t> source and
repair flows. This protocol needs to provide an unreliable datagram
<t hangText="Source Protocol:"> A protocol used for the source flow being service, as UDP does (<xref target="RFC6363" sectionFormat="comma" section
protected, ="7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-7"
e.g., RTP.</t> derivedContent="RFC6363"/>).
</dd>
<t hangText="Transport Protocol:"> The protocol used for the transport of <dt pn="section-2.1-2.41">Encoding Window: (ADDED)</dt>
the source and <dd pn="section-2.1-2.42"> Set of source symbols available at the send
repair flows, using an unreliable datagram service such as UDP. er/coding node
<!-- and the Datagram Congestion Control Protocol (DCCP) (either DCCP-STD that are used (with a Sliding Window FEC code) to generate a repair symbol
or DCCP-UDP <xref target="RFC6773"/>).--> .</dd>
</t> <dt pn="section-2.1-2.43">Decoding Window: (ADDED)</dt>
<dd pn="section-2.1-2.44"> Set of received or decoded source and repai
<t hangText="Encoding Window: (ADDED)"> Set of Source Symbols available at the s r symbols available
ender/coding node at a receiver that are used (with a Sliding Window FEC code) to
that are used to generate a repair symbol, with a Sliding Window FEC Code. decode lost source symbols.</dd>
</t> <dt pn="section-2.1-2.45">Code Rate:</dt>
<dd pn="section-2.1-2.46"> The ratio between the number of source symb
<t hangText="Decoding Window: (ADDED)"> Set of received or decoded source and re ols and the
pair symbols available
at a receiver that are used to decode erased source symbols, with a Slidin
g Window FEC Code.</t>
<t hangText="Code Rate:"> The ratio between the number of source symbols a
nd the
number of encoding symbols. By definition, the code rate is such that 0 number of encoding symbols. By definition, the code rate is such that 0
&lt; code rate &lt;= 1. A code rate close to 1 indicates that a small &lt; code rate &lt;= 1. A code rate close to 1 indicates that a small
number of repair symbols have been produced during the encoding number of repair symbols have been produced during the encoding
process.</t> process.</dd>
<dt pn="section-2.1-2.47">Encoding Symbol:</dt>
<t hangText="Encoding Symbol:"> Unit of data generated by the encoding pro <dd pn="section-2.1-2.48"> Unit of data generated by the encoding proc
cess. With ess. With
systematic codes, source symbols are part of the encoding symbols.</t> systematic codes, source symbols are part of the encoding symbols.</dd>
<dt pn="section-2.1-2.49">Packet Erasure Channel:</dt>
<t hangText="Packet Erasure Channel:"> A communication path where packets <dd pn="section-2.1-2.50"> A communication path where packets are eith
are either er
lost (e.g., in our case, by a congested router, or because the number of lost (e.g., in our case, by a congested router, or because the number of
transmission errors exceeds the correction capabilities of the transmission errors exceeds the correction capabilities of the
physical-layer code) or received. When a packet is received, it is physical-layer code) or received. When a packet is received, it is
assumed that this packet is not corrupted (i.e., in our case, the bit-erro assumed that this packet is not corrupted (i.e., in our case, the bit erro
rs, rs,
if any, are fixed by the physical-layer code and therefore hidden to if any, are fixed by the physical-layer code and are therefore hidden to
the upper layers). </t> the upper layers). </dd>
<dt pn="section-2.1-2.51">Repair Symbol:</dt>
<t hangText="Repair Symbol:"> Encoding symbol that is not a source symbol. <dd pn="section-2.1-2.52"> Encoding symbol that is not a source symbol
</t> .</dd>
<dt pn="section-2.1-2.53">Source Block:</dt>
<t hangText="Source Block:"> Group of ADUs that are to be FEC protected as <dd pn="section-2.1-2.54"> Group of ADUs that are to be FEC protected
a single as a single
block. block.
This notion is restricted to Block FEC Codes.</t> This notion is restricted to Block FEC codes.</dd>
<dt pn="section-2.1-2.55">Source Symbol:</dt>
<t hangText="Source Symbol:"> Unit of data used during the encoding proces <dd pn="section-2.1-2.56"> Unit of data used during the encoding proce
s.</t> ss.</dd>
<dt pn="section-2.1-2.57">Systematic Code:</dt>
<t hangText="Systematic Code:"> FEC code in which the source symbols are p <dd pn="section-2.1-2.58"> FEC code in which the source symbols are pa
art of the rt of the
encoding symbols.</t> encoding symbols.</dd>
</list></t> </dl>
</section>
<t> <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL ">
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <name slugifiedName="name-requirements-language">Requirements Language</
"MAY", and "OPTIONAL" in this document are to be interpreted as name>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> <t pn="section-2.2-1">
when, and only when, they appear in all capitals, as shown here. The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
</t> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP 14 <xref target="RFC2119" format="default" s
ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they app
ear in all capitals, as
shown here.
</t>
</section>
</section> </section>
<section anchor="ArchitectureOverview" numbered="true" toc="include" removeI
<section anchor="ArchitectureOverview" title="Summary of Architecture Overvi nRFC="false" pn="section-3">
ew"> <name slugifiedName="name-summary-of-architecture-ove">Summary of Architec
<!-- ====================== --> ture Overview</name>
<t pn="section-3-1">
<t> The architecture of <xref target="RFC6363" format="default" sectionFormat="of" s
The architecture of <xref target="RFC6363"/>, Section 3, equally applies to this ection="3" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-3" derivedCon
tent="RFC6363"/> equally applies to this
FECFRAME extension and is not repeated here. FECFRAME extension and is not repeated here.
However, we provide hereafter a quick summary to facilitate the understanding of this However, this section includes a quick summary to facilitate the understanding o f this
document to readers not familiar with the concepts and terminology. document to readers not familiar with the concepts and terminology.
</t> </t>
<figure anchor="fig_archi" align="left" suppress-title="false" pn="figure-
<figure anchor="fig_archi" title="FECFRAME architecture at a sender."> 1">
<artwork><![CDATA[ <name slugifiedName="name-fecframe-architecture-at-a-">FECFRAME Architec
ture at a Sender</name>
<artwork name="" type="" align="left" alt="" pn="section-3-2.1">
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
| (1) Application Data Units (ADUs) | (1) Application Data Units (ADUs)
| |
v v
+----------------------+ +----------------+ +----------------------+ +----------------+
| FEC Framework | | | | FEC Framework | | |
| |-------------------------->| FEC Scheme | | |--------------------------&gt;| FEC Scheme |
|(2) Construct source |(3) Source Block | | |(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding| | blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| | |(6) Construct FEC |&lt;--------------------------| |
| Source and Repair | | | | Source and Repair | | |
| Packets |(5) Explicit Source FEC | | | Packets |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+ +----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs | Repair FEC Payload IDs
| Repair symbols | Repair symbols
| |
|(7) FEC Source and Repair Packets |(7) FEC Source and Repair Packets
v v
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-3-3">
<t> The FECFRAME architecture is illustrated in <xref target="fig_archi" format="def
The FECFRAME architecture is illustrated in <xref target="fig_archi"/> from the ault" sectionFormat="of" derivedContent="Figure 1"/> for a block FEC scheme from
sender's the sender's
point of view, in case of a block FEC Scheme. point of view.
It shows an application generating an ADU flow (other flows, from other applicat It shows an application generating an ADU flow (other flows from other applicati
ions, may co-exist). ons may coexist).
These ADUs, of variable size, must be somehow mapped to source symbols of fixed These ADUs of variable size must be somehow mapped to source symbols of a fixed
size (this fixed size size (this fixed size
is a requirement of all FEC Schemes that comes from the way mathematical operati is a requirement of all FEC schemes, which comes from the way mathematical
ons are applied to symbols content). operations are applied to the symbols' content).
This is the goal of an ADU-to-symbols mapping process that is FEC-Scheme specifi This is the goal of an ADU-to-symbols mapping process that is FEC scheme specifi
c (see below). c (see below).
Once the source block is built, taking into account both the FEC Scheme constrai Once the source block is built, taking into account both the FEC scheme constrai
nts (e.g., in terms nts (e.g., in terms
of maximum source block size) and the application's flow constraints (e.g., in t erms of real-time constraints), of maximum source block size) and the application's flow constraints (e.g., in t erms of real-time constraints),
the associated source symbols are handed to the FEC Scheme in order to produce a n appropriate number the associated source symbols are handed to the FEC scheme in order to produce a n appropriate number
of repair symbols. of repair symbols.
FEC Source Packets (containing ADUs) and FEC Repair Packets (containing one or m ore repair symbols each) FEC Source Packets (containing ADUs) and FEC Repair Packets (containing one or m ore repair symbols each)
are then generated and sent using an appropriate transport protocol (more precis are then generated and sent using an appropriate transport protocol (more
ely <xref target="RFC6363"/>, Section 7, requires a precisely, <xref target="RFC6363" format="default" sectionFormat="of" section="7
transport protocol providing an unreliable datagram service, such as UDP<!-- or " derivedLink="https://rfc-editor.org/rfc/rfc6363#section-7" derivedContent="RFC
DCCP-->). 6363"/> requires a
In practice FEC Source Packets may be passed to the transport layer as soon as a transport protocol providing an unreliable datagram service, such as UDP).
vailable, without having to wait for In practice, FEC Source Packets may be passed to the transport layer as soon
as available without having to wait for
FEC encoding to take place. FEC encoding to take place.
In that case a copy of the associated source symbols needs to be kept within FEC FRAME for future In that case, a copy of the associated source symbols needs to be kept within FE CFRAME for future
FEC encoding purposes. FEC encoding purposes.
</t> </t>
<t pn="section-3-4">
<t> At a receiver (not shown), FECFRAME processing operates in a similar way,
At a receiver (not shown), FECFRAME processing operates in a similar way, taking taking as input the incoming FEC Source and Repair Packets received. In case
as input the incoming of FEC Source Packet losses, the FEC decoding of the associated block may
FEC Source and Repair Packets received. recover all (in case of successful decoding) or a subset that is potentially emp
In case of FEC Source Packet losses, the FEC decoding of the associated block ma ty
y recover all (in case (if decoding fails) of the missing source symbols. After source-symbol-to-ADU
of successful decoding) or a subset potentially empty (otherwise) of the missing mapping, when lost ADUs are recovered, they are then assigned to their
source symbols.
After source-symbol-to-ADU mapping, when lost ADUs are recovered, they are then
assigned to their
respective flow (see below). respective flow (see below).
ADUs are returned to the application(s), either in their initial transmission or
der (in that case ADUs
received after an erased one will be delayed until FEC decoding has taken place)
or not (in that case
each ADU is returned as soon as it is received or recovered), depending on the a
pplication requirements.
</t>
<t> ADUs are returned to the application(s), either in their initial transmission
FECFRAME features two subtle mechanisms: order (in which case all ADUs received after a lost ADU will be delayed until
<list style="symbols"> FEC decoding has taken place) or not (in which case each ADU is returned as
<t> ADUs-to-source-symbols mapping: soon as it is received or recovered), depending on the application
in order to manage variable size ADUs, FECFRAME and FEC Schemes c requirements.
an use small, fixed size </t>
<t pn="section-3-5">
FECFRAME features two subtle mechanisms whose details are FEC scheme dependent:
</t>
<ul spacing="normal" bare="false" empty="false" pn="section-3-6">
<li pn="section-3-6.1"> ADUs-to-source-symbols mapping:
in order to manage variable size ADUs, FECFRAME and FEC schemes c
an use small, fixed-size
symbols and create a mapping between ADUs and symbols. symbols and create a mapping between ADUs and symbols.
To each ADU this mechanism prepends a length field (plus a flow i The mapping details are
dentifier, see below) and FEC scheme dependent and must be defined in the associated document.
For instance, with certain FEC schemes, to each ADU, this mechanism prepen
ds a length field (plus a flow identifier; see below) and
pads the result to a multiple of the symbol size. pads the result to a multiple of the symbol size.
A small ADU may be mapped to a single source symbol while a large one may be mapped to A small ADU may be mapped to a single source symbol, while a larg e one may be mapped to
multiple symbols. multiple symbols.
The mapping details are FEC-Scheme-dependent and must be defined </li>
in the associated document; <li pn="section-3-6.2"> Assignment of decoded ADUs to flows in multi-flo
</t> w configurations:
<t> Assignment of decoded ADUs to flows in multi-flow configurations: when multiple flows are multiplexed over the same FECFRAME instance, a
when multiple flows are multiplexed over the same FECFRAME instan problem is to assign a decoded ADU to the right flow (UDP port numbers
ce, a problem is to assign and IP addresses traditionally used to map incoming ADUs to flows are
a decoded ADU to the right flow (UDP port numbers and IP addresse not recovered during FEC decoding). The mapping details are FEC
s traditionally used to map scheme dependent and must be
incoming ADUs to flows are not recovered during FEC decoding). defined in the associated document. For instance, with certain FEC
To make it possible, at the FECFRAME sending instance, each ADU i schemes, to make it possible, at the
s prepended with a flow FECFRAME sending instance, each ADU is prepended with a flow
identifier (1 byte) during the ADU-to-source-symbols mapping (see identifier (1 byte) during the ADU-to-source-symbols mapping (see
above). above). The flow identifiers are also shared between all FECFRAME
The flow identifiers are also shared between all FECFRAME instanc instances as part of the FEC Framework Configuration Information.
es as part of the FEC Framework
Configuration Information.
This (flow identifier + length + application payload + padding),
called ADUI, is then FEC protected.
Therefore a decoded ADUI contains enough information to assign th
e ADU to the right flow.
</t>
</list>
</t>
<t> The ADU Information (ADUI), which includes the flow identifier, length,
application payload, and padding, is then FEC protected. Therefore, a
decoded ADUI contains enough information to assign the ADU to the right
flow. Note that a FEC scheme may also be restricted to the particular
case of a single flow over a FECFRAME instance; that would make
the above mechanism pointless.
</li>
</ul>
<t pn="section-3-7">
A few aspects are not covered by FECFRAME, namely: A few aspects are not covered by FECFRAME, namely:
<list style="symbols">
<t> <xref target="RFC6363"/> section 8 does not detail any congestion con
trol mechanism,
but only provides high level normative requirements; </t>
<t> the possibility of having feedbacks from receiver(s) is considered ou
t of scope, although
such a mechanism may exist within the application (e.g., through
RTCP control messages); </t>
<t> flow adaptation at a FECFRAME sender (e.g., how to set the FEC code r
ate based on transmission
conditions) is not detailed, but it needs to comply with the cong
estion control normative
requirements (see above). </t>
</list>
</t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-3-8">
<li pn="section-3-8.1">
<xref target="RFC6363" format="default" sectionFormat="of" section="8"
derivedLink="https://rfc-editor.org/rfc/rfc6363#section-8" derivedContent="RFC6
363"/> does not detail any congestion control mechanisms and
only provides high-level normative requirements. </li>
<li pn="section-3-8.2"> The possibility of having feedback from receiver
(s) is considered
out of scope, although such a mechanism may exist within the
application (e.g., through RTP Control Protocol (RTCP)
messages). </li>
<li pn="section-3-8.3"> Flow adaptation at a FECFRAME sender (e.g., how
to set the FEC
code rate based on transmission conditions) is not detailed, but it
needs to comply with the congestion control normative requirements
(see above). </li>
</ul>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
<section title="Procedural Overview"> <name slugifiedName="name-procedural-overview">Procedural Overview</name>
<!-- ====================== --> <section anchor="generalProceduralOverview" numbered="true" toc="include"
<section anchor="generalProceduralOverview" title="General"> removeInRFC="false" pn="section-4.1">
<!-- ====================== --> <name slugifiedName="name-general">General</name>
<t pn="section-4.1-1">
<t> The general considerations of <xref target="RFC6363" format="default" sectionFor
The general considerations of <xref target="RFC6363"/>, Section 4.1, that mat="of" section="4.1" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-4
.1" derivedContent="RFC6363"/> that
are specific to block FEC codes are not repeated here. are specific to block FEC codes are not repeated here.
</t> </t>
<t pn="section-4.1-2">
<t> With a Sliding Window FEC code, the FEC Source Packet <bcp14>MUST</bcp14>
With a Sliding Window FEC Code, the FEC Source Packet MUST
contain information to identify the position occupied by contain information to identify the position occupied by
the ADU within the source flow, in terms specific to the the ADU within the source flow in terms specific to the
FEC Scheme. FEC scheme.
This information is known as the Source FEC Payload ID, and This information is known as the Source FEC Payload ID, and
the FEC Scheme is responsible for defining and interpreting it. the FEC scheme is responsible for defining and interpreting it.
<!--
This information MAY be
encoded into a specific field within the FEC source packet format
defined in this specification, called the Explicit Source FEC Payload
ID field. The exact contents and format of the Explicit Source FEC
Payload ID field are defined by the FEC schemes. Alternatively, the
FEC Scheme MAY define how the Source FEC Payload ID is derived from
other fields within the source packets.
</t> </t>
<t pn="section-4.1-3">
<t> With a Sliding Window FEC code, the FEC Repair
With a Sliding Window FEC Code, the FEC Repair Packets <bcp14>MUST</bcp14> contain information that identifies the relationship
Packets MUST contain information that identifies the relationship
between the contained repair payloads and the original source symbols between the contained repair payloads and the original source symbols
used during encoding. used during encoding.
This information is known as the Repair FEC Payload ID, and This information is known as the Repair FEC Payload ID, and
the FEC Scheme is responsible for defining and interpreting it. the FEC scheme is responsible for defining and interpreting it.
</t> </t>
<t pn="section-4.1-4">
<t> The sender operation (<xref target="RFC6363" format="default" sectionFormat="com
The Sender Operation (<xref target="RFC6363"/>, Section 4.2.) ma" section="4.2" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-4.2" d
and Receiver Operation (<xref target="RFC6363"/>, Section 4.3) are erivedContent="RFC6363"/>)
both specific to block FEC codes and therefore omitted below. and receiver operation (<xref target="RFC6363" format="default" sectionFormat="c
omma" section="4.3" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-4.3"
derivedContent="RFC6363"/>) are
both specific to block FEC codes and are therefore omitted below.
The following two sections detail similar operations for Sliding Window The following two sections detail similar operations for Sliding Window
FEC codes. FEC codes.
</t> </t>
</section> </section>
<section anchor="senderoperation-convolutional" numbered="true" toc="inclu
<section anchor="senderoperation-convolutional" title="Sender Operation with Sli de" removeInRFC="false" pn="section-4.2">
ding Window FEC Codes"> <name slugifiedName="name-sender-operation-with-slidi">Sender Operation
<!-- ====================== --> with Sliding Window FEC Codes</name>
<t pn="section-4.2-1">
<t> With a Sliding Window FEC scheme, the following operations, illustrated in
With a Sliding Window FEC Scheme, the following operations, illustrated in <xref target="senderfigure-convolutional" format="default" sectionFormat="of" de
Figure <xref target="senderfigure-convolutional" format="counter"></xref> rivedContent="Figure 2"/>
for the generic case (non-RTP repair flows), and in for the generic case (non-RTP repair flows) and in
Figure <xref target="senderfigurertp-convolutional" format="counter"></xref> <xref target="senderfigurertp-convolutional" format="default" sectionFormat="of"
derivedContent="Figure 3"/>
for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows: for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows:
<list style="numbers"> </t>
<t>A new ADU is provided by the application.</t> <ol spacing="normal" type="1" start="1" pn="section-4.2-2">
<li pn="section-4.2-2.1" derivedCounter="1.">A new ADU is provided by
<t>The FEC Framework communicates this ADU to the FEC Scheme.</t> the application.</li>
<li pn="section-4.2-2.2" derivedCounter="2.">The FEC Framework communi
<t>The sliding encoding window is updated by the FEC Scheme. cates this ADU to the FEC scheme.</li>
The ADU-to-source-symbols mapping as well as the encoding window management <li pn="section-4.2-2.3" derivedCounter="3.">The sliding encoding wind
details ow is updated by the FEC scheme.
are both the responsibility of the FEC Scheme and MUST be detailed there. The ADU-to-source-symbol mapping as well as the encoding window management d
<xref target="codingwindow-possibleManagement"></xref> provides non-normativ etails
e hints about what are both the responsibility of the FEC scheme and <bcp14>MUST</bcp14> be det
FEC Scheme designers need to consider;</t> ailed there.
<xref target="codingwindow-possibleManagement" format="default" sectionForma
<t>The Source FEC Payload ID information of the source packet is t="of" derivedContent="Appendix A"/> provides non-normative hints about what
determined by the FEC Scheme. If required by the FEC Scheme, the FEC scheme designers need to consider.</li>
<li pn="section-4.2-2.4" derivedCounter="4.">The Source FEC Payload ID
information of the source packet is
determined by the FEC scheme. If required by the FEC scheme, the
Source FEC Payload ID is encoded into the Explicit Source FEC Source FEC Payload ID is encoded into the Explicit Source FEC
Payload ID field and returned to the FEC Framework.</t> Payload ID field and returned to the FEC Framework.</li>
<li pn="section-4.2-2.5" derivedCounter="5.">The FEC Framework constru
<t>The FEC Framework constructs the FEC Source Packet according to cts the FEC Source Packet according to
<!-- REMOVED: <xref target="sourcepackets"></xref>, --> Figure 6 in <xref target="RFC6363" format="default" sectionFormat="of" derivedCo
<xref target="RFC6363"></xref> Figure 6, ntent="RFC6363"/>,
using the Explicit Source FEC Payload ID using the Explicit Source FEC Payload ID
provided by the FEC Scheme if applicable.</t> provided by the FEC scheme if applicable.</li>
<li pn="section-4.2-2.6" derivedCounter="6.">The FEC Source Packet is
<t>The FEC Source Packet is sent using normal transport-layer procedures. sent using normal transport-layer procedures.
This packet is sent using This packet is sent using
the same ADU flow identification information as would have been the same ADU flow identification information as would have been
used for the original source packet if the FEC Framework were not used for the original source packet if the FEC Framework were not
present (e.g., the source and destination addresses and UDP port numbers on the IP datagram carrying the present (e.g., the source and destination addresses and UDP port numbers on the IP datagram carrying the
source packet will be the same whether or not the FEC Framework is applied). source packet will be the same whether or not the FEC Framework is applied).
</t> </li>
<li pn="section-4.2-2.7" derivedCounter="7.">When the FEC Framework ne
<t>When the FEC Framework needs to send one or several FEC Repair Packets (e eds to send one or several FEC Repair Packets (e.g., according
.g., according to the target code rate), it asks the FEC scheme to create one
to the target Code Rate), it asks the FEC Scheme to create one
or several repair packet payloads from the current sliding encoding window or several repair packet payloads from the current sliding encoding window
along with their Repair FEC Payload ID.</t> along with their Repair FEC Payload ID.</li>
<li pn="section-4.2-2.8" derivedCounter="8.">The Repair FEC Payload ID
<t>The Repair FEC Payload IDs and repair packet payloads are provided back b s and repair packet payloads are provided back by the
y the FEC scheme to the FEC Framework.</li>
FEC Scheme to the FEC Framework.</t> <li pn="section-4.2-2.9" derivedCounter="9.">The FEC Framework constru
cts FEC Repair Packets
<t>The FEC Framework constructs FEC Repair Packets according to Figure 7 in <xref target="RFC6363" format="default" sectionForm
according to <xref target="RFC6363"></xref> Figure 7, <!-- REMOVED: <xref ta at="of" derivedContent="RFC6363"/>,
rget="repairpackets"></xref>, --> using the FEC Payload IDs and repair packet payloads provided by the FEC sch
using the FEC Payload IDs and repair packet payloads provided by the FEC Sch eme.</li>
eme.</t> <li pn="section-4.2-2.10" derivedCounter="10.">The FEC Repair Packets
are sent using normal transport-layer procedures.
<t>The FEC Repair Packets are sent using normal transport-layer procedures.
The port(s) and multicast group(s) to be used for FEC Repair Packets are def ined The port(s) and multicast group(s) to be used for FEC Repair Packets are def ined
in the FEC Framework Configuration Information.</t> in the FEC Framework Configuration Information.</li>
</list></t> </ol>
<figure anchor="senderfigure-convolutional" align="left" suppress-title=
<figure align="center" anchor="senderfigure-convolutional" title="Sender "false" pn="figure-2">
Operation with Sliding Window FEC Codes"> <name slugifiedName="name-sender-operation-with-slidin">Sender Operati
<artwork><![CDATA[ on with Sliding Window FEC Codes</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-3.1">
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
| (1) New Application Data Unit (ADU) | (1) New Application Data Unit (ADU)
v v
+---------------------+ +----------------+ +---------------------+ +----------------+
| FEC Framework | | FEC Scheme | | FEC Framework | | FEC Scheme |
| |-------------------------->| | | |--------------------------&gt;| |
| | (2) New ADU |(3) Update of | | | (2) New ADU |(3) Update of |
| | | encoding | | | | encoding |
| |<--------------------------| window | | |&lt;--------------------------| window |
|(5) Construct FEC | (4) Explicit Source | | |(5) Construct FEC | (4) Explicit Source | |
| Source Packet | FEC Payload ID(s) |(7) FEC | | Source Packet | FEC Payload ID(s) |(7) FEC |
| |<--------------------------| encoding | | |&lt;--------------------------| encoding |
|(9) Construct FEC | (8) Repair FEC Payload ID | | |(9) Construct FEC | (8) Repair FEC Payload ID | |
| Repair Packet(s) | + Repair symbol(s) +----------------+ | Repair Packet(s) | + Repair symbol(s) +----------------+
+---------------------+ +---------------------+
| |
| (6) FEC Source Packet | (6) FEC Source Packet
| (10) FEC Repair Packets | (10) FEC Repair Packets
v v
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
]]></artwork> </artwork>
</figure> </figure>
<figure anchor="senderfigurertp-convolutional" align="left" suppress-tit
<figure align="center" anchor="senderfigurertp-convolutional" title="Sen le="false" pn="figure-3">
der Operation with Sliding Window FEC Codes and RTP Repair Flows"> <name slugifiedName="name-sender-operation-with-sliding">Sender Operat
<artwork><![CDATA[ ion with Sliding Window FEC Codes and RTP Repair Flows</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-4.1">
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
| (1) New Application Data Unit (ADU) | (1) New Application Data Unit (ADU)
v v
+---------------------+ +----------------+ +---------------------+ +----------------+
| FEC Framework | | FEC Scheme | | FEC Framework | | FEC Scheme |
| |-------------------------->| | | |--------------------------&gt;| |
| | (2) New ADU |(3) Update of | | | (2) New ADU |(3) Update of |
| | | encoding | | | | encoding |
| |<--------------------------| window | | |&lt;--------------------------| window |
|(5) Construct FEC | (4) Explicit Source | | |(5) Construct FEC | (4) Explicit Source | |
| Source Packet | FEC Payload ID(s) |(7) FEC | | Source Packet | FEC Payload ID(s) |(7) FEC |
| |<--------------------------| encoding | | |&lt;--------------------------| encoding |
|(9) Construct FEC | (8) Repair FEC Payload ID | | |(9) Construct FEC | (8) Repair FEC Payload ID | |
| Repair Packet(s) | + Repair symbol(s) +----------------+ | Repair Packet(s) | + Repair symbol(s) +----------------+
+---------------------+ +---------------------+
| | | |
|(6) Source |(10) Repair payloads |(6) Source |(10) Repair payloads
| packets | | packets |
| + -- -- -- -- -+ | + -- -- -- -- -+
| | RTP | | | RTP |
| +-- -- -- -- --+ | +-- -- -- -- --+
v v v v
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
]]></artwork> </artwork>
</figure> </figure>
</section>
</section> <section anchor="receiveroperation-convolutional" numbered="true" toc="inc
lude" removeInRFC="false" pn="section-4.3">
<section anchor="receiveroperation-convolutional" title="Receiver Operation with <name slugifiedName="name-receiver-operation-with-sli">Receiver Operatio
Sliding Window FEC Codes"> n with Sliding Window FEC Codes</name>
<!-- ====================== --> <t pn="section-4.3-1">
With a Sliding Window FEC scheme, the following operations are illustrated in
<t> <xref target="receiverfigure" format="default" sectionFormat="of" derivedContent
With a Sliding Window FEC Scheme, the following operations, illustrated in ="Figure 4"/>
Figure <xref target="receiverfigure" format="counter"/> for the generic case (non-RTP repair flows) and in
for the generic case (non-RTP repair flows), and in <xref target="receiverfigurertp" format="default" sectionFormat="of" derivedCont
Figure <xref target="receiverfigurertp" format="counter"></xref> ent="Figure 5"/>
for the case of RTP repair flows. for the case of RTP repair flows.
The only differences with respect to block FEC codes lie in steps (4) and (5). The only differences with respect to block FEC codes lie in steps (4) and (5).
Therefore this section does not repeat the other steps of Therefore, this section does not repeat the other steps of
<xref target="RFC6363"/>, Section 4.3, "Receiver Operation". <xref target="RFC6363" format="default" sectionFormat="of" section="4.3" derived
Link="https://rfc-editor.org/rfc/rfc6363#section-4.3" derivedContent="RFC6363"/>
("Receiver Operation").
The new steps (4) and (5) are: The new steps (4) and (5) are:
<!-- <list style="empty"> --> </t>
<list hangIndent="4" style="hanging"> <ol type="1" start="4" spacing="normal" pn="section-4.3-2">
<t hangText="4."> The FEC Scheme uses the received FEC Payload IDs (and d <li pn="section-4.3-2.1" derivedCounter="4."> The FEC scheme uses the
erived received FEC Payload IDs (and derived
FEC Source Payload IDs when the Explicit Source FEC Payload ID field is n ot used) FEC Source Payload IDs when the Explicit Source FEC Payload ID field is n ot used)
to insert source and repair packets into the decoding window in the right way. to insert source and repair packets into the decoding window in the right way.
If at least one source packet is missing and at least one repair packet If at least one source packet is missing and at least one repair packet
has been received, then FEC decoding is attempted to recover missing sou has been received, then FEC decoding is attempted to recover the missing
rce payloads. source payloads.
The FEC Scheme determines whether source packets have been lost and wheth The FEC scheme determines whether source packets have been lost and wheth
er er
enough repair packets have been received to decode any or all of the miss ing enough repair packets have been received to decode any or all of the miss ing
source payloads.</t> source payloads.</li>
<li pn="section-4.3-2.2" derivedCounter="5."> The FEC scheme returns t
<t hangText="5."> The FEC Scheme returns the received and decoded ADUs to he received and decoded ADUs to the
the
FEC Framework, along with indications of any ADUs that were missing and c ould FEC Framework, along with indications of any ADUs that were missing and c ould
not be decoded.</t> not be decoded.</li>
</list> </ol>
</t> <figure anchor="receiverfigure" align="left" suppress-title="false" pn="
figure-4">
<figure align="center" anchor="receiverfigure" <name slugifiedName="name-receiver-operation-with-slid">Receiver Opera
title="Receiver Operation with Sliding Window FEC Codes"> tion with Sliding Window FEC Codes</name>
<preamble></preamble> <artwork name="" type="" align="left" alt="" pn="section-4.3-3.1">
<artwork><![CDATA[
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
|(6) ADUs |(6) ADUs
| |
+----------------------+ +----------------+ +----------------------+ +----------------+
| FEC Framework | | FEC Scheme | | FEC Framework | | FEC Scheme |
| |<--------------------------| | | |&lt;--------------------------| |
|(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding|
| IDs and pass IDs & |-------------------------->| | | IDs and pass IDs &amp; |--------------------------&gt;| |
| payloads to FEC |(3) Explicit Source FEC +----------------+ | payloads to FEC |(3) Explicit Source FEC +----------------+
| scheme | Payload IDs | scheme | Payload IDs
+----------------------+ Repair FEC Payload IDs +----------------------+ Repair FEC Payload IDs
^ Source payloads ^ Source payloads
| Repair payloads | Repair payloads
|(1) FEC Source |(1) FEC Source
| and Repair Packets | and Repair Packets
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
]]></artwork> </artwork>
</figure> </figure>
<figure anchor="receiverfigurertp" align="left" suppress-title="false" p
<figure align="center" anchor="receiverfigurertp" n="figure-5">
title="Receiver Operation with Sliding Window FEC Codes and RTP <name slugifiedName="name-receiver-operation-with-slidi">Receiver Oper
Repair Flows"> ation with Sliding Window FEC Codes and RTP Repair Flows</name>
<preamble></preamble> <artwork name="" type="" align="left" alt="" pn="section-4.3-4.1">
<artwork><![CDATA[
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
|(6) ADUs |(6) ADUs
| |
+----------------------+ +----------------+ +----------------------+ +----------------+
| FEC Framework | | FEC Scheme | | FEC Framework | | FEC Scheme |
| |<--------------------------| | | |&lt;--------------------------| |
|(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding| |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding|
| IDs and pass IDs & |--------------------------&gt;| | | IDs and pass IDs &amp; |--------------------------&gt;| |
| payloads to FEC |(3) Explicit Source FEC +----------------+ | payloads to FEC |(3) Explicit Source FEC +----------------+
| scheme | Payload IDs | scheme | Payload IDs
+----------------------+ Repair FEC Payload IDs +----------------------+ Repair FEC Payload IDs
^ ^ Source payloads ^ ^ Source payloads
| | Repair payloads | | Repair payloads
|Source pkts |Repair payloads |Source pkts |Repair payloads
| | | |
+-- |- -- -- -- -- -- -+ +-- |- -- -- -- -- -- -+
|RTP| | RTP Processing | |RTP| | RTP Processing |
| | +-- -- -- --|-- -+ | | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ | | +-- -- -- -- -- |--+ |
| | RTP Demux | | | | RTP Demux | |
+-- -- -- -- -- -- -- -+ +-- -- -- -- -- -- -- -+
^ ^
|(1) FEC Source and Repair Packets |(1) FEC Source and Repair Packets
| |
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
]]></artwork> </artwork>
</figure> </figure>
</section>
</section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<section title="Protocol Specification"> <name slugifiedName="name-protocol-specification">Protocol Specification</
<!-- ====================== --> name>
<section anchor="generalProtocolSpecification" title="General"> <section anchor="generalProtocolSpecification" numbered="true" toc="includ
<!-- ====================== --> e" removeInRFC="false" pn="section-5.1">
<name slugifiedName="name-general-2">General</name>
<t> <t pn="section-5.1-1">
This section discusses the protocol elements for the FEC Framework specific to S liding Window FEC schemes. This section discusses the protocol elements for the FEC Framework specific to S liding Window FEC schemes.
The global formats of source data packets (i.e., <xref target="RFC6363"/>, Figur e 6) and repair data packets (i.e., <xref target="RFC6363"/>, Figures 7 and 8) r emain the same with Sliding Window FEC codes. The global formats of source data packets (i.e., <xref target="RFC6363" format=" default" sectionFormat="of" derivedContent="RFC6363"/>, Figure 6) and repair dat a packets (i.e., <xref target="RFC6363" format="default" sectionFormat="of" deri vedContent="RFC6363"/>, Figures 7 and 8) remain the same with Sliding Window FEC codes.
They are not repeated here. They are not repeated here.
</t> </t>
</section> </section>
<section anchor="config" numbered="true" toc="include" removeInRFC="false"
<section anchor="config" title="FEC Framework Configuration Information"> pn="section-5.2">
<!-- ====================== --> <name slugifiedName="name-fec-framework-configuration">FEC Framework Con
figuration Information</name>
<t> <t pn="section-5.2-1">
The FEC Framework Configuration Information considerations of <xref target="RFC6 The FEC Framework Configuration Information considerations of <xref target="RFC6
363"/>, Section 5.5, equally applies to this 363" format="default" sectionFormat="of" section="5.5" derivedLink="https://rfc-
FECFRAME extension and is not repeated here. editor.org/rfc/rfc6363#section-5.5" derivedContent="RFC6363"/> equally
apply to this FECFRAME extension and are not repeated here.
</t> </t>
</section> </section>
<section anchor="fecscheme" numbered="true" toc="include" removeInRFC="fal
<section anchor="fecscheme" title="FEC Scheme Requirements"> se" pn="section-5.3">
<!-- ====================== --> <name slugifiedName="name-fec-scheme-requirements">FEC Scheme Requiremen
ts</name>
<t> <t pn="section-5.3-1">
The FEC Scheme requirements of <xref target="RFC6363"/>, Section 5.6, mostly app The FEC scheme requirements of <xref target="RFC6363" format="default" sectionFo
ly to this rmat="of" section="5.6" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-
FECFRAME extension and are not repeated here. 5.6" derivedContent="RFC6363"/> mostly apply to this FECFRAME extension and
An exception though is the "full specification of the FEC code", item (4), that are not repeated here. An exception, though, is the "full specification of
is specific to block FEC codes. the FEC code", item (4), which is specific to block FEC codes.
The following item (4-bis) applies in case of Sliding Window FEC schemes: In case of a Sliding Window FEC scheme, then the
<list hangIndent="4" style="hanging"> following item (4-bis) applies:
<t hangText="4-bis. A full specification of the Sliding Window FEC code">
<vspace blankLines="1" />
This specification MUST precisely define the
valid FEC-Scheme-Specific Information values, the valid FEC
Payload ID values, and the valid packet payload sizes (where packet
payload refers to the space within a packet dedicated to carrying
encoding symbols).
<vspace blankLines="1" />
Furthermore, given valid values of the FEC-Scheme-Specific Information, a
valid
Repair FEC Payload ID value, a valid packet payload size, and
a valid encoding window (i.e., a set of source symbols),
the specification MUST uniquely define the values of the encoding
symbol (or symbols) to be included in the repair packet payload with the
given Repair FEC Payload ID value.
<!--
<vspace blankLines="1" />
A common and simple way to specify the FEC code
to the required level of detail is to provide a precise
specification of an encoding algorithm that - given
valid values of the FEC-Scheme-Specific Information, a
valid Repair FEC Payload ID value, a valid packet payload size,
and in case of a Block FEC Code a source block
as input - produces the exact value of the encoding symbols as
output.
-->
</t>
</list>
</t> </t>
<dl newline="true" spacing="normal" indent="4" pn="section-5.3-2">
<t> <dt pn="section-5.3-2.1">4-bis.</dt>
Additionally, the FEC Scheme associated to a Sliding Window FEC Code: <dd pn="section-5.3-2.2">
<list style="symbols"> <t pn="section-5.3-2.2.1">A full specification of the Sliding Window
<t> MUST define the relationships between ADUs and the associated source FEC code.
symbols (mapping);</t> </t>
<t> MUST define the management of the encoding window that slides over th <t pn="section-5.3-2.2.2">
e set of ADUs. This specification <bcp14>MUST</bcp14> precisely define the
<xref target="codingwindow-possibleManagement"/> provides non nor valid FEC-Scheme-Specific Information values, the valid FEC
mative hints about what Payload ID values, and the valid packet payload sizes (where "packet
FEC Scheme designers need to consider;</t> payload" refers to the space within a packet dedicated to carrying
<t> MUST define the management of the decoding window. encoding symbols).
This usually consists in managing a system of linear equations (in case o </t>
f a linear FEC code);</t> <t pn="section-5.3-2.2.3">
</list> Furthermore, given valid values of the FEC-Scheme-Specific Information, a
valid Repair FEC Payload ID value, a valid packet payload size, and a vali
d
encoding window (i.e., a set of source symbols), the specification
<bcp14>MUST</bcp14> uniquely define the values of the encoding symbol (or
symbols) to be included in the repair packet payload with the given Repair
FEC Payload ID value.
</t>
</dd>
</dl>
<t pn="section-5.3-3">
Additionally, the FEC scheme associated with a Sliding Window FEC code:
</t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-5.3-4">
<li pn="section-5.3-4.1">
<bcp14>MUST</bcp14> define the relationships between ADUs and the as
sociated source symbols (mapping).</li>
<li pn="section-5.3-4.2">
<bcp14>MUST</bcp14> define the management of the encoding window tha
t slides over the set of ADUs.
<xref target="codingwindow-possibleManagement" format="default" s
ectionFormat="of" derivedContent="Appendix A"/> provides non-normative hints abo
ut what
FEC scheme designers need to consider.</li>
<li pn="section-5.3-4.3">
<bcp14>MUST</bcp14> define the management of the decoding window.
This usually consists of managing a system of linear equations (for a lin
ear FEC code).</li>
</ul>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6">
<section title="Feedback"> <name slugifiedName="name-feedback">Feedback</name>
<!-- ====================== --> <t pn="section-6-1">
The discussion in <xref target="RFC6363" format="default" sectionFormat="of" sec
<t> tion="6" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-6" derivedConte
The discussion of <xref target="RFC6363"/>, Section 6, equally applies to this nt="RFC6363"/> equally applies to this FECFRAME extension and is not repeated
FECFRAME extension and is not repeated here. here.
</t> </t>
</section> </section>
<section anchor="TransportProtocols" numbered="true" toc="include" removeInR
<section anchor="TransportProtocols" title="Transport Protocols"> FC="false" pn="section-7">
<!-- ====================== --> <name slugifiedName="name-transport-protocols">Transport Protocols</name>
<t pn="section-7-1">
<t> The discussion in <xref target="RFC6363" format="default" sectionFormat="of" sec
The discussion of <xref target="RFC6363"/>, Section 7, equally applies to this tion="7" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-7" derivedConte
nt="RFC6363"/> equally applies to this
FECFRAME extension and is not repeated here. FECFRAME extension and is not repeated here.
</t> </t>
</section> </section>
<section anchor="sec_congestion" numbered="true" toc="include" removeInRFC="
<section anchor="sec_congestion" title="Congestion Control"> false" pn="section-8">
<!-- ====================== --> <name slugifiedName="name-congestion-control">Congestion Control</name>
<t> <t pn="section-8-1">
The discussion of <xref target="RFC6363"/>, Section 8, equally applies to this The discussion in <xref target="RFC6363" format="default" sectionFormat="of" sec
tion="8" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-8" derivedConte
nt="RFC6363"/> equally applies to this
FECFRAME extension and is not repeated here. FECFRAME extension and is not repeated here.
</t> </t>
</section>
<section anchor="implementationStatus" title="Implementation Status">
<!-- ====================== -->
<t>
Editor's notes: RFC Editor, please remove this section motivated by RFC 7942 bef
ore publishing the RFC. Thanks!
</t>
<t>An implementation of FECFRAME extended to Sliding Window codes exists:
<list style="symbols">
<t>Organisation: Inria</t>
<t>Description: This is an implementation of FECFRAME extended to Sliding
Window codes and supporting the RLC FEC Scheme <xref target="RLC-ID"/>.
It is based on: (1) a proprietary implementation of FECFRAME, made by Inr
ia and Expway for which interoperability tests have been conducted;
and (2) a proprietary implementation of RLC Sliding Window FEC Codes.</t>
<t>Maturity: the basic FECFRAME maturity is "production", the FECFRAME ex
tension maturity is "under progress".</t>
<t>Coverage: the software implements a subset of <xref target="RFC6363"/>
, as specialized by the 3GPP eMBMS standard <xref target="MBMSTS"/>.
This software also covers the additional features of FECFRAME extended to
Sliding Window codes, in particular the RLC FEC Scheme.</t>
<t>Licensing: proprietary.</t>
<t>Implementation experience: maximum.</t>
<t>Information update date: March 2018.</t>
<t>Contact: vincent.roca@inria.fr</t>
</list>
</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-9">
<section title="Security Considerations"> <name slugifiedName="name-security-considerations">Security Considerations
<!-- ====================== --> </name>
<t pn="section-9-1">
<t> This FECFRAME extension does not add any new security considerations. All the
This FECFRAME extension does not add any new security consideration. considerations of <xref target="RFC6363" format="default" sectionFormat="of" sec
All the considerations of <xref target="RFC6363"/>, Section 9, apply to this doc tion="9" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-9" derivedConte
ument as well. nt="RFC6363"/> apply to this document as well. However, for the sake of
However, for the sake of completeness, the following goal can be added to the li completeness, the following goal can be added to the list provided in <xref targ
st provided in Section 9.1 "Problem Statement" of <xref target="RFC6363"/>: et="RFC6363" format="default" sectionFormat="of" section="9.1" derivedLink="http
<list style="symbols"> s://rfc-editor.org/rfc/rfc6363#section-9.1" derivedContent="RFC6363"/> ("Problem
<t> Attacks can try to corrupt source flows in order to modify the receiv Statement"):
er application's behavior
(as opposed to just denying service).</t>
</list>
</t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-9-2">
<li pn="section-9-2.1"> Attacks can try to corrupt source flows in order
to modify the receiver application's behavior
(as opposed to just denying service).</li>
</ul>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-10">
<section title="Operations and Management Considerations"> <name slugifiedName="name-operations-and-management-c">Operations and Mana
<!-- ====================== --> gement Considerations</name>
<t> <t pn="section-10-1">
This FECFRAME extension does not add any new Operations and Management Considera This FECFRAME extension does not add any new Operations and Management Considera
tion. tions.
All the considerations of <xref target="RFC6363"/>, Section 10, apply to this do All the considerations of <xref target="RFC6363" format="default" sectionFormat=
cument as well. "of" section="10" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-10" de
rivedContent="RFC6363"/> apply to this document as well.
</t> </t>
</section> </section>
<section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="iana" title="IANA Considerations"> "section-11">
<!-- ====================== --> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t pn="section-11-1">
<t> This document has no IANA actions.
No IANA actions are required for this document.
</t> </t>
<t pn="section-11-2">A FEC scheme for use with this FEC Framework is ident
<t>A FEC Scheme for use with this FEC Framework is identified via its FEC Encodi ified via its FEC Encoding ID.
ng ID.
It is subject to IANA registration in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry. It is subject to IANA registration in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry.
All the rules of <xref target="RFC6363"/>, Section 11, apply and are not repeate d here. All the rules of <xref target="RFC6363" format="default" sectionFormat="of" sect ion="11" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-11" derivedCont ent="RFC6363"/> apply and are not repeated here.
</t> </t>
</section>
<section title="Acknowledgments">
<!-- ====================== -->
<t>
The authors would like to thank Christer Holmberg, David Black, Gorry Fairhurst,
and Emmanuel Lochin, Spencer Dawkins, Ben Campbell, Benjamin Kaduk, Eric Rescor
la, Adam Roach, and Greg Skinner for their valuable feedback on this document.
This document being an extension to <xref target="RFC6363"/>, the authors would
also like to thank Mark Watson as the main author of that RFC.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-12">
<name slugifiedName="name-references">References</name>
&rfc2119; <references pn="section-12.1">
&rfc8174; <name slugifiedName="name-normative-references">Normative References</na
&rfc6363; me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
</references> 119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<references title="Informative References"> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
&rfc5052; <author initials="S." surname="Bradner" fullname="S. Bradner">
&rfc6364; <organization showOnFrontPage="true"/>
&rfc6681; </author>
<!-- &rfc6773; --> <date year="1997" month="March"/>
&rfc6816; <abstract>
&rfc6865; <t>In many standards track documents several words are used to sig
&rfc8406; nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
<reference anchor="MBMSTS" target="http://ftp.3gpp.org/specs/html-info/263 s. This document specifies an Internet Best Current Practices for the Internet
46.htm"> Community, and requests discussion and suggestions for improvements.</t>
<front> </abstract>
<title>Multimedia Broadcast/Multicast Service (MBMS); Protocols and co </front>
decs</title> <seriesInfo name="BCP" value="14"/>
<author> <seriesInfo name="RFC" value="2119"/>
<organization>3GPP</organization> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</author> </reference>
<date month="March" year="2009" /> <reference anchor="RFC6363" target="https://www.rfc-editor.org/info/rfc6
</front> 363" quoteTitle="true" derivedAnchor="RFC6363">
<seriesInfo name="3GPP TS" value="26.346" /> <front>
</reference> <title>Forward Error Correction (FEC) Framework</title>
<author initials="M." surname="Watson" fullname="M. Watson">
<reference anchor="RLC-ID" target="https://tools.ietf.org/html/draft-ietf- <organization showOnFrontPage="true"/>
tsvwg-rlc-fec-scheme"> </author>
<front> <author initials="A." surname="Begen" fullname="A. Begen">
<title>Sliding Window Random Linear Code (RLC) Forward Erasure Correct <organization showOnFrontPage="true"/>
ion (FEC) Scheme for FECFRAME</title> </author>
<author initials="V" surname="Roca" fullname="Vincent Roca"> <organiza <author initials="V." surname="Roca" fullname="V. Roca">
tion /> </author> <organization showOnFrontPage="true"/>
<author initials="B" surname="Teibi" fullname="Belkacem Teibi"> <organ </author>
ization /> </author> <date year="2011" month="October"/>
<date month="September" year="2018" /> <abstract>
</front> <t>This document describes a framework for using Forward Error Cor
<seriesInfo name='Work in' value='Progress' /> rection (FEC) codes with applications in public and private IP networks to provi
<seriesInfo name='Transport Area Working Group (TSVWG)' value='draft-iet de protection against packet loss. The framework supports applying FEC to arbit
f-tsvwg-rlc-fec-scheme (Work in Progress)' /> rary packet flows over unreliable transport and is primarily intended for real-t
</reference> ime, or streaming, media. This framework can be used to define Content Delivery
Protocols that provide FEC for streaming media delivery or other packet flows.
Content Delivery Protocols defined using this framework can support any FEC sch
eme (and associated FEC codes) that is compliant with various requirements defin
ed in this document. Thus, Content Delivery Protocols can be defined that are no
t specific to a particular FEC scheme, and FEC schemes can be defined that are n
ot specific to a particular Content Delivery Protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6363"/>
<seriesInfo name="DOI" value="10.17487/RFC6363"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references>
<references pn="section-12.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="MBMSTS" target="http://ftp.3gpp.org/specs/html-info/2
6346.htm" quoteTitle="true" derivedAnchor="MBMSTS">
<front>
<title>Multimedia Broadcast/Multicast Service (MBMS); Protocols and
codecs</title>
<seriesInfo name="3GPP TS" value="26.346"/>
<author>
<organization showOnFrontPage="true">3GPP</organization>
</author>
<date month="March" year="2009"/>
</front>
</reference>
<reference anchor="RFC5052" target="https://www.rfc-editor.org/info/rfc5
052" quoteTitle="true" derivedAnchor="RFC5052">
<front>
<title>Forward Error Correction (FEC) Building Block</title>
<author initials="M." surname="Watson" fullname="M. Watson">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Luby" fullname="M. Luby">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Vicisano" fullname="L. Vicisano">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="August"/>
<abstract>
<t>This document describes how to use Forward Error Correction (FE
C) codes to efficiently provide and/or augment reliability for bulk data transfe
r over IP multicast. This document defines a framework for the definition of th
e information that needs to be communicated in order to use an FEC code for bulk
data transfer, in addition to the encoded data itself, and for definition of fo
rmats and codes for communication of that information. Both information communi
cated with the encoded data itself and information that needs to be communicated
'out-of-band' are considered. The procedures for specifying new FEC codes, def
ining the information communication requirements associated with those codes and
registering them with the Internet Assigned Numbers Authority (IANA) are also d
escribed. The requirements on Content Delivery Protocols that wish to use FEC c
odes defined within this framework are also defined. The companion document tit
led "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes
some applications of FEC codes for delivering content. This document obsoletes R
FC 3452. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5052"/>
<seriesInfo name="DOI" value="10.17487/RFC5052"/>
</reference>
<reference anchor="RFC6364" target="https://www.rfc-editor.org/info/rfc6
364" quoteTitle="true" derivedAnchor="RFC6364">
<front>
<title>Session Description Protocol Elements for the Forward Error C
orrection (FEC) Framework</title>
<author initials="A." surname="Begen" fullname="A. Begen">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="October"/>
<abstract>
<t>This document specifies the use of the Session Description Prot
ocol (SDP) to describe the parameters required to signal the Forward Error Corre
ction (FEC) Framework Configuration Information between the sender(s) and receiv
er(s). This document also provides examples that show the semantics for groupin
g multiple source and repair flows together for the applications that simultaneo
usly use multiple instances of the FEC Framework. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6364"/>
<seriesInfo name="DOI" value="10.17487/RFC6364"/>
</reference>
<reference anchor="RFC6681" target="https://www.rfc-editor.org/info/rfc6
681" quoteTitle="true" derivedAnchor="RFC6681">
<front>
<title>Raptor Forward Error Correction (FEC) Schemes for FECFRAME</t
itle>
<author initials="M." surname="Watson" fullname="M. Watson">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Stockhammer" fullname="T. Stockhammer
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Luby" fullname="M. Luby">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="August"/>
<abstract>
<t>This document describes Fully-Specified Forward Error Correctio
n (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliab
le delivery of media streams in the context of the FEC Framework. The Raptor an
d RaptorQ codes are systematic codes, where a number of repair symbols are gener
ated from a set of source symbols and sent in one or more repair flows in additi
on to the source symbols that are sent to the receiver(s) within a source flow.
The Raptor and RaptorQ codes offer close to optimal protection against arbitrar
y packet losses at a low computational complexity. Six FEC Schemes are defined:
two for the protection of arbitrary packet flows, two that are optimized for sm
all source blocks, and two for the protection of a single flow that already cont
ains a sequence number. Repair data may be sent over arbitrary datagram transpor
t (e.g., UDP) or using RTP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6681"/>
<seriesInfo name="DOI" value="10.17487/RFC6681"/>
</reference>
<reference anchor="RFC6816" target="https://www.rfc-editor.org/info/rfc6
816" quoteTitle="true" derivedAnchor="RFC6816">
<front>
<title>Simple Low-Density Parity Check (LDPC) Staircase Forward Erro
r Correction (FEC) Scheme for FECFRAME</title>
<author initials="V." surname="Roca" fullname="V. Roca">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Cunche" fullname="M. Cunche">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Lacan" fullname="J. Lacan">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="December"/>
<abstract>
<t>This document describes a fully specified simple Forward Error
Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that
can be used to protect media streams along the lines defined by FECFRAME. Thes
e codes have many interesting properties: they are systematic codes, they perfor
m close to ideal codes in many use-cases, and they also feature very high encodi
ng and decoding throughputs. LDPC-Staircase codes are therefore a good solution
to protect a single high bitrate source flow or to protect globally several mid
-rate flows within a single FECFRAME instance. They are also a good solution wh
enever the processing load of a software encoder or decoder must be kept to a mi
nimum.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6816"/>
<seriesInfo name="DOI" value="10.17487/RFC6816"/>
</reference>
<reference anchor="RFC6865" target="https://www.rfc-editor.org/info/rfc6
865" quoteTitle="true" derivedAnchor="RFC6865">
<front>
<title>Simple Reed-Solomon Forward Error Correction (FEC) Scheme for
FECFRAME</title>
<author initials="V." surname="Roca" fullname="V. Roca">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Cunche" fullname="M. Cunche">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Lacan" fullname="J. Lacan">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Bouabdallah" fullname="A. Bouabdallah
">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Matsuzono" fullname="K. Matsuzono">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="February"/>
<abstract>
<t>This document describes a fully-specified simple Forward Error
Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known
as the Galois Field) GF(2^^m), with 2 &lt;= m &lt;= 16, that can be used to pro
tect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solo
mon codes considered have attractive properties, since they offer optimal protec
tion against packet erasures and the source symbols are part of the encoding sym
bols, which can greatly simplify decoding. However, the price to pay is a limit
on the maximum source block size, on the maximum number of encoding symbols, an
d a computational complexity higher than that of the Low-Density Parity Check (L
DPC) codes, for instance.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6865"/>
<seriesInfo name="DOI" value="10.17487/RFC6865"/>
</reference>
<reference anchor="RFC8406" target="https://www.rfc-editor.org/info/rfc8
406" quoteTitle="true" derivedAnchor="RFC8406">
<front>
<title>Taxonomy of Coding Techniques for Efficient Network Communica
tions</title>
<author initials="B." surname="Adamson" fullname="B. Adamson">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Adjih" fullname="C. Adjih">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Bilbao" fullname="J. Bilbao">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Firoiu" fullname="V. Firoiu">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Fitzek" fullname="F. Fitzek">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Ghanem" fullname="S. Ghanem">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Lochin" fullname="E. Lochin">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Masucci" fullname="A. Masucci">
<organization showOnFrontPage="true"/>
</author>
<author initials="M-J." surname="Montpetit" fullname="M-J. Montpetit
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Pedersen" fullname="M. Pedersen">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Peralta" fullname="G. Peralta">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Roca" fullname="V. Roca" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Saxena" fullname="P. Saxena">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Sivakumar" fullname="S. Sivakumar">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="June"/>
<abstract>
<t>This document summarizes recommended terminology for Network Co
ding concepts and constructs. It provides a comprehensive set of terms in order
to avoid ambiguities in future IRTF and IETF documents on Network Coding. This
document is the product of the Coding for Efficient Network Communications Rese
arch Group (NWCRG), and it is in line with the terminology used by the RFCs prod
uced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF
working groups.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8406"/>
<seriesInfo name="DOI" value="10.17487/RFC8406"/>
</reference>
<reference anchor="RFC8681" target="https://www.rfc-editor.org/info/rfc8
681" quoteTitle="true" derivedAnchor="RFC8681">
<front>
<title>Sliding Window Random Linear Code (RLC) Forward Erasure Corre
ction (FEC) Schemes for FECFRAME</title>
<seriesInfo name="RFC" value="8681"/>
<seriesInfo name="DOI" value="10.17487/RFC8681"/>
<author initials="V" surname="Roca" fullname="Vincent Roca">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Teibi" fullname="Belkacem Teibi">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2020"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="codingwindow-possibleManagement" numbered="true" toc="inclu
<section anchor="codingwindow-possibleManagement" title="About Sliding Encoding de" removeInRFC="false" pn="section-appendix.a">
Window Management (informational)"> <name slugifiedName="name-about-sliding-encoding-wind">About Sliding Encod
<!-- ====================== --> ing Window Management (Informational)</name>
<t pn="section-appendix.a-1">
<t> The FEC Framework does not specify the management of the sliding encoding window
The FEC Framework does not specify the management of the sliding encoding window , which is the responsibility of the FEC scheme.
which is the responsibility of the FEC Scheme.
This annex only provides a few informational hints. This annex only provides a few informational hints.
</t> </t>
<t pn="section-appendix.a-2">
<t> Source symbols are added to the sliding encoding window each time a
Source symbols are added to the sliding encoding window each time a new ADU is a new ADU is available at the sender after the ADU-to-source-symbol
vailable at the sender, after the ADU-to-source-symbol mapping specific to the F mapping specific to the FEC scheme has been done.
EC Scheme.
</t>
<t>
Source symbols are removed from the sliding encoding window, for instance:
<list style="symbols">
<t> after a certain delay, when an "old" ADU of a real-time flow times ou
t.
The source symbol retention delay in the sliding encoding window
should therefore be initialized according to the real-time features of incoming
flow(s) when applicable; </t>
<t> once the sliding encoding window has reached its maximum size (there
is usually an upper limit to the sliding encoding window size).
In that case the oldest symbol is removed each time a new source
symbol is added. </t>
</list>
</t> </t>
<t pn="section-appendix.a-3">
<t> Source symbols are removed from the sliding encoding window. For instance:
</t>
<ul spacing="normal" bare="false" empty="false" pn="section-appendix.a-4">
<li pn="section-appendix.a-4.1"> After a certain delay, when an "old" AD
U of a real-time flow times out.
The source symbol retention delay in the sliding encoding window
should therefore be initialized according to the real-time features of incoming
flow(s) when applicable. </li>
<li pn="section-appendix.a-4.2"> Once the sliding encoding window has re
ached its maximum size (there is usually an upper limit to the sliding encoding
window size).
In that case, the oldest symbol is removed each time a new source
symbol is added. </li>
</ul>
<t pn="section-appendix.a-5">
Several considerations can impact the management of this sliding encoding window : Several considerations can impact the management of this sliding encoding window :
<list style="symbols">
<t> at the source flows level: real-time constraints can limit the total
time source symbols can remain in the encoding window; </t>
<t> at the FEC code level: theoretical or practical limitations (e.g., be
cause of computational complexity) can limit the number of source symbols in the
encoding window; </t>
<t> at the FEC Scheme level: signaling and window management are intrinsi
cally related.
For instance, an encoding window composed of a non-sequential set
of source symbols requires an appropriate signaling to inform a receiver of the
composition of the encoding window, and the associated transmission overhead ca
n limit the maximum encoding window size.
On the opposite, an encoding window always composed of a sequenti
al set of source symbols simplifies signaling: providing the identity of the fir
st source symbol plus their number is sufficient, which creates a fixed and rela
tively small transmission overhead.
</t>
</list>
<!-- The most stringent limitation defines the maximum encoding window size, eit
her in terms of number of source symbols or number of ADUs, whichever applies. -
->
</t> </t>
</section> <ul spacing="normal" bare="false" empty="false" pn="section-appendix.a-6">
<li pn="section-appendix.a-6.1"> At the source flows level: real-time co
nstraints can limit the
total time during which source symbols can remain in the encoding window.
</li>
<li pn="section-appendix.a-6.2"> At the FEC code level: theoretical or p
ractical limitations (e.g., because of computational complexity) can limit the n
umber of source symbols in the encoding window. </li>
<li pn="section-appendix.a-6.3"> At the FEC scheme level: signaling and
window management are intrinsically related.
For instance, an encoding window composed of a nonsequential set
of source symbols requires appropriate signaling to inform a receiver of the com
position of the encoding window, and the associated transmission overhead can li
mit the maximum encoding window size.
On the contrary, an encoding window always composed of a sequenti
al set of source symbols simplifies signaling: providing the identity of the fir
st source symbol plus its number is sufficient, which creates a fixed and relati
vely small transmission overhead.
</li>
</ul>
</section>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.b">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t pn="section-appendix.b-1">
The authors would like to thank Christer Holmberg, David Black, Gorry
Fairhurst, Emmanuel Lochin, Spencer Dawkins, Ben Campbell, Benjamin Kaduk,
Eric Rescorla, Adam Roach, and Greg Skinner for their valuable feedback on
this document. This document being an extension of <xref target="RFC6363" forma
t="default" sectionFormat="of" derivedContent="RFC6363"/>, the authors would als
o like to thank Mark Watson as the
main author of that RFC.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Vincent Roca" initials="V" surname="Roca">
<organization showOnFrontPage="true">INRIA</organization>
<address>
<postal>
<street/>
<city/>
<extaddr>Univ. Grenoble Alpes</extaddr>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
</address>
</author>
<author fullname="Ali Begen" initials="A." surname="Begen">
<organization showOnFrontPage="true">Networked Media</organization>
<address>
<postal>
<street/>
<city>Konya</city>
<region/>
<code/>
<country>Turkey</country>
</postal>
<email>ali.begen@networked.media</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 138 change blocks. 
849 lines changed or deleted 1283 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/