rfc8681xml2.original.xml   rfc8681.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-rlc-fec-scheme-16" indexInclude="true" ipr
.2119.xml"> ="trust200902" number="8681" prepTime="2020-01-08T16:08:50" scripts="Common,Lati
<!ENTITY rfc5170 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC n" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude=
.5170.xml"> <!-- ldpc --> "true" xml:lang="en">
<!ENTITY rfc5510 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <link href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme-1
.5510.xml"> <!-- r-s --> 6" rel="prev"/>
<!ENTITY rfc6363 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <link href="https://dx.doi.org/10.17487/rfc8681" rel="alternate"/>
.6363.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!ENTITY rfc6364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <front>
.6364.xml"> <title abbrev="RLC FEC Scheme">Sliding Window Random Linear Code (RLC) Forwa
<!ENTITY rfc6726 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC rd Erasure Correction (FEC) Schemes for FECFRAME</title>
.6726.xml"> <!-- flute --> <seriesInfo name="RFC" value="8681" stream="IETF"/>
<!ENTITY rfc6681 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <author fullname="Vincent Roca" initials="V" surname="Roca">
.6681.xml"> <!-- raptor/q for ff --> <organization showOnFrontPage="true">INRIA</organization>
<!ENTITY rfc6816 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <address>
.6816.xml"> <!-- ldpc-staircase for ff --> <postal>
<!ENTITY rfc6865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <street/>
.6865.xml"> <!-- r-s for ff --> <city/>
<!ENTITY rfc8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <code/>
.8174.xml"> <extaddr>Univ. Grenoble Alpes</extaddr>
<!ENTITY rfc8406 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <country>France</country>
.8406.xml"> </postal>
]> <email>vincent.roca@inria.fr</email>
</address>
<?rfc toc="yes" ?> </author>
<?rfc compact="yes" ?> <author fullname="Belkacem Teibi" initials="B" surname="Teibi">
<?rfc subcompact="yes" ?> <organization showOnFrontPage="true">INRIA</organization>
<?rfc symrefs="yes" ?> <address>
<?rfc sortrefs="yes" ?> <postal>
<?rfc rfcedstyle="yes" ?> <street/>
<city/>
<rfc category="std" docName="draft-ietf-tsvwg-rlc-fec-scheme-16" ipr="trust20090 <code/>
2"> <extaddr>Univ. Grenoble Alpes</extaddr>
<country>France</country>
<front> </postal>
<title abbrev="RLC FEC Scheme">Sliding Window Random Linear Code (RLC) Fo <email>belkacem.teibi@gmail.com</email>
rward Erasure Correction (FEC) Schemes for FECFRAME</title> </address>
</author>
<author fullname="Vincent Roca" initials="V" surname="Roca"> <date month="01" year="2020"/>
<organization>INRIA</organization> <workgroup>TSVWG</workgroup>
<address> <keyword>RLC</keyword>
<postal> <keyword>FEC</keyword>
<street></street> <keyword>FECFRAME</keyword>
<city>Univ. Grenoble Alpes</city> <keyword>packet loss recovery</keyword>
<code></code> <keyword>reliability</keyword>
<country>France</country> <abstract pn="section-abstract">
</postal> <t pn="section-abstract-1">
<email>vincent.roca@inria.fr</email> This document describes two fully specified Forward Erasure Correction (FEC) Sch
</address> emes for Sliding Window Random Linear Codes (RLC), one for RLC over the Galois F
</author> ield (a.k.a., Finite Field) GF(2), a second one for RLC over the Galois Field GF
(2<sup>8</sup>), each time with the possibility of controlling the code density.
<author fullname="Belkacem Teibi" initials="B" surname="Teibi"> They can protect arbitrary media streams along the lines defined by FECFRAME ext
<organization>INRIA</organization> ended to Sliding Window FEC Codes.
<address> These Sliding Window FEC Codes rely on an encoding window that slides over the s
<postal> ource symbols, generating new repair symbols whenever needed.
<street></street> Compared to block FEC codes, these Sliding Window FEC Codes offer key advantages
<city>Univ. Grenoble Alpes</city> with real-time flows in terms of reduced FEC-related latency while often provid
<code></code> ing improved packet erasure recovery capabilities.
<country>France</country>
</postal>
<email>belkacem.teibi@gmail.com</email>
</address>
</author>
<!-- <date month="February" year="2017" /> -->
<date/>
<workgroup>TSVWG</workgroup>
<abstract>
<t>
This document describes two fully-specified Forward Erasure Correction (FEC) Sch
emes for Sliding Window Random Linear Codes (RLC), one for RLC over the Galois F
ield (A.K.A. Finite Field) GF(2), a second one for RLC over the Galois Field GF(
2^^8), each time with the possibility of controlling the code density.
They can protect arbitrary media streams along the lines defined by FECFRAME ext
ended to sliding window FEC codes.
These sliding window FEC codes rely on an encoding window that slides over the s
ource symbols, generating new repair symbols whenever needed.
Compared to block FEC codes, these sliding window FEC codes offer key advantages
with real-time flows in terms of reduced FEC-related latency while often provid
ing improved packet erasure recovery capabilities.
</t> </t>
</abstract> </abstract>
<boilerplate>
</front> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<middle> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<section anchor="introduction" title="Introduction"> <t pn="section-boilerplate.1-1">
<!-- ====================== --> This is an Internet Standards Track document.
</t>
<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/rfc8681" 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>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derive
dContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-limits-of-blo
ck-codes-with-">Limits of Block Codes with Real-Time Flows</xref></t>
</li>
<li pn="section-toc.1-1.1.2.2">
<t keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derive
dContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-lower-latency
-and-better-pr">Lower Latency and Better Protection of Real-Time Flows with the
Sliding Window RLC Codes</xref></t>
</li>
<li pn="section-toc.1-1.1.2.3">
<t keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derive
dContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-small-transmi
ssion-overhead">Small Transmission Overheads with the Sliding Window RLC FEC Sch
eme</xref></t>
</li>
<li pn="section-toc.1-1.1.2.4">
<t keepWithNext="true" pn="section-toc.1-1.1.2.4.1"><xref derive
dContent="1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-document-orga
nization">Document Organization</xref></t>
</li>
</ul>
</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-definitions-and-abbreviat
io">Definitions and Abbreviations</xref></t>
</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-common-procedures">Common
Procedures</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derive
dContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-codec-paramet
ers">Codec Parameters</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t keepWithNext="true" pn="section-toc.1-1.3.2.2.1"><xref derive
dContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-adu-adui-and-
source-symbols">ADU, ADUI, and Source Symbols Mappings</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t keepWithNext="true" pn="section-toc.1-1.3.2.3.1"><xref derive
dContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-encoding-wind
ow-management">Encoding Window Management</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4">
<t keepWithNext="true" pn="section-toc.1-1.3.2.4.1"><xref derive
dContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-source-symbol
-identificatio">Source Symbol Identification</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5">
<t keepWithNext="true" pn="section-toc.1-1.3.2.5.1"><xref derive
dContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-pseudorandom-
number-generat">Pseudorandom Number Generator (PRNG)</xref></t>
</li>
<li pn="section-toc.1-1.3.2.6">
<t keepWithNext="true" pn="section-toc.1-1.3.2.6.1"><xref derive
dContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-coding-coeffi
cients-generat">Coding Coefficients Generation Function</xref></t>
</li>
<li pn="section-toc.1-1.3.2.7">
<t keepWithNext="true" pn="section-toc.1-1.3.2.7.1"><xref derive
dContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-finite-field-
operations">Finite Field Operations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.7.2">
<li pn="section-toc.1-1.3.2.7.2.1">
<t keepWithNext="true" pn="section-toc.1-1.3.2.7.2.1.1"><xre
f derivedContent="3.7.1" format="counter" sectionFormat="of" target="section-3.7
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-f
inite-field-definitions">Finite Field Definitions</xref></t>
</li>
<li pn="section-toc.1-1.3.2.7.2.2">
<t keepWithNext="true" pn="section-toc.1-1.3.2.7.2.2.1"><xre
f derivedContent="3.7.2" format="counter" sectionFormat="of" target="section-3.7
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-l
inear-combination-of-sourc">Linear Combination of Source Symbol Computation</xre
f></t>
</li>
</ul>
</li>
</ul>
</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-sliding-window-rlc-fec-sc
he">Sliding Window RLC FEC Scheme over GF(2<sup>8</sup>) for Arbitrary Packet Fl
ows</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-formats-and-c
odes">Formats and Codes</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.1.2">
<li pn="section-toc.1-1.4.2.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.1.1"><xre
f derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-f
ec-framework-configuration">FEC Framework Configuration Information</xref></t>
</li>
<li pn="section-toc.1-1.4.2.1.2.2">
<t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.2.1"><xre
f derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xplicit-source-fec-payload">Explicit Source FEC Payload ID</xref></t>
</li>
<li pn="section-toc.1-1.4.2.1.2.3">
<t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.3.1"><xre
f derivedContent="4.1.3" format="counter" sectionFormat="of" target="section-4.1
.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-r
epair-fec-payload-id">Repair FEC Payload ID</xref></t>
</li>
</ul>
</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-procedures">P
rocedures</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-sliding-window-rlc-fec-sc
hem">Sliding Window RLC FEC Scheme over GF(2) for Arbitrary Packet Flows</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-formats-and-c
odes-2">Formats and Codes</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.1.2">
<li pn="section-toc.1-1.5.2.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.5.2.1.2.1.1"><xre
f derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-f
ec-framework-configuration-">FEC Framework Configuration Information</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.2">
<t keepWithNext="true" pn="section-toc.1-1.5.2.1.2.2.1"><xre
f derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xplicit-source-fec-payload-">Explicit Source FEC Payload ID</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.3">
<t keepWithNext="true" pn="section-toc.1-1.5.2.1.2.3.1"><xre
f derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1
.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-r
epair-fec-payload-id-2">Repair FEC Payload ID</xref></t>
</li>
</ul>
</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-procedures-2"
>Procedures</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-fec-code-specification">F
EC Code Specification</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derive
dContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-encoding-side
">Encoding Side</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derive
dContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-decoding-side
">Decoding Side</xref></t>
</li>
</ul>
</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-security-considerations">
Security Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t keepWithNext="true" pn="section-toc.1-1.7.2.1.1"><xref derive
dContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-attacks-again
st-the-data-fl">Attacks Against the Data Flow</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.7.2.1.2">
<li pn="section-toc.1-1.7.2.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.7.2.1.2.1.1"><xre
f derivedContent="7.1.1" format="counter" sectionFormat="of" target="section-7.1
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-a
ccess-to-confidential-cont">Access to Confidential Content</xref></t>
</li>
<li pn="section-toc.1-1.7.2.1.2.2">
<t keepWithNext="true" pn="section-toc.1-1.7.2.1.2.2.1"><xre
f derivedContent="7.1.2" format="counter" sectionFormat="of" target="section-7.1
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-c
ontent-corruption">Content Corruption</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7.2.2">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.1"><xref derive
dContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-attacks-again
st-the-fec-par">Attacks Against the FEC Parameters</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t keepWithNext="true" pn="section-toc.1-1.7.2.3.1"><xref derive
dContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-when-several-
source-flows-a">When Several Source Flows are to be Protected Together</xref></t
>
</li>
<li pn="section-toc.1-1.7.2.4">
<t keepWithNext="true" pn="section-toc.1-1.7.2.4.1"><xref derive
dContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-baseline-secu
re-fec-framewo">Baseline Secure FEC Framework Operation</xref></t>
</li>
<li pn="section-toc.1-1.7.2.5">
<t keepWithNext="true" pn="section-toc.1-1.7.2.5.1"><xref derive
dContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-additional-se
curity-conside">Additional Security Considerations for Numerical Computations</x
ref></t>
</li>
</ul>
</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-operations-and-management
-c">Operations and Management Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t keepWithNext="true" pn="section-toc.1-1.8.2.1.1"><xref derive
dContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-operational-r
ecommendations">Operational Recommendations: Finite Field GF(2) Versus GF(2<sup>
8</sup>)</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t keepWithNext="true" pn="section-toc.1-1.8.2.2.1"><xref derive
dContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-operational-r
ecommendations-">Operational Recommendations: Coding Coefficients Density Thresh
old</xref></t>
</li>
</ul>
</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-iana-considerations">IANA
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-references">References<
/xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t keepWithNext="true" pn="section-toc.1-1.10.2.1.1"><xref deriv
edContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-normative-
references">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t keepWithNext="true" pn="section-toc.1-1.10.2.2.1"><xref deriv
edContent="10.2" format="counter" sectionFormat="of" target="section-10.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.11">
<t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedConten
t="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>
.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tinymt
32-validation-criteri">TinyMT32 Validation Criteria (Normative)</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedConten
t="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>
.  <xref derivedContent="" format="title" sectionFormat="of" target="name-assess
ing-the-prng-adequacy">Assessing the PRNG Adequacy (Informational)</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedConten
t="Appendix C" format="default" sectionFormat="of" target="section-appendix.c"/>
.  <xref derivedContent="" format="title" sectionFormat="of" target="name-possib
le-parameter-derivati">Possible Parameter Derivation (Informational)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.13.2">
<li pn="section-toc.1-1.13.2.1">
<t keepWithNext="true" pn="section-toc.1-1.13.2.1.1"><xref deriv
edContent="C.1" format="counter" sectionFormat="of" target="section-c.1"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-case-of-a-cb
r-real-time-flo">Case of a CBR Real-Time Flow</xref></t>
</li>
<li pn="section-toc.1-1.13.2.2">
<t keepWithNext="true" pn="section-toc.1-1.13.2.2.1"><xref deriv
edContent="C.2" format="counter" sectionFormat="of" target="section-c.2"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-other-types-
of-real-time-fl">Other Types of Real-Time Flow</xref></t>
</li>
<li pn="section-toc.1-1.13.2.3">
<t keepWithNext="true" pn="section-toc.1-1.13.2.3.1"><xref deriv
edContent="C.3" format="counter" sectionFormat="of" target="section-c.3"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-case-of-a-no
n-real-time-flo">Case of a Non-Real-Time Flow</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedConten
t="Appendix D" format="default" sectionFormat="of" target="section-appendix.d"/>
.  <xref derivedContent="" format="title" sectionFormat="of" target="name-decodi
ng-beyond-maximum-lat">Decoding Beyond Maximum Latency Optimization (Information
al)</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.e"/><xref derived
Content="" format="title" sectionFormat="of" target="name-acknowledgments">Ackno
wledgments</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t keepWithNext="true" pn="section-toc.1-1.16.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.f"/><xref derived
Content="" format="title" sectionFormat="of" target="name-authors-addresses">Aut
hors' Addresses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">
Application-Level Forward Erasure Correction (AL-FEC) codes, or simply FEC codes , are a key element of communication systems. Application-Level Forward Erasure Correction (AL-FEC) codes, or simply FEC codes , are a key element of communication systems.
They are used to recover from packet losses (or erasures) during content deliver y sessions to a potentially large number of receivers (multicast/broadcast trans missions). They are used to recover from packet losses (or erasures) during content deliver y sessions to a potentially large number of receivers (multicast/broadcast trans missions).
This is the case with the FLUTE/ALC protocol <xref target="RFC6726"/> when used This is the case with the File Delivery over Unidirectional Transport
for reliable file transfers over lossy networks, and the FECFRAME protocol <xref (FLUTE)/Asynchronous Layered Coding (ALC) protocol <xref target="RFC6726" format
target="RFC6363"/> when used for reliable continuous media transfers over lossy ="default" sectionFormat="of" derivedContent="RFC6726"/> when used for reliable
networks. file transfers over lossy networks, and the FECFRAME protocol <xref target="RFC6
363" format="default" sectionFormat="of" derivedContent="RFC6363"/> when used fo
r reliable continuous media transfers over lossy networks.
</t> </t>
<t pn="section-1-2">
<t> The present document only focuses on the FECFRAME protocol, which is used in mul
The present document only focuses on the FECFRAME protocol, used in multicast/br ticast/broadcast delivery mode, particularly for content that features stringent
oadcast delivery mode, in particular for contents that feature stringent real-ti real-time constraints: each source packet has a maximum validity period after w
me constraints: each source packet has a maximum validity period after which it hich it will not be considered by the destination application.
will not be considered by the destination application.
</t> </t>
<section anchor="intro_block_codes" numbered="true" toc="include" removeIn
<section anchor="intro:block_codes" title="Limits of Block Codes RFC="false" pn="section-1.1">
with Real-Time Flows"> <name slugifiedName="name-limits-of-block-codes-with-">Limits of Block C
<!-- ====================== --> odes with Real-Time Flows</name>
<t pn="section-1.1-1">
<t> With FECFRAME, there is a single FEC encoding point (either an end host/server
With FECFRAME, there is a single FEC encoding point (either an end-host/server ( (source) or a middlebox) and a single FEC decoding point per receiver (either
source) or a middlebox) and a single FEC decoding point per receiver (either an an end host (receiver) or middlebox).
end-host (receiver) or middlebox). In this context, currently standardized AL-FEC codes for FECFRAME like Reed-Solo
In this context, currently standardized AL-FEC codes for FECFRAME like Reed-Solo mon <xref target="RFC6865" format="default" sectionFormat="of" derivedContent="R
mon <xref target="RFC6865"/>, LDPC-Staircase <xref target="RFC6816"/>, or Raptor FC6865"/>, LDPC-Staircase <xref target="RFC6816" format="default" sectionFormat=
/RaptorQ <xref target="RFC6681"/>, are all linear block codes: they require the "of" derivedContent="RFC6816"/>, or Raptor/RaptorQ <xref target="RFC6681" format
data flow to be segmented into blocks of a predefined maximum size. ="default" sectionFormat="of" derivedContent="RFC6681"/>, are all linear block c
odes: they require the data flow to be segmented into blocks of a predefined max
imum size.
</t> </t>
<t pn="section-1.1-2">
<t>
To define this block size, it is required to find an appropriate balance between robustness and decoding latency: the larger the block size, the higher the robu stness (e.g., in case of long packet erasure bursts), but also the higher the ma ximum decoding latency (i.e., the maximum time required to recover a lost (erase d) packet thanks to FEC protection). To define this block size, it is required to find an appropriate balance between robustness and decoding latency: the larger the block size, the higher the robu stness (e.g., in case of long packet erasure bursts), but also the higher the ma ximum decoding latency (i.e., the maximum time required to recover a lost (erase d) packet thanks to FEC protection).
Therefore, with a multicast/broadcast session where different receivers experien ce different packet loss rates, the block size should be chosen by considering t he worst communication conditions one wants to support, but without exceeding th e desired maximum decoding latency. Therefore, with a multicast/broadcast session where different receivers experien ce different packet loss rates, the block size should be chosen by considering t he worst communication conditions one wants to support, but without exceeding th e desired maximum decoding latency.
This choice then impacts the FEC-related latency of all receivers, even those ex periencing a good communication quality, since no FEC encoding can happen until all the source data of the block is available at the sender, which directly depe nds on the block size. This choice then impacts the FEC-related latency of all receivers, even those ex periencing a good communication quality, since no FEC encoding can happen until all the source data of the block is available at the sender, which directly depe nds on the block size.
</t> </t>
</section>
</section> <section anchor="intro_conv_codes" numbered="true" toc="include" removeInR
FC="false" pn="section-1.2">
<section anchor="intro:conv_codes" title="Lower Latency and Bette <name slugifiedName="name-lower-latency-and-better-pr">Lower Latency and
r Protection of Real-Time Flows with the Sliding Window RLC Codes"> Better Protection of Real-Time Flows with the Sliding Window RLC Codes</name>
<!-- ====================== --> <t pn="section-1.2-1">
This document introduces two fully specified FEC schemes that do not follow the
<t> block code approach: the Sliding Window Random Linear Codes (RLC) over either Ga
This document introduces two fully-specified FEC Schemes that do not follow the lois Fields (a.k.a., Finite Fields) GF(2) (the "binary case") or GF(2<sup>8</sup
block code approach: the Sliding Window Random Linear Codes (RLC) over either Ga >), each time with the possibility of controlling the code density.
lois Fields (A.K.A. Finite Fields) GF(2) (the "binary case") or GF(2^^8), each t These FEC schemes are used to protect arbitrary media streams along the lines de
ime with the possibility of controlling the code density. fined by FECFRAME extended to Sliding Window FEC Codes <xref target="RFC8680" fo
These FEC Schemes are used to protect arbitrary media streams along the lines de rmat="default" sectionFormat="of" derivedContent="RFC8680"/>.
fined by FECFRAME extended to sliding window FEC codes <xref target="fecframe-ex These FEC schemes and, more generally, Sliding Window FEC Codes are recommended,
t"/>. for instance, with media that feature real-time constraints sent within a multi
These FEC Schemes, and more generally Sliding Window FEC codes, are recommended cast/broadcast session <xref target="Roca17" format="default" sectionFormat="of"
for instance, with media that feature real-time constraints sent within a multic derivedContent="Roca17"/>.
ast/broadcast session <xref target="Roca17"/>.
</t> </t>
<t pn="section-1.2-2">
<t> The RLC codes belong to the broad class of Sliding Window AL-FEC Codes (a.k.a.,
The RLC codes belong to the broad class of sliding-window AL-FEC codes (A.K.A. c convolutional codes) <xref target="RFC8406" format="default" sectionFormat="of"
onvolutional codes) <xref target="RFC8406"/>. derivedContent="RFC8406"/>.
The encoding process is based on an encoding window that slides over the set of The encoding process is based on an encoding window that slides over the set of
source packets (in fact source symbols as we will see in <xref target="CommonPro source packets (in fact source symbols as we will see in <xref target="CommonPro
c_adui_creation"/>), this window being either of fixed size or variable size (A. c_adui_creation" format="default" sectionFormat="of" derivedContent="Section 3.2
K.A. an elastic window). "/>), this window being either of fixed size or variable size (a.k.a., an elasti
c window).
Repair symbols are generated on-the-fly, by computing a random linear combinatio n of the source symbols present in the current encoding window, and passed to th e transport layer. Repair symbols are generated on-the-fly, by computing a random linear combinatio n of the source symbols present in the current encoding window, and passed to th e transport layer.
</t> </t>
<t pn="section-1.2-3">
<t>
At the receiver, a linear system is managed from the set of received source and repair packets. At the receiver, a linear system is managed from the set of received source and repair packets.
New variables (representing source symbols) and equations (representing the line ar combination carried by each repair symbol received) are added upon receiving new packets. New variables (representing source symbols) and equations (representing the line ar combination carried by each repair symbol received) are added upon receiving new packets.
Variables and the equations they are involved in are removed when they are too o ld with respect to their validity period (real-time constraints). Variables and the equations they are involved in are removed when they are too o ld with respect to their validity period (real-time constraints).
Lost source symbols are then recovered thanks to this linear system whenever its rank permits to solve it (at least partially). Lost source symbols are then recovered thanks to this linear system whenever its rank permits to solve it (at least partially).
</t> </t>
<t pn="section-1.2-4">
<t>
The protection of any multicast/broadcast session needs to be dimensioned by con sidering the worst communication conditions one wants to support. The protection of any multicast/broadcast session needs to be dimensioned by con sidering the worst communication conditions one wants to support.
This is also true with RLC (more generally any sliding window) code. This is also true with RLC (more generally, any sliding window) code.
However, the receivers experiencing a good to medium communication quality will However, the receivers experiencing a good to medium communication quality will
observe a reduced FEC-related latency compared to block codes <xref target="Roca observe a reduced FEC-related latency compared to block codes <xref target="Roca
17"/> since an isolated lost source packet is quickly recovered with the followi 17" format="default" sectionFormat="of" derivedContent="Roca17"/> since an isola
ng repair packet. ted lost source packet is quickly recovered with the following repair packet.
On the opposite, with a block code, recovering an isolated lost source packet al ways requires waiting for the first repair packet to arrive after the end of the block. On the opposite, with a block code, recovering an isolated lost source packet al ways requires waiting for the first repair packet to arrive after the end of the block.
Additionally, under certain situations (e.g., with a limited FEC-related latency Additionally, under certain situations (e.g., with a limited FEC-related latency
budget and with constant bitrate transmissions after FECFRAME encoding), slidin budget and with constant bitrate transmissions after FECFRAME encoding), Slidin
g window codes can more efficiently achieve a target transmission quality (e.g., g Window Codes can more efficiently achieve a target transmission quality (e.g.,
measured by the residual loss after FEC decoding) by sending fewer repair packe measured by the residual loss after FEC decoding) by sending fewer repair packe
ts (i.e., higher code rate) than block codes. ts (i.e., higher code rate) than block codes.
<!-- <xref target="Roca17"/> -->
</t> </t>
</section>
</section> <section anchor="intro_low_tx_overhead" numbered="true" toc="include" remo
veInRFC="false" pn="section-1.3">
<section anchor="intro:low_tx_overhead" title="Small Transmission <name slugifiedName="name-small-transmission-overhead">Small Transmissio
Overheads with the Sliding Window RLC FEC Scheme"> n Overheads with the Sliding Window RLC FEC Scheme</name>
<!-- ====================== --> <t pn="section-1.3-1">
The Sliding Window RLC FEC scheme is designed to limit the packet header overhea
<t> d.
The Sliding Window RLC FEC Scheme is designed to limit the packet header overhea
d.
The main requirement is that each repair packet header must enable a receiver to reconstruct the set of source symbols plus the associated coefficients used dur ing the encoding process. The main requirement is that each repair packet header must enable a receiver to reconstruct the set of source symbols plus the associated coefficients used dur ing the encoding process.
In order to minimize packet overhead, the set of source symbols in the encoding window as well as the set of coefficients over GF(2^^m) (where m is 1 or 8, depe nding on the FEC Scheme) used in the linear combination are not individually lis ted in the repair packet header. In order to minimize packet overhead, the set of source symbols in the encoding window as well as the set of coefficients over GF(2<sup>m</sup>) (where m is 1 o r 8, depending on the FEC scheme) used in the linear combination are not individ ually listed in the repair packet header.
Instead, each FEC Repair Packet header contains: Instead, each FEC Repair Packet header contains:
<list style="symbols">
<t>the Encoding Symbol Identifier (ESI) of the first source symbol in the
encoding window as well as the number of symbols (since this number may vary wi
th a variable size, elastic window).
These two pieces of information enable each receiver to reconstruct the s
et of source symbols considered during encoding, the only constraint being that
there cannot be any gap;</t>
<t>the seed and density threshold parameters used by a coding coefficient
s generation function (<xref target="CommonProc_coef_generation_func"/>).
These two pieces of information enable each receiver to generate the same
set of coding coefficients over GF(2^^m) as the sender;</t>
</list>
</t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-1.3-2">
<t> <li pn="section-1.3-2.1">the Encoding Symbol Identifier (ESI) of the f
Therefore, no matter the number of source symbols present in the encoding window irst source symbol in the encoding window as well as the number of symbols (sinc
, each FEC Repair Packet features a fixed 64-bit long header, called Repair FEC e this number may vary with a variable size, elastic window).
Payload ID (<xref target="fig_repair_fpi"/>). These two pieces of information enable each receiver to reconstruct the s
Similarly, each FEC Source Packet features a fixed 32-bit long trailer, called E et of source symbols considered during encoding, the only constraint being that
xplicit Source FEC Payload ID (<xref target="fig_src_fpi"/>), that contains the there cannot be any gap;</li>
ESI of the first source symbol (<xref target="CommonProc_adui_creation"/>). <li pn="section-1.3-2.2">the seed and density threshold parameters use
d by a coding coefficients generation function (<xref target="CommonProc_coef_ge
neration_func" format="default" sectionFormat="of" derivedContent="Section 3.6"/
>).
These two pieces of information enable each receiver to generate the same
set of coding coefficients over GF(2<sup>m</sup>) as the sender;</li>
</ul>
<t pn="section-1.3-3">
Therefore, no matter the number of source symbols present in the encoding window
, each FEC Repair Packet features a fixed 64-bit long header, called Repair FEC
Payload ID (<xref target="fig_repair_fpi" format="default" sectionFormat="of" de
rivedContent="Figure 8"/>).
Similarly, each FEC Source Packet features a fixed 32-bit long trailer, called E
xplicit Source FEC Payload ID (<xref target="fig_src_fpi" format="default" secti
onFormat="of" derivedContent="Figure 6"/>), that contains the ESI of the first s
ource symbol (<xref target="CommonProc_adui_creation" format="default" sectionFo
rmat="of" derivedContent="Section 3.2"/>).
</t> </t>
</section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-1.4
">
<section title="Document Organization"> <name slugifiedName="name-document-organization">Document Organization</
<!-- ====================== --> name>
<t> <t pn="section-1.4-1">
This fully-specified FEC Scheme follows the structure required by <xref target=" This fully-specified FEC scheme follows the structure required by <xref target="
RFC6363"/>, section 5.6. "FEC Scheme Requirements", namely: RFC6363" format="default" sectionFormat="comma" section="5.6" derivedLink="https
<list style="hanging"> ://rfc-editor.org/rfc/rfc6363#section-5.6" derivedContent="RFC6363"/> ("FEC Sche
<t hangText="3. Procedures:"> me Requirements"), namely:
This section describes procedures specific to this FEC Scheme, namely: RL
C parameters derivation, ADUI and source symbols mapping, pseudo-random number g
enerator, and coding coefficients generation function;</t>
<t hangText="4. Formats and Codes:">
This section defines the Source FEC Payload ID and Repair FEC Payload ID
formats, carrying the signaling information associated to each source or repair
symbol.
It also defines the FEC Framework Configuration Information (FFCI) carryi
ng signaling information for the session;</t>
<t hangText="5. FEC Code Specification:">
Finally this section provides the code specification.</t>
</list>
</t> </t>
<ol type="1" start="3" spacing="normal" pn="section-1.4-2">
</section> <li pn="section-1.4-2.1" derivedCounter="3.">Procedures:
This section describes procedures specific to this FEC scheme, namely: RL
</section> C parameters derivation, ADUI and source symbols mapping, pseudorandom number ge
nerator, and coding coefficients generation function;</li>
<section anchor="definitionsAndAbbreviations" title="Definitions and Abbr <li pn="section-1.4-2.2" derivedCounter="4.">Formats and Codes:
eviations"> This section defines the Source FEC Payload ID and Repair FEC Payload ID
<!-- ====================== --> formats, carrying the signaling information associated to each source or repair
symbol.
<t> It also defines the FEC Framework Configuration Information (FFCI) carryi
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL ng signaling information for the session;</li>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <li pn="section-1.4-2.3" derivedCounter="5.">FEC Code Specification:
"MAY", and "OPTIONAL" in this document are to be interpreted as Finally this section provides the code specification.</li>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> </ol>
</section>
</section>
<section anchor="definitionsAndAbbreviations" numbered="true" toc="include"
removeInRFC="false" pn="section-2">
<name slugifiedName="name-definitions-and-abbreviatio">Definitions and Abb
reviations</name>
<t pn="section-2-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED
</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</b
cp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT R
ECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" d
erivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat=
"of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
<t pn="section-2-2">This document uses the following definitions and abbre
<t>This document uses the following definitions and abbreviations: <list style=" viations: </t>
hanging"> <dl newline="false" spacing="normal" pn="section-2-3">
<t hangText="a^^b"> a to the power of b</t> <dt pn="section-2-3.1">a<sup>b</sup></dt>
<t hangText="GF(q)"> denotes a finite field (also known as the Galois <dd pn="section-2-3.2"> a to the power of b</dd>
Field) with q elements. <dt pn="section-2-3.3">GF(q)</dt>
We assume that q = 2^^m in this document</t> <dd pn="section-2-3.4"> denotes a finite field (also know
<t hangText="m"> defines the length of the elements in the finite n as the Galois Field) with q elements.
field, in bits. We assume that q = 2<sup>m</sup> in this document
In this document, m is equal to 1 or 8</t> </dd>
<t hangText="ADU:"> Application Data Unit</t> <dt pn="section-2-3.5">m</dt>
<t hangText="ADUI:"> Application Data Unit Information (includes the F <dd pn="section-2-3.6"> defines the length of the element
, L and padding fields in addition to the ADU)</t> s in the finite field, in bits.
<t hangText="E:"> size of an encoding symbol (i.e., source or repai In this document, m is equal to 1 or 8</dd>
r symbol), assumed fixed (in bytes)</t> <dt pn="section-2-3.7">ADU:</dt>
<t hangText="br_in:"> transmission bitrate at the input of the FECFRAME <dd pn="section-2-3.8"> Application Data Unit</dd>
sender, assumed fixed (in bits/s)</t> <dt pn="section-2-3.9">ADUI:</dt>
<t hangText="br_out:"> transmission bitrate at the output of the FECFRAM <dd pn="section-2-3.10"> Application Data Unit Information
E sender, assumed fixed (in bits/s)</t> (includes the F, L and padding fields in addition to the ADU)</dd>
<t hangText="max_lat:"> maximum FEC-related latency within FECFRAME (a de <dt pn="section-2-3.11">E:</dt>
cimal number expressed in seconds)</t> <dd pn="section-2-3.12"> size of an encoding symbol (i.e.,
<t hangText="cr:"> RLC coding rate, ratio between the total number o source or repair symbol), assumed fixed (in bytes)</dd>
f source symbols and the total number of source plus repair symbols</t> <dt pn="section-2-3.13">br_in:</dt>
<!-- <t hangText="plr:"> packet loss rate during packet communicat <dd pn="section-2-3.14"> transmission bitrate at the input
ions</t> --> of the FECFRAME sender, assumed fixed (in bits/s)</dd>
<t hangText="ew_size:"> encoding window current size at a sender <dt pn="section-2-3.15">br_out:</dt>
(in symbols)</t> <dd pn="section-2-3.16"> transmission bitrate at the outpu
<t hangText="ew_max_size:"> encoding window maximum size at a sender (in symb t of the FECFRAME sender, assumed fixed (in bits/s)</dd>
ols)</t> <dt pn="section-2-3.17">max_lat:</dt>
<t hangText="dw_max_size:"> decoding window maximum size at a receiver (in sy <dd pn="section-2-3.18"> maximum FEC-related latency within FECFRA
mbols)</t> ME (a decimal number expressed in seconds)</dd>
<t hangText="ls_max_size:"> linear system maximum size (or width) at a receiv <dt pn="section-2-3.19">cr:</dt>
er (in symbols)</t> <dd pn="section-2-3.20"> RLC coding rate, ratio between th
<t hangText="WSR:"> window size ratio parameter used to derive ew_max e total number of source symbols and the total number of source plus repair symb
_size (encoder) and ls_max_size (decoder).</t> ols</dd>
<dt pn="section-2-3.21">ew_size:</dt>
<t hangText="PRNG:"> pseudo-random number generator</t> <dd pn="section-2-3.22"> encoding window current size at a
<t hangText="TinyMT32:"> PRNG used in this specification.</t> sender (in symbols)</dd>
<t hangText="DT:"> coding coefficients density threshold, an integer <dt pn="section-2-3.23">ew_max_size:</dt>
between 0 and 15 (inclusive) the controls <dd pn="section-2-3.24"> encoding window maximum size at a sender
the fraction of coefficients that are non zero</t (in symbols)</dd>
> <dt pn="section-2-3.25">dw_max_size:</dt>
</list></t> <dd pn="section-2-3.26"> decoding window maximum size at a receive
r (in symbols)</dd>
</section> <dt pn="section-2-3.27">ls_max_size:</dt>
<dd pn="section-2-3.28"> linear system maximum size (or width) at
<!-- =========================================================================== a receiver (in symbols)</dd>
================ --> <dt pn="section-2-3.29">WSR:</dt>
<dd pn="section-2-3.30"> window size ratio parameter used
<section anchor="CommonProcedures" title="Common Procedures"> to derive ew_max_size (encoder) and ls_max_size (decoder).</dd>
<!-- ================ --> <dt pn="section-2-3.31">PRNG:</dt>
<t> <dd pn="section-2-3.32"> pseudorandom number generator</dd
This section introduces the procedures that are used by these FEC Schemes. >
<dt pn="section-2-3.33">TinyMT32:</dt>
<dd pn="section-2-3.34"> PRNG used in this specification.</dd>
<dt pn="section-2-3.35">DT:</dt>
<dd pn="section-2-3.36"> coding coefficients density thres
hold, an integer between 0 and 15 (inclusive) the controls
the fraction of coefficients that are nonzero</dd
>
</dl>
</section>
<section anchor="CommonProcedures" numbered="true" toc="include" removeInRFC
="false" pn="section-3">
<name slugifiedName="name-common-procedures">Common Procedures</name>
<t pn="section-3-1">
This section introduces the procedures that are used by these FEC schemes.
</t> </t>
<section anchor="CommonProc_rlcParameters" numbered="true" toc="include" r
<section anchor="CommonProc_rlcParameters" title="Codec Parameter emoveInRFC="false" pn="section-3.1">
s"> <name slugifiedName="name-codec-parameters">Codec Parameters</name>
<!-- ====================== --> <t pn="section-3.1-1">
A codec implementing the Sliding Window RLC FEC scheme relies on several paramet
<t> ers:
A codec implementing the Sliding Window RLC FEC Scheme relies on several paramet </t>
ers: <dl newline="true" spacing="normal" pn="section-3.1-2">
<list style="hanging"> <dt pn="section-3.1-2.1">Maximum FEC-related latency budget, max_lat (
<t hangText="Maximum FEC-related latency budget, max_lat (a decimal numbe a decimal number expressed in seconds) with real-time flows:</dt>
r expressed in seconds) with real-time flows:"> <dd pn="section-3.1-2.2">
a source ADU flow can have real-time constraints, and therefore a ny FECFRAME related operation should take place within the validity a source ADU flow can have real-time constraints, and therefore a ny FECFRAME related operation should take place within the validity
period of each ADU (<xref target="decodingBeyondMaxLatency"/> des period of each ADU (<xref target="decodingBeyondMaxLatency" forma
cribes an exception to this rule). t="default" sectionFormat="of" derivedContent="Appendix D"/> describes an except
When there are multiple flows with different real-time constraint ion to this rule).
s, we consider the most stringent constraints (see <xref target="RFC6363"/>, When there are multiple flows with different real-time
Section 10.2, item 6, for recommendations when several flows are constraints, we consider the most stringent constraints (see
globally protected). item 6 in <xref target="RFC6363" format="default" sectionFormat="
of" section="10.2" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-10.2"
derivedContent="RFC6363"/>,
for recommendations when several flows are globally protected).
The maximum FEC-related latency budget, max_lat, accounts for all sources of latency added by FEC encoding (at a sender) and FEC decoding (at a r eceiver). The maximum FEC-related latency budget, max_lat, accounts for all sources of latency added by FEC encoding (at a sender) and FEC decoding (at a r eceiver).
Other sources of latency (e.g., added by network communications) are out of scope and must be considered separately (said differently, they have already been deducted from max_lat). Other sources of latency (e.g., added by network communications) are out of scope and must be considered separately (said differently, they have already been deducted from max_lat).
max_lat can be regarded as the latency budget permitted for all F EC-related operations. max_lat can be regarded as the latency budget permitted for all F EC-related operations.
This is an input parameter that enables a FECFRAME sender to deri This is an input parameter that enables a FECFRAME sender to deri
ve other internal parameters (see <xref target="possible_param_derivation"/>); ve other internal parameters (see <xref target="possible_param_derivation" forma
</t> t="default" sectionFormat="of" derivedContent="Appendix C"/>);
</dd>
<t hangText="Encoding window current (resp. maximum) size, ew_size (resp. <dt pn="section-3.1-2.3">Encoding window current (resp. maximum) size,
ew_max_size) (in symbols):"> ew_size (resp. ew_max_size) (in symbols):</dt>
<dd pn="section-3.1-2.4">
<t pn="section-3.1-2.4.1">
at a FECFRAME sender, during FEC encoding, a repair symbol is com puted as a linear combination of the ew_size source symbols present in the encod ing window. at a FECFRAME sender, during FEC encoding, a repair symbol is com puted as a linear combination of the ew_size source symbols present in the encod ing window.
The ew_max_size is the maximum size of this window, while ew_size is the current size. The ew_max_size is the maximum size of this window, while ew_size is the current size.
For example, in the common case at session start, upon receiving new source ADUs, the ew_size progressively increases until it reaches its maximu m value, ew_max_size. For example, in the common case at session start, upon receiving new source ADUs, the ew_size progressively increases until it reaches its maximu m value, ew_max_size.
We have: We have:
<list style="none"> </t>
<t> 0 &lt; ew_size &le; ew_max_size </t> <ul spacing="normal" empty="true" bare="false" pn="section-3.1-2.4.2
</list></t> ">
<li pn="section-3.1-2.4.2.1"> 0 &lt; ew_size &lt;= ew_max_size </l
<t hangText="Decoding window maximum size, dw_max_size (in symbols):"> i>
</ul>
</dd>
<dt pn="section-3.1-2.5">Decoding window maximum size, dw_max_size (in
symbols):</dt>
<dd pn="section-3.1-2.6">
at a FECFRAME receiver, dw_max_size is the maximum number of rece ived or lost source symbols that are still within their latency budget; at a FECFRAME receiver, dw_max_size is the maximum number of rece ived or lost source symbols that are still within their latency budget;
</t> </dd>
<dt pn="section-3.1-2.7">Linear system maximum size, ls_max_size (in s
<t hangText="Linear system maximum size, ls_max_size (in symbols):"> ymbols):</dt>
<dd pn="section-3.1-2.8">
at a FECFRAME receiver, the linear system maximum size, ls_max_si ze, is the maximum number of received or lost source symbols in the linear syste m (i.e., the variables). at a FECFRAME receiver, the linear system maximum size, ls_max_si ze, is the maximum number of received or lost source symbols in the linear syste m (i.e., the variables).
It SHOULD NOT be smaller than dw_max_size since it would mean tha It <bcp14>SHOULD NOT</bcp14> be smaller than dw_max_size since it
t, even after receiving a sufficient number of FEC Repair Packets, a lost ADU ma would mean that, even after receiving a sufficient number of FEC Repair Packets
y not be recovered just because the associated source symbols have been prematur , a lost ADU may not be recovered just because the associated source symbols hav
ely removed from the linear system, which is usually counter-productive. e been prematurely removed from the linear system, which is usually counter-prod
On the opposite, the linear system MAY grow beyond the dw_max_siz uctive.
e (<xref target="decodingBeyondMaxLatency"/>); On the opposite, the linear system <bcp14>MAY</bcp14> grow beyond
<!-- with old source symbols kept in the linear system whereas th the dw_max_size (<xref target="decodingBeyondMaxLatency" format="default" sect
eir associated ADUs timed-out --> ionFormat="of" derivedContent="Appendix D"/>);
</t> </dd>
<dt pn="section-3.1-2.9">Symbol size, E (in bytes):</dt>
<t hangText="Symbol size, E (in bytes):"> <dd pn="section-3.1-2.10">
the E parameter determines the source and repair symbol sizes (ne cessarily equal). the E parameter determines the source and repair symbol sizes (ne cessarily equal).
This is an input parameter that enables a FECFRAME sender to deri ve other internal parameters, as explained below. This is an input parameter that enables a FECFRAME sender to deri ve other internal parameters, as explained below.
An implementation at a sender MUST fix the E parameter and MUST c An implementation at a sender <bcp14>MUST</bcp14> fix the E param
ommunicate it as part of the FEC Scheme-Specific Information (<xref target="Arbi eter and <bcp14>MUST</bcp14> communicate it as part of the FEC Scheme-Specific I
traryFlows_fssi"/>). nformation (<xref target="ArbitraryFlows_fssi" format="default" sectionFormat="o
</t> f" derivedContent="Section 4.1.1.2"/>).
</dd>
<t hangText="Code rate, cr:"> <dt pn="section-3.1-2.11">Code rate, cr:</dt>
The code rate parameter determines the amount of redundancy added <dd pn="section-3.1-2.12">
to the flow. The code rate parameter determines the amount of redundancy added to the flow.
More precisely the cr is the ratio between the total number of so More precisely the cr is the ratio between the total number of source symbols
urce symbols and the total number of source plus repair symbols and by definitio and the total number of source plus repair symbols and by definition: 0 &lt; cr
n: 0 &lt; cr &le; 1. &lt;= 1.
This is an input parameter that enables a FECFRAME sender to deri This is an input parameter that enables a FECFRAME sender to derive other inte
ve other internal parameters, as explained below. rnal parameters, as explained below.
However, there is no need to communicate the cr parameter per see However, there is no need to communicate the cr parameter per see (it's not re
(it's not required to process a repair symbol at a receiver). quired to process a repair symbol at a receiver).
This code rate parameter can be static. This code rate parameter can be static.
However, in specific use-cases (e.g., with unicast transmissions However, in specific use-cases (e.g., with unicast transmissions in presence o
in presence of a feedback mechanism that estimates the communication quality, ou f a feedback mechanism that estimates the communication quality, out of scope of
t of scope of FECFRAME), the code rate may be adjusted dynamically. FECFRAME), the code rate may be adjusted dynamically.
</t> </dd>
</list> </dl>
</t> <t pn="section-3.1-3"><xref target="possible_param_derivation" format="d
efault" sectionFormat="of" derivedContent="Appendix C"/> proposes non-normative
<t> techniques to derive those parameters, depending on the use-case specificities.
<xref target="possible_param_derivation"/> proposes non normative techniques to
derive those parameters, depending on the use-case specificities.
</t> </t>
</section>
</section> <section anchor="CommonProc_adui_creation" numbered="true" toc="include" r
emoveInRFC="false" pn="section-3.2">
<section anchor="CommonProc_adui_creation" title="ADU, ADUI and Source Sy <name slugifiedName="name-adu-adui-and-source-symbols">ADU, ADUI, and So
mbols Mappings"> urce Symbols Mappings</name>
<!-- ==================================== --> <t pn="section-3.2-1">
<t>
At a sender, an ADU coming from the application is not directly mapped to source symbols. At a sender, an ADU coming from the application is not directly mapped to source symbols.
When multiple source flows (e.g., media streams) are mapped onto the same FECFRA ME instance, each flow is assigned its own Flow ID value (see below). When multiple source flows (e.g., media streams) are mapped onto the same FECFRA ME instance, each flow is assigned its own Flow ID value (see below).
This Flow ID is then prepended to each ADU before FEC encoding. This Flow ID is then prepended to each ADU before FEC encoding.
This way, FEC decoding at a receiver also recovers this Flow ID and the recovere d ADU can be assigned to the right source flow This way, FEC decoding at a receiver also recovers this Flow ID and the recovere d ADU can be assigned to the right source flow
(note that the 5-tuple used to identify the right source flow of a received ADU is absent with a recovered ADU since it is not FEC protected). (note that the 5-tuple used to identify the right source flow of a received ADU is absent with a recovered ADU since it is not FEC protected).
<!--
Indeed, a lost ADU recovered at a receiver must contain enough information to be
assigned to the right application flow
(UDP port numbers and IP addresses cannot be used to that purpose as they are no
t protected by FEC encoding).
This requires adding the flow identifier to each ADU before doing FEC encoding.
</t> </t>
<t pn="section-3.2-2">
<t>
Additionally, since ADUs are of variable size, padding is needed so that each AD U (with its flow identifier) contribute Additionally, since ADUs are of variable size, padding is needed so that each AD U (with its flow identifier) contribute
to an integral number of source symbols. to an integral number of source symbols.
This requires adding the original ADU length to each ADU before doing FEC encodi ng. This requires adding the original ADU length to each ADU before doing FEC encodi ng.
Because of these requirements, an intermediate format, the ADUI, or ADU Informat ion, is considered <xref target="RFC6363"/>. Because of these requirements, an intermediate format, the ADUI, or ADU Informat ion, is considered <xref target="RFC6363" format="default" sectionFormat="of" de rivedContent="RFC6363"/>.
</t> </t>
<t pn="section-3.2-3">
<t> For each incoming ADU, an ADUI <bcp14>MUST</bcp14> be created as follows.
For each incoming ADU, an ADUI MUST created as follows. First of all, 3 bytes are prepended (<xref target="fig_adui_creation" format="de
First of all, 3 bytes are prepended (<xref target="fig_adui_creation"/>): fault" sectionFormat="of" derivedContent="Figure 1"/>):
<list style="hanging"> </t>
<t hangText="Flow ID (F) (8-bit field):"> <dl newline="false" spacing="normal" pn="section-3.2-4">
<dt pn="section-3.2-4.1">Flow ID (F) (8-bit field):</dt>
<dd pn="section-3.2-4.2">
this unsigned byte contains the integer identifier associated to the sour ce ADU flow to which this ADU belongs. this unsigned byte contains the integer identifier associated to the sour ce ADU flow to which this ADU belongs.
It is assumed that a single byte is sufficient, which implies that no mor e than 256 flows will be protected by It is assumed that a single byte is sufficient, which implies that no mor e than 256 flows will be protected by
a single FECFRAME session instance.</t> a single FECFRAME session instance.</dd>
<dt pn="section-3.2-4.3">Length (L) (16-bit field):</dt>
<t hangText="Length (L) (16-bit field):"> <dd pn="section-3.2-4.4">
this unsigned integer contains the length of this ADU, in network byte or der (i.e., big endian). this unsigned integer contains the length of this ADU, in network byte or der (i.e., big endian).
This length is for the ADU itself and does not include the F, L, or Pad f ields. This length is for the ADU itself and does not include the F, L, or Pad f ields.
</t> </dd>
</list> </dl>
</t> <t pn="section-3.2-5">
<t>
Then, zero padding is added to the ADU if needed: Then, zero padding is added to the ADU if needed:
<list style="hanging"> </t>
<t hangText="Padding (Pad) (variable size field):"> <dl newline="false" spacing="normal" pn="section-3.2-6">
<dt pn="section-3.2-6.1">Padding (Pad) (variable size field):</dt>
<dd pn="section-3.2-6.2">
this field contains zero padding to align the F, L, ADU and padding this field contains zero padding to align the F, L, ADU and padding
up to a size that is multiple of E bytes (i.e., the source and repair sym bol length). up to a size that is multiple of E bytes (i.e., the source and repair sym bol length).
</t> </dd>
</list> </dl>
<t pn="section-3.2-7">
The data unit resulting from the ADU and the F, L, and Pad fields is called ADUI . The data unit resulting from the ADU and the F, L, and Pad fields is called ADUI .
Since ADUs can have different sizes, this is also the case for ADUIs. Since ADUs can have different sizes, this is also the case for ADUIs.
However, an ADUI always contributes to an integral number of source symbols. However, an ADUI always contributes to an integral number of source symbols.
</t> </t>
<figure anchor="fig_adui_creation" align="left" suppress-title="false" p
<figure anchor="fig_adui_creation" title="ADUI Creation example (here 3 source s n="figure-1">
ymbols are created for this ADUI)."> <name slugifiedName="name-adui-creation-example-resul">ADUI Creation E
<artwork><![CDATA[ xample, Resulting in Three Source Symbols</name>
<artwork name="" type="" align="left" alt="" pn="section-3.2-8.1">
symbol length, E E E symbol length, E E E
< ------------------ >< ------------------ >< ------------------ &gt; < ------------------ &gt;&lt; ------------------ &gt;&lt; ------------------ &gt;
+-+--+---------------------------------------------+-------------+ +-+--+---------------------------------------------+-------------+
|F| L| ADU | Pad | |F| L| ADU | Pad |
+-+--+---------------------------------------------+-------------+]]></artwork> +-+--+---------------------------------------------+-------------+
</figure> </artwork>
</figure>
<t> <t pn="section-3.2-9">
Note that neither the initial 3 bytes nor the optional padding are sent over the network. Note that neither the initial 3 bytes nor the optional padding are sent over the network.
However, they are considered during FEC encoding, and a receiver who lost a cert ain FEC Source Packet (e.g., the UDP datagram However, they are considered during FEC encoding, and a receiver that lost a cer tain FEC Source Packet (e.g., the UDP datagram
containing this FEC Source Packet when UDP is used as the transport protocol) wi ll be able to recover the ADUI if FEC decoding succeeds. containing this FEC Source Packet when UDP is used as the transport protocol) wi ll be able to recover the ADUI if FEC decoding succeeds.
Thanks to the initial 3 bytes, this receiver will get rid of the padding (if any ) and identify the corresponding ADU flow. Thanks to the initial 3 bytes, this receiver will get rid of the padding (if any ) and identify the corresponding ADU flow.
</t> </t>
</section>
</section> <section anchor="encodingWindowManagement" numbered="true" toc="include" r
emoveInRFC="false" pn="section-3.3">
<section anchor="encodingWindowManagement" title="Encoding Window Managem <name slugifiedName="name-encoding-window-management">Encoding Window Ma
ent"> nagement</name>
<!-- ====================== --> <t pn="section-3.3-1">
<t>
Source symbols and the corresponding ADUs are removed from the encoding window: Source symbols and the corresponding ADUs are removed from the encoding window:
<list style="symbols">
<t> when the sliding encoding window has reached its maximum size, ew_max
_size.
In that case the oldest symbol MUST be removed before adding a new symbol
, so that the current encoding window size always
remains inferior or equal to the maximum size: ew_size &le; ew_max_size;<
/t>
<t> when an ADU has reached its maximum validity duration in case of a re
al-time flow.
When this happens, all source symbols corresponding to the ADUI that expi
red SHOULD be removed from the encoding window; </t>
</list>
</t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-3.3-2">
<t> <li pn="section-3.3-2.1"> when the sliding encoding window has reached
its maximum size, ew_max_size.
In that case the oldest symbol <bcp14>MUST</bcp14> be removed before adding a n
ew symbol, so that the current encoding window size always
remains inferior or equal to the maximum size: ew_size &lt;= ew_max_size;</li>
<li pn="section-3.3-2.2"> when an ADU has reached its maximum validity
duration in case of a real-time flow.
When this happens, all source symbols corresponding to the ADUI that expi
red <bcp14>SHOULD</bcp14> be removed from the encoding window; </li>
</ul>
<t pn="section-3.3-3">
Source symbols are added to the sliding encoding window each time a new ADU arri ves, once the ADU-to-source symbols mapping has been performed Source symbols are added to the sliding encoding window each time a new ADU arri ves, once the ADU-to-source symbols mapping has been performed
(<xref target="CommonProc_adui_creation"/>). (<xref target="CommonProc_adui_creation" format="default" sectionFormat="of" der ivedContent="Section 3.2"/>).
The current size of the encoding window, ew_size, is updated after adding new so urce symbols. The current size of the encoding window, ew_size, is updated after adding new so urce symbols.
This process may require to remove old source symbols so that: ew_size &le; ew_m ax_size. This process may require to remove old source symbols so that: ew_size &lt;= ew_ max_size.
</t> </t>
<t pn="section-3.3-4">
<t>
Note that a FEC codec may feature practical limits in the number of source symbo ls in the encoding window (e.g., for computational complexity reasons). Note that a FEC codec may feature practical limits in the number of source symbo ls in the encoding window (e.g., for computational complexity reasons).
This factor may further limit the ew_max_size value, in addition to the maximum This factor may further limit the ew_max_size value, in addition to the maximum
FEC-related latency budget (<xref target="CommonProc_rlcParameters"/>). FEC-related latency budget (<xref target="CommonProc_rlcParameters" format="defa
</t> ult" sectionFormat="of" derivedContent="Section 3.1"/>).
<!--
<t>
Limitations MAY exist that impact the encoding window management. For instance:
<list style="symbols">
<t> at the FEC Framework level: the source flows can have real-time constraints
that limit the number of ADUs in the encoding window;</t>
<t> at the FEC Scheme level: there may be theoretical or practical limitations (
e.g., because of computational complexity aspect or field size limits in the sig
naling headers) that limit the number of ADUs in the encoding window.</t>
</list>
The most stringent limitation defines the maximum encoding window size, either i
n terms of number of source symbols or number of ADUs, whichever applies.
</t> </t>
</section>
</section> <section anchor="CommonProc_esi" numbered="true" toc="include" removeInRFC
="false" pn="section-3.4">
<section anchor="CommonProc_esi" title="Source Symbol Identification"> <name slugifiedName="name-source-symbol-identificatio">Source Symbol Ide
<!-- ================ --> ntification</name>
<t pn="section-3.4-1">
<t>
Each source symbol is identified by an Encoding Symbol ID (ESI), an unsigned int eger. Each source symbol is identified by an Encoding Symbol ID (ESI), an unsigned int eger.
The ESI of source symbols MUST start with value 0 for the first source symbol an d MUST be managed sequentially. The ESI of source symbols <bcp14>MUST</bcp14> start with value 0 for the first s ource symbol and <bcp14>MUST</bcp14> be managed sequentially.
Wrapping to zero happens after reaching the maximum value made possible by the E SI field size Wrapping to zero happens after reaching the maximum value made possible by the E SI field size
(this maximum value is FEC Scheme dependant, for instance, 2^32-1 with FEC Schem es XXX and YYY). (this maximum value is FEC scheme dependent, for instance, 2<sup>32</sup>-1 with FEC schemes 9 and 10).
</t> </t>
<t pn="section-3.4-2">
<t>
No such consideration applies to repair symbols. No such consideration applies to repair symbols.
</t> </t>
</section>
</section> <section anchor="CommonProc_prng" numbered="true" toc="include" removeInRF
C="false" pn="section-3.5">
<section anchor="CommonProc_prng" title="Pseudo-Random Number Generator <name slugifiedName="name-pseudorandom-number-generat">Pseudorandom Numb
(PRNG)"> er Generator (PRNG)</name>
<!-- ====================== --> <t pn="section-3.5-1">
In order to compute coding coefficients (see <xref target="CommonProc_coef_gener
<t> ation_func" format="default" sectionFormat="of" derivedContent="Section 3.6"/>),
In order to compute coding coefficients (see <xref target="CommonProc_coef_gener the RLC FEC schemes rely on the TinyMT32 PRNG defined in <xref target="RFC8682"
ation_func"/>), the RLC FEC Schemes rely on the TinyMT32 PRNG defined in <xref t format="default" sectionFormat="of" derivedContent="RFC8682"/> with two additio
arget="tinymt32"/> with two additional functions defined in this section. nal functions defined in this section.
</t> </t>
<t pn="section-3.5-2">
<t> This PRNG <bcp14>MUST</bcp14> first be initialized with a 32-bit unsigned intege
This PRNG MUST first be initialized with a 32-bit unsigned integer, used as a se r, used as a seed, with:
ed, with: </t>
<list style="empty"> <sourcecode type="c" markers="false" pn="section-3.5-3">
<t>void tinymt32_init (tinymt32_t * s, uint32_t seed);</t> void tinymt32_init (tinymt32_t * s, uint32_t seed);
</list> </sourcecode>
With the FEC Schemes defined in this document, the seed is in practice restricte <t pn="section-3.5-4">
d to a value between 0 and 0xFFFF inclusive (note that this PRNG accepts a seed With the FEC schemes defined in this document, the seed is in practice restricte
value equal to 0), d to a value between 0 and 0xFFFF inclusive (note that this PRNG accepts a seed
since this is the Repair_Key 16-bit field value of the Repair FEC Payload ID (<x value equal to 0),
ref target="ArbitraryFlows_repair_fpi"/>). since this is the Repair_Key 16-bit field value of the Repair FEC Payload ID (<x
In practice, how to manage the seed and Repair_Key values (both are equal) is le ref target="ArbitraryFlows_repair_fpi" format="default" sectionFormat="of" deriv
ft to the implementer, using a monotonically increasing counter being one possib edContent="Section 4.1.3"/>).
ility (<xref target="ArbitraryFlows_FECCodeSpecification_encoding"/>). In practice, how to manage the seed and Repair_Key values (both are equal) is le
ft to the implementer, using a monotonically increasing counter being one possib
ility (<xref target="ArbitraryFlows_FECCodeSpecification_encoding" format="defau
lt" sectionFormat="of" derivedContent="Section 6.1"/>).
In addition to the seed, this function takes as parameter a pointer to an instan ce of a tinymt32_t structure that is used to keep the internal state of the PRNG . In addition to the seed, this function takes as parameter a pointer to an instan ce of a tinymt32_t structure that is used to keep the internal state of the PRNG .
</t> </t>
<t pn="section-3.5-5">
<t> Then, each time a new pseudorandom integer between 0 and 15 inclusive (4-bit pse
Then, each time a new pseudo-random integer between 0 and 15 inclusive (4-bit ps udorandom integer) is needed, the following function is used:
eudo-random integer) is needed, the following function is used: </t>
<list style="empty"> <sourcecode type="c" markers="false" pn="section-3.5-6">
<t>uint32_t tinymt32_rand16 (tinymt32_t * s);</t> uint32_t tinymt32_rand16 (tinymt32_t * s);
</list> </sourcecode>
<t pn="section-3.5-7">
This function takes as parameter a pointer to the same tinymt32_t structure (tha t is left unchanged between successive calls to the function). This function takes as parameter a pointer to the same tinymt32_t structure (tha t is left unchanged between successive calls to the function).
</t> </t>
<t pn="section-3.5-8">
<t> Similarly, each time a new pseudorandom integer between 0 and 255 inclusive (8-b
Similarly, each time a new pseudo-random integer between 0 and 255 inclusive (8- it pseudorandom integer) is needed, the following function is used:
bit pseudo-random integer) is needed, the following function is used:
<list style="empty">
<t>uint32_t tinymt32_rand256 (tinymt32_t * s);</t>
</list>
</t> </t>
<sourcecode type="c" markers="false" pn="section-3.5-9">
<t> uint32_t tinymt32_rand256 (tinymt32_t * s);
These two functions keep respectively the 4 or 8 less significant bits of the 32 </sourcecode>
-bit pseudo-random number generated by the tinymt32_generate_uint32() function o <t pn="section-3.5-10">
f <xref target="tinymt32"/>. These two functions keep respectively the 4 or 8 less significant bits of the 32
-bit pseudorandom number generated by the tinymt32_generate_uint32() function of
<xref target="RFC8682" format="default" sectionFormat="of" derivedContent="RFC8
682"/>.
This is done by computing the result of a binary AND between the tinymt32_genera te_uint32() output and respectively the 0xF or 0xFF constants, using 32-bit unsi gned integer operations. This is done by computing the result of a binary AND between the tinymt32_genera te_uint32() output and respectively the 0xF or 0xFF constants, using 32-bit unsi gned integer operations.
<xref target="fig_tinymt32_mapping"/> shows a possible implementation. <xref target="fig_tinymt32_mapping" format="default" sectionFormat="of" derivedC
This is a C language implementation, written for C99 <xref target="C99"/>. ontent="Figure 2"/> shows a possible implementation.
Test results discussed in <xref target="annex_assessing_prng"/> show that this This is a C language implementation, written for C99 <xref target="C99" format="
simple technique, applied to this PRNG, is in line with the RLC FEC Schemes need default" sectionFormat="of" derivedContent="C99"/>.
s. Test results discussed in <xref target="annex_assessing_prng" format="default"
sectionFormat="of" derivedContent="Appendix B"/> show that this simple technique
, applied to this PRNG, is in line with the RLC FEC schemes needs.
</t> </t>
<figure anchor="fig_tinymt32_mapping" align="left" suppress-title="false
<figure anchor="fig_tinymt32_mapping" title="4-bit and 8-bit mapping functions f " pn="figure-2">
or TinyMT32"> <name slugifiedName="name-4-bit-and-8-bit-mapping-fun">4-bit and 8-bit
<artwork><![CDATA[ Mapping Functions for TinyMT32</name>
<CODE BEGINS> <sourcecode name="" type="c" markers="true" pn="section-3.5-11.1">
/** /**
* This function outputs a pseudo-random integer in [0 .. 15] range. * This function outputs a pseudorandom integer in [0 .. 15] range.
* *
* @param s pointer to tinymt internal state. * @param s pointer to tinymt internal state.
* @return unsigned integer between 0 and 15 inclusive. * @return unsigned integer between 0 and 15 inclusive.
*/ */
uint32_t tinymt32_rand16(tinymt32_t *s) uint32_t tinymt32_rand16(tinymt32_t *s)
{ {
return (tinymt32_generate_uint32(s) & 0xF); return (tinymt32_generate_uint32(s) &amp; 0xF);
} }
/** /**
* This function outputs a pseudo-random integer in [0 .. 255] range. * This function outputs a pseudorandom integer in [0 .. 255] range.
* *
* @param s pointer to tinymt internal state. * @param s pointer to tinymt internal state.
* @return unsigned integer between 0 and 255 inclusive. * @return unsigned integer between 0 and 255 inclusive.
*/ */
uint32_t tinymt32_rand256(tinymt32_t *s) uint32_t tinymt32_rand256(tinymt32_t *s)
{ {
return (tinymt32_generate_uint32(s) & 0xFF); return (tinymt32_generate_uint32(s) &amp; 0xFF);
} }
<CODE ENDS> </sourcecode>
]]></artwork> </figure>
</figure> <t pn="section-3.5-12">
Any implementation of this PRNG <bcp14>MUST</bcp14> have the same output as
that provided by the reference implementation of <xref target="RFC8682" format="
default" sectionFormat="of" derivedContent="RFC8682"/>.
<t> In order to increase the compliance confidence, three criteria are proposed: the
Any implementation of this PRNG MUST have the same output as that provided by th one described in <xref target="RFC8682" format="default" sectionFormat="of" der
e reference implementation of <xref target="tinymt32"/>. ivedContent="RFC8682"/> (for the TinyMT32 32-bit unsigned integer generator), an
In order to increase the compliancy confidence, three criteria are proposed: the d the two others detailed in <xref target="annex_tinymt32_validation" format="de
one described in <xref target="tinymt32"/> (for the TinyMT32 32-bit unsigned in fault" sectionFormat="of" derivedContent="Appendix A"/> (for the mapping to 4-bi
teger generator), and the two others detailed in <xref target="annex_tinymt32_va t and 8-bit intervals).
lidation"/> (for the mapping to 4-bit and 8-bit intervals).
Because of the way the mapping functions work, it is unlikely that an implementa tion that fulfills the first criterion fails to fulfill the two others. Because of the way the mapping functions work, it is unlikely that an implementa tion that fulfills the first criterion fails to fulfill the two others.
</t> </t>
</section>
<section anchor="CommonProc_coef_generation_func" numbered="true" toc="inc
lude" removeInRFC="false" pn="section-3.6">
<name slugifiedName="name-coding-coefficients-generat">Coding Coefficien
ts Generation Function</name>
<t pn="section-3.6-1">
The coding coefficients used during the encoding process are
generated at the RLC encoder by the generate_coding_coefficients()
function each time a new repair symbol needs to be produced.
</section> The fraction of coefficients that are nonzero (i.e., the density) is controlled
by the DT (Density Threshold) parameter.
<section anchor="CommonProc_coef_generation_func" title="Coding Coefficie DT has values between 0 (the minimum value) and 15 (the maximum value), and the
nts Generation Function"> average probability of having a nonzero coefficient equals (DT + 1) / 16.
<!-- ====================== --> In particular, when DT equals 15 the function guaranties that all coefficients a
re nonzero (i.e., maximum density).
<t>
The coding coefficients, used during the encoding process, are generated at the
RLC encoder by the generate_coding_coefficients()
function each time a new repair symbol needs to be produced.
The fraction of coefficients that are non zero (i.e., the density) is controlled
by the DT (Density Threshold) parameter.
DT has values between 0 (the minimum value) and 15 (the maximum value), and the
average probability of having a non zero coefficient equals (DT + 1) / 16.
In particular, when DT equals 15 the function guaranties that all coefficients a
re non zero (i.e., maximum density).
</t> </t>
<t pn="section-3.6-2">
<t> These considerations apply to both the RLC over GF(2) and RLC over GF(2<sup>8</s
These considerations apply to both the RLC over GF(2) and RLC over GF(2^^8), the up>), the only difference being the value of the m parameter.
only difference being the value of the m parameter. With the RLC over GF(2) FEC scheme (<xref target="ArbitraryFlows_RLC_GF_2" forma
With the RLC over GF(2) FEC Scheme (<xref target="ArbitraryFlows_RLC_GF_2"/>), m t="default" sectionFormat="of" derivedContent="Section 5"/>), m is equal to 1.
is equal to 1. With RLC over GF(2<sup>8</sup>) FEC scheme (<xref target="ArbitraryFlows_RLC_GF_
With RLC over GF(2^^8) FEC Scheme (<xref target="ArbitraryFlows_RLC_GF_28"/>), m 28" format="default" sectionFormat="of" derivedContent="Section 4"/>), m is equa
is equal to 8. l to 8.
</t> </t>
<t pn="section-3.6-3"><xref target="fig_coef_generation_func" format="de
<t> fault" sectionFormat="of" derivedContent="Figure 3"/> shows the reference genera
<xref target="fig_coef_generation_func"/> shows the reference generate_coding_co te_coding_coefficients() implementation.
efficients() implementation. This is a C language implementation, written for C99 <xref target="C99" format="
This is a C language implementation, written for C99 <xref target="C99"/>. default" sectionFormat="of" derivedContent="C99"/>.
</t> </t>
<figure anchor="fig_coef_generation_func" align="left" suppress-title="f
<figure anchor="fig_coef_generation_func" title="Coding Coefficients Generation alse" pn="figure-3">
Function Reference Implementation"> <name slugifiedName="name-reference-implementation-of">Reference Imple
<artwork><![CDATA[ mentation of the Coding Coefficients Generation Function</name>
<CODE BEGINS> <sourcecode name="" type="c" markers="true" pn="section-3.6-4.1">
#include <string.h> #include &lt;string.h&gt;
/* /*
* Fills in the table of coding coefficients (of the right size) * Fills in the table of coding coefficients (of the right size)
* provided with the appropriate number of coding coefficients to * provided with the appropriate number of coding coefficients to
* use for the repair symbol key provided. * use for the repair symbol key provided.
* *
* (in) repair_key key associated to this repair symbol. This * (in) repair_key key associated to this repair symbol. This
* parameter is ignored (useless) if m=1 and dt=15 * parameter is ignored (useless) if m=1 and dt=15
* (in/out) cc_tab pointer to a table of the right size to store * (in/out) cc_tab pointer to a table of the right size to store
* coding coefficients. All coefficients are * coding coefficients. All coefficients are
* stored as bytes, regardless of the m parameter, * stored as bytes, regardless of the m parameter,
* upon return of this function. * upon return of this function.
* (in) cc_nb number of entries in the cc_tab table. This * (in) cc_nb number of entries in the cc_tab table. This
* value is equal to the current encoding window * value is equal to the current encoding window
* size. * size.
* (in) dt integer between 0 and 15 (inclusive) that * (in) dt integer between 0 and 15 (inclusive) that
* controls the density. With value 15, all * controls the density. With value 15, all
* coefficients are guaranteed to be non zero * coefficients are guaranteed to be nonzero
* (i.e. equal to 1 with GF(2) and equal to a * (i.e., equal to 1 with GF(2) and equal to a
* value in {1,... 255} with GF(2^^8)), otherwise * value in {1,... 255} with GF(2^^8)), otherwise
* a fraction of them will be 0. * a fraction of them will be 0.
* (in) m Finite Field GF(2^^m) parameter. In this * (in) m Finite Field GF(2^^m) parameter. In this
* document only values 1 and 8 are considered. * document only values 1 and 8 are considered.
* (out) returns 0 in case of success, an error code * (out) returns 0 in case of success, an error code
* different than 0 otherwise. * different than 0 otherwise.
*/ */
int generate_coding_coefficients (uint16_t repair_key, int generate_coding_coefficients (uint16_t repair_key,
uint8_t* cc_tab, uint8_t* cc_tab,
uint16_t cc_nb, uint16_t cc_nb,
uint8_t dt, uint8_t dt,
uint8_t m) uint8_t m)
{ {
uint32_t i; uint32_t i;
tinymt32_t s; /* PRNG internal state */ tinymt32_t s; /* PRNG internal state */
if (dt > 15) { if (dt &gt; 15) {
return -1; /* error, bad dt parameter */ return -1; /* error, bad dt parameter */
} }
switch (m) { switch (m) {
case 1: case 1:
if (dt == 15) { if (dt == 15) {
/* all coefficients are 1 */ /* all coefficients are 1 */
memset(cc_tab, 1, cc_nb); memset(cc_tab, 1, cc_nb);
} else { } else {
/* here coefficients are either 0 or 1 */ /* here coefficients are either 0 or 1 */
tinymt32_init(&s, repair_key); tinymt32_init(&amp;s, repair_key);
for (i = 0 ; i < cc_nb ; i++) { for (i = 0 ; i &lt; cc_nb ; i++) {
cc_tab[i] = (tinymt32_rand16(&s) <= dt) ? 1 : 0; cc_tab[i] = (tinymt32_rand16(&amp;s) &lt;= dt) ? 1 : 0;
} }
} }
break; break;
case 8: case 8:
tinymt32_init(&s, repair_key); tinymt32_init(&amp;s, repair_key);
if (dt == 15) { if (dt == 15) {
/* coefficient 0 is avoided here in order to include /* coefficient 0 is avoided here in order to include
* all the source symbols */ * all the source symbols */
for (i = 0 ; i < cc_nb ; i++) { for (i = 0 ; i &lt; cc_nb ; i++) {
do { do {
cc_tab[i] = (uint8_t) tinymt32_rand256(&s); cc_tab[i] = (uint8_t) tinymt32_rand256(&amp;s);
} while (cc_tab[i] == 0); } while (cc_tab[i] == 0);
} }
} else { } else {
/* here a certain number of coefficients should be 0 */ /* here a certain number of coefficients should be 0 */
for (i = 0 ; i < cc_nb ; i++) { for (i = 0 ; i &lt; cc_nb ; i++) {
if (tinymt32_rand16(&s) <= dt) { if (tinymt32_rand16(&amp;s) &lt;= dt) {
do { do {
cc_tab[i] = (uint8_t) tinymt32_rand256(&s); cc_tab[i] = (uint8_t) tinymt32_rand256(&amp;s);
} while (cc_tab[i] == 0); } while (cc_tab[i] == 0);
} else { } else {
cc_tab[i] = 0; cc_tab[i] = 0;
} }
} }
} }
break; break;
default: default:
return -2; /* error, bad parameter m */ return -2; /* error, bad parameter m */
} }
return 0; /* success */ return 0; /* success */
} }
<CODE ENDS> </sourcecode>
]]></artwork> </figure>
</figure> </section>
<section anchor="CommonProc_gf_specificiation" numbered="true" toc="includ
</section> e" removeInRFC="false" pn="section-3.7">
<name slugifiedName="name-finite-field-operations">Finite Field Operatio
<section anchor="CommonProc_gf_specificiation" title="Finite Fields Opera ns</name>
tions"> <section numbered="true" toc="include" removeInRFC="false" pn="section-3
<!-- ====================== --> .7.1">
<name slugifiedName="name-finite-field-definitions">Finite Field Defin
<section title="Finite Field Definitions"> itions</name>
<!-- ====================== --> <t pn="section-3.7.1-1">
<t> The two RLC FEC schemes specified in this document reuse the Finite Fields
The two RLC FEC Schemes specified in this document reuse the Finite Fields defin defined in <xref target="RFC5510" format="default" section="8.1" sectionFormat="
ed in <xref target="RFC5510"/>, section 8.1. comma" derivedLink="https://rfc-editor.org/rfc/rfc5510#section-8.1" derivedConte
More specifically, the elements of the field GF(2^^m) are represented by polynom nt="RFC5510"/>.
ials with binary coefficients (i.e., over GF(2)) and degree lower or equal to m- More specifically, the elements of the field GF(2<sup>m</sup>) are represented b
1. y polynomials with binary coefficients (i.e., over GF(2)) and degree lower or eq
ual to m-1.
The addition between two elements is defined as the addition of binary polynomia ls in GF(2), which is equivalent to a bitwise XOR operation on the binary repres entation of these elements. The addition between two elements is defined as the addition of binary polynomia ls in GF(2), which is equivalent to a bitwise XOR operation on the binary repres entation of these elements.
</t> </t>
<t pn="section-3.7.1-2">
<t> With GF(2<sup>8</sup>), multiplication between two elements is the multiplicatio
With GF(2^^8), multiplication between two elements is the multiplication modulo n modulo a given irreducible polynomial of degree 8.
a given irreducible polynomial of degree 8. The following irreducible polynomial is used for GF(2<sup>8</sup>):
The following irreducible polynomial is used for GF(2^^8):
<list style="empty">
<t>x^^8 + x^^4 + x^^3 + x^^2 + 1 </t>
</list>
</t> </t>
<ul empty="true" spacing="normal" bare="false" pn="section-3.7.1-3">
<t> <li pn="section-3.7.1-3.1">x<sup>8</sup> + x<sup>4</sup> + x<sup>3</
sup> + x<sup>2</sup> + 1 </li>
</ul>
<t pn="section-3.7.1-4">
With GF(2), multiplication corresponds to a logical AND operation. With GF(2), multiplication corresponds to a logical AND operation.
</t> </t>
</section>
</section> <section anchor="CommonProc_linear_combination_computation" numbered="tr
ue" toc="include" removeInRFC="false" pn="section-3.7.2">
<section anchor="CommonProc_linear_combination_computation" title <name slugifiedName="name-linear-combination-of-sourc">Linear Combinat
="Linear Combination of Source Symbols Computation"> ion of Source Symbol Computation</name>
<!-- ====================== --> <t pn="section-3.7.2-1">
The two RLC FEC schemes require the computation of a linear combination of sourc
<t> e symbols, using the coding coefficients produced by the generate_coding_coeffic
The two RLC FEC Schemes require the computation of a linear combination of sourc ients() function and stored in the cc_tab[] array.
e symbols, using the coding coefficients produced by the generate_coding_coeffic
ients() function and stored in the cc_tab[] array.
</t> </t>
<t pn="section-3.7.2-2">
<t> With the RLC over GF(2<sup>8</sup>) FEC scheme, a linear combination of the ew_s
With the RLC over GF(2^^8) FEC Scheme, a linear combination of the ew_size sourc ize source symbol present in the encoding window, say src_0 to src_ew_size_1, in
e symbol present in the encoding window, say src_0 to src_ew_size_1, in order to order to generate a repair symbol, is computed as follows.
generate a repair symbol, is computed as follows.
For each byte of position i in each source and the repair symbol, where i belong s to [0; E-1], compute: For each byte of position i in each source and the repair symbol, where i belong s to [0; E-1], compute:
<list style="none">
<t> repair[i] = cc_tab[0] * src_0[i] XOR cc_tab[1] * src_1[i] XOR ... XOR
cc_tab[ew_size - 1] * src_ew_size_1[i]</t>
</list>
where * is the multiplication over GF(2^^8).
In practice various optimizations need to be used in order to make this computat
ion efficient (see in particular <xref target="PGM13"/>).
</t> </t>
<sourcecode type="pseudocode" markers="false" pn="section-3.7.2-3">
<t> repair[i] = cc_tab[0] * src_0[i] XOR cc_tab[1] * src_1[i] XOR ...
With the RLC over GF(2) FEC Scheme (binary case), a linear combination is comput XOR cc_tab[ew_size - 1] * src_ew_size_1[i]
ed as follows. </sourcecode>
<t pn="section-3.7.2-4">
where * is the multiplication over GF(2<sup>8</sup>).
In practice various optimizations need to be used in order to make this computat
ion efficient (see in particular <xref target="PGM13" format="default" sectionFo
rmat="of" derivedContent="PGM13"/>).
</t>
<t pn="section-3.7.2-5">
With the RLC over GF(2) FEC scheme (binary case), a linear combination is comput
ed as follows.
The repair symbol is the XOR sum of all the source symbols corresponding to a co ding coefficient cc_tab[j] equal to 1 (i.e., the source symbols corresponding to zero coding coefficients are ignored). The repair symbol is the XOR sum of all the source symbols corresponding to a co ding coefficient cc_tab[j] equal to 1 (i.e., the source symbols corresponding to zero coding coefficients are ignored).
The XOR sum of the byte of position i in each source is computed and stored in t he corresponding byte of the repair symbol, where i belongs to [0; E-1]. The XOR sum of the byte of position i in each source is computed and stored in t he corresponding byte of the repair symbol, where i belongs to [0; E-1].
In practice, the XOR sums will be computed several bytes at a time (e.g., on 64 bit words, or on arrays of 16 or more bytes when using SIMD CPU extensions). In practice, the XOR sums will be computed several bytes at a time (e.g., on 64 bit words, or on arrays of 16 or more bytes when using SIMD CPU extensions).
</t> </t>
<t pn="section-3.7.2-6">
<t> With both FEC schemes, the details of how to optimize the computation of these l
With both FEC Schemes, the details of how to optimize the computation of these l inear combinations are of high practical importance but out of scope of this doc
inear combinations are of high practical importance but out of scope of this doc ument.
ument.
</t> </t>
</section>
</section> </section>
</section>
</section> <section anchor="ArbitraryFlows_RLC_GF_28" numbered="true" toc="include" rem
oveInRFC="false" pn="section-4">
</section> <name slugifiedName="name-sliding-window-rlc-fec-sche">Sliding Window RLC
FEC Scheme over GF(2<sup>8</sup>) for Arbitrary Packet Flows</name>
<section anchor="ArbitraryFlows_RLC_GF_28" title="Sliding Window RLC FEC Scheme <t pn="section-4-1">
over GF(2^^8) for Arbitrary Packet Flows"> This fully-specified FEC scheme defines the Sliding Window Random Linear Codes (
<!-- ==================================== --> RLC) over GF(2<sup>8</sup>).
<t>
This fully-specified FEC Scheme defines the Sliding Window Random Linear Codes (
RLC) over GF(2^^8).
</t> </t>
<section anchor="ArbitraryFlows_formatsAndCodes" numbered="true" toc="incl
<section anchor="ArbitraryFlows_formatsAndCodes" title="Formats and Codes ude" removeInRFC="false" pn="section-4.1">
"> <name slugifiedName="name-formats-and-codes">Formats and Codes</name>
<!-- ==================================== --> <section numbered="true" toc="include" removeInRFC="false" pn="section-4
.1.1">
<section title="FEC Framework Configuration Information"> <name slugifiedName="name-fec-framework-configuration">FEC Framework C
<!-- ================ --> onfiguration Information</name>
<t> <t pn="section-4.1.1-1">
Following the guidelines of <xref target="RFC6363"/>, section 5.6, this section Following the guidelines of <xref target="RFC6363" format="default" sectionForma
provides t="of" section="5.6" derivedLink="https://rfc-editor.org/rfc/rfc6363#section-5.6
" derivedContent="RFC6363"/>, this section provides
the FEC Framework Configuration Information (or FFCI). the FEC Framework Configuration Information (or FFCI).
This FCCI needs to be shared (e.g., using SDP) between the FECFRAME sender and r eceiver This FCCI needs to be shared (e.g., using SDP) between the FECFRAME sender and r eceiver
instances in order to synchronize them. instances in order to synchronize them.
It includes a FEC Encoding ID, mandatory for any FEC Scheme specification, plus It includes a FEC Encoding ID, mandatory for any FEC scheme specification, plus
scheme-specific elements. scheme-specific elements.
</t>
<section title="FEC Encoding ID">
<!-- ================ -->
<t>
<list style="symbols">
<t>FEC Encoding ID:
the value assigned to this fully specified FEC Scheme MUST be XXXX,
as assigned by IANA (<xref target="iana"/>).</t>
</list>
</t> </t>
<section numbered="true" toc="exclude" removeInRFC="false" pn="section
<t> -4.1.1.1">
<name slugifiedName="name-fec-encoding-id">FEC Encoding ID</name>
<dl newline="false" spacing="normal" pn="section-4.1.1.1-1">
<dt pn="section-4.1.1.1-1.1">FEC Encoding ID:</dt>
<dd pn="section-4.1.1.1-1.2">the value assigned to this fully spec
ified FEC scheme <bcp14>MUST</bcp14> be 10,
as assigned by IANA (<xref target="iana" format="default" sectionFormat="
of" derivedContent="Section 9"/>).</dd>
</dl>
<t pn="section-4.1.1.1-2">
When SDP is used to communicate the FFCI, this FEC Encoding ID is carried in When SDP is used to communicate the FFCI, this FEC Encoding ID is carried in
the 'encoding-id' parameter. the 'encoding-id' parameter.
</t> </t>
</section> </section>
<section anchor="ArbitraryFlows_fssi" numbered="true" toc="exclude" re
<section anchor="ArbitraryFlows_fssi" title="FEC Scheme-S moveInRFC="false" pn="section-4.1.1.2">
pecific Information"> <name slugifiedName="name-fec-scheme-specific-informa">FEC Scheme-Sp
<!-- ================ --> ecific Information</name>
<t> <t pn="section-4.1.1.2-1">
The FEC Scheme-Specific Information (FSSI) includes elements that are specific t The FEC Scheme-Specific Information (FSSI) includes elements that are specific t
o the present FEC Scheme. o the present FEC scheme.
More precisely: More precisely:
<list style="hanging"> </t>
<t hangText="Encoding symbol size (E):"> <dl newline="false" spacing="normal" pn="section-4.1.1.2-2">
a non-negative integer that indicates the size of each encoding s <dt pn="section-4.1.1.2-2.1">Encoding symbol size (E):</dt>
ymbol in bytes;</t> <dd pn="section-4.1.1.2-2.2">
<t hangText="Window Size Ratio (WSR) parameter: "> a non-negative integer that indicates the size of each encoding s
ymbol in bytes;</dd>
<dt pn="section-4.1.1.2-2.3">Window Size Ratio (WSR) parameter: </
dt>
<dd pn="section-4.1.1.2-2.4">
a non-negative integer between 0 and 255 (both inclusive) used to initialize window sizes. a non-negative integer between 0 and 255 (both inclusive) used to initialize window sizes.
A value of 0 indicates this parameter is not considered (e.g., a fixed encoding window size may be chosen). A value of 0 indicates this parameter is not considered (e.g., a fixed encoding window size may be chosen).
A value between 1 and 255 inclusive is required by certain of the A value between 1 and 255 inclusive is required by certain of the
parameter derivation techniques described in <xref target="possible_param_deriv parameter derivation techniques described in <xref target="possible_param_deriv
ation"/>;</t> ation" format="default" sectionFormat="of" derivedContent="Appendix C"/>;</dd>
</list> </dl>
<t pn="section-4.1.1.2-3">
This element is required both by the sender (RLC encoder) and the receiver(s) (R LC decoder). This element is required both by the sender (RLC encoder) and the receiver(s) (R LC decoder).
</t> </t>
<t pn="section-4.1.1.2-4">
<t> When SDP is used to communicate the FFCI, this FEC Scheme-Specific Information i
When SDP is used to communicate the FFCI, this FEC Scheme-specific information i s carried in
s carried in the 'fssi' parameter in textual representation as specified in <xref target="RFC
the 'fssi' parameter in textual representation as specified in <xref target="RFC 6364" format="default" sectionFormat="of" derivedContent="RFC6364"/>.
6364"/>.
For instance: For instance:
</t> </t>
<t> <sourcecode type="sdp" markers="false" pn="section-4.1.1.2-5">
fssi=E:1400,WSR:191 fssi=E:1400,WSR:191
</t> </sourcecode>
<t> <t pn="section-4.1.1.2-6">
In that case the name values "E" and "WSR" are used to convey the E and WSR para meters respectively. In that case the name values "E" and "WSR" are used to convey the E and WSR para meters respectively.
</t> </t>
<t pn="section-4.1.1.2-7">
<t>
If another mechanism requires the FSSI to be carried as an opaque octet string, the encoding format consists If another mechanism requires the FSSI to be carried as an opaque octet string, the encoding format consists
of the following three octets, where the E field is carried in "big-endian" or " network order" format, that is, of the following three octets, where the E field is carried in "big-endian" or " network order" format, that is,
most significant byte first: most significant byte first:
<list style="hanging"> </t>
<t> Encoding symbol length (E): 16-bit field;</t> <dl newline="false" spacing="normal" pn="section-4.1.1.2-8">
<t> Window Size Ratio Parameter (WSR): 8-bit field.</t> <dt pn="section-4.1.1.2-8.1"/>
</list> <dd pn="section-4.1.1.2-8.2"> Encoding symbol length (E): 16-bit f
ield;</dd>
<dt pn="section-4.1.1.2-8.3"/>
<dd pn="section-4.1.1.2-8.4"> Window Size Ratio Parameter (WSR): 8
-bit field.</dd>
</dl>
<t pn="section-4.1.1.2-9">
These three octets can be communicated as such, or for instance, be subject to a n additional Base64 encoding. These three octets can be communicated as such, or for instance, be subject to a n additional Base64 encoding.
</t> </t>
<figure anchor="fig_ArbitraryFlows_fssi_binary" align="left" suppres
<figure anchor="fig_ArbitraryFlows_fssi_binary" title="FSSI Encoding Format"> s-title="false" pn="figure-4">
<artwork> <name slugifiedName="name-fssi-encoding-format">FSSI Encoding Form
at</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1.1.2-1
0.1">
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) | WSR | | Encoding Symbol Length (E) | WSR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> </artwork>
</figure> </figure>
</section>
</section> </section>
<section anchor="ArbitraryFlows_src_fpi" numbered="true" toc="include" r
</section> emoveInRFC="false" pn="section-4.1.2">
<name slugifiedName="name-explicit-source-fec-payload">Explicit Source
<section anchor="ArbitraryFlows_src_fpi" title="Explicit Source F FEC Payload ID</name>
EC Payload ID"> <t pn="section-4.1.2-1">
<!-- ================ --> A FEC Source Packet <bcp14>MUST</bcp14> contain an Explicit Source FEC Payload I
D that is appended to the
<t> end of the packet as illustrated in <xref target="fig_src_pkt_format" format="de
A FEC Source Packet MUST contain an Explicit Source FEC Payload ID that is appen fault" sectionFormat="of" derivedContent="Figure 5"/>.
ded to the
end of the packet as illustrated in <xref target="fig_src_pkt_format"/>.
</t> </t>
<figure anchor="fig_src_pkt_format" align="left" suppress-title="false
<figure anchor="fig_src_pkt_format" title="Structure of an FEC Source Packet wit " pn="figure-5">
h the <name slugifiedName="name-structure-of-an-fec-source-">Structure of
Explicit Source FEC Payload ID"> an FEC Source Packet with the Explicit Source FEC Payload ID</name>
<artwork> <artwork name="" type="" align="left" alt="" pn="section-4.1.2-2.1">
+--------------------------------+ +--------------------------------+
| IP Header | | IP Header |
+--------------------------------+ +--------------------------------+
| Transport Header | | Transport Header |
+--------------------------------+ +--------------------------------+
| ADU | | ADU |
+--------------------------------+ +--------------------------------+
| Explicit Source FEC Payload ID | | Explicit Source FEC Payload ID |
+--------------------------------+ +--------------------------------+
</artwork> </artwork>
</figure> </figure>
<t pn="section-4.1.2-3">
<t>
More precisely, the Explicit Source FEC Payload ID is composed of the following field, More precisely, the Explicit Source FEC Payload ID is composed of the following field,
carried in "big-endian" or "network order" format, that is, most significant byt e first carried in "big-endian" or "network order" format, that is, most significant byt e first
(<xref target="fig_src_fpi"/>): (<xref target="fig_src_fpi" format="default" sectionFormat="of" derivedContent="
<list style="hanging"> Figure 6"/>):
<t hangText="Encoding Symbol ID (ESI) (32-bit field):"> </t>
<dl newline="false" spacing="normal" pn="section-4.1.2-4">
<dt pn="section-4.1.2-4.1">Encoding Symbol ID (ESI) (32-bit field):<
/dt>
<dd pn="section-4.1.2-4.2">
this unsigned integer identifies the first source symbol of the A DUI corresponding to this FEC Source Packet. this unsigned integer identifies the first source symbol of the A DUI corresponding to this FEC Source Packet.
The ESI is incremented for each new source symbol, and after reac hing the maximum value The ESI is incremented for each new source symbol, and after reac hing the maximum value
(2^32-1), wrapping to zero occurs. (2<sup>32</sup>-1), wrapping to zero occurs.
</t> </dd>
</list></t> </dl>
<figure anchor="fig_src_fpi" align="left" suppress-title="false" pn="f
<figure anchor="fig_src_fpi" title="Source FEC Payload ID Encoding Format"> igure-6">
<artwork> <name slugifiedName="name-source-fec-payload-id-encod">Source FEC Pa
yload ID Encoding Format</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1.2-5.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID (ESI) | | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> </artwork>
</figure> </figure>
</section>
</section> <section anchor="ArbitraryFlows_repair_fpi" numbered="true" toc="include
" removeInRFC="false" pn="section-4.1.3">
<section anchor="ArbitraryFlows_repair_fpi" title="Repair FEC Pay <name slugifiedName="name-repair-fec-payload-id">Repair FEC Payload ID
load ID"> </name>
<!-- ================ --> <t pn="section-4.1.3-1">
A FEC Repair Packet <bcp14>MAY</bcp14> contain one or more repair symbols.
<t> When there are several repair symbols, all of them <bcp14>MUST</bcp14> have been
A FEC Repair Packet MAY contain one or more repair symbols. generated from the same encoding window,
When there are several repair symbols, all of them MUST have been generated from
the same encoding window,
using Repair_Key values that are managed as explained below. using Repair_Key values that are managed as explained below.
A receiver can easily deduce the number of repair symbols within a FEC Repair Pa cket by A receiver can easily deduce the number of repair symbols within a FEC Repair Pa cket by
comparing the received FEC Repair Packet size (equal to the UDP payload size whe n UDP is the underlying comparing the received FEC Repair Packet size (equal to the UDP payload size whe n UDP is the underlying
transport protocol) and the symbol size, E, communicated in the FFCI. transport protocol) and the symbol size, E, communicated in the FFCI.
</t> </t>
<t pn="section-4.1.3-2">
<t> A FEC Repair Packet <bcp14>MUST</bcp14> contain a Repair FEC Payload ID that is
A FEC Repair Packet MUST contain a Repair FEC Payload ID that is prepended to th prepended to the
e repair symbol as illustrated in <xref target="fig_repair_pkt_format" format="def
repair symbol as illustrated in <xref target="fig_repair_pkt_format"/>. ault" sectionFormat="of" derivedContent="Figure 7"/>.
</t> </t>
<figure anchor="fig_repair_pkt_format" align="left" suppress-title="fa
<figure anchor="fig_repair_pkt_format" title="Structure of an FEC Repair Packet lse" pn="figure-7">
with the Repair FEC Payload ID"> <name slugifiedName="name-structure-of-an-fec-repair-">Structure of
<artwork> an FEC Repair Packet with the Repair FEC Payload ID</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1.3-3.1">
+--------------------------------+ +--------------------------------+
| IP Header | | IP Header |
+--------------------------------+ +--------------------------------+
| Transport Header | | Transport Header |
+--------------------------------+ +--------------------------------+
| Repair FEC Payload ID | | Repair FEC Payload ID |
+--------------------------------+ +--------------------------------+
| Repair Symbol | | Repair Symbol |
+--------------------------------+ +--------------------------------+
</artwork> </artwork>
</figure> </figure>
<t pn="section-4.1.3-4">
<t>
More precisely, the Repair FEC Payload ID is composed of the following fields wh ere all integer fields are carried More precisely, the Repair FEC Payload ID is composed of the following fields wh ere all integer fields are carried
in "big-endian" or "network order" format, that is, most significant byte first in "big-endian" or "network order" format, that is, most significant byte first
(<xref target="fig_repair_fpi"/>): (<xref target="fig_repair_fpi" format="default" sectionFormat="of" derivedConten
<list style="hanging"> t="Figure 8"/>):
<t hangText="Repair_Key (16-bit field):"> </t>
this unsigned integer is used as a seed by the coefficient generation fun <dl newline="false" spacing="normal" pn="section-4.1.3-5">
ction (<xref target="CommonProc_coef_generation_func"/>) <dt pn="section-4.1.3-5.1">Repair_Key (16-bit field):</dt>
<dd pn="section-4.1.3-5.2">
this unsigned integer is used as a seed by the coefficient generation fun
ction (<xref target="CommonProc_coef_generation_func" format="default" sectionFo
rmat="of" derivedContent="Section 3.6"/>)
in order to generate the desired number of coding coefficients. in order to generate the desired number of coding coefficients.
This repair key may be a monotonically increasing integer value that loop s back to 0 after reaching 65535 This repair key may be a monotonically increasing integer value that loop s back to 0 after reaching 65535
(see <xref target="ArbitraryFlows_FECCodeSpecification_encoding"/>). (see <xref target="ArbitraryFlows_FECCodeSpecification_encoding" format=" default" sectionFormat="of" derivedContent="Section 6.1"/>).
When a FEC Repair Packet contains several repair symbols, this repair key value is that of the first repair symbol. When a FEC Repair Packet contains several repair symbols, this repair key value is that of the first repair symbol.
The remaining repair keys can be deduced by incrementing by 1 this value, up to a maximum value of 65535 after which it loops back to 0. The remaining repair keys can be deduced by incrementing by 1 this value, up to a maximum value of 65535 after which it loops back to 0.
</t> </dd>
<dt pn="section-4.1.3-5.3">Density Threshold for the coding coeffici
<t hangText="Density Threshold for the coding coefficients, DT (4-bit field):"> ents, DT (4-bit field):</dt>
this unsigned integer carries the Density Threshold (DT) used by the codi <dd pn="section-4.1.3-5.4">
ng coefficient generation function <xref target="CommonProc_coef_generation_func this unsigned integer carries the Density Threshold (DT) used by the codi
"/>. ng coefficient generation function <xref target="CommonProc_coef_generation_func
More precisely, it controls the probability of having a non zero coding c " format="default" sectionFormat="of" derivedContent="Section 3.6"/>.
oefficient, which equals (DT+1) / 16. More precisely, it controls the probability of having a nonzero coding co
When a FEC Repair Packet contains several repair symbols, the DT value ap efficient, which equals (DT+1) / 16.
plies to all of them; </t> When a FEC Repair Packet contains several repair symbols, the DT value ap
plies to all of them; </dd>
<t hangText="Number of Source Symbols in the encoding window, NSS (12-bit field) <dt pn="section-4.1.3-5.5">Number of Source Symbols in the encoding
:"> window, NSS (12-bit field):</dt>
<dd pn="section-4.1.3-5.6">
this unsigned integer indicates the number of source symbols in the encod ing window when this repair symbol was generated. this unsigned integer indicates the number of source symbols in the encod ing window when this repair symbol was generated.
When a FEC Repair Packet contains several repair symbols, this NSS value When a FEC Repair Packet contains several repair symbols, this NSS value
applies to all of them; </t> applies to all of them; </dd>
<dt pn="section-4.1.3-5.7">ESI of First Source Symbol in the encodin
<t hangText="ESI of First Source Symbol in the encoding window, FSS_ESI (32-bit g window, FSS_ESI (32-bit field):</dt>
field):"> <dd pn="section-4.1.3-5.8">
this unsigned integer indicates the ESI of the first source symbol in the encoding window when this repair symbol was generated. this unsigned integer indicates the ESI of the first source symbol in the encoding window when this repair symbol was generated.
When a FEC Repair Packet contains several repair symbols, this FSS_ESI va When a FEC Repair Packet contains several repair symbols, this FSS_ESI va
lue applies to all of them; </t> lue applies to all of them; </dd>
</list> </dl>
</t> <figure anchor="fig_repair_fpi" align="left" suppress-title="false" pn
="figure-8">
<figure anchor="fig_repair_fpi" title="Repair FEC Payload ID Encoding Format"> <name slugifiedName="name-repair-fec-payload-id-encod">Repair FEC Pa
<artwork> yload ID Encoding Format</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1.3-6.1">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repair_Key | DT |NSS (# src symb in ew) | | Repair_Key | DT |NSS (# src symb in ew) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FSS_ESI | | FSS_ESI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> </artwork>
</figure> </figure>
</section>
</section> </section>
<section anchor="ArbitraryFlows_Procedures" numbered="true" toc="include"
</section> removeInRFC="false" pn="section-4.2">
<name slugifiedName="name-procedures">Procedures</name>
<section anchor="ArbitraryFlows_Procedures" title="Procedures"> <t pn="section-4.2-1">
<!-- ================ --> All the procedures of <xref target="CommonProcedures" format="default" sectionFo
<t> rmat="of" derivedContent="Section 3"/> apply to this FEC scheme.
All the procedures of <xref target="CommonProcedures"/> apply to this FEC Scheme
.
</t>
</section>
</section> <!-- ArbitraryFlows -->
<section anchor="ArbitraryFlows_RLC_GF_2" title="Sliding Window RLC FEC Scheme o
ver GF(2) for Arbitrary Packet Flows">
<!-- ==================================== -->
<t>
This fully-specified FEC Scheme defines the Sliding Window Random Linear Codes (
RLC) over GF(2) (binary case).
</t> </t>
</section>
<section title="Formats and Codes"> </section>
<!-- ==================================== --> <section anchor="ArbitraryFlows_RLC_GF_2" numbered="true" toc="include" remo
veInRFC="false" pn="section-5">
<section title="FEC Framework Configuration Information"> <name slugifiedName="name-sliding-window-rlc-fec-schem">Sliding Window RLC
<!-- ================ --> FEC Scheme over GF(2) for Arbitrary Packet Flows</name>
<t pn="section-5-1">
<section title="FEC Encoding ID"> This fully-specified FEC scheme defines the Sliding Window Random Linear Codes (
<!-- ================ --> RLC) over GF(2) (binary case).
<t>
<list style="symbols">
<t>FEC Encoding ID:
the value assigned to this fully specified FEC Scheme MUST be YYYY,
as assigned by IANA (<xref target="iana"/>).</t>
</list>
</t> </t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.1
<t> ">
<name slugifiedName="name-formats-and-codes-2">Formats and Codes</name>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5
.1.1">
<name slugifiedName="name-fec-framework-configuration-">FEC Framework
Configuration Information</name>
<section numbered="true" toc="exclude" removeInRFC="false" pn="section
-5.1.1.1">
<name slugifiedName="name-fec-encoding-id-2">FEC Encoding ID</name>
<dl newline="false" spacing="normal" pn="section-5.1.1.1-1">
<dt pn="section-5.1.1.1-1.1">FEC Encoding ID:</dt>
<dd pn="section-5.1.1.1-1.2">the value assigned to this fully spec
ified FEC scheme
<bcp14>MUST</bcp14> be 9,
as assigned by IANA (<xref target="iana" format="default" sectionFormat="
of" derivedContent="Section 9"/>).</dd>
</dl>
<t pn="section-5.1.1.1-2">
When SDP is used to communicate the FFCI, this FEC Encoding ID is carried in When SDP is used to communicate the FFCI, this FEC Encoding ID is carried in
the 'encoding-id' parameter. the 'encoding-id' parameter.
</t> </t>
</section> </section>
<section numbered="true" toc="exclude" removeInRFC="false" pn="section
<section title="FEC Scheme-Specific Information"> -5.1.1.2">
<!-- ================ --> <name slugifiedName="name-fec-scheme-specific-informat">FEC Scheme-S
<t> pecific Information</name>
All the considerations of <xref target="ArbitraryFlows_fssi"/> apply here. <t pn="section-5.1.1.2-1">
All the considerations of <xref target="ArbitraryFlows_fssi" format="default" se
ctionFormat="of" derivedContent="Section 4.1.1.2"/> apply here.
</t> </t>
</section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5
</section> .1.2">
<name slugifiedName="name-explicit-source-fec-payload-">Explicit Sourc
<section title="Explicit Source FEC Payload ID"> e FEC Payload ID</name>
<!-- ================ --> <t pn="section-5.1.2-1">
All the considerations of <xref target="ArbitraryFlows_src_fpi" format="default"
<t> sectionFormat="of" derivedContent="Section 4.1.2"/> apply here.
All the considerations of <xref target="ArbitraryFlows_src_fpi"/> apply here.
</t> </t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5
<section title="Repair FEC Payload ID"> .1.3">
<!-- ================ --> <name slugifiedName="name-repair-fec-payload-id-2">Repair FEC Payload
ID</name>
<t> <t pn="section-5.1.3-1">
All the considerations of <xref target="ArbitraryFlows_repair_fpi"/> apply here, All the considerations of <xref target="ArbitraryFlows_repair_fpi" format="defau
with the only exception that the Repair_Key field lt" sectionFormat="of" derivedContent="Section 4.1.3"/> apply here, with the onl
y exception that the Repair_Key field
is useless if DT = 15 (indeed, in that case all the coefficients are necessarily equal to 1 and the coefficient generation function does not use any PRNG). is useless if DT = 15 (indeed, in that case all the coefficients are necessarily equal to 1 and the coefficient generation function does not use any PRNG).
When DT = 15 the FECFRAME sender MUST set the Repair_Key field to zero on trans mission and a receiver MUST ignore it on receipt. When DT = 15 the FECFRAME sender <bcp14>MUST</bcp14> set the Repair_Key field t o zero on transmission and a receiver <bcp14>MUST</bcp14> ignore it on receipt.
</t> </t>
</section> </section>
</section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2
">
<section title="Procedures"> <name slugifiedName="name-procedures-2">Procedures</name>
<!-- ================ --> <t pn="section-5.2-1">
All the procedures of <xref target="CommonProcedures" format="default" sectionFo
<t> rmat="of" derivedContent="Section 3"/> apply to this FEC scheme.
All the procedures of <xref target="CommonProcedures"/> apply to this FEC Scheme
.
</t> </t>
</section> </section>
</section>
</section> <!-- ArbitraryFlows --> <section anchor="ArbitraryFlows_FECCodeSpecification" numbered="true" toc="i
nclude" removeInRFC="false" pn="section-6">
<section anchor="ArbitraryFlows_FECCodeSpecification" title="FEC Code Spe <name slugifiedName="name-fec-code-specification">FEC Code Specification</
cification"> name>
<!-- ================ --> <section anchor="ArbitraryFlows_FECCodeSpecification_encoding" numbered="t
rue" toc="include" removeInRFC="false" pn="section-6.1">
<section anchor="ArbitraryFlows_FECCodeSpecification_encoding" ti <name slugifiedName="name-encoding-side">Encoding Side</name>
tle="Encoding Side"> <t pn="section-6.1-1">
<!-- ================ -->
<t>
This section provides a high level description of a Sliding Window RLC encoder. This section provides a high level description of a Sliding Window RLC encoder.
</t> </t>
<t pn="section-6.1-2">
<t>
Whenever a new FEC Repair Packet is needed, the RLC encoder instance first gathe rs the ew_size source symbols currently in the sliding encoding window. Whenever a new FEC Repair Packet is needed, the RLC encoder instance first gathe rs the ew_size source symbols currently in the sliding encoding window.
Then it chooses a repair key, which can be a monotonically increasing integer va lue, incremented for each repair symbol up to a maximum Then it chooses a repair key, which can be a monotonically increasing integer va lue, incremented for each repair symbol up to a maximum
value of 65535 (as it is carried within a 16-bit field) after which it loops bac k to 0. value of 65535 (as it is carried within a 16-bit field) after which it loops bac k to 0.
This repair key is communicated to the coefficient generation function (<xref ta rget="CommonProc_coef_generation_func"/>) in order to generate This repair key is communicated to the coefficient generation function (<xref ta rget="CommonProc_coef_generation_func" format="default" sectionFormat="of" deriv edContent="Section 3.6"/>) in order to generate
ew_size coding coefficients. ew_size coding coefficients.
Finally, the FECFRAME sender computes the repair symbol as a linear combination of the ew_size source symbols using the ew_size coding coefficients Finally, the FECFRAME sender computes the repair symbol as a linear combination of the ew_size source symbols using the ew_size coding coefficients
(<xref target="CommonProc_gf_specificiation"/>). (<xref target="CommonProc_gf_specificiation" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
When E is small and when there is an incentive to pack several repair symbols wi thin the same FEC Repair Packet, the appropriate number of repair symbols When E is small and when there is an incentive to pack several repair symbols wi thin the same FEC Repair Packet, the appropriate number of repair symbols
are computed. are computed.
In that case the repair key for each of them MUST be incremented by 1, keeping t he same ew_size source symbols, since only the first repair key will In that case the repair key for each of them <bcp14>MUST</bcp14> be incremented by 1, keeping the same ew_size source symbols, since only the first repair key w ill
be carried in the Repair FEC Payload ID. be carried in the Repair FEC Payload ID.
The FEC Repair Packet can then be passed to the transport layer for transmission . The FEC Repair Packet can then be passed to the transport layer for transmission .
The source versus repair FEC packet transmission order is out of scope of this d ocument and several approaches exist that are implementation-specific. The source versus repair FEC packet transmission order is out of scope of this d ocument and several approaches exist that are implementation-specific.
</t> </t>
<t> <t pn="section-6.1-3">
Other solutions are possible to select a repair key value when a new FEC Repair Packet is needed, for instance, by choosing a random integer between 0 and 65535 . Other solutions are possible to select a repair key value when a new FEC Repair Packet is needed, for instance, by choosing a random integer between 0 and 65535 .
However, selecting the same repair key as before (which may happen in case of a random process) is only meaningful if the encoding window has changed, However, selecting the same repair key as before (which may happen in case of a random process) is only meaningful if the encoding window has changed,
otherwise the same FEC Repair Packet will be generated. otherwise the same FEC Repair Packet will be generated.
In any case, choosing the repair key is entirely at the discretion of the sender , since it is communicated to the receiver(s) in each Repair FEC Payload ID. A r eceiver should not make any assumption on the way the repair key is managed. In any case, choosing the repair key is entirely at the discretion of the sender , since it is communicated to the receiver(s) in each Repair FEC Payload ID. A r eceiver should not make any assumption on the way the repair key is managed.
</t> </t>
</section> </section>
<section anchor="ArbitraryFlows_FECCodeSpecification_decoding" numbered="t
<section anchor="ArbitraryFlows_FECCodeSpecification_decoding" ti rue" toc="include" removeInRFC="false" pn="section-6.2">
tle="Decoding Side"> <name slugifiedName="name-decoding-side">Decoding Side</name>
<!-- ================ --> <t pn="section-6.2-1">
<t>
This section provides a high level description of a Sliding Window RLC decoder. This section provides a high level description of a Sliding Window RLC decoder.
</t> </t>
<t pn="section-6.2-2">
<t>
A FECFRAME receiver needs to maintain a linear system whose variables are the re ceived and lost source symbols. A FECFRAME receiver needs to maintain a linear system whose variables are the re ceived and lost source symbols.
Upon receiving a FEC Repair Packet, a receiver first extracts all the repair sym bols it contains (in case several repair symbols are packed together). Upon receiving a FEC Repair Packet, a receiver first extracts all the repair sym bols it contains (in case several repair symbols are packed together).
For each repair symbol, when at least one of the corresponding source symbols it protects has been lost, the receiver adds an equation to the linear system For each repair symbol, when at least one of the corresponding source symbols it protects has been lost, the receiver adds an equation to the linear system
(or no equation if this repair packet does not change the linear system rank). (or no equation if this repair packet does not change the linear system rank).
This equation of course re-uses the ew_size coding coefficients that are compute d by the same coefficient generation function This equation of course re-uses the ew_size coding coefficients that are compute d by the same coefficient generation function
(<xref target="CommonProc_coef_generation_func"/>), using the repair key and enc (<xref target="CommonProc_coef_generation_func" format="default" sectionFormat="
oding window descriptions carried in the Repair FEC Payload ID. of" derivedContent="Section 3.6"/>), using the repair key and encoding window de
Whenever possible (i.e., when a sub-system covering one or more lost source symb scriptions carried in the Repair FEC Payload ID.
ols is of full rank), decoding is performed in order to recover Whenever possible (i.e., when a sub-system covering one or more lost source
lost source symbols. symbols is of full rank), decoding is performed in order to recover lost
Gaussian elimination is one possible algorithm to solve this linear system. source symbols. Gaussian elimination is one possible algorithm to solve this
Each time an ADUI can be totally recovered, padding is removed (thanks to the Le linear system. Each time an ADUI can be totally recovered, padding is removed
ngth field, L, of the ADUI) and the ADU is assigned to the corresponding (thanks to the Length field, L, of the ADUI) and the ADU is assigned to the
application flow (thanks to the Flow ID field, F, of the ADUI). corresponding application flow (thanks to the Flow ID field, F, of the ADUI).
This ADU is finally passed to the corresponding upper application. This ADU is finally passed to the corresponding upper application. Received
Received FEC Source Packets, containing an ADU, MAY be passed to the application FEC Source Packets, containing an ADU, <bcp14>MAY</bcp14> be passed to the
either immediately or after some time to guaranty an ordered delivery to application either immediately or after some time to guaranty an ordered
the application. delivery to the application. This document does not mandate any approach as
This document does not mandate any approach as this is an operational and manage this is an operational and management decision.
ment decision.
</t> </t>
<t pn="section-6.2-3">
<t>
With real-time flows, a lost ADU that is decoded after the maximum latency or an ADU received after this delay has no value to the application. With real-time flows, a lost ADU that is decoded after the maximum latency or an ADU received after this delay has no value to the application.
This raises the question of deciding whether or not an ADU is late. This raises the question of deciding whether or not an ADU is late.
This decision MAY be taken within the FECFRAME receiver (e.g., using the decodin g window, see <xref target="CommonProc_rlcParameters"/>) This decision <bcp14>MAY</bcp14> be taken within the FECFRAME receiver (e.g., us ing the decoding window, see <xref target="CommonProc_rlcParameters" format="def ault" sectionFormat="of" derivedContent="Section 3.1"/>)
or within the application (e.g., using RTP timestamps within the ADU). or within the application (e.g., using RTP timestamps within the ADU).
Deciding which option to follow and whether or not to pass all ADUs, including t hose assumed late, to the application are operational decisions that depend Deciding which option to follow and whether or not to pass all ADUs, including t hose assumed late, to the application are operational decisions that depend
on the application and are therefore out of scope of this document. on the application and are therefore out of scope of this document.
Additionally, <xref target="decodingBeyondMaxLatency"/> discusses a backward com patible optimization whereby late source symbols MAY still be used within Additionally, <xref target="decodingBeyondMaxLatency" format="default" sectionFo rmat="of" derivedContent="Appendix D"/> discusses a backward compatible optimiza tion whereby late source symbols <bcp14>MAY</bcp14> still be used within
the FECFRAME receiver in order to improve transmission robustness. the FECFRAME receiver in order to improve transmission robustness.
</t> </t>
</section>
</section> </section>
<section anchor="SecurityConsiderations" numbered="true" toc="include" remov
</section> eInRFC="false" pn="section-7">
<name slugifiedName="name-security-considerations">Security Considerations
<section anchor="implementationStatus" title="Implementation Status"> </name>
<!-- ====================== --> <t pn="section-7-1">
The FEC Framework document <xref target="RFC6363" format="default" sectionFormat
<t> ="of" derivedContent="RFC6363"/> provides a fairly comprehensive
Editor's notes: RFC Editor, please remove this section motivated by RFC 6982 bef analysis of security considerations applicable to FEC schemes.
ore publishing the RFC. Thanks.
</t>
<t>An implementation of the Sliding Window RLC FEC Scheme for FECFRAME exists:
<list style="symbols">
<t>Organisation: Inria</t>
<t>Description: This is an implementation of the Sliding Window RLC FEC S
cheme limited to GF(2^^8).
It relies on a modified version of our OpenFEC (http://openfec.org) FEC c
ode library.
It is integrated in our FECFRAME software (see <xref target="fecframe-ext
"/>).</t>
<t>Maturity: prototype.</t>
<t>Coverage: this software complies with the Sliding Window RLC FEC Schem
e.</t>
<t>Licensing: proprietary.</t>
<t>Contact: vincent.roca@inria.fr</t>
</list></t>
</section>
<!-- ===========================================================================
================ -->
<section anchor="SecurityConsiderations" title="Security Considerations">
<!-- ====================== -->
<t>
The FEC Framework document <xref target="RFC6363"/> provides a fairly comprehens
ive
analysis of security considerations applicable to FEC Schemes.
Therefore, the present section follows the security considerations section of Therefore, the present section follows the security considerations section of
<xref target="RFC6363"/> and only discusses specific topics. <xref target="RFC6363" format="default" sectionFormat="of" derivedContent="RFC63 63"/> and only discusses specific topics.
</t> </t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7.1
<section title="Attacks Against the Data Flow"> ">
<!-- ====================== --> <name slugifiedName="name-attacks-against-the-data-fl">Attacks Against t
he Data Flow</name>
<section title="Access to Confidential Content"> <section numbered="true" toc="include" removeInRFC="false" pn="section-7
<!-- ====================== --> .1.1">
<name slugifiedName="name-access-to-confidential-cont">Access to Confi
<t>The Sliding Window RLC FEC Scheme specified in this document does not change dential Content</name>
the <t pn="section-7.1.1-1">The Sliding Window RLC FEC scheme specified in
recommendations of <xref target="RFC6363"/>. this document does not change the
To summarize, if confidentiality is a concern, it is RECOMMENDED that one of the recommendations of <xref target="RFC6363" format="default" sectionFormat="of" de
solutions mentioned in <xref target="RFC6363"/> is used with special rivedContent="RFC6363"/>.
To summarize, if confidentiality is a concern, it is <bcp14>RECOMMENDED</bcp14>
that one of the
solutions mentioned in <xref target="RFC6363" format="default" sectionFormat="of
" derivedContent="RFC6363"/> is used with special
considerations to the way this solution is applied (e.g., is encryption applied considerations to the way this solution is applied (e.g., is encryption applied
before or after FEC protection, within the end-system or in a middlebox), to the operational before or after FEC protection, within the end system or in a middlebox), to the operational
constraints (e.g., performing FEC decoding in a protected environment may be constraints (e.g., performing FEC decoding in a protected environment may be
complicated or even impossible) and to the threat model. complicated or even impossible) and to the threat model.
</t> </t>
</section>
</section> <section anchor="sec_content_corruption" numbered="true" toc="include" r
emoveInRFC="false" pn="section-7.1.2">
<section title="Content Corruption" anchor="sec_content_c <name slugifiedName="name-content-corruption">Content Corruption</name
orruption"> >
<!-- ====================== --> <t pn="section-7.1.2-1">The Sliding Window RLC FEC scheme specified in
this document does not change the
<t>The Sliding Window RLC FEC Scheme specified in this document does not change recommendations of <xref target="RFC6363" format="default" sectionFormat="of" de
the rivedContent="RFC6363"/>.
recommendations of <xref target="RFC6363"/>. To summarize, it is <bcp14>RECOMMENDED</bcp14> that one of the solutions mention
To summarize, it is RECOMMENDED that one of the solutions mentioned in ed in
<xref target="RFC6363"/> is used on both the FEC Source and Repair Packets. <xref target="RFC6363" format="default" sectionFormat="of" derivedContent="RFC63
63"/> is used on both the FEC Source and Repair Packets.
</t> </t>
</section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7.2
</section> ">
<name slugifiedName="name-attacks-against-the-fec-par">Attacks Against t
<section title="Attacks Against the FEC Parameters"> he FEC Parameters</name>
<!-- ====================== --> <t pn="section-7.2-1">
The FEC scheme specified in this document defines parameters that
<t>
The FEC Scheme specified in this document defines parameters that
can be the basis of attacks. can be the basis of attacks.
More specifically, the following parameters of the FFCI may be modified More specifically, the following parameters of the FFCI may be modified
by an attacker who targets receivers (<xref target="ArbitraryFlows_fssi"/>): by an attacker who targets receivers (<xref target="ArbitraryFlows_fssi" format=
<list style="symbols"> "default" sectionFormat="of" derivedContent="Section 4.1.1.2"/>):
<t>FEC Encoding ID: </t>
changing this parameter leads a receiver to consider a different <dl newline="false" spacing="normal" pn="section-7.2-2">
FEC Scheme. <dt pn="section-7.2-2.1">FEC Encoding ID:</dt>
<dd pn="section-7.2-2.2">changing this parameter leads a receiver to c
onsider a different FEC scheme.
The consequences are severe, the format of the Explicit Source FE C Payload ID The consequences are severe, the format of the Explicit Source FE C Payload ID
and Repair FEC Payload ID of received packets will probably diffe r, leading to and Repair FEC Payload ID of received packets will probably diffe r, leading to
various malfunctions. various malfunctions.
Even if the original and modified FEC Schemes share the same form at, FEC decoding Even if the original and modified FEC schemes share the same form at, FEC decoding
will either fail or lead to corrupted decoded symbols. will either fail or lead to corrupted decoded symbols.
This will happen if an attacker turns value YYYY (i.e., RLC over GF(2)) to value XXXX (RLC over GF(2^^8)), This will happen if an attacker turns value 9 (i.e., RLC over GF( 2)) to value 10 (RLC over GF(2<sup>8</sup>)),
an additional consequence being a higher processing overhead at t he receiver. an additional consequence being a higher processing overhead at t he receiver.
In any case, the attack results in a form of Denial of Service (D oS) or corrupted content. In any case, the attack results in a form of Denial of Service (D oS) or corrupted content.
</t> </dd>
<t>Encoding symbol length (E): <dt pn="section-7.2-2.3">Encoding symbol length (E):</dt>
setting this E parameter to a different value will confuse a rece <dd pn="section-7.2-2.4">setting this E parameter to a different value
iver. will confuse a receiver.
If the size of a received FEC Repair Packet is no longer multiple of the modified E value, If the size of a received FEC Repair Packet is no longer multiple of the modified E value,
a receiver quickly detects a problem and SHOULD reject the packet . a receiver quickly detects a problem and <bcp14>SHOULD</bcp14> re ject the packet.
If the new E value is a sub-multiple of the original E value (e.g ., half the original value), If the new E value is a sub-multiple of the original E value (e.g ., half the original value),
then receivers may not detect the problem immediately. then receivers may not detect the problem immediately.
For instance, a receiver may think that a received FEC Repair Pac ket contains more repair symbols For instance, a receiver may think that a received FEC Repair Pac ket contains more repair symbols
(e.g., twice as many if E is reduced by half), leading to malfunc tions whose nature depends on (e.g., twice as many if E is reduced by half), leading to malfunc tions whose nature depends on
implementation details. implementation details.
Here also, the attack always results in a form of DoS or corrupte d content. Here also, the attack always results in a form of DoS or corrupte d content.
</t> </dd>
</list> </dl>
</t> <t pn="section-7.2-3">
It is therefore <bcp14>RECOMMENDED</bcp14> that security measures be taken to
<t> guarantee the FFCI integrity, as specified in <xref target="RFC6363" format="def
It is therefore RECOMMENDED that security measures be taken to ault" sectionFormat="of" derivedContent="RFC6363"/>.
guarantee the FFCI integrity, as specified in <xref target="RFC6363"/>.
How to achieve this depends on the way the FFCI is communicated from the sender How to achieve this depends on the way the FFCI is communicated from the sender
to the receiver, which is not specified in this document. to the receiver, which is not specified in this document.
</t> </t>
<t pn="section-7.2-4">
<t>
Similarly, attacks are possible against the Explicit Source FEC Payload ID Similarly, attacks are possible against the Explicit Source FEC Payload ID
and Repair FEC Payload ID. and Repair FEC Payload ID.
More specifically, in case of a FEC Source Packet, the following value can be mo dified by an attacker who targets receivers: More specifically, in case of a FEC Source Packet, the following value can be mo dified by an attacker who targets receivers:
<list style="symbols"> </t>
<t>Encoding Symbol ID (ESI): <dl newline="false" spacing="normal" pn="section-7.2-5">
changing the ESI leads a receiver to consider a wrong ADU, result <dt pn="section-7.2-5.1">Encoding Symbol ID (ESI):</dt>
ing in severe consequences, including <dd pn="section-7.2-5.2">changing the ESI leads a receiver to consider
a wrong ADU, resulting in severe consequences, including
corrupted content passed to the receiving application; corrupted content passed to the receiving application;
</t> </dd>
</list> </dl>
<t pn="section-7.2-6">
And in case of a FEC Repair Packet: And in case of a FEC Repair Packet:
<list style="symbols"> </t>
<t>Repair Key: <dl newline="false" spacing="normal" pn="section-7.2-7">
changing this value leads a receiver to generate a wrong coding c <dt pn="section-7.2-7.1">Repair Key:</dt>
oefficient sequence, and therefore <dd pn="section-7.2-7.2">changing this value leads a receiver to gener
ate a wrong coding coefficient sequence, and therefore
any source symbol decoded using the repair symbols contained in t his packet will be corrupted; any source symbol decoded using the repair symbols contained in t his packet will be corrupted;
</t> </dd>
<t>DT: <dt pn="section-7.2-7.3">DT:</dt>
changing this value also leads a receiver to generate a wrong cod <dd pn="section-7.2-7.4">changing this value also leads a receiver to
ing coefficient sequence, and therefore generate a wrong coding coefficient sequence, and therefore
any source symbol decoded using the repair symbols contained in t his packet will be corrupted. any source symbol decoded using the repair symbols contained in t his packet will be corrupted.
In addition, if the DT value is significantly increased, it will generate a higher processing overhead at a receiver. In addition, if the DT value is significantly increased, it will generate a higher processing overhead at a receiver.
In case of very large encoding windows, this may impact the termi nal performance; In case of very large encoding windows, this may impact the termi nal performance;
</t> </dd>
<t>NSS: <dt pn="section-7.2-7.5">NSS:</dt>
changing this value leads a receiver to consider a different set <dd pn="section-7.2-7.6">changing this value leads a receiver to consi
of source symbols, and therefore der a different set of source symbols, and therefore
any source symbol decoded using the repair symbols contained in t his packet will be corrupted. any source symbol decoded using the repair symbols contained in t his packet will be corrupted.
In addition, if the NSS value is significantly increased, it will generate a higher processing overhead at a receiver, In addition, if the NSS value is significantly increased, it will generate a higher processing overhead at a receiver,
which may impact the terminal performance; which may impact the terminal performance;
</t> </dd>
<t>FSS_ESI: <dt pn="section-7.2-7.7">FSS_ESI:</dt>
changing this value also leads a receiver to consider a different <dd pn="section-7.2-7.8">changing this value also leads a receiver to
set of source symbols and therefore consider a different set of source symbols and therefore
any source symbol decoded using the repair symbols contained in t his packet will be corrupted. any source symbol decoded using the repair symbols contained in t his packet will be corrupted.
</t> </dd>
</list> </dl>
It is therefore RECOMMENDED that security measures are taken to guarantee the <t pn="section-7.2-8">
FEC Source and Repair Packets as stated in <xref target="RFC6363"/>. It is therefore <bcp14>RECOMMENDED</bcp14> that security measures are taken to g
uarantee the
FEC Source and Repair Packets as stated in <xref target="RFC6363" format="defaul
t" sectionFormat="of" derivedContent="RFC6363"/>.
</t> </t>
</section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3
">
<section title="When Several Source Flows are to be Protected Tog <name slugifiedName="name-when-several-source-flows-a">When Several Sour
ether"> ce Flows are to be Protected Together</name>
<!-- ====================== --> <t pn="section-7.3-1">The Sliding Window RLC FEC scheme specified in thi
s document does not change the
<t>The Sliding Window RLC FEC Scheme specified in this document does not change recommendations of <xref target="RFC6363" format="default" sectionFormat="of" de
the rivedContent="RFC6363"/>.</t>
recommendations of <xref target="RFC6363"/>.</t> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7.4
</section> ">
<name slugifiedName="name-baseline-secure-fec-framewo">Baseline Secure F
<section title="Baseline Secure FEC Framework Operation"> EC Framework Operation</name>
<!-- ====================== --> <t pn="section-7.4-1">The Sliding Window RLC FEC scheme specified in thi
s document does not change the
<t>The Sliding Window RLC FEC Scheme specified in this document does not change recommendations of <xref target="RFC6363" format="default" sectionFormat="of" de
the rivedContent="RFC6363"/> concerning the use of
recommendations of <xref target="RFC6363"/> concerning the use of the IPsec/Encapsulating Security Payload (ESP) security protocol as a mandatory-
the IPsec/ESP security protocol as a mandatory to implement (but not mandatory to-implement (but not mandatory-to-use) security scheme.
to use) security scheme.
This is well suited to situations where the only insecure domain is the one This is well suited to situations where the only insecure domain is the one
over which the FEC Framework operates. over which the FEC Framework operates.
</t> </t>
</section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-7.5
">
<section title="Additional Security Considerations for Numerical <name slugifiedName="name-additional-security-conside">Additional Securi
Computations"> ty Considerations for Numerical Computations</name>
<!-- ====================== --> <t pn="section-7.5-1">
In addition to the above security considerations, inherited from <xref target="R
<t> FC6363" format="default" sectionFormat="of" derivedContent="RFC6363"/>,
In addition to the above security considerations, inherited from <xref target="R the present document introduces several formulae, in particular in <xref target=
FC6363"/>, "param_derivation_cbr_realtime" format="default" sectionFormat="of" derivedConte
the present document introduces several formulae, in particular in <xref target= nt="Appendix C.1"/>.
"param_derivation_cbr_realtime"/>. It is <bcp14>RECOMMENDED</bcp14> to check that the computed values stay within r
It is RECOMMENDED to check that the computed values stay within reasonable bound easonable bounds since numerical overflows,
s since numerical overflows, caused by an erroneous implementation or an erroneous input value, may lead to h
caused by an erroneous implementation or an erroneous input value, may lead to h azardous behaviors.
azardous behaviours.
However, what "reasonable bounds" means is use-case and implementation dependent and is not detailed in this document. However, what "reasonable bounds" means is use-case and implementation dependent and is not detailed in this document.
</t> </t>
<t> <t pn="section-7.5-2"><xref target="param_derivation_other_realtime_flow
<xref target="param_derivation_other_realtime_flows"/> also mentions the possibi s" format="default" sectionFormat="of" derivedContent="Appendix C.2"/> also ment
lity of "using the ions the possibility of "using the
timestamp field of an RTP packet header" when applicable. timestamp field of an RTP packet header" when applicable.
A malicious attacker may deliberately corrupt this header field in order to trig ger hazardous behaviours at a FECFRAME receiver. A malicious attacker may deliberately corrupt this header field in order to trig ger hazardous behaviors at a FECFRAME receiver.
Protection against this type of content corruption can be addressed with the abo ve recommendations on a baseline secure operation. Protection against this type of content corruption can be addressed with the abo ve recommendations on a baseline secure operation.
In addition, it is also RECOMMENDED to check that the timestamp value be within reasonable bounds. In addition, it is also <bcp14>RECOMMENDED</bcp14> to check that the timestamp v alue be within reasonable bounds.
</t> </t>
</section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-8">
</section> <name slugifiedName="name-operations-and-management-c">Operations and Mana
gement Considerations</name>
<section title="Operations and Management Considerations"> <t pn="section-8-1">
<!-- ====================== --> The FEC Framework document <xref target="RFC6363" format="default" sectionFormat
="of" derivedContent="RFC6363"/> provides a fairly comprehensive
<t> analysis of operations and management considerations applicable to FEC schemes.
The FEC Framework document <xref target="RFC6363"/> provides a fairly comprehens
ive
analysis of operations and management considerations applicable to FEC Schemes.
Therefore, the present section only discusses specific topics. Therefore, the present section only discusses specific topics.
</t> </t>
<section anchor="oprecom_ff_considerations" numbered="true" toc="include"
<section anchor="oprecom_ff_considerations" title="Operational Re removeInRFC="false" pn="section-8.1">
commendations: Finite Field GF(2) Versus GF(2^^8)"> <name slugifiedName="name-operational-recommendations">Operational Recom
<!-- ================ --> mendations: Finite Field GF(2) Versus GF(2<sup>8</sup>)</name>
<t pn="section-8.1-1">
<t> The present document specifies two FEC schemes that differ on the Finite Field u
The present document specifies two FEC Schemes that differ on the Finite Field u sed for the coding coefficients.
sed for the coding coefficients. It is expected that the RLC over GF(2<sup>8</sup>) FEC scheme will be mostly use
It is expected that the RLC over GF(2^^8) FEC Scheme will be mostly used since i d since it warrants a higher packet loss protection.
t warrants a higher packet loss protection.
In case of small encoding windows, the associated processing overhead is not an issue (e.g., we measured decoding speeds between In case of small encoding windows, the associated processing overhead is not an issue (e.g., we measured decoding speeds between
745 Mbps and 2.8 Gbps on an ARM Cortex-A15 embedded board in <xref target="Roca1 745 Mbps and 2.8 Gbps on an ARM Cortex-A15 embedded board in <xref target="Roca1
7"/> depending on the code rate and the channel conditions, using an encoding wi 7" format="default" sectionFormat="of" derivedContent="Roca17"/> depending on th
ndow of size 18 or 23 symbols; see the above article for the details). e code rate and the channel conditions, using an encoding window of size 18 or 2
Of course the CPU overhead will increase with the encoding window size, because 3 symbols; see the above article for the details).
more operations in the GF(2^^8) finite field will Of course the CPU overhead will increase with the encoding window size, because
more operations in the GF(2<sup>8</sup>) finite field will
be needed. be needed.
</t> </t>
<t pn="section-8.1-2">
<t> The RLC over GF(2) FEC scheme offers an alternative.
The RLC over GF(2) FEC Scheme offers an alternative.
In that case operations symbols can be directly XOR-ed together which warrants h igh bitrate encoding and decoding operations, and In that case operations symbols can be directly XOR-ed together which warrants h igh bitrate encoding and decoding operations, and
can be an advantage with large encoding windows. can be an advantage with large encoding windows.
However, packet loss protection is significantly reduced by using this FEC Schem e. However, packet loss protection is significantly reduced by using this FEC schem e.
</t> </t>
</section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-8.2
">
<section title="Operational Recommendations: Coding Coefficients <name slugifiedName="name-operational-recommendations-">Operational Reco
Density Threshold"> mmendations: Coding Coefficients Density Threshold</name>
<!-- ================ --> <t pn="section-8.2-1">
In addition to the choice of the Finite Field, the two FEC schemes define a codi
<t> ng coefficient density threshold (DT) parameter.
In addition to the choice of the Finite Field, the two FEC Schemes define a codi This parameter enables a sender to control the code density, i.e., the proportio
ng coefficient density threshold (DT) parameter. n of coefficients that are nonzero on average.
This parameter enables a sender to control the code density, i.e., the proportio With RLC over GF(2<sup>8</sup>), it is usually appropriate that small encoding w
n of coefficients that are non zero on average. indows be associated to a density threshold equal to 15,
With RLC over GF(2^^8), it is usually appropriate that small encoding windows be
associated to a density threshold equal to 15,
the maximum value, in order to warrant a high loss protection. the maximum value, in order to warrant a high loss protection.
</t> </t>
<t pn="section-8.2-2">
<t>
On the opposite, with larger encoding windows, it is usually appropriate that th e density threshold be reduced. On the opposite, with larger encoding windows, it is usually appropriate that th e density threshold be reduced.
With large encoding windows, an alternative can be to use RLC over GF(2) and a d ensity threshold equal to 7 (i.e., an average density equal to 1/2) or smaller. With large encoding windows, an alternative can be to use RLC over GF(2) and a d ensity threshold equal to 7 (i.e., an average density equal to 1/2) or smaller.
</t> </t>
<t pn="section-8.2-3">
<t>
Note that using a density threshold equal to 15 with RLC over GF(2) is equivalen t to using an XOR code that computes the XOR sum of all the source symbols in th e encoding window. Note that using a density threshold equal to 15 with RLC over GF(2) is equivalen t to using an XOR code that computes the XOR sum of all the source symbols in th e encoding window.
In that case: (1) only a single repair symbol can be produced for any encoding w indow, and (2) the repair_key parameter becomes useless (the coding coefficients generation function does not rely on the PRNG). In that case: (1) only a single repair symbol can be produced for any encoding w indow, and (2) the repair_key parameter becomes useless (the coding coefficients generation function does not rely on the PRNG).
</t> </t>
</section>
</section> </section>
<section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn=
</section> "section-9">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section anchor="iana" title="IANA Considerations"> <t pn="section-9-1">
<!-- ====================== -->
<t>
This document registers two values in the "FEC Framework (FECFRAME) This document registers two values in the "FEC Framework (FECFRAME)
FEC Encoding IDs" registry <xref target="RFC6363"/> as follows: FEC Encoding IDs" registry <xref target="RFC6363" format="default" sectionFormat
<list style="symbols"> ="of" derivedContent="RFC6363"/> as follows:
<t>YYYY refers to the Sliding Window Random Linear Codes (RLC) over GF(2
) FEC Scheme for Arbitrary Packet Flows, as defined in <xref target="ArbitraryFl
ows_RLC_GF_2"/> of this document.</t>
<t>XXXX refers to the Sliding Window Random Linear Codes (RLC) over GF(2
^^8) FEC Scheme for Arbitrary Packet Flows, as defined in <xref target="Arbitrar
yFlows_RLC_GF_28"/> of this document.</t>
</list>
</t>
</section>
<section title="Acknowledgments">
<!-- ====================== -->
<t>
The authors would like to thank the three TSVWG chairs, Wesley Eddy, our shepher
d, David Black and Gorry Fairhurst, as well as Spencer Dawkins, our responsible
AD,
and all those who provided comments, namely (alphabetical order) Alan DeKok, Jon
athan Detchart, Russ Housley, Emmanuel Lochin, Marie-Jose Montpetit, and Greg Sk
inner.
Last but not least, the authors are really grateful to the IESG members, in part
icular Benjamin Kaduk, Mirja Kuhlewind, Eric Rescorla, Adam Roach, and Roman Dan
yliw for their highly valuable feedbacks that greatly contributed to improve thi
s specification.
</t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-9-2">
</section> <li pn="section-9-2.1">9 refers to the Sliding Window Random Linear Code
s (RLC) over GF(2) FEC Scheme for Arbitrary Packet Flows, as defined in <xref ta
</middle> rget="ArbitraryFlows_RLC_GF_2" format="default" sectionFormat="of" derivedConten
t="Section 5"/> of this document.</li>
<back> <li pn="section-9-2.2">10 refers to the Sliding Window Random Linear Cod
<references title="Normative References"> es (RLC) over GF(2<sup>8</sup>) FEC Scheme for Arbitrary Packet Flows, as define
<!-- ====================== --> d in <xref target="ArbitraryFlows_RLC_GF_28" format="default" sectionFormat="of"
&rfc2119; derivedContent="Section 4"/> of this document.</li>
&rfc8174; </ul>
</section>
&rfc6363; </middle>
&rfc6364; <back>
<references pn="section-10">
<reference anchor="fecframe-ext" target="https://tools.ietf.org/html/draf <name slugifiedName="name-references">References</name>
t-ietf-tsvwg-fecframe-ext"> <references pn="section-10.1">
<front> <name slugifiedName="name-normative-references">Normative References</na
<title>Forward Error Correction (FEC) Framework Extension me>
to Sliding Window Codes</title> <reference anchor="C99" quoteTitle="true" derivedAnchor="C99">
<author initials='V.' surname='Roca'> <organization /> < <front>
/author> <title>Programming languages - C: C99, correction 3:2007</title>
<author initials='A.' surname='Begen'> <organization /> < <seriesInfo name="ISO/IEC" value="9899:1999/Cor 3:2007"/>
/author> <author>
<date month="January" year="2019" /> <organization showOnFrontPage="true">International Organization fo
</front> r Standardization</organization>
<seriesInfo name='Transport Area Working Group (TSVWG)' value='dr </author>
aft-ietf-tsvwg-fecframe-ext (Work in Progress)' /> <date month="November" year="2007"/>
</reference> </front>
</reference>
<reference anchor="tinymt32" target="https://tools.ietf.org/html/draft-ro <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
ca-tsvwg-tinymt32"> 119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>TinyMT32 Pseudo Random Number Generator (PRNG)</ti <title>Key words for use in RFCs to Indicate Requirement Levels</tit
tle> le>
<author initials="M" surname="Saito"> <organization /> < <author initials="S." surname="Bradner" fullname="S. Bradner">
/author> <organization showOnFrontPage="true"/>
<author initials="M" surname="Matsumoto"> <organization </author>
/> </author> <date year="1997" month="March"/>
<author initials="V." surname="Roca"> <organization /> < <abstract>
/author> <t>In many standards track documents several words are used to sig
<author initials="E" surname="Baccelli"> <organization / nify the requirements in the specification. These words are often capitalized.
> </author> This document defines these words as they should be interpreted in IETF document
<date month="February" year="2019" /> s. This document specifies an Internet Best Current Practices for the Internet
</front> Community, and requests discussion and suggestions for improvements.</t>
<seriesInfo name='Transport Area Working Group (TSVWG)' value='dr </abstract>
aft-roca-tsvwg-tinymt32 (Work in Progress)' /> </front>
</reference> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<reference anchor="C99"> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<front> </reference>
<title>Programming languages - C: C99, correction 3:2007</title> <reference anchor="RFC6363" target="https://www.rfc-editor.org/info/rfc6
<author /> 363" quoteTitle="true" derivedAnchor="RFC6363">
<date month="November" year="2007" /> <front>
</front> <title>Forward Error Correction (FEC) Framework</title>
<seriesInfo name="International Organization for Standardization," value <author initials="M." surname="Watson" fullname="M. Watson">
="ISO/IEC 9899:1999/Cor 3:2007" /> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="A." surname="Begen" fullname="A. Begen">
</references> <organization showOnFrontPage="true"/>
</author>
<references title="Informative References"> <author initials="V." surname="Roca" fullname="V. Roca">
<!-- ====================== --> <organization showOnFrontPage="true"/>
</author>
&rfc5170; <date year="2011" month="October"/>
&rfc5510; <abstract>
&rfc6726; <t>This document describes a framework for using Forward Error Cor
&rfc6681; <!-- raptor(Q) for ff --> rection (FEC) codes with applications in public and private IP networks to provi
&rfc6816; <!-- ldpc-staircase for ff --> de protection against packet loss. The framework supports applying FEC to arbit
&rfc6865; <!-- r-s for ff --> rary packet flows over unreliable transport and is primarily intended for real-t
&rfc8406; 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.
<reference anchor="Roca16" target="https://hal.inria.fr/hal-01395937/en/" Content Delivery Protocols defined using this framework can support any FEC sch
> eme (and associated FEC codes) that is compliant with various requirements defin
<front> ed in this document. Thus, Content Delivery Protocols can be defined that are no
<title>Block or Convolutional AL-FEC Codes? A Performance t specific to a particular FEC scheme, and FEC schemes can be defined that are n
Comparison for Robust Low-Latency Communications</title> ot specific to a particular Content Delivery Protocol. [STANDARDS-TRACK]</t>
<author initials='V.' surname='Roca'> <organization /> < </abstract>
/author> </front>
<author initials='B.' surname='Teibi'> <organization /> <seriesInfo name="RFC" value="6363"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC6363"/>
<author initials='C.' surname='Burdinat'> <organization </reference>
/> </author> <reference anchor="RFC6364" target="https://www.rfc-editor.org/info/rfc6
<author initials='T.' surname='Tran'> <organization /> < 364" quoteTitle="true" derivedAnchor="RFC6364">
/author> <front>
<author initials='C.' surname='Thienot'> <organization / <title>Session Description Protocol Elements for the Forward Error C
> </author> orrection (FEC) Framework</title>
<date month="November" year="2016" /> <author initials="A." surname="Begen" fullname="A. Begen">
</front> <organization showOnFrontPage="true"/>
<seriesInfo name='HAL open-archive document,hal-01395937' value=' </author>
https://hal.inria.fr/hal-01395937/en/' /> <date year="2011" month="October"/>
</reference> <abstract>
<t>This document specifies the use of the Session Description Prot
<reference anchor="Roca17" target="https://hal.inria.fr/hal-01571609v1/en ocol (SDP) to describe the parameters required to signal the Forward Error Corre
/"> ction (FEC) Framework Configuration Information between the sender(s) and receiv
<front> er(s). This document also provides examples that show the semantics for groupin
<title>Less Latency and Better Protection with AL-FEC Sli g multiple source and repair flows together for the applications that simultaneo
ding Window Codes: a Robust Multimedia CBR Broadcast Case Study</title> usly use multiple instances of the FEC Framework. [STANDARDS-TRACK]</t>
<author initials='V.' surname='Roca'> <organization /> < </abstract>
/author> </front>
<author initials='B.' surname='Teibi'> <organization /> <seriesInfo name="RFC" value="6364"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC6364"/>
<author initials='C.' surname='Burdinat'> <organization </reference>
/> </author> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
<author initials='T.' surname='Tran'> <organization /> < 174" quoteTitle="true" derivedAnchor="RFC8174">
/author> <front>
<author initials='C.' surname='Thienot'> <organization / <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
> </author> tle>
<date month="October" year="2017" /> <author initials="B." surname="Leiba" fullname="B. Leiba">
</front> <organization showOnFrontPage="true"/>
<seriesInfo name='13th IEEE International Conference on Wireless </author>
and Mobile Computing, Networking and Communications (WiMob17), October 2017' val <date year="2017" month="May"/>
ue='https://hal.inria.fr/hal-01571609v1/en/' /> <abstract>
</reference> <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
<reference anchor="PGM13" target="http://web.eecs.utk.edu/~plank/plank/pap t only UPPERCASE usage of the key words have the defined special meanings.</t>
ers/UT-CS-13-717.html"> </abstract>
<front> </front>
<title>A Complete Treatment of Software Implementations of Finite Field <seriesInfo name="BCP" value="14"/>
Arithmetic for Erasure Coding Applications</title> <seriesInfo name="RFC" value="8174"/>
<author initials="J." surname="Plank"> <organization /> </author> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
<author initials="K." surname="Greenan"> <organization /> </author> </reference>
<author initials="E." surname="Miller"> <organization /> </author> <reference anchor="RFC8680" target="https://www.rfc-editor.org/info/rfc8
<date month="October" year="2013" /> 680" quoteTitle="true" derivedAnchor="RFC8680">
</front> <front>
<seriesInfo name="University of Tennessee Technical Report UT-CS-13-717, <title>Forward Error Correction (FEC) Framework Extension to Sliding
" value="http://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html" /> Window Codes</title>
</reference> <seriesInfo name="RFC" value="8680"/>
<seriesInfo name="DOI" value="10.17487/RFC8680"/>
</references> <author initials="V" surname="Roca" fullname="Vincent Roca">
<organization showOnFrontPage="true"/>
<!-- ====================== --> </author>
<author initials="A" surname="Begen" fullname="Ali Begen">
<section anchor="annex_tinymt32_validation" title="TinyMT32 Validation Cr <organization showOnFrontPage="true"/>
iteria (Normative)"> </author>
<!-- ====================== --> <date month="January" year="2020"/>
</front>
<t> </reference>
<reference anchor="RFC8682" target="https://www.rfc-editor.org/info/rfc8
682" quoteTitle="true" derivedAnchor="RFC8682">
<front>
<title>TinyMT32 Pseudorandom Number Generator (PRNG)</title>
<seriesInfo name="RFC" value="8682"/>
<seriesInfo name="DOI" value="10.17487/RFC8682"/>
<author initials="M" surname="Saito" fullname="Mutsuo Saito">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Matsumoto" fullname="Makoto Matsumoto"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="V" surname="Roca" fullname="Vincent Roca" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="E" surname="Baccelli" fullname="Emmanuel Baccelli"
>
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2020"/>
</front>
</reference>
</references>
<references pn="section-10.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="PGM13" target="http://web.eecs.utk.edu/~plank/plank/p
apers/UT-CS-13-717.html" quoteTitle="true" derivedAnchor="PGM13">
<front>
<title>A Complete Treatment of Software Implementations of Finite Fi
eld Arithmetic for Erasure Coding Applications</title>
<seriesInfo name="University of Tennessee Technical Report" value="U
T-CS-13-717"/>
<author initials="J." surname="Plank">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Greenan">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Miller">
<organization showOnFrontPage="true"/>
</author>
<date month="October" year="2013"/>
</front>
</reference>
<reference anchor="RFC5170" target="https://www.rfc-editor.org/info/rfc5
170" quoteTitle="true" derivedAnchor="RFC5170">
<front>
<title>Low Density Parity Check (LDPC) Staircase and Triangle Forwar
d Error Correction (FEC) Schemes</title>
<author initials="V." surname="Roca" fullname="V. Roca">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Neumann" fullname="C. Neumann">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Furodet" fullname="D. Furodet">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="June"/>
<abstract>
<t>This document describes two Fully-Specified Forward Error Corre
ction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle
, and their application to the reliable delivery of data objects on the packet e
rasure channel (i.e., a communication path where packets are either received wit
hout any corruption or discarded during transmission). These systematic FEC cod
es belong to the well- known class of "Low Density Parity Check" codes, and are
large block FEC codes in the sense of RFC 3453. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5170"/>
<seriesInfo name="DOI" value="10.17487/RFC5170"/>
</reference>
<reference anchor="RFC5510" target="https://www.rfc-editor.org/info/rfc5
510" quoteTitle="true" derivedAnchor="RFC5510">
<front>
<title>Reed-Solomon Forward Error Correction (FEC) Schemes</title>
<author initials="J." surname="Lacan" fullname="J. Lacan">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Roca" fullname="V. Roca">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Peltotalo" fullname="J. Peltotalo">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Peltotalo" fullname="S. Peltotalo">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="April"/>
<abstract>
<t>This document describes a Fully-Specified Forward Error Correct
ion (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2.
.16}, and its application to the reliable delivery of data objects on the packet
erasure channel (i.e., a communication path where packets are either received w
ithout any corruption or discarded during transmission). This document also des
cribes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes o
ver GF(2^^8) when there is no encoding symbol group. Finally, in the context of
the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), th
is document assigns an FEC Instance ID to the special case of Reed-Solomon codes
over GF(2^^8).</t>
<t>Reed-Solomon codes belong to the class of Maximum Distance Sepa
rable (MDS) codes, i.e., they enable a receiver to recover the k source symbols
from any set of k received symbols. The schemes described here are compatible w
ith the implementation from Luigi Rizzo. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5510"/>
<seriesInfo name="DOI" value="10.17487/RFC5510"/>
</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="RFC6726" target="https://www.rfc-editor.org/info/rfc6
726" quoteTitle="true" derivedAnchor="RFC6726">
<front>
<title>FLUTE - File Delivery over Unidirectional Transport</title>
<author initials="T." surname="Paila" fullname="T. Paila">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Walsh" fullname="R. Walsh">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Luby" fullname="M. Luby">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Roca" fullname="V. Roca">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Lehtonen" fullname="R. Lehtonen">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="November"/>
<abstract>
<t>This document defines File Delivery over Unidirectional Transpo
rt (FLUTE), a protocol for the unidirectional delivery of files over the Interne
t, which is particularly suited to multicast networks. The specification builds
on Asynchronous Layered Coding, the base protocol designed for massively scalab
le multicast distribution. This document obsoletes RFC 3926. [STANDARDS-TRACK]<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="6726"/>
<seriesInfo name="DOI" value="10.17487/RFC6726"/>
</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="Roca16" target="https://hal.inria.fr/hal-01395937/en/
" quoteTitle="true" derivedAnchor="Roca16">
<front>
<title>Block or Convolutional AL-FEC Codes? A Performance Comparison
for Robust Low-Latency Communications</title>
<seriesInfo name="HAL ID" value="hal-01395937v2"/>
<author initials="V." surname="Roca">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Teibi">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Burdinat">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Tran-Thai">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Thienot">
<organization showOnFrontPage="true"/>
</author>
<date month="February" year="2017"/>
</front>
</reference>
<reference anchor="Roca17" target="https://hal.inria.fr/hal-01571609v1/e
n/" quoteTitle="true" derivedAnchor="Roca17">
<front>
<title>Less Latency and Better Protection with AL-FEC Sliding Window
Codes: a Robust Multimedia CBR Broadcast Case Study</title>
<seriesInfo name="HAL ID" value="hal-01571609"/>
<author initials="V." surname="Roca">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Teibi">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Burdinat">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Tran">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Thienot">
<organization showOnFrontPage="true"/>
</author>
<date month="October" year="2017"/>
</front>
<refcontent>13th IEEE International Conference on Wireless and
Mobile Computing, Networking and Communications (WiMob17)</refconten
t>
</reference>
</references>
</references>
<section anchor="annex_tinymt32_validation" numbered="true" toc="include" re
moveInRFC="false" pn="section-appendix.a">
<name slugifiedName="name-tinymt32-validation-criteri">TinyMT32 Validation
Criteria (Normative)</name>
<t pn="section-appendix.a-1">
PRNG determinism, for a given seed, is a requirement. PRNG determinism, for a given seed, is a requirement.
Consequently, in order to validate an implementation of the TinyMT32 PRNG, the f ollowing criteria MUST be met. Consequently, in order to validate an implementation of the TinyMT32 PRNG, the f ollowing criteria <bcp14>MUST</bcp14> be met.
</t> </t>
<t pn="section-appendix.a-2">
<t> The first criterion focuses on the tinymt32_rand256(), where the 32-bit integer
The first criterion focusses on the tinymt32_rand256(), where the 32-bit integer of the core TinyMT32 PRNG is scaled down to an 8-bit integer.
of the core TinyMT32 PRNG is scaled down to an 8-bit integer.
Using a seed value of 1, the first 50 values returned by: tinymt32_rand256() as 8-bit unsigned integers Using a seed value of 1, the first 50 values returned by: tinymt32_rand256() as 8-bit unsigned integers
MUST be equal to values provided in <xref target="fig_tinymt32_out_truncated_256 "/>, to be read line by line. <bcp14>MUST</bcp14> be equal to values provided in <xref target="fig_tinymt32_ou t_truncated_256" format="default" sectionFormat="of" derivedContent="Figure 9"/> , to be read line by line.
</t> </t>
<figure anchor="fig_tinymt32_out_truncated_256" align="left" suppress-titl
<figure anchor="fig_tinymt32_out_truncated_256" title="First 50 decimal values ( e="false" pn="figure-9">
to be read per line) returned by tinymt32_rand256() as 8-bit unsigned integers, <name slugifiedName="name-first-50-decimal-values-to-">First 50 decimal
with a seed value of 1."> values (to be read per line) returned by tinymt32_rand256() as 8-bit unsigned in
<artwork><![CDATA[ tegers, with a seed value of 1</name>
<artwork name="" type="" align="left" alt="" pn="section-appendix.a-3.1"
>
37 225 177 176 21 37 225 177 176 21
246 54 139 168 237 246 54 139 168 237
211 187 62 190 104 211 187 62 190 104
135 210 99 176 11 135 210 99 176 11
207 35 40 113 179 207 35 40 113 179
214 254 101 212 211 214 254 101 212 211
226 41 234 232 203 226 41 234 232 203
29 194 211 112 107 29 194 211 112 107
217 104 197 135 23 217 104 197 135 23
89 210 252 109 166 89 210 252 109 166
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-appendix.a-4">
<t> The second criterion focuses on the tinymt32_rand16(), where the 32-bit integer
The second criterion focusses on the tinymt32_rand16(), where the 32-bit integer of the core TinyMT32 PRNG is scaled down to a 4-bit integer.
of the core TinyMT32 PRNG is scaled down to a 4-bit integer.
Using a seed value of 1, the first 50 values returned by: tinymt32_rand16() as 4 -bit unsigned integers Using a seed value of 1, the first 50 values returned by: tinymt32_rand16() as 4 -bit unsigned integers
MUST be equal to values provided in <xref target="fig_tinymt32_out_truncated_16" />, to be read line by line. <bcp14>MUST</bcp14> be equal to values provided in <xref target="fig_tinymt32_ou t_truncated_16" format="default" sectionFormat="of" derivedContent="Figure 10"/> , to be read line by line.
</t> </t>
<figure anchor="fig_tinymt32_out_truncated_16" align="left" suppress-title
<figure anchor="fig_tinymt32_out_truncated_16" title="First 50 decimal values (t ="false" pn="figure-10">
o be read per line) returned by tinymt32_rand16() as 4-bit unsigned integers, wi <name slugifiedName="name-first-50-decimal-values-to-b">First 50 decimal
th a seed value of 1."> values (to be read per line) returned by tinymt32_rand16() as 4-bit unsigned in
<artwork><![CDATA[ tegers, with a seed value of 1</name>
<artwork name="" type="" align="left" alt="" pn="section-appendix.a-5.1"
>
5 1 1 0 5 5 1 1 0 5
6 6 11 8 13 6 6 11 8 13
3 11 14 14 8 3 11 14 14 8
7 2 3 0 11 7 2 3 0 11
15 3 8 1 3 15 3 8 1 3
6 14 5 4 3 6 14 5 4 3
2 9 10 8 11 2 9 10 8 11
13 2 3 0 11 13 2 3 0 11
9 8 5 7 7 9 8 5 7 7
9 2 12 13 6 9 2 12 13 6
]]></artwork> </artwork>
</figure> </figure>
</section>
</section> <section anchor="annex_assessing_prng" numbered="true" toc="include" removeI
nRFC="false" pn="section-appendix.b">
<section anchor="annex_assessing_prng" title="Assessing the PRNG Adequacy <name slugifiedName="name-assessing-the-prng-adequacy">Assessing the PRNG
(Informational)"> Adequacy (Informational)</name>
<!-- ====================== --> <t pn="section-appendix.b-1">
This annex discusses the adequacy of the TinyMT32 PRNG and the tinymt32_rand16()
<t> and tinymt32_rand256() functions, to the RLC FEC schemes.
This annex discusses the adequacy of the TinyMT32 PRNG and the tinymt32_rand16() The goal is to assess the adequacy of these two functions in producing coding co
and tinymt32_rand256() functions, to the RLC FEC Schemes. efficients that are sufficiently different from one another, across various repa
The goal is to assess the adequacy of these two functions in producing coding co ir symbols with repair key values in sequence (we can expect this approach to be
efficients that are sufficiently different from one another, across various repa commonly used by implementers, see <xref target="ArbitraryFlows_FECCodeSpecific
ir symbols with repair key values in sequence (we can expect this approach to be ation_encoding" format="default" sectionFormat="of" derivedContent="Section 6.1"
commonly used by implementers, see <xref target="ArbitraryFlows_FECCodeSpecific />).
ation_encoding"/>).
This section is purely informational and does not claim to be a solid evaluation . This section is purely informational and does not claim to be a solid evaluation .
</t> </t>
<t pn="section-appendix.b-2">
<t> The two RLC FEC schemes use the PRNG to produce pseudorandom coding coefficients
The two RLC FEC Schemes use the PRNG to produce pseudo-random coding coefficient (<xref target="CommonProc_coef_generation_func" format="default" sectionFormat=
s (<xref target="CommonProc_coef_generation_func"/>), each time a new repair sym "of" derivedContent="Section 3.6"/>), each time a new repair symbol is needed.
bol is needed. A different repair key is used for each repair symbol, usually by incrementing t
A different repair key is used for each repair symbol, usually by incrementing t he repair key value (<xref target="ArbitraryFlows_FECCodeSpecification_encoding"
he repair key value (<xref target="ArbitraryFlows_FECCodeSpecification_encoding" format="default" sectionFormat="of" derivedContent="Section 6.1"/>).
/>). For each repair symbol, a limited number of pseudorandom numbers is needed, depe
For each repair symbol, a limited number of pseudo-random numbers is needed, dep nding on the DT and encoding window size (<xref target="CommonProc_coef_generati
ending on the DT and encoding window size (<xref target="CommonProc_coef_generat on_func" format="default" sectionFormat="of" derivedContent="Section 3.6"/>), us
ion_func"/>), using either tinymt32_rand16() or tinymt32_rand256(). ing either tinymt32_rand16() or tinymt32_rand256().
Therefore we are more interested in the randomness of small sequences of random Therefore, we are more interested in the randomness of small sequences of random
numbers mapped to 4-bit or 8-bit integers, than in the randomness of a very larg numbers mapped to 4-bit or 8-bit integers, than in the randomness of a very lar
e sequence of random numbers which is not representative of the usage of the PRN ge sequence of random numbers which is not representative of the usage of the PR
G. NG.
</t> </t>
<t pn="section-appendix.b-3">
<t>
Evaluation of tinymt32_rand16(): Evaluation of tinymt32_rand16():
We first generate a huge number (1,000,000,000) of small sequences (20 pseudo-ra ndom numbers per sequence), increasing the seed value for each sequence, and per form statistics on the number of occurrences of each of the 16 possible values a cross all sequences. We first generate a huge number (1,000,000,000) of small sequences (20 pseudoran dom numbers per sequence), increasing the seed value for each sequence, and perf orm statistics on the number of occurrences of each of the 16 possible values ac ross all sequences.
In this first test we consider 32-bit seed values in order to assess the PRNG qu ality after output truncation to 4 bits. In this first test we consider 32-bit seed values in order to assess the PRNG qu ality after output truncation to 4 bits.
<figure anchor="fig_tinymt32_out_truncated_16_huge_nb_small_seq"
title="tinymt32_rand16(): occurrence statistics across a huge number (1,000,000,
000) of small sequences (20 pseudo-random numbers per sequence), with 0 as the f
irst PRNG seed.">
<artwork><![CDATA[
value occurrences percentage (%) (total of 20000000000)
0 1250036799 6.2502
1 1249995831 6.2500
2 1250038674 6.2502
3 1250000881 6.2500
4 1250023929 6.2501
5 1249986320 6.2499
6 1249995587 6.2500
7 1250020363 6.2501
8 1249995276 6.2500
9 1249982856 6.2499
10 1249984111 6.2499
11 1250009551 6.2500
12 1249955768 6.2498
13 1249994654 6.2500
14 1250000569 6.2500
15 1249978831 6.2499
]]></artwork>
</figure>
The results (<xref target="fig_tinymt32_out_truncated_16_huge_nb_small_seq"/>) s
how that all possible values are almost equally represented, or said differently
, that the tinymt32_rand16() output converges to a uniform distribution where ea
ch of the 16 possible values would appear exactly 1 / 16 * 100 = 6.25% of times.
</t> </t>
<table anchor="table_tinymt32_out_truncated_16_huge_nb_small_seq" align="c
<t> enter" pn="table-1">
Since the RLC FEC Schemes use of this PRNG will be limited to 16-bit seed values <name slugifiedName="name-tinymt32_rand16-occurrence-">tinymt32_rand16()
, we carried out the same test for the first 2^^16 seed values only. Occurrence Statistics</name>
The distribution (not shown) is of course less uniform, with value occurences ra <thead>
nging between 6.2121% (i.e., 81,423 occurences out of a total of 65536*20=1,310, <tr>
720) and 6.2948% (i.e., 82,507 occurences). <th align="left" colspan="1" rowspan="1">Value</th>
However, we do not believe it significantly impacts the RLC FEC Scheme behavior. <th align="left" colspan="1" rowspan="1"> Occurrences</th>
<th align="left" colspan="1" rowspan="1">Percentage (%)</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">1250036799</td>
<td align="left" colspan="1" rowspan="1">6.2502</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">1249995831</td>
<td align="left" colspan="1" rowspan="1">6.2500</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">1250038674</td>
<td align="left" colspan="1" rowspan="1">6.2502</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">1250000881</td>
<td align="left" colspan="1" rowspan="1">6.2500</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">1250023929</td>
<td align="left" colspan="1" rowspan="1">6.2501</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">1249986320</td>
<td align="left" colspan="1" rowspan="1">6.2499</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">1249995587</td>
<td align="left" colspan="1" rowspan="1">6.2500</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">1250020363</td>
<td align="left" colspan="1" rowspan="1">6.2501</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">1249995276</td>
<td align="left" colspan="1" rowspan="1">6.2500</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">1249982856</td>
<td align="left" colspan="1" rowspan="1">6.2499</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">1249984111</td>
<td align="left" colspan="1" rowspan="1">6.2499</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">11</td>
<td align="left" colspan="1" rowspan="1">1250009551</td>
<td align="left" colspan="1" rowspan="1">6.2500</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">12</td>
<td align="left" colspan="1" rowspan="1">1249955768</td>
<td align="left" colspan="1" rowspan="1">6.2498</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">13</td>
<td align="left" colspan="1" rowspan="1">1249994654</td>
<td align="left" colspan="1" rowspan="1">6.2500</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">1250000569</td>
<td align="left" colspan="1" rowspan="1">6.2500</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">1249978831</td>
<td align="left" colspan="1" rowspan="1">6.2499</td>
</tr>
</tbody>
</table>
<t pn="section-appendix.b-5">
Evaluation of tinymt32_rand16(): We first generate a huge number
(1,000,000,000) of small sequences
(20 pseudorandom numbers per sequence), increasing the seed value for each
sequence, and perform
statistics on the number of occurrences of each of the 16 possible values
across the 20,000,000,000
numbers of all sequences. In this first test, we consider 32-bit seed values in
order to assess the PRNG
quality after output truncation to 4 bits.
</t> </t>
<t pn="section-appendix.b-6">
<t> The results (<xref target="table_tinymt32_out_truncated_16_huge_nb_small_seq" fo
rmat="default" sectionFormat="of" derivedContent="Table 1"/>) show that all poss
ible values are almost equally represented, or said differently, that the tinymt
32_rand16() output converges to a uniform distribution where each of the 16 poss
ible values would appear exactly 1 / 16 * 100 = 6.25% of times.
</t>
<t pn="section-appendix.b-7">
Since the RLC FEC schemes use of this PRNG will be limited to 16-bit seed values
, we carried out the same test for the first 2<sup>16</sup> seed values only.
The distribution (not shown) is of course less uniform, with value occurrences r
anging between 6.2121% (i.e., 81,423 occurrences out of a total of 65536*20=1,31
0,720) and 6.2948% (i.e., 82,507 occurrences).
However, we do not believe it significantly impacts the RLC FEC scheme behavior.
</t>
<t pn="section-appendix.b-8">
Other types of biases may exist that may be visible with smaller tests, for inst ance to evaluate the convergence speed to a uniform distribution. Other types of biases may exist that may be visible with smaller tests, for inst ance to evaluate the convergence speed to a uniform distribution.
We therefore perform 200 tests, each of them consisting in producing 200 sequenc
es, keeping only the first value of each sequence. We therefore perform 200 tests, each of them producing 200 sequences,
We use non overlapping repair keys for each sequence, starting with value 0 and keeping only the first value of each sequence.
increasing it after each use.
<!-- We use non-overlapping repair keys for each sequence, starting with value 0 and
<figure anchor="fig_tinymt32_out_truncated_16_small_nb_small_seq" increasing it after each use.
title="tinymt32_rand16(): occurrence statistics across a small number (100) of s </t>
equences, keeping only the first value of each sequence, with 0 as the first PRN <table anchor="table_tinymt32_out_truncated_16_small_nb_small_seq" align="
G seed."> center" pn="table-2">
<artwork><![CDATA[ <name slugifiedName="name-tinymt32_rand16-occurrence-s">tinymt32_rand16(
value occurrences percentage (total of 200) ) Occurrence Statistics</name>
0 13 6.5000 <thead>
1 11 5.5000 <tr>
2 15 7.5000 <th align="left" colspan="1" rowspan="1">Value</th>
3 10 5.0000 <th align="left" colspan="1" rowspan="1">Min Occurrences</th>
4 15 7.5000 <th align="left" colspan="1" rowspan="1">Max Occurrences</th>
5 17 8.5000 <th align="left" colspan="1" rowspan="1">Average Occurrences</th>
6 11 5.5000 </tr>
7 14 7.0000 </thead>
8 10 5.0000 <tbody>
9 11 5.5000 <tr>
10 12 6.0000 <td align="left" colspan="1" rowspan="1">0</td>
11 11 5.5000 <td align="left" colspan="1" rowspan="1">4</td>
12 12 6.0000 <td align="left" colspan="1" rowspan="1">21</td>
13 17 8.5000 <td align="left" colspan="1" rowspan="1">6.3675</td>
14 13 6.5000 </tr>
15 8 4.0000 <tr>
]]></artwork> <td align="left" colspan="1" rowspan="1">1</td>
</figure> <td align="left" colspan="1" rowspan="1">4</td>
<figure anchor="fig_tinymt32_out_truncated_16_small_nb_small_seq" <td align="left" colspan="1" rowspan="1">22</td>
title="tinymt32_rand16(): occurrence statistics across 200 tests, each of them c <td align="left" colspan="1" rowspan="1">6.0200</td>
onsisting in 200 sequences of 1 pseudo-random number each, with non overlapping </tr>
PRNG seeds in sequence starting from 0."> <tr>
<artwork><![CDATA[ <td align="left" colspan="1" rowspan="1">2</td>
value min occurrences max occurrences average occurrences <td align="left" colspan="1" rowspan="1">4</td>
0 4 21 6.3675 <td align="left" colspan="1" rowspan="1">20</td>
1 4 22 6.0200 <td align="left" colspan="1" rowspan="1">6.3125</td>
2 4 20 6.3125 </tr>
3 5 23 6.1775 <tr>
4 5 24 6.1000 <td align="left" colspan="1" rowspan="1">3</td>
5 4 21 6.5925 <td align="left" colspan="1" rowspan="1">5</td>
6 5 30 6.3075 <td align="left" colspan="1" rowspan="1">23</td>
7 6 22 6.2225 <td align="left" colspan="1" rowspan="1">6.1775</td>
8 5 26 6.1750 </tr>
9 3 21 5.9425 <tr>
10 5 24 6.3175 <td align="left" colspan="1" rowspan="1">4</td>
11 4 22 6.4300 <td align="left" colspan="1" rowspan="1">5</td>
12 5 21 6.1600 <td align="left" colspan="1" rowspan="1">24</td>
13 5 22 6.3100 <td align="left" colspan="1" rowspan="1">6.1000</td>
14 4 26 6.3950 </tr>
15 4 21 6.1700 <tr>
]]></artwork> <td align="left" colspan="1" rowspan="1">5</td>
</figure> <td align="left" colspan="1" rowspan="1">4</td>
<xref target="fig_tinymt32_out_truncated_16_small_nb_small_seq"/> shows across a <td align="left" colspan="1" rowspan="1">21</td>
ll 200 tests, for each of the 16 possible pseudo-random number values, the minim <td align="left" colspan="1" rowspan="1">6.5925</td>
um (resp. maximum) number of times it appeared in a test, as well as the average </tr>
number of occurrences across the 200 tests. <tr>
<td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">30</td>
<td align="left" colspan="1" rowspan="1">6.3075</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">22</td>
<td align="left" colspan="1" rowspan="1">6.2225</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">26</td>
<td align="left" colspan="1" rowspan="1">6.1750</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">21</td>
<td align="left" colspan="1" rowspan="1">5.9425</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">10 </td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">24</td>
<td align="left" colspan="1" rowspan="1">6.3175</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">11 </td>
<td align="left" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">22</td>
<td align="left" colspan="1" rowspan="1">6.4300</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">12 </td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">21</td>
<td align="left" colspan="1" rowspan="1">6.1600</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">13 </td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">22</td>
<td align="left" colspan="1" rowspan="1">6.3100</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">14 </td>
<td align="left" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">26</td>
<td align="left" colspan="1" rowspan="1">6.3950</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">15 </td>
<td align="left" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">21</td>
<td align="left" colspan="1" rowspan="1">6.1700</td>
</tr>
</tbody>
</table>
<t pn="section-appendix.b-10"><xref target="table_tinymt32_out_truncated_1
6_small_nb_small_seq" format="default" sectionFormat="of" derivedContent="Table
2"/> shows across all 200 tests, for each of the 16 possible pseudorandom number
values, the minimum (resp. maximum) number of times it appeared in a test, as w
ell as the average number of occurrences across the 200 tests.
Although the distribution is not perfect, there is no major bias. Although the distribution is not perfect, there is no major bias.
On the opposite, in the same conditions, the Park-Miller linear congruential PRN G of <xref target="RFC5170"/> with a result scaled down to 4-bit values, using s eeds in sequence starting from 1, returns systematically 0 as the first value du ring some time, then after a certain repair key value threshold, it systematical ly returns 1, etc. On the contrary, in the same conditions, the Park-Miller linear congruential PRN G of <xref target="RFC5170" format="default" sectionFormat="of" derivedContent=" RFC5170"/> with a result scaled down to 4-bit values, using seeds in sequence st arting from 1, systematically returns 0 as the first value during some time. The n, after a certain repair key value threshold, it systematically returns 1, etc.
</t> </t>
<t pn="section-appendix.b-11">
<t>
Evaluation of tinymt32_rand256(): Evaluation of tinymt32_rand256():
The same approach is used here. The same approach is used here.
Results (not shown) are similar: occurrences vary between 7,810,3368 (i.e., 0.39 05%) and 7,814,7952 (i.e., 0.3907%). Results (not shown) are similar: occurrences vary between 7,810,3368 (i.e., 0.39 05%) and 7,814,7952 (i.e., 0.3907%).
Here also we see a convergence to the theoretical uniform distribution where eac h of the 256 possible values would appear exactly 1 / 256 * 100 = 0.390625% of t imes. Here also we see a convergence to the theoretical uniform distribution where eac h of the 256 possible values would appear exactly 1 / 256 * 100 = 0.390625% of t imes.
</t> </t>
</section>
</section> <section anchor="possible_param_derivation" numbered="true" toc="include" re
moveInRFC="false" pn="section-appendix.c">
<section anchor="possible_param_derivation" title="Possible Parameter Der <name slugifiedName="name-possible-parameter-derivati">Possible Parameter
ivation (Informational)"> Derivation (Informational)</name>
<!-- ====================== --> <t pn="section-appendix.c-1"><xref target="CommonProc_rlcParameters" forma
t="default" sectionFormat="of" derivedContent="Section 3.1"/> defines several pa
<t> rameters to control the encoder or decoder.
<xref target="CommonProc_rlcParameters"/> defines several parameters to control
the encoder or decoder.
This annex proposes techniques to derive these parameters according to the targe t use-case. This annex proposes techniques to derive these parameters according to the targe t use-case.
This annex is informational, in the sense that using a different derivation tech nique will not prevent the encoder and decoder to interoperate: a decoder can st ill recover an erased source symbol without any error. This annex is informational, in the sense that using a different derivation tech nique will not prevent the encoder and decoder to interoperate: a decoder can st ill recover an erased source symbol without any error.
However, in case of a real-time flow, an inappropriate parameter derivation may lead to the decoding of erased source packets after their validity period, makin g them useless to the target application. However, in case of a real-time flow, an inappropriate parameter derivation may lead to the decoding of erased source packets after their validity period, makin g them useless to the target application.
This annex proposes an approach to reduce this risk, among other things. This annex proposes an approach to reduce this risk, among other things.
</t> </t>
<t pn="section-appendix.c-2">
<t> The FEC schemes defined in this document can be used in various manners, dependi
The FEC Schemes defined in this document can be used in various manners, dependi ng on the target use-case:
ng on the target use-case: </t>
<list style="symbols"> <ul spacing="normal" bare="false" empty="false" pn="section-appendix.c-3">
<t> the source ADU flow they protect may or may not have real-time constr <li pn="section-appendix.c-3.1"> the source ADU flow they protect may or
aints;</t> may not have real-time constraints;</li>
<t> the source ADU flow may be a Constant Bitrate (CBR) or Variable BitRa <li pn="section-appendix.c-3.2"> the source ADU flow may be a Constant B
te (VBR) flow;</t> itrate (CBR) or Variable Bitrate (VBR) flow;</li>
<t> with a VBR source ADU flow, the flow's minimum and maximum bitrates m <li pn="section-appendix.c-3.3"> with a VBR source ADU flow, the flow's
ay or may not be known;</t> minimum and maximum bitrates may or may not be known;</li>
<t> and the communication path between encoder and decoder may be a CBR c <li pn="section-appendix.c-3.4"> and the communication path between enco
ommunication path (e.g., as with certain LTE-based broadcast channels) or not (g der and decoder may be a CBR communication path (e.g., as with certain LTE-based
eneral case, e.g., with Internet).</t> broadcast channels) or not (general case, e.g., with Internet).</li>
</list> </ul>
<t pn="section-appendix.c-4">
The parameter derivation technique should be suited to the use-case, as describe d in the following sections. The parameter derivation technique should be suited to the use-case, as describe d in the following sections.
</t> </t>
<section anchor="param_derivation_cbr_realtime" numbered="true" toc="inclu
<section anchor="param_derivation_cbr_realtime" title="Ca de" removeInRFC="false" pn="section-c.1">
se of a CBR Real-Time Flow"> <name slugifiedName="name-case-of-a-cbr-real-time-flo">Case of a CBR Rea
<!-- ====================== --> l-Time Flow</name>
<t pn="section-c.1-1">
<t>
In the following, we consider a real-time flow with max_lat latency budget. In the following, we consider a real-time flow with max_lat latency budget.
The encoding symbol size, E, is constant. The encoding symbol size, E, is constant.
The code rate, cr, is also constant, its value depending on the expected communi cation loss model (this choice is out of scope of this document). The code rate, cr, is also constant, its value depending on the expected communi cation loss model (this choice is out of scope of this document).
</t> </t>
<t pn="section-c.1-2">
<t>
In a first configuration, the source ADU flow bitrate at the input of the FECFRA ME sender is fixed and equal to br_in (in bits/s), and this value is known by th e FECFRAME sender. In a first configuration, the source ADU flow bitrate at the input of the FECFRA ME sender is fixed and equal to br_in (in bits/s), and this value is known by th e FECFRAME sender.
It follows that the transmission bitrate at the output of the FECFRAME sender wi ll be higher, depending on the added repair flow overhead. It follows that the transmission bitrate at the output of the FECFRAME sender wi ll be higher, depending on the added repair flow overhead.
In order to comply with the maximum FEC-related latency budget, we have: In order to comply with the maximum FEC-related latency budget, we have:
<list style="none"> </t>
<t> dw_max_size = (max_lat * br_in) / (8 * E) </t> <ul empty="true" spacing="normal" bare="false" pn="section-c.1-3">
</list> <li pn="section-c.1-3.1"> dw_max_size = (max_lat * br_in) / (8 * E) </
li>
</ul>
<t pn="section-c.1-4">
assuming that the encoding and decoding times are negligible with respect to the target max_lat. assuming that the encoding and decoding times are negligible with respect to the target max_lat.
This is a reasonable assumption in many situations (e.g., see <xref target="opre com_ff_considerations"/> in case of small window sizes). This is a reasonable assumption in many situations (e.g., see <xref target="opre com_ff_considerations" format="default" sectionFormat="of" derivedContent="Secti on 8.1"/> in case of small window sizes).
Otherwise the max_lat parameter should be adjusted in order to avoid the problem . Otherwise the max_lat parameter should be adjusted in order to avoid the problem .
In any case, interoperability will never be compromized by choosing a too large value. In any case, interoperability will never be compromised by choosing a too large value.
</t> </t>
<t pn="section-c.1-5">
<t> In a second configuration, the FECFRAME sender generates a fixed bitrate flow, e
In a second configuration, the FECFRAME sender generates a fixed bitrate flow, e qual to the CBR communication path bitrate equal to br_out (in bits/s), and this
qual to the CBR communication path bitrate equal to br_out (in bits/s), and this value is known by the FECFRAME sender, as in <xref target="Roca17" format="defa
value is known by the FECFRAME sender, as in <xref target="Roca17"/>. ult" sectionFormat="of" derivedContent="Roca17"/>.
The maximum source flow bitrate needs to be such that, with the added repair flo w overhead, the total transmission bitrate remains inferior or equal to br_out. The maximum source flow bitrate needs to be such that, with the added repair flo w overhead, the total transmission bitrate remains inferior or equal to br_out.
We have: We have:
<list style="none"> </t>
<t> dw_max_size = (max_lat * br_out * cr) / (8 * E) </t> <ul empty="true" spacing="normal" bare="false" pn="section-c.1-6">
</list> <li pn="section-c.1-6.1"> dw_max_size = (max_lat * br_out * cr) / (8 *
E) </li>
</ul>
<t pn="section-c.1-7">
assuming here also that the encoding and decoding times are negligible with resp ect to the target max_lat. assuming here also that the encoding and decoding times are negligible with resp ect to the target max_lat.
</t> </t>
<t pn="section-c.1-8">
<t>
For decoding to be possible within the latency budget, it is required that the e ncoding window maximum size be smaller than or at most equal to the decoding win dow maximum size. For decoding to be possible within the latency budget, it is required that the e ncoding window maximum size be smaller than or at most equal to the decoding win dow maximum size.
The ew_max_size is the main parameter at a FECFRAME sender, but its exact value has no impact on the the FEC-related latency budget. The ew_max_size is the main parameter at a FECFRAME sender, but its exact value has no impact on the FEC-related latency budget.
The ew_max_size parameter is computed as follows: The ew_max_size parameter is computed as follows:
<list style="none">
<t> ew_max_size = dw_max_size * WSR / 255</t>
<!-- <t> ew_max_size = dw_max_size * 0.75 </t> -->
</list>
In line with <xref target="Roca17"/>, WSR = 191 is considered as a reasonable va
lue (the resulting encoding to decoding window size ratio is then close to 0.75)
, but other values between 1 and 255 inclusive are possible, depending on the us
e-case.
<!-- It is always RECOMMENDED to check that the ew_max_size value stays within r
easonable bounds in order to avoid hazardous behaviours. -->
<!--
However, any value ew_max_size &lt; dw_max_size can be used without impact on th
e FEC-related latency budget.
Another value could be determined depending on the use-case details, which is ou
t of scope of this document.
Whenever the FEC protection (i.e., cr value) is sufficient in front of the exper
ienced packet losses, the ew_max_size guaranties that the recovery of lost ADUs
will happen at a FECFRAME receiver on time.
</t> </t>
<ul empty="true" spacing="normal" bare="false" pn="section-c.1-9">
<t> <li pn="section-c.1-9.1"> ew_max_size = dw_max_size * WSR / 255</li>
</ul>
<t pn="section-c.1-10">
In line with <xref target="Roca17" format="default" sectionFormat="of" derivedCo
ntent="Roca17"/>, WSR = 191 is considered as a reasonable value (the resulting e
ncoding to decoding window size ratio is then close to 0.75), but other values b
etween 1 and 255 inclusive are possible, depending on the use-case.
</t>
<t pn="section-c.1-11">
The dw_max_size is computed by a FECFRAME sender but not explicitly communicated to a FECFRAME receiver. The dw_max_size is computed by a FECFRAME sender but not explicitly communicated to a FECFRAME receiver.
However, a FECFRAME receiver can easily evaluate the ew_max_size by observing th e maximum Number of Source Symbols (NSS) value contained in the Repair FEC Paylo ad ID of received FEC Repair Packets (<xref target="ArbitraryFlows_repair_fpi"/> ). However, a FECFRAME receiver can easily evaluate the ew_max_size by observing th e maximum Number of Source Symbols (NSS) value contained in the Repair FEC Paylo ad ID of received FEC Repair Packets (<xref target="ArbitraryFlows_repair_fpi" f ormat="default" sectionFormat="of" derivedContent="Section 4.1.3"/>).
A receiver can then easily compute dw_max_size: A receiver can then easily compute dw_max_size:
<list style="none">
<t> dw_max_size = max_NSS_observed * 255 / WSR </t>
<!-- <t> dw_max_size = max_NSS_observed / 0.75 </t> -->
</list>
A receiver can then chose an appropriate linear system maximum size:
<list style="none">
<t> ls_max_size &ge; dw_max_size </t>
</list>
It is good practice to use a larger value for ls_max_size as explained in <xref
target="decodingBeyondMaxLatency"/>, which does not impact maximum latency nor i
nteroperability.
</t> </t>
<ul empty="true" spacing="normal" bare="false" pn="section-c.1-12">
<t> <li pn="section-c.1-12.1"> dw_max_size = max_NSS_observed * 255 / WSR
In any case, for a given use-case (i.e., for target encoding and decoding device </li>
s and desired protection levels in front of communication impairments) and for t </ul>
he computed ew_max_size, dw_max_size and ls_max_size values, it is RECOMMENDED t <t pn="section-c.1-13">
o check that the maximum encoding time and maximum memory requirements at a FECF A receiver can then choose an appropriate linear system maximum size:
RAME sender, and maximum decoding time and maximum memory requirements at a FECF
RAME receiver, stay within reasonable bounds.
When assuming that the encoding and decoding times are negligible with respect t
o the target max_lat, this should be verified as well, otherwise the max_lat SHO
ULD be adjusted accordingly.
</t> </t>
<ul empty="true" spacing="normal" bare="false" pn="section-c.1-14">
<t> <li pn="section-c.1-14.1"> ls_max_size &gt;= dw_max_size </li>
</ul>
<t pn="section-c.1-15">
It is good practice to use a larger value for ls_max_size as explained in <xref
target="decodingBeyondMaxLatency" format="default" sectionFormat="of" derivedCon
tent="Appendix D"/>, which does not impact maximum latency nor interoperability.
</t>
<t pn="section-c.1-16">
In any case, for a given use-case (i.e., for target encoding and decoding device
s and desired protection levels in front of communication impairments) and for t
he computed ew_max_size, dw_max_size and ls_max_size values, it is <bcp14>RECOMM
ENDED</bcp14> to check that the maximum encoding time and maximum memory require
ments at a FECFRAME sender, and maximum decoding time and maximum memory require
ments at a FECFRAME receiver, stay within reasonable bounds.
When assuming that the encoding and decoding times are negligible with respect t
o the target max_lat, this should be verified as well, otherwise the max_lat <bc
p14>SHOULD</bcp14> be adjusted accordingly.
</t>
<t pn="section-c.1-17">
The particular case of session start needs to be managed appropriately since the ew_size, starting at zero, increases each time a new source ADU is received by the FECFRAME sender, until it reaches the ew_max_size value. The particular case of session start needs to be managed appropriately since the ew_size, starting at zero, increases each time a new source ADU is received by the FECFRAME sender, until it reaches the ew_max_size value.
Therefore a FECFRAME receiver SHOULD continuously observe the received FEC Repai r Packets, since the NSS value carried in the Repair FEC Payload ID will increas e too, and adjust its ls_max_size accordingly if need be. Therefore, a FECFRAME receiver <bcp14>SHOULD</bcp14> continuously observe the re ceived FEC Repair Packets, since the NSS value carried in the Repair FEC Payload ID will increase too, and adjust its ls_max_size accordingly if need be.
With a CBR flow, session start is expected to be the only moment when the encodi ng window size will increase. With a CBR flow, session start is expected to be the only moment when the encodi ng window size will increase.
Similarly, with a CBR real-time flow, the session end is expected to be the only moment when the encoding window size will progressively decrease. Similarly, with a CBR real-time flow, the session end is expected to be the only moment when the encoding window size will progressively decrease.
No adjustment of the ls_max_size is required at the FECFRAME receiver in that ca se. No adjustment of the ls_max_size is required at the FECFRAME receiver in that ca se.
</t> </t>
</section>
</section> <section anchor="param_derivation_other_realtime_flows" numbered="true" to
c="include" removeInRFC="false" pn="section-c.2">
<section anchor="param_derivation_other_realtime_flows" t <name slugifiedName="name-other-types-of-real-time-fl">Other Types of Re
itle="Other Types of Real-Time Flow"> al-Time Flow</name>
<!-- ====================== --> <t pn="section-c.2-1">
<t>
In the following, we consider a real-time source ADU flow with a max_lat latency budget and a variable bitrate (VBR) measured at the entry of the FECFRAME sende r. In the following, we consider a real-time source ADU flow with a max_lat latency budget and a variable bitrate (VBR) measured at the entry of the FECFRAME sende r.
A first approach consists in considering the smallest instantaneous bitrate of t he source ADU flow, when this parameter is known, and to reuse the derivation of <xref target="param_derivation_cbr_realtime"/>. A first approach consists in considering the smallest instantaneous bitrate of t he source ADU flow, when this parameter is known, and to reuse the derivation of <xref target="param_derivation_cbr_realtime" format="default" sectionFormat="of " derivedContent="Appendix C.1"/>.
Considering the smallest bitrate means that the encoding and decoding window max imum size estimations are pessimistic: these windows have the smallest size requ ired to enable on-time decoding at a FECFRAME receiver. Considering the smallest bitrate means that the encoding and decoding window max imum size estimations are pessimistic: these windows have the smallest size requ ired to enable on-time decoding at a FECFRAME receiver.
If the instantaneous bitrate is higher than this smallest bitrate, this approach leads to an encoding window that is unnecessarily small, which reduces robustne ss in front of long erasure bursts. If the instantaneous bitrate is higher than this smallest bitrate, this approach leads to an encoding window that is unnecessarily small, which reduces robustne ss in front of long erasure bursts.
</t> </t>
<t pn="section-c.2-2">
<t>
Another approach consists in using ADU timing information (e.g., using the times tamp field of an RTP packet header, or registering the time upon receiving a new ADU). Another approach consists in using ADU timing information (e.g., using the times tamp field of an RTP packet header, or registering the time upon receiving a new ADU).
From the global FEC-related latency budget, the FECFRAME sender can derive a pra ctical maximum latency budget for encoding operations, max_lat_for_encoding. From the global FEC-related latency budget, the FECFRAME sender can derive a pra ctical maximum latency budget for encoding operations, max_lat_for_encoding.
For the FEC Schemes specified in this document, this latency budget SHOULD be co For the FEC schemes specified in this document, this latency budget <bcp14>SHOUL
mputed with: D</bcp14> be computed with:
<list style="none"> </t>
<t> max_lat_for_encoding = max_lat * WSR / 255 </t> <ul empty="true" spacing="normal" bare="false" pn="section-c.2-3">
<!-- <t> max_lat_for_encoding = max_lat * 0.75 </t> --> <li pn="section-c.2-3.1"> max_lat_for_encoding = max_lat * WSR / 255 <
</list> /li>
It follows that any source symbols associated to an ADU that has timed-out with </ul>
respect to max_lat_for_encoding SHOULD be removed from the encoding window. <t pn="section-c.2-4">
It follows that any source symbols associated to an ADU that has timed-out with
respect to max_lat_for_encoding <bcp14>SHOULD</bcp14> be removed from the encodi
ng window.
With this approach there is no pre-determined ew_size value: this value fluctuat es over the time according to the instantaneous source ADU flow bitrate. With this approach there is no pre-determined ew_size value: this value fluctuat es over the time according to the instantaneous source ADU flow bitrate.
For practical reasons, a FECFRAME sender may still require that ew_size does not increase beyond a maximum value (<xref target="param_derivation_non_realtime"/> ). For practical reasons, a FECFRAME sender may still require that ew_size does not increase beyond a maximum value (<xref target="param_derivation_non_realtime" f ormat="default" sectionFormat="of" derivedContent="Appendix C.3"/>).
</t> </t>
<t pn="section-c.2-5">
<t>
With both approaches, and no matter the choice of the FECFRAME sender, a FECFRAM E receiver can still easily evaluate the ew_max_size by observing the maximum Nu mber of Source Symbols (NSS) value contained in the Repair FEC Payload ID of rec eived FEC Repair Packets. With both approaches, and no matter the choice of the FECFRAME sender, a FECFRAM E receiver can still easily evaluate the ew_max_size by observing the maximum Nu mber of Source Symbols (NSS) value contained in the Repair FEC Payload ID of rec eived FEC Repair Packets.
A receiver can then compute dw_max_size and derive an appropriate ls_max_size as explained in <xref target="param_derivation_cbr_realtime"/>. A receiver can then compute dw_max_size and derive an appropriate ls_max_size as explained in <xref target="param_derivation_cbr_realtime" format="default" sect ionFormat="of" derivedContent="Appendix C.1"/>.
</t> </t>
<t pn="section-c.2-6">
<t>
When the observed NSS fluctuates significantly, a FECFRAME receiver may want to adapt its ls_max_size accordingly. When the observed NSS fluctuates significantly, a FECFRAME receiver may want to adapt its ls_max_size accordingly.
In particular when the NSS is significantly reduced, a FECFRAME receiver may wan t to reduce the ls_max_size too in order to limit computation complexity. In particular when the NSS is significantly reduced, a FECFRAME receiver may wan t to reduce the ls_max_size too in order to limit computation complexity.
A balance must be found between using an ls_max_size "too large" (which increase s computation complexity and memory requirements) and the opposite (which reduce s recovery performance). A balance must be found between using an ls_max_size "too large" (which increase s computation complexity and memory requirements) and the opposite (which reduce s recovery performance).
</t> </t>
</section>
<!-- <section anchor="param_derivation_non_realtime" numbered="true" toc="inclu
<t> de" removeInRFC="false" pn="section-c.3">
Beyond these general guidelines, the details of how to manage these situations a <name slugifiedName="name-case-of-a-non-real-time-flo">Case of a Non-Rea
t a FECFRAME sender and receiver can depend on additional considerations that ar l-Time Flow</name>
e out of scope of this document. <t pn="section-c.3-1">
</t>
</section>
<section anchor="param_derivation_non_realtime" title="Ca
se of a Non Real-Time Flow">
<!-- ====================== -->
<t>
Finally there are configurations where a source ADU flow has no real-time constr aints. Finally there are configurations where a source ADU flow has no real-time constr aints.
FECFRAME and the FEC Schemes defined in this document can still be used. FECFRAME and the FEC schemes defined in this document can still be used.
The choice of appropriate parameter values can be directed by practical consider ations. The choice of appropriate parameter values can be directed by practical consider ations.
For instance, it can derive from an estimation of the maximum memory amount that could be dedicated to the linear system at a FECFRAME receiver, or the maximum computation complexity at a FECFRAME receiver, both of them depending on the ls_ max_size parameter. For instance, it can derive from an estimation of the maximum memory amount that could be dedicated to the linear system at a FECFRAME receiver, or the maximum computation complexity at a FECFRAME receiver, both of them depending on the ls_ max_size parameter.
The same considerations also apply to the FECFRAME sender, where the maximum mem ory amount and computation complexity depend on the ew_max_size parameter. The same considerations also apply to the FECFRAME sender, where the maximum mem ory amount and computation complexity depend on the ew_max_size parameter.
</t> </t>
<t pn="section-c.3-2">
<t>
Here also, the NSS value contained in FEC Repair Packets is used by a FECFRAME r eceiver to determine the current coding window size and ew_max_size by observing its maximum value over the time. Here also, the NSS value contained in FEC Repair Packets is used by a FECFRAME r eceiver to determine the current coding window size and ew_max_size by observing its maximum value over the time.
</t> </t>
</section>
<!-- </section>
<t> <section anchor="decodingBeyondMaxLatency" numbered="true" toc="include" rem
Beyond these general guidelines, the details of how to manage these situations a oveInRFC="false" pn="section-appendix.d">
t a FECFRAME sender and receiver can depend on additional considerations that ar <name slugifiedName="name-decoding-beyond-maximum-lat">Decoding Beyond Max
e out of scope of this document. imum Latency Optimization (Informational)</name>
</t> <t pn="section-appendix.d-1">
This annex introduces non-normative considerations.
</section>
</section>
<section anchor="decodingBeyondMaxLatency" title="Decoding Beyond Maximum
Latency Optimization (Informational)">
<!-- ====================== -->
<t>
This annex introduces non normative considerations.
It is provided as suggestions, without any impact on interoperability. It is provided as suggestions, without any impact on interoperability.
For more information see <xref target="Roca16"/>. For more information see <xref target="Roca16" format="default" sectionFormat="o f" derivedContent="Roca16"/>.
</t> </t>
<t pn="section-appendix.d-2">
<t> With a real-time source ADU flow, it is possible to improve the decoding perform
With a real-time source ADU flow, it is possible to improve the decoding perform ance of Sliding Window Codes without impacting maximum latency, at the cost of e
ance of sliding window codes without impacting maximum latency, at the cost of e xtra memory and CPU overhead.
xtra memory and CPU overhead.
The optimization consists, for a FECFRAME receiver, to extend the linear system beyond the decoding window maximum size, by keeping a certain number of old sour ce symbols whereas their associated ADUs timed-out: The optimization consists, for a FECFRAME receiver, to extend the linear system beyond the decoding window maximum size, by keeping a certain number of old sour ce symbols whereas their associated ADUs timed-out:
<list style="none"> </t>
<t> ls_max_size > dw_max_size </t> <ul empty="true" spacing="normal" bare="false" pn="section-appendix.d-3">
</list> <li pn="section-appendix.d-3.1"> ls_max_size &gt; dw_max_size </li>
</ul>
<t pn="section-appendix.d-4">
Usually the following choice is a good trade-off between decoding performance an d extra CPU overhead: Usually the following choice is a good trade-off between decoding performance an d extra CPU overhead:
<list style="none">
<t> ls_max_size = 2 * dw_max_size </t>
</list>
</t> </t>
<ul empty="true" spacing="normal" bare="false" pn="section-appendix.d-5">
<t> <li pn="section-appendix.d-5.1"> ls_max_size = 2 * dw_max_size </li>
</ul>
<t pn="section-appendix.d-6">
When the dw_max_size is very small, it may be preferable to keep a minimum ls_ma x_size value (e.g., LS_MIN_SIZE_DEFAULT = 40 symbols). When the dw_max_size is very small, it may be preferable to keep a minimum ls_ma x_size value (e.g., LS_MIN_SIZE_DEFAULT = 40 symbols).
Going below this threshold will not save a significant amount of memory nor CPU cycles. Going below this threshold will not save a significant amount of memory nor CPU cycles.
Therefore: Therefore:
<list style="none">
<t> ls_max_size = max(2 * dw_max_size, LS_MIN_SIZE_DEFAULT) </t>
</list>
</t> </t>
<ul empty="true" spacing="normal" bare="false" pn="section-appendix.d-7">
<t> <li pn="section-appendix.d-7.1"> ls_max_size = max(2 * dw_max_size, LS_M
IN_SIZE_DEFAULT) </li>
</ul>
<t pn="section-appendix.d-8">
Finally, it is worth noting that a receiver that benefits from an FEC protection significantly higher than what is required to recover from packet losses, can c hoose to reduce the ls_max_size. Finally, it is worth noting that a receiver that benefits from an FEC protection significantly higher than what is required to recover from packet losses, can c hoose to reduce the ls_max_size.
In that case lost ADUs will be recovered without relying on this optimization. In that case lost ADUs will be recovered without relying on this optimization.
</t> </t>
<figure anchor="fig_decoding_beyond_max_latency" align="left" suppress-tit
<figure anchor="fig_decoding_beyond_max_laetency" title="Relationship between pa le="false" pn="figure-11">
rameters to decode beyond maximum latency."> <name slugifiedName="name-relationship-between-parame">Relationship betw
<artwork> een Parameters to Decode beyond Maximum Latency</name>
<artwork name="" type="" align="left" alt="" pn="section-appendix.d-9.1"
>
ls_max_size ls_max_size
/---------------------------------^-------------------------------\ /---------------------------------^-------------------------------\
late source symbols late source symbols
(pot. decoded but not delivered) dw_max_size (pot. decoded but not delivered) dw_max_size
/--------------^-----------------\ /--------------^---------------\ /--------------^-----------------\ /--------------^---------------\
src0 src1 src2 src3 src4 src5 src6 src7 src8 src9 src10 src11 src12 src0 src1 src2 src3 src4 src5 src6 src7 src8 src9 src10 src11 src12
</artwork> </artwork>
</figure> </figure>
<t pn="section-appendix.d-10">
<t> It means that source symbols, and therefore ADUs, may be decoded even if the add
It means that source symbols, and therefore ADUs, may be decoded even if the add ed latency exceeds the maximum value permitted by the application (the "late sou
ed latency exceeds the maximum value permitted by the application (the "late sou rce symbols" of <xref target="fig_decoding_beyond_max_latency" format="default"
rce symbols" of <xref target="fig_decoding_beyond_max_laetency"/>). sectionFormat="of" derivedContent="Figure 11"/>).
It follows that the corresponding ADUs will not be useful to the application. It follows that the corresponding ADUs will not be useful to the application.
However, decoding these "late symbols" significantly improves the global robustn ess in bad reception conditions and is therefore recommended for receivers exper iencing bad communication conditions <xref target="Roca16"/>. However, decoding these "late symbols" significantly improves the global robustn ess in bad reception conditions and is therefore recommended for receivers exper iencing bad communication conditions <xref target="Roca16" format="default" sect ionFormat="of" derivedContent="Roca16"/>.
In any case whether or not to use this optimization and what exact value to use for the ls_max_size parameter are local decisions made by each receiver independ ently, without any impact on the other receivers nor on the source. In any case whether or not to use this optimization and what exact value to use for the ls_max_size parameter are local decisions made by each receiver independ ently, without any impact on the other receivers nor on the source.
</t> </t>
</section>
</section> <section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.e">
</back> <name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t pn="section-appendix.e-1">
The authors would like to thank the three TSVWG chairs, Wesley Eddy (our shepher
d), David Black, and Gorry Fairhurst; as well as Spencer Dawkins, our responsibl
e AD;
and all those who provided comments -- namely (in alphabetical order), Alan DeKo
k, Jonathan Detchart, Russ Housley, Emmanuel Lochin, Marie-Jose Montpetit, and G
reg Skinner.
Last but not least, the authors are really grateful to the IESG members, in part
icular Benjamin Kaduk, Mirja Kuehlewind, Eric Rescorla, Adam Roach, and Roman Da
nyliw for their highly valuable feedback that greatly contributed to improving t
his specification.
</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.f">
<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/>
<code/>
<extaddr>Univ. Grenoble Alpes</extaddr>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
</address>
</author>
<author fullname="Belkacem Teibi" initials="B" surname="Teibi">
<organization showOnFrontPage="true">INRIA</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<extaddr>Univ. Grenoble Alpes</extaddr>
<country>France</country>
</postal>
<email>belkacem.teibi@gmail.com</email>
</address>
</author>
</section>
</back>
</rfc> </rfc>
 End of changes. 226 change blocks. 
1651 lines changed or deleted 2537 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/