rfc9407xml2.original.xml   rfc9407.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- $Id$ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<rfc category="exp" docName="draft-irtf-nwcrg-tetrys-04" ipr="trust200902" obsol <!ENTITY nbsp "&#160;">
etes="" updates="" submissionType="IETF" xml:lang="en"> <!ENTITY zwsp "&#8203;">
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2 <!ENTITY nbhy "&#8209;">
629.xslt' ?> <!ENTITY wj "&#8288;">
<?rfc toc="yes"?> ]>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category="
<?rfc tocindent="yes"?> exp" consensus="true" docName="draft-irtf-nwcrg-tetrys-04" number="9407" ipr="tr
<?rfc symrefs="yes"?> ust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3"
<?rfc sortrefs="yes"?> symRefs="true" sortRefs="true" version="3">
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front> <front>
<title abbrev="Tetrys Network Coding Protocol">Tetrys, an On-the-Fly Netwo <title abbrev="Tetrys Network Coding Protocol">Tetrys: An On-the-Fly Network
rk Coding Protocol</title> Coding Protocol</title>
<author fullname="Jonathan Detchart" initials="J." surname="Detchart"> <seriesInfo name="RFC" value="9407"/>
<organization>ISAE-SUPAERO</organization> <author fullname="Jonathan Detchart" initials="J." surname="Detchart">
<address> <organization>ISAE-SUPAERO</organization>
<postal> <address>
<street>10, avenue Edouard Belin</street> <postal>
<street>BP 54032</street> <street>10, avenue Edouard Belin</street>
<city>Toulouse CEDEX 4</city> <extaddr>BP 54032</extaddr>
<code>31055</code> <city>Toulouse CEDEX 4</city>
<country>France</country> <code>31055</code>
</postal> <country>France</country>
<email>jonathan.detchart@isae-supaero.fr</email> </postal>
</address> <email>jonathan.detchart@isae-supaero.fr</email>
</author> </address>
<author fullname="Emmanuel Lochin" initials="E." surname="Lochin"> </author>
<organization>ENAC</organization> <author fullname="Emmanuel Lochin" initials="E." surname="Lochin">
<address> <organization>ENAC</organization>
<postal> <address>
<street>7, avenue Edouard Belin</street> <postal>
<city>Toulouse</city> <street>7, avenue Edouard Belin</street>
<code>31400</code> <city>Toulouse</city>
<country>France</country> <code>31400</code>
</postal> <country>France</country>
<email>emmanuel.lochin@enac.fr</email> </postal>
</address> <email>emmanuel.lochin@enac.fr</email>
</author> </address>
<author fullname="Jerome Lacan" initials="J." surname="Lacan"> </author>
<organization>ISAE-SUPAERO</organization> <author fullname="Jerome Lacan" initials="J." surname="Lacan">
<address> <organization>ISAE-SUPAERO</organization>
<postal> <address>
<street>10, avenue Edouard Belin</street> <postal>
<street>BP 54032</street> <street>10, avenue Edouard Belin</street>
<city>Toulouse CEDEX 4</city> <extaddr>BP 54032</extaddr>
<code>31055</code> <city>Toulouse CEDEX 4</city>
<country>France</country> <code>31055</code>
</postal> <country>France</country>
<email>jerome.lacan@isae-supaero.fr</email> </postal>
</address> <email>jerome.lacan@isae-supaero.fr</email>
</author> </address>
<author fullname="Vincent Roca" initials="V." surname="Roca"> </author>
<organization>INRIA</organization> <author fullname="Vincent Roca" initials="V." surname="Roca">
<address> <organization>INRIA</organization>
<postal> <address>
<street>655, avenue de l'Europe</street> <postal>
<street>Inovallee; Montbonnot</street> <street>655, avenue de l'Europe</street>
<city>ST ISMIER cedex</city> <extaddr>Inovallee; Montbonnot</extaddr>
<code>38334</code> <city>St Ismier CEDEX</city>
<country>France</country> <code>38334</code>
</postal> <country>France</country>
<email>vincent.roca@inria.fr</email> </postal>
</address> <email>vincent.roca@inria.fr</email>
</author> </address>
<date /> </author>
<area /> <date year="2023" month="June" />
<workgroup>NWCRG</workgroup> <workgroup>Coding for Efficient NetWork Communications</workgroup>
<keyword>Network Coding</keyword> <keyword>Network Coding</keyword>
<abstract> <abstract>
<t>This document describes Tetrys, an On-The-Fly Network Coding (NC) pr <t>This document describes Tetrys, which is an on-the-fly network coding p
otocol that can be used to transport delay-sensitive and loss-sensitive data ove rotocol that can be used to transport delay-sensitive and loss-sensitive data ov
r a lossy network. Tetrys may recover from erasures within an RTT-independent de er a lossy network. Tetrys may recover from erasures within an RTT-independent d
lay, thanks to the transmission of Coded Packets. elay thanks to the transmission of coded packets.
This document is a record of the experience gained by the authors while developi ng and testing the Tetrys protocol in real conditions.</t> This document is a record of the experience gained by the authors while developi ng and testing the Tetrys protocol in real conditions.</t>
<t> <t>
This document is a product of the Coding for Efficient Network Commu This document is a product of the Coding for Efficient NetWork Commu
nications Research Group (NWCRG). It conforms to the NWCRG taxonomy<xref target nications Research Group (NWCRG).
="RFC8406" />. It conforms to the NWCRG taxonomy described in RFC 8406.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction" numbered="true" toc="default" <section anchor="intro" numbered="true" toc="default">
> <name>Introduction</name>
<!-- ==================================== -->
<t>This document is a product of and represents the collaborative work <t>This document is a product of and represents the collaborative work
and consensus of the Coding for Efficient Network Communications and consensus of the Coding for Efficient NetWork Communications
Research Group (NWCRG). It is not an IETF product and is not an IETF s Research Group (NWCRG). It is not an IETF product or an IETF standard.
tandard.</t> </t>
<t> <t>This document describes Tetrys, which is an on-the-fly network coding
This document describes Tetrys, a novel erasure coding protocol. Net protocol that can be used to transport delay-sensitive and
work codes were introduced in the early 2000s loss-sensitive data over a lossy network.
<xref target="AHL-00" pageno="false" format="default" /> Network codes were introduced in the early 2000s <xref
to address the limitations of transmission over the Internet (delay, target="AHL-00" format="default"/> to address the limitations of
capacity and packet loss). While network codes have seen some deployment fairly transmission over the Internet (delay, capacity, and packet
recently in the Internet community, the use of application layer erasure codes loss). While network codes have seen some deployment fairly
in the IETF has already been standardized in the RMT recently in the Internet community, the use of application-layer
<xref target="RFC3452" pageno="false" format="default" /> erasure codes in the IETF has already been standardized in the RMT
and the FECFRAME <xref target="RFC5052" format="default"/> <xref target="RFC5445" for
<xref target="RFC8680" pageno="false" format="default" /> mat="default"/>
working groups. The protocol presented here may be seen as a network and FECFRAME
coding extension to standard unicast transport protocols (or even multicast or <xref target="RFC8680" format="default"/>
anycast with a few modifications). The current proposal may be considered a com Working Groups. The protocol presented here may be seen as a network
bination of network erasure coding and feedback mechanisms -coding extension to standard unicast transport protocols (or even multicast or
<xref target="Tetrys" pageno="false" format="default" />, <xref targ anycast with a few modifications). The current proposal may be considered a com
et="Tetrys-RT" pageno="false" format="default"/> bination of network erasure coding and feedback mechanisms
. <xref target="Tetrys" format="default"/> <xref target="Tetrys-RT" fo
</t> rmat="default"/>.
<t>The main innovation of the Tetrys protocol is in the generation of C </t>
oded Packets from an Elastic Encoding Window. This window is filled by any Sourc <t>The main innovation of the Tetrys protocol is in the generation of code
e Packets coming from an input flow and is periodically updated with the receive d packets from an elastic encoding window. This window is filled by any source p
r feedback. These feedback messages provide to the sender with information about ackets coming from an input flow and is periodically updated with the receiver f
the highest sequence number received or rebuilt, which can enable flushing the eedback.
corresponding Source Packets stored in the encoding window. The size of this win These feedback messages provide to the sender information about the
dow may be fixed or dynamically updated. If the window is full, incoming Source highest sequence number received or rebuilt, which can enable the flushing the
Packets replace older sources packets which are dropped. As a matter of fact, it corresponding source packets stored in the encoding window. The size of this
s limit should be correctly sized. Finally, Tetrys allows to deal with losses on window may be fixed or dynamically updated. If the window is full, incoming
both the forward and return paths and in particular, is resilient to acknowledg source packets replace older source packets that are dropped. As a matter of
ment losses. All these operations are further detailed in <xref target="tetrys_b fact, its limit should be correctly sized.
asic_functions" pageno="false" format="default" />.</t>
<t>With Tetrys, a Coded Packet is a linear combination over a finite fi
eld of the data Source Packets belonging to the coding window. The coefficients
finite field's choice is a trade-off between the best erasure recovery performan
ce (finite fields of 256 elements) and the system constraints (finite fields of
16 elements is preferred) and is driven by the application.</t>
<t>Thanks to the Elastic Encoding Window, the Coded Packets are built o
n-the-fly, by using a predefined method to choose the coefficients. The redundan
cy ratio may be dynamically adjusted, and the coefficients may be generated in d
ifferent ways, during the transmission. Compared to FEC block codes, this allows
reducing the bandwidth use and the decoding delay.</t>
<t>The description of the design of the Tetrys protocol in this documen
t is complemented by a record of the experience gained by the authors while deve
loping and testing the Tetrys protocol in realistic conditions. In particular, s
everal research issues are discussed in <xref target="research" pageno="false" f
ormat="default" /> following our own experience and observations.</t>
<section title="Requirements Notation" numbered="true" toc="default"> Finally, Tetrys allows dealing with losses on both the forward and return paths
<!-- ==================================== --> and is particularly resilient to acknowledgment losses. All these operations are
<t> further detailed in <xref target="tetrys_basic_functions" format="default"/>.</
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" <t>With Tetrys, a coded packet is a linear combination over a finite field
in this document are to be interpreted as described in BCP14 <xref target="RFC21 of the data source packets belonging to the coding window.
19" pageno="false" format="default" /> <xref target="RFC8174" pageno="false" fo
rmat="default" /> when, and only when, they appear in all capitals, as shown her The choice of coefficients, as finite fields elements, is a trade-off between th
e. e best erasure recovery performance (finite fields of 256 elements) and the syst
</t> em constraints (finite fields of 16 elements are preferred) and is driven by the
</section> application.</t>
<t>Thanks to the elastic encoding window, the coded packets are built on-t
he-fly by using a predefined method to choose the coefficients. The redundancy r
atio may be dynamically adjusted and the coefficients may be generated in differ
ent ways during the transmission. Compared to Forward Error Correction (FEC) blo
ck codes, this reduces the bandwidth use and the decoding delay.</t>
<t>The design description of the Tetrys protocol in this document is compl
emented by a record of the experience gained by the authors while developing and
testing the Tetrys protocol in realistic conditions. In particular, several res
earch issues are discussed in <xref target="research" format="default"/> followi
ng our own experience and observations.</t>
<section numbered="true" toc="default">
<name>Requirements Notation</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="terminology" title="Definitions, Notations and Abbreviati </section>
ons" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<!-- ==================================== --> <name>Definitions, Notations, and Abbreviations</name>
<t> <t>
The notation used in this document is based on the NWCRG taxon omy The notation used in this document is based on the NWCRG taxon omy
<xref target="RFC8406" pageno="false" format="default" /> <xref target="RFC8406" format="default"/>.
. </t>
</t> <dl spacing="normal" newline="false">
<t> <dt>Source Symbol:</dt><dd>A symbol that is transmitted between the ingr
<list style="empty"> ess and egress of the network.</dd>
<t>Source Symbol: a symbol that is transmitted between the ingres <dt>Coded Symbol:</dt><dd>A linear combination over a finite field of a
s and egress of the network.</t> set of source symbols.</dd>
<t>Coded Symbol: a linear combination over a finite field of a se <dt>Source Symbol ID:</dt><dd>A sequence number to identify the source s
t of Source Symbols.</t> ymbols.</dd>
<t>Source Symbol ID: a sequence number to identify the Source Sym <dt>Coded Symbol ID:</dt><dd>A sequence number to identify the coded sym
bols.</t> bols.</dd>
<t>Coded Symbol ID: a sequence number to identify the Coded Symbo <dt>Encoding Coefficients:</dt><dd>Elements of the finite field characte
ls.</t> rizing the linear combination used to generate coded symbols.</dd>
<t>Encoding Coefficients: elements of the finite field characteri <dt>Encoding Vector:</dt><dd>A set of the coding coefficients and input
zing the linear combination used to generate Coded Symbols.</t> source symbol IDs.</dd>
<t>Encoding Vector: a set of the coding coefficients and input So <dt>Source Packet:</dt><dd>A source packet contains a source symbol with
urce Symbol IDs.</t> its associated IDs.</dd>
<t>Source Packet: a Source Packet contains a Source Symbol with i <dt>Coded Packet:</dt><dd>A coded packet contains a coded symbol, the co
ts associated IDs.</t> ded symbol's ID, and encoding vector.</dd>
<t>Coded Packet: a Coded Packet contains a Coded Symbol, the Code <dt>Input Symbol:</dt><dd>A symbol at the input of the Tetrys encoder.</
d Symbol's ID, and Encoding Vector.</t> dd>
<t>Input Symbol: a symbol at the input of the Tetrys Encoder.</t> <dt>Output Symbol:</dt><dd>A symbol generated by the Tetrys encoder. For
<t>Output Symbol: a symbol generated by the Tetrys Encoder. For a a non-systematic mode, all output symbols are coded symbols. For a systematic m
non-systematic mode, all Output Symbols are Coded Symbols. For a systematic mod ode, output symbols <bcp14>MAY</bcp14> be the input symbols and a number of code
e, Output Symbols MAY be the Input Symbols and a number of Coded Symbols that ar d symbols that are linear combinations of the input symbols plus the encoding ve
e linear combinations of the Input Symbols + the Encoding Vectors.</t> ctors.</dd>
<t>Feedback Packet: a Feedback Packet is a packet containing info <dt>Feedback Packet:</dt><dd>A feedback packet is a packet containing in
rmation about the decoded or received Source Symbols. It MAY also contain additi formation about the decoded or received source symbols. It <bcp14>MAY</bcp14> al
onal information about the Packet Error Rate or the number of various packets in so contain additional information about the Packet Error Rate or the number of v
the receiver decoding window.</t> arious packets in the receiver decoding window.</dd>
<t>Elastic Encoding Window: an encoder-side buffer that stores al <dt>Elastic Encoding Window:</dt><dd>An encoder-side buffer that stores
l the non-acknowledged Source Packets of the input flow involved in the coding p all the unacknowledged source packets of the input flow involved in the coding p
rocess.</t> rocess.</dd>
<t>Coding Coefficient Generator Identifier: a unique identifier t <dt>Coding Coefficient Generator Identifier (CCGI):</dt><dd>A unique identifier
hat defines a function or an algorithm allowing to generate the Encoding Vector. that
</t> defines a function or an algorithm allowing the generation of the encoding
<t>Code Rate: Define the rate between the number of Input Symbols vector.</dd>
and the number of Output Symbols.</t> <dt>Code Rate:</dt><dd>Defines the rate between the number of input symb
</list> ols and the number of output symbols.</dd>
</t> </dl>
</section>
<section anchor="tetrys_architecture" numbered="true" toc="default">
<name>Architecture</name>
<section anchor="use_cases" numbered="true" toc="default">
<name>Use Cases</name>
<t>Tetrys is well suited, but not limited, to the use case where
there is a single flow originated by a single source with intra-stre
am
coding at a single encoding node. Note that the input
stream <bcp14>MAY</bcp14> be a multiplex of several upper-layer
streams. Transmission <bcp14>MAY</bcp14> be over a single path or
multiple paths.
This is the simplest use case that is quite
aligned with currently proposed scenarios for end-to-end
streaming.</t>
</section> </section>
<section anchor="tetrys_architecture" title="Architecture" numbered="true" <section anchor="protocol_overview" numbered="true" toc="default">
toc="default"> <name>Overview</name>
<!-- ==================================== --> <figure anchor="fig-archi-tetrys">
<section anchor="use_cases" title="Use Cases" numbered="true" toc="defa <name>Tetrys Architecture</name>
ult"> <artwork name="" type="" align="left" alt=""><![CDATA[
<!-- ==================================== -->
<t>Tetrys is well suited, but not limited to, the use case where the
re is a single flow originated by a single source, with intra stream coding at a
single encoding node. Note that the input stream MAY be a multiplex of several
upper layer streams.
Transmission MAY be over a single path or multiple paths.
This is the simplest use-case, that is very much aligned
with currently proposed scenarios for end-to-end streaming.</t>
</section>
<section anchor="protocol_overview" title="Overview" numbered="true" to
c="default">
<!-- ==================================== -->
<figure anchor="fig-archi-tetrys" title="Tetrys Architecture" suppre
ss-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt=""
width="" height="">
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| App | | App | | App | | App |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
| ^ | ^
| Source Source | | Source Source |
| Symbols Symbols | | Symbols Symbols |
| | | |
v | v |
+----------+ +----------+ +----------+ +----------+
| | output packets | | | | Output Packets | |
| Tetrys |---------------&gt;| Tetrys | | Tetrys |--------------->| Tetrys |
| Encoder |Feedback Packets| Decoder | | Encoder |Feedback Packets| Decoder |
| |&lt;---------------| | | |<---------------| |
+----------+ +----------+ +----------+ +----------+
</artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The Tetrys protocol features several key functionalities. The man The Tetrys protocol features several key functionalities. The man
datory features are: datory features include:
<list style="symbols"> </t>
<t>on-the-fly encoding;</t> <ul spacing="normal">
<t>decoding;</t> <li>on-the-fly encoding;</li>
<t>signaling, to carry in particular the symbol identifiers in <li>decoding;</li>
the encoding window and the associated coding coefficients when meaningful;</t> <li>signaling, to carry in particular the symbol IDs in the encoding w
<t>feedback management;</t> indow and the associated coding coefficients when meaningful;</li>
<t>elastic window management;</t> <li>feedback management;</li>
<t>Tetrys packet header creation and processing;</t> <li>elastic window management; and</li>
</list> <li>Tetrys packet header creation and processing.</li>
</t> </ul>
<t> <t>The optional features include:
and the optional features are : </t>
<list style="symbols"> <ul spacing="normal">
<t>channel estimation;</t> <li>channel estimation;</li>
<t>dynamic adjustment of the Code Rate and flow control;</t> <li>dynamic adjustment of the code rate and flow control; and</li>
<t> <li>
congestion control management (if appropriate). See <xref t congestion control management (if appropriate). See <xref
arget="transport-issue" /> for further details; target="transport-issue" format="default"/> for further
</t> details.
</list> </li>
</t> </ul>
<t> <t>
Several building blocks provide these functionalities: Several building blocks provide the following functionalities:
<list style="symbols"> </t>
<t>The Tetrys Building Block: this BB embeds both the Tetrys D <dl spacing="normal">
ecoder and Tetrys Encoder and thus, is used during encoding, and decoding proces <dt>The Tetrys Building Block:</dt><dd>This building block embeds
ses. both the Tetrys decoder and Tetrys encoder; thus, it is used during
It must be noted that Tetrys does not man encoding and decoding processes. It must be noted that Tetrys does
date a specific building block. not mandate a specific building block. Instead, any building block
Instead, any building block compatible wi compatible with the elastic encoding window feature of Tetrys may be
th the Elastic Encoding Window feature of Tetrys may be used.</t> used.</dd>
<t> <dt>The Window Management Building Block:</dt><dd>This building block
The Window Management Building Block: this building block i is in charge of managing the encoding window at a Tetrys
s in charge of managing the encoding window at a Tetrys sender. sender.
</t> </dd>
</list> </dl>
</t> <t>
<t> To ease the addition of future components and services, Tetrys ad
To ease the addition of future components and services, Tetrys ad ds a header extension mechanism that is compatible with that of Layered Coding T
ds a header extension mechanism, compatible with that of LCT ransport (LCT)
<xref target="RFC5651" />, NORM <xref target="RFC5651" format="default"/>, NACK-Oriented Reliable
<xref target="RFC5740" />, FECFRAME Multicast (NORM)
<xref target="RFC8680" />. <xref target="RFC5740" format="default"/>, and FEC Framework (FEC
</t> FRAME)
<!-- VR: pas d'accord... JL: OK, a discuter. <xref target="RFC8680" format="default"/>.
<t>Tetrys uses three building blocks to provide a reliabl </t>
e protocol:</t>
<t> - The Tetrys Encoding Building Block creates some
linear combinations of all the non-acknowledged Input Symbols. An upper limit ca
n be set to avoid big computations. Each linear combination is called a Coded Sy
mbol. It is associated to an Encoding Vector, which MUST defines the Input Symbo
ls and MAY define the coefficients used in the combinations. If not, a Coding Co
efficient Generator Identifier (CCGI) is used to identify the function or the al
gorithm used to rebuild the coefficients.</t>
<t> - The Tetrys Relaying Building Block transmits inp
ut packets received from the source or a relay node to a relay node or the desti
nation node. According to the characteristics of previous and next links, it can
remove some Coded Packets or generate additional Coded Packets. The generation
of new packets is done by the recoding process (which does not need a decoding p
rocess).</t>
<t> - The Tetrys Decoding Building Block stores all th
e received output packets. When it is possible, the Coded Symbols are decoded to
rebuild the lost Source Symbols.
Regularly, this building block sends a feedback p
acket containing information about the acknowledgment of received and decoded So
urce Symbols.
When this information is received by a Tetrys Enc
oding Building Block, the acknowledged Source Symbols are removed, and will not
be considered in the next Coded Symbols.</t>
<t>This encoding mechanism is called an elastic coding wi
ndow. Each generated Output Symbols is encapsulated in an output packet format.
</t>
-->
</section> </section>
</section>
<section anchor="tetrys_basic_functions" numbered="true" toc="default">
<name>Tetrys Basic Functions</name>
<section anchor="encoding" numbered="true" toc="default">
<name>Encoding</name>
<t>At the beginning of a transmission, a Tetrys encoder <bcp14>MUST<
/bcp14> choose an initial code rate that adds redundancy as it doesn't know the
packet loss rate of the channel.
In the steady state, the Tetrys encoder <bcp14>MAY</bcp14> generate coded symbol
s when it receives a source symbol from the application or some feedback from th
e decoding blocks depending on the code rate.</t>
<t>When a Tetrys encoder needs to generate a coded symbol, it considers
the set of source symbols stored in the elastic encoding window and generates an
encoding vector with the coded symbol. These source symbols are the set of sour
ce symbols that are not yet acknowledged by the receiver. For each source symbol
, a finite field coefficient is determined using a Coding Coefficient Generator.
This generator <bcp14>MAY</bcp14> take the source symbol IDs and the coded symbo
l ID as an input and <bcp14>MAY</bcp14> determine a coefficient in a determinist
ic way as presented in <xref target="coded-packet" format="default"/>. Finally,
the coded symbol is the sum of the source symbols multiplied by their correspond
ing coefficients.</t>
<t>A Tetrys encoder <bcp14>MUST</bcp14> set a limit to the elastic encod
ing window maximum size. This controls the algorithmic complexity at the encoder
and decoder by limiting the size of linear combinations. It is also needed in s
ituations where all window update packets are lost or absent.</t>
</section> </section>
<section anchor="tetrys_basic_functions" title="Tetrys Basic Functions" nu <section anchor="windowing" numbered="true" toc="default">
mbered="true" toc="default"> <name>The Elastic Encoding Window</name>
<!-- ==================================== --> <t>When an input source symbol is passed to a Tetrys encoder, it is
<section anchor="encoding" title="Encoding" numbered="true" toc="defaul added to the elastic encoding window. This window <bcp14>MUST</bcp14> have a lim
t"> it set by the encoding building block.
<!-- ==================================== --> If the elastic encoding window has reached its limit, the window slides over the
<t>At the beginning of a transmission, a Tetrys Encoder MUST choose symbols. The first (oldest) symbol is removed, and the newest symbol is added.
an initial Code Rate (added redundancy) as it doesn't know the packet loss rate As an element of the coding window, this symbol is included in the next linear c
of the channel. In the steady state, depending on the Code Rate, the Tetrys Enco ombinations created to generate the coded symbols.</t>
der MAY generate Coded Symbols when it receives a Source Symbol from the applica <t>As explained below, the Tetrys decoder sends periodic feedback indica
tion or some feedback from the decoding blocks.</t> ting the received or decoded source symbols. When the sender receives the inform
<t>When a Tetrys Encoder needs to generate a Coded Symbol, it consid ation that a source symbol was received or decoded by the receiver, it removes t
ers the set of Source Symbols stored in the Elastic Encoding Window and generate his symbol from the coding window.</t>
s an Encoding Vector with the Coded Symbol. These Source Symbols are the set of
Source Symbols that are not yet acknowledged by the receiver. For each Source Sy
mbol, a finite field coefficient is determined using a Coding Coefficient Genera
tor. This generator MAY take as input the Source Symbol IDs and the Coded Symbol
ID and MAY determine a coefficient in a deterministic way as presented in <xref
target="coded-packet" pageno="false" format="default" />. Finally, the Coded Sy
mbol is the sum of the Source Symbols multiplied by their corresponding coeffici
ents.</t>
<t>A Tetrys Encoder SHOULD set a limit to the Elastic Encoding Windo
w maximum size. This controls the algorithmic complexity at the encoder and deco
der by limiting the size of linear combinations. It is also needed in situations
where window update packets are all lost or absent.</t>
</section>
<section anchor="windowing" title="The Elastic Encoding Window" numbere
d="true" toc="default">
<!-- ==================================== -->
<t>When an input Source Symbol is passed to a Tetrys Encoder, it is
added to the Elastic Encoding Window. This window MUST have a limit set by the e
ncoding building Block. If the Elastic Encoding Window reached its limit, the wi
ndow slides over the symbols: the first (oldest) symbol is removed, and the newe
st symbol is added. As an element of the coding window, this symbol is included
in the next linear combinations created to generate the Coded Symbols.</t>
<t>As explained below, the Tetrys Decoder sends periodic feedback in
dicating the received or decoded Source Symbols. When the sender receives the in
formation that a Source Symbol was received or decoded by the receiver, it remov
es this symbol from the coding window.</t>
</section>
<section anchor="decoding" title="Decoding" numbered="true" toc="defaul
t">
<!-- ==================================== -->
<t>A standard Gaussian elimination is sufficient to recover the eras
ed Source Symbols, when the matrix rank enables it.</t>
</section>
</section> </section>
<section anchor="encapsulation-format" title="Packet Format" numbered="tru <section anchor="decoding" numbered="true" toc="default">
e" toc="default"> <name>Decoding</name>
<!-- ==================================== --> <t>A standard Gaussian elimination is sufficient to recover the eras
<section anchor="common-packet-header-format" title="Common Header Form ed source symbols when the matrix rank enables it.</t>
at" numbered="true" toc="default"> </section>
<!-- ==================================== --> </section>
<section anchor="encapsulation-format" numbered="true" toc="default">
<name>Packet Format</name>
<section anchor="common-packet-header-format" numbered="true" toc="defa
ult">
<name>Common Header Format</name>
<t> <t>
All types of Tetrys packets share the same common header format ( All types of Tetrys packets share the same common header format (
see <xref target="fig-common-header-format" pageno="false" format="default" />). see <xref target="fig-common-header-format" format="default"/>).
<figure anchor="fig-common-header-format" title="Common Header Fo </t>
rmat" suppress-title="false" align="left" alt="" width="" height=""> <figure anchor="fig-common-header-format">
<artwork xml:space="preserve" name="" type="" align="left" alt <name>Common Header Format</name>
="" width="" height=""> <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C |S| Reserved | HDR_LEN | PKT_TYPE | | V | C |S| Reserved | HDR_LEN | PKT_TYPE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*C bits) | | Congestion Control Information (CCI, length = 32*C bits) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S bits) | | Transport Session Identifier (TSI, length = 32*S bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) | | Header Extensions (if applicable) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
</t> <t>As noted above, this format is inspired by, and inherits from, the LC
<t>As already noted above in the document, this format is inspired a T header format <xref target="RFC5651" format="default"/> with slight modificati
nd inherits from the LCT header format <xref target="RFC5651" pageno="false" for ons.</t>
mat="default" /> with slight modifications.</t> <dl spacing="normal">
<t> <dt>Tetrys version number (V):</dt><dd>4 bits.
<list style="symbols"> Indicates the Tetrys version number. The Tetrys ve
<t>Tetrys version number (V): 4 bits. rsion number for this specification is 1.</dd>
Indicates the Tetrys version number. The Tetrys ve <dt>Congestion control flag (C):</dt><dd>2 bits. C set to 0b00
rsion number for this specification is 1.</t> indicates the Congestion Control Information (CCI) field
<t> is 0 bits in length. C set to 0b01 indicates the CCI field
Congestion control flag (C): 2 bits. is 32
C=0 indicates the Congestion Control Information (CCI) field bits in length. C set to 0b10 indicates the CCI field is 64
is 0 bits in length. C=1 indicates the CCI field is 32 bits in length. C=2 indi bits in
cates the CCI field is 64 bits in length. C=3 indicates the CCI field is 96 bit length. C set to 0b11 indicates the CCI field is 96 bits i
s in length. n
</t> length.
<t>Transport Session Identifier flag (S): 1 bit. </dd>
This is the number of full 32-bit words in the TSI field <dt>Transport Session Identifier flag (S):</dt><dd>1 bit.
. The TSI field is 32*S bits in length, i.e., the length is either 0 bits or 32 This is the number of full 32-bit words in the TSI field
bits.</t> . The TSI field is 32*S bits in length; i.e., the length is either 0 bits or 32
<t>Reserved (Resv): 9 bits. These bits are reserved. In this bits.</dd>
version of the specification, they MUST be set to zero by senders and MUST be ig <dt>Reserved (Resv):</dt><dd>9 bits. These bits are reserved. In this
nored by receivers.</t> version of the specification, they <bcp14>MUST</bcp14> be set to zero by sender
<t>Header length (HDR_LEN): 8 bits. s and <bcp14>MUST</bcp14> be ignored by receivers.</dd>
The total length of the Tetrys header in units of 3 <dt>Header length (HDR_LEN):</dt><dd>8 bits. The total length of
2-bit words. The the Tetrys header in units of 32-bit words. The length of the Tetrys
length of the Tetrys header MUST be a multiple of 3 header <bcp14>MUST</bcp14> be a multiple of 32 bits. This field may
2 bits. This be used to directly access the portion of the packet beyond the
field may be used to directly access the portion of Tetrys header, i.e., to the first next header if it exists, to the
the packet packet payload if it exists and there is no other header, or to the
beyond the Tetrys header, i.e., to the first next h end of the packet if there are no other headers or packet
eader if it payload.</dd>
exists, or to the packet payload if it exists and t <dt>Tetrys packet type (PKT_TYPE):</dt><dd>8 bits.
here is no There are three types of packets: the PKT_TYPE_SO
other header, or to the end of the packet if there URCE (0b00) defined in <xref target="source-packet" format="default"/>, the PKT_
are no others TYPE_CODED (0b01) defined in <xref target="coded-packet" format="default"/> and
headers or packet payload.</t> the PKT_TYPE_WND_UPT (0b11) for window update packets defined in <xref target="a
<t>PKT_TYPE: Tetrys packet type, 8 bits. ck-packet" format="default"/>.</dd>
Type of packet. There is 3 types of packets: the <dt>Congestion Control Information (CCI):</dt><dd>0, 32, 64, or 96 bit
PKT_TYPE_SOURCE (0) defined in <xref target="source-packet" pageno="false" forma s.
t="default" />, the PKT_TYPE_CODED (1) defined in <xref target="coded-packet" pa
geno="false" format="default" /> and the PKT_TYPE_WND_UPT (3), for window update
packets defined in <xref target="ack-packet" pageno="false" format="default" />
.</t>
<t>Congestion Control Information (CCI): 0, 32, 64, or 96 bits
Used to carry congestion control information. For example, the Used to carry congestion control information. For example, the
congestion control information could include layer numbers, congestion control information could include layer numbers,
logical channel numbers, and sequence numbers. Thi s field is logical channel numbers, and sequence numbers. Thi s field is
opaque for this specification. opaque for this specification.
This field MUST be 0 bits (absent) if C=0. This field <bcp14>MUST</bcp14> be 0 bits (absent) i
This field MUST be 32 bits if C=1. f C is set to 0b00.
This field MUST be 64 bits if C=2. This field <bcp14>MUST</bcp14> be 32 bits if C is s
This field MUST be 96 bits if C=3.</t> et to 0b01.
<t> This field <bcp14>MUST</bcp14> be 64 bits if C is s
Transport Session Identifier (TSI): 0 or 32 bits et to 0b10.
This field <bcp14>MUST</bcp14> be 96 bits if C is s
et to 0b11.</dd>
<dt>Transport Session Identifier (TSI):</dt><dd>0 or 32 bits.
The TSI uniquely identifies a session among all ses sions from a The TSI uniquely identifies a session among all ses sions from a
particular Tetrys encoder. The TSI is scoped by the IP address of the particular Tetrys encoder. The TSI is scoped by the IP address of the
sender, and thus the IP address of the sender and t sender; thus, the IP address of the sender and the
he TSI together TSI together
uniquely identify the session. Although a TSI, con uniquely identify the session.
jointly with Although a TSI always uniquely identifies a session conjointly with
the IP address of the sender, always uniquely ident the IP address of the sender, whether the TSI is in
ifies a session, cluded in the Tetrys header depends on
whether the TSI is included in the Tetrys header de
pends on
what is used as the TSI value. If the underlying t ransport is what is used as the TSI value. If the underlying t ransport is
UDP, then the 16-bit UDP source port number MAY ser ve as the TSI UDP, then the 16-bit UDP source port number <bcp14> MAY</bcp14> serve as the TSI
for the session. for the session.
<!-- If the TSI value appears multiple times in a
packet, then all occurrences MUST be the same value
. -->
If there is If there is
no underlying TSI provided by the network, transpor no underlying TSI provided by the network, transpor
t or any other t, or any other
layer, then the TSI MUST be included in the Tetrys layer, then the TSI <bcp14>MUST</bcp14> be included
header. in the Tetrys header.
</t> </dd>
</list> </dl>
</t> <section anchor="header-extension-format" numbered="true" toc="default">
<section anchor="header-extension-format" title="Header Extensions" <name>Header Extensions</name>
numbered="true" toc="default"> <t>Header extensions are used in Tetrys to accommodate optional h
<!-- ==================================== --> eader fields that are not always used or have variable sizes.
<t>Header Extensions are used in Tetrys to accommodate optional h The presence of header extensions <bcp14>MAY</bcp
eader fields that are not always used or have variable size. 14> be inferred by the Tetrys header length (HDR_LEN).
The presence of Header Extensions MAY be inferred If HDR_LEN is larger than the length of the stand
by the Tetrys header length (HDR_LEN). ard header, then the remaining header space is taken by header extensions.</t>
If HDR_LEN is larger than the length of the stand <t>If present, header extensions <bcp14>MUST</bcp14> be processed to e
ard header, then the remaining header space is taken by Header Extensions.</t> nsure that they are recognized before performing any congestion control procedur
<t>If present, Header Extensions MUST be processed to ensure that e or otherwise accepting a packet.
they are recognized before performing any congestion control procedure or other The default action for unrecognized header extens
wise accepting a packet. ions is to ignore them.
The default action for unrecognized Header Extens This allows for the future introduction of backwa
ions is to ignore them. rd-compatible enhancements to Tetrys without changing the Tetrys version number.
This allows the future introduction of backward-c Header extensions that are not backward-compatibl
ompatible enhancements to Tetrys without changing the Tetrys version number. e <bcp14>MUST NOT</bcp14> be introduced without changing the Tetrys version numb
Non-backward-compatible Header Extensions CANNOT er.</t>
be introduced without changing the Tetrys version number.</t> <t>
<t> There are two formats for header extensions as depicted in <xr
There are two formats for Header Extensions as depicted in <xr ef target="fig_header_extension" format="default"/>:
ef target="fig:header_extension" pageno="false" format="default" /> : </t>
<list style="symbols"> <ul spacing="normal">
<t>The first format is used for variable-length extensions, <li>The first format is used for variable-length extensions with hea
with Header Extension Type (HET) values between 0 and 127.</t> der extension type (HET) values between 0 and 127.</li>
<t>The second format is used for fixed-length (one 32-bit w <li>The second format is used for fixed-length (one 32-bit word) ext
ord) extensions, using HET values from 128 to 255.</t> ensions using HET values from 128 to 255.</li>
</list> </ul>
</t> <figure anchor="fig_header_extension">
<figure anchor="fig:header_extension" title="Header Extension For <name>Header Extension Format</name>
mat" suppress-title="false" align="left" alt="" width="" height=""> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork xml:space="preserve" name="" type="" align="left" alt
="" width="" height="">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (&lt;=127) | HEL | | | HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . .
. Header Extension Content (HEC) . . Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (&gt;=128) | Header Extension Content (HEC) | | HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t> <dl spacing="normal">
<list style="symbols"> <dt>Header Extension Type (HET):</dt><dd>8 bits. The type of the hea
<t>Header Extension Type (HET): 8 bits der extension. This document defines several possible types.
<t>The type of the Header Extension. This documen
t defines several possible types.
Additional types may be defined in future version s of this specification. Additional types may be defined in future version s of this specification.
HET values from 0 to 127 are used for variable-le HET values from 0 to 127 are used for variable-le
ngth Header Extensions. ngth header extensions.
HET values from 128 to 255 are used for fixed-len HET values from 128 to 255 are used for fixed-len
gth 32-bit Header Extensions.</t> gth, 32-bit header extensions.</dd>
</t> <dt>Header Extension Length (HEL):</dt><dd>8 bits. The length of t
<t>Header Extension Length (HEL): 8 bits he whole header extension field expressed in multiples of 32-bit words.
<t>The length of the whole Header Extension field This field <bcp14>MUST</bcp14> be present for var
, expressed in multiples of 32-bit words. iable-length extensions (HETs between 0 and 127) and <bcp14>MUST NOT</bcp14> be
This field MUST be present for variable-length ex present for fixed-length extensions (HETs between 128 and 255).</dd>
tensions (HETs between 0 and 127) and MUST NOT be present for fixed-length exten <dt>Header Extension Content (HEC):</dt><dd>Length of the variable
sions (HETs between 128 and 255).</t></t> . The content of the header extension.
<t>Header Extension Content (HEC): variable length The format of this subfield depends on the header
<t>The content of the Header Extension. extension type.
The format of this subfield depends on the Header For fixed-length header extensions, the HEC is 24
Extension Type. bits.
For fixed-length Header Extensions, the HEC is 24 For variable-length header extensions, the HEC fi
bits. eld has a variable size as specified by the HEL field.
For variable-length Header Extensions, the HEC fi Note that the length of each header extension <bc
eld has variable size, as specified by the HEL field. p14>MUST</bcp14> be a multiple of 32 bits.
Note that the length of each Header Extension MUS Additionally, the total size of the Tetrys header
T be a multiple of 32 bits. , including all header extensions and optional header fields, cannot exceed 255
Also, note that the total size of the Tetrys head 32-bit words.</dd>
er, including all Header Extensions and all optional header fields, cannot excee </dl>
d 255 32-bit words.</t></t> </section>
</list> </section>
</t> <section anchor="source-packet" numbered="true" toc="default">
</section> <name>Source Packet Format</name>
</section> <t>A source packet is a common packet header encapsulation, a source
<section anchor="source-packet" title="Source Packet Format" numbered=" symbol ID, and a source symbol (payload). The source symbols <bcp14>MAY</bcp14>
true" toc="default"> have variable sizes.</t>
<!-- ==================================== --> <figure anchor="fig-src-pkt">
<t>A Source Packet is a Common Packet Header encapsulation, a Source <name>Source Packet Format</name>
Symbol ID and a Source Symbol (payload). The Source Symbols MAY have variable s <artwork name="" type="" align="left" alt=""><![CDATA[
izes.</t>
<figure anchor="fig-src-pkt" title="Source Packet Format" suppress-t
itle="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt=""
width="" height="">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Common Packet Header / / Common Packet Header /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Symbol ID | | Source Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Payload / / Payload /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t>Common Packet Header: a common packet header (as common header fo <dl spacing="normal">
rmat) where Packet Type=0.</t> <dt>Common Packet Header:</dt><dd>A common packet header (as common head
<t>Source Symbol ID: the sequence number to identify a Source Symbol er format) where packet type is set to 0b00.</dd>
.</t> <dt>Source Symbol ID:</dt><dd>The sequence number to identify a source s
<t>Payload: the payload (Source Symbol)</t> ymbol.</dd>
</section> <dt>Payload:</dt><dd>The payload (source symbol).</dd>
<section anchor="coded-packet" title="Coded Packet Format" numbered="tr </dl>
ue" toc="default"> </section>
<!-- ==================================== --> <section anchor="coded-packet" numbered="true" toc="default">
<name>Coded Packet Format</name>
<t> <t>
A Coded Packet is the encapsulation of a Common Packet Header, a A coded packet is the encapsulation of a common packet header, a
Coded Symbol ID, the associated Encoding Vector, and a Coded Symbol (payload). coded symbol ID, the associated encoding vector, and a coded symbol (payload).
As the Source Symbols MAY have variable sizes, all the Source Sym As the source symbols <bcp14>MAY</bcp14> have variable sizes, all
bol sizes need to be encoded. To generate this encoded payload size, as a 16-bit the source symbol sizes need to be encoded. To generate this encoded payload si
unsigned value, the linear combination uses the same coefficients as the coded ze as a 16-bit unsigned value, the linear combination uses the same coefficients
payload. The result MUST be stored in the Coded Packet as the Encoded Payload Si as the coded payload. The result <bcp14>MUST</bcp14> be stored in the coded pac
ze (16 bits): as it is an optional field, the Encoding Vector MUST signal the us ket as the encoded payload size (16 bits). As it is an optional field, the encod
e of variable Source Symbol sizes with the field V (see <xref target="unified-en ing vector <bcp14>MUST</bcp14> signal the use of variable source symbol sizes wi
coding-vector-format" pageno="false" format="default" />). th the field V (see <xref target="unified-encoding-vector-format" format="defaul
</t> t"/>).
<figure anchor="fig-rpr-pkt" title="Coded Packet Format" suppress-ti </t>
tle="false" align="left" alt="" width="" height=""> <figure anchor="fig-rpr-pkt">
<artwork xml:space="preserve" name="" type="" align="left" alt="" <name>Coded Packet Format</name>
width="" height=""> <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Common Packet Header / / Common Packet Header /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Coded Symbol ID | | Coded Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Encoding Vector / / Encoding Vector /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Payload Size | | | Encoded Payload Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
/ Payload / / Payload /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t>Common Packet Header: a common packet header (as common header fo <dl spacing="normal">
rmat) where Packet Type=1.</t> <dt>Common Packet Header:</dt><dd>A common packet header (as common head
<t>Coded Symbol ID: the sequence number to identify a Coded Symbol.< er format) where packet type is set to 0b01.</dd>
/t> <dt>Coded Symbol ID:</dt><dd>The sequence number to identify a coded sym
<t>Encoding Vector: an Encoding Vector to define the linear combinat bol.</dd>
ion used (coefficients and Source Symbols).</t> <dt>Encoding Vector:</dt><dd>An encoding vector to define the linear com
<t>Encoded Payload Size: the coded payload size used if the Source S bination used (coefficients and source symbols).</dd>
ymbols have a variable size (optional,<xref target="unified-encoding-vector-form <dt>Encoded Payload Size:</dt><dd>The coded payload size used if the sou
at" pageno="false" format="default" />).</t> rce symbols have a variable size (optional, <xref target="unified-encoding-vecto
<t>Payload: the Coded Symbol.</t> r-format" format="default"/>).</dd>
<section anchor="unified-encoding-vector-format" title="The Encoding <dt>Payload:</dt><dd>The coded symbol.</dd>
Vector" numbered="true" toc="default"> </dl>
<t>An Encoding Vector contains all the information about the linear <section anchor="unified-encoding-vector-format" numbered="true" toc="de
combination used to generate a Coded Symbol. The information includes the source fault">
identifiers and the coefficients used for each Source Symbol. It MAY be stored <name>The Encoding Vector</name>
in different ways depending on the situation.</t> <t>An encoding vector contains all the information about the linear co
<figure anchor="fig-unif-enc-vec" title="Encoding Vector Format" mbination used to generate a coded symbol. The information includes the source i
suppress-title="false" align="left" alt="" width="" height=""> dentifiers and the coefficients used for each source symbol. It <bcp14>MAY</bcp1
<artwork xml:space="preserve" name="" type="" align="left" alt 4> be stored in different ways depending on the situation.</t>
="" width="" height=""> <figure anchor="fig-unif-enc-vec">
<name>Encoding Vector Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EV_LEN | CCGI | I |C|V| NB_IDS | NB_COEFS | | EV_LEN | CCGI | I |C|V| NB_IDS | NB_COEFS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FIRST_SOURCE_ID | | FIRST_SOURCE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| b_id | | | b_id | |
+-+-+-+-+-+-+-+-+ id_bit_vector +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ id_bit_vector +-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ coef_bit_vector +-+-+-+-+-+-+-+ + coef_bit_vector +-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t> <dl>
<list style="symbols"> <dt>Encoding Vector Length (EV_LEN):</dt><dd>8 bits. The size in
<t>Encoding Vector Length (EV_LEN) (8-bits): size in units units of 32-bit words.</dd>
of 32-bit words.</t> <dt>Coding Coefficient Generator Identifier (CCGI):</dt><dd><t>4-b
<t>Coding Coefficient Generator Identifier (CCGI): 4-bit ID it ID to identify the algorithm or function used to generate the coefficients. A
to identify the algorithm or the function used to generate the coefficients. As s a CCGI is included in each encoded vector, it <bcp14>MAY</bcp14> dynamically c
a CCGI is included in each encoded vector, it MAY dynamically change between th hange between the generation of two coded symbols.
e generation of 2 Coded Symbols. The CCGI builds the coding coefficients used to generate th
The CCGI builds the coding coefficients used to generate th e coded symbols. They <bcp14>MUST</bcp14> be known by all the Tetrys encoders or
e Coded Symbols. They MUST be known by all the Tetrys encoders or decoders. decoders.
The two RLC FEC schemes specified in this document reuse th The two RLC FEC schemes specified in this document reuse th
e Finite Fields defined in <xref target="RFC5510" pageno="false" format="default e finite fields defined in <xref target="RFC5510" sectionFormat="comma" section=
" />, Section 8.1. More specifically, the elements of the field GF(2^(m)) are r "8.1"/>.
epresented by polynomials with binary coefficients (i.e., over GF(2)) and degree More specifically, the elements of the field GF(2<sup>(m)</sup>) are represented
lower or equal to m-1. The addition between two elements is defined as the addi by polynomials with binary coefficients (i.e., over GF(2)) and with degree lowe
tion of binary polynomials in GF(2), which is equivalent to a bitwise XOR operat r or equal to m-1. The addition between two elements is defined as the addition
ion on the binary representation of these elements. of binary polynomials in GF(2), which is equivalent to a bitwise XOR operation o
With GF(2^(8)), multiplication between two elements is the n the binary representation of these elements.
multiplication modulo a given irreducible polynomial of degree 8. The following With GF(2<sup>(8)</sup>), multiplication between two elemen
irreducible polynomial is used for GF(2^(8)): ts is the multiplication modulo a given irreducible polynomial of degree 8. The
following irreducible polynomial is used for GF(2<sup>(8)</sup>):</t>
x^(8) + x^(4) + x^(3) + x^(2) + 1 <t indent="3">x<sup>(8)</sup> + x<sup>(4)</sup> + x<sup>(3)</sup> + x<sup>( 2)</sup> + 1</t>
With GF(2^(4)), multiplication between two elements is the m ultiplication modulo a given irreducible polynomial of degree 4. The following i rreducible polynomial is used for GF(2^(4)): <t>With GF(2<sup>(4)</sup>), multiplication between two elem ents is the multiplication modulo a given irreducible polynomial of degree 4. Th e following irreducible polynomial is used for GF(2<sup>(4)</sup>):</t>
x^(4) + x + 1 <t indent="3">x<sup>(4)</sup> + x + 1
<list style="ccgi"> </t>
<t>0: Vandermonde based coefficients over the finite <ul spacing="normal">
field GF(2^(4)), as defined below. Each coefficient is built as alpha^( (source_ <li>0b00: Vandermonde-based coefficients over the finite field G
symbol_id*coded-symbol_id) % 16), with alpha the root of the primitive polynomia F(2<sup>(4)</sup>) as defined below. Each coefficient is built as alpha<sup>( (s
l.</t> ource_symbol_id*coded-symbol_id) % 16)</sup>, with alpha the root of the primiti
<t>1: Vandermonde based coefficients over the finite ve polynomial.</li>
field GF(2^(8)), as defined below. Each coefficient is built as alpha^( (source_ <li>0b01: Vandermonde-based coefficients over the finite field G
symbol_id*coded-symbol_id) % 256), with alpha the root of the primitive polynomi F(2<sup>(8)</sup>) as defined below. Each coefficient is built as alpha<sup>( (s
al.</t> ource_symbol_id*coded-symbol_id) % 256)</sup>, with alpha the root of the primit
<t>Suppose we want to generate the Coded Symbol 2 as ive polynomial.</li>
a linear combination of the Source Symbols 1,2,4 using CCGI=1. The coefficients <li>Suppose we want to generate the coded symbol 2 as a linear c
will be alpha^( (1 * 1) % 256), alpha^( (1 * 2) % 256), alpha^( (1 * 4) % 256).< ombination of the source symbols 1, 2, and 4 using CCGI set to 0b01. The coeffic
/t> ients will be alpha<sup>( (1 * 1) % 256)</sup>, alpha<sup>( (1 * 2) % 256)</sup>
</list> , and alpha<sup>( (1 * 4) % 256)</sup>.</li>
</t> </ul></dd>
<!-- <t>Store the Source Symbol IDs (I) (1 bit): if equal t <dt>
o 1, the Encoding Vector contains the list of the Source Symbol IDs, if equal to
0, there is no Source Symbol ID information.</t> -->
<t>
Store the Source Symbol ID Format (I) (2 bits): Store the Source Symbol ID Format (I) (2 bits):
<list style="symbols"> </dt><dd>
<t>00 means there is no Source Symbol ID information. <ul spacing="normal">
</t> <li>0b00 means there is no source symbol ID information.</li>
<t>01 means the Encoding Vector contains the edge blo <li>0b01 means the encoding vector contains the edge blocks of t
cks of the Source Symbol IDs without compression.</t> he source symbol IDs without compression.</li>
<t>10 means the Encoding Vector contains the compress <li>0b10 means the encoding vector contains the compressed list
ed list of the Source Symbol IDs.</t> of the source symbol IDs.</li>
<t>11 means the Encoding Vector contains the compress <li>0b11 means the encoding vector contains the compressed edge
ed edge blocks of the Source Symbol IDs.</t> blocks of the source symbol IDs.</li>
</list> </ul>
</t> </dd>
<t>Store the Encoding Coefficients (C): 1 bit to indicate i <dt>Store the Encoding Coefficients (C):</dt><dd>1 bit to indicate i
f an Encoding Vector contains information about the coefficients used.</t> f an encoding vector contains information about the coefficients used.</dd>
<t>Having Source Symbols with Variable Size Encoding (V): s <dt>Having Source Symbols with Variable Size Encoding (V):</dt><dd>S
et V to 1 if the combination which refers to the Encoding Vector is a combinatio et V to 0b01 if the combination that refers to the encoding vector is a combinat
n of Source Symbols with variable sizes. In this case, the Coded Packets MUST ha ion of source symbols with variable sizes. In this case, the coded packets <bcp1
ve the 'Encoded Payload Size' field.</t> 4>MUST</bcp14> have the 'Encoded Payload Size' field.</dd>
<t>NB_IDS: the number of source IDs stored in the Encoding <dt>NB_IDS:</dt><dd>The number of source IDs stored in the encoding
Vector (depending on I).</t> vector (depending on I).</dd>
<t>Number of coefficients (NB_COEFS): The number of the coe <dt>Number of Coefficients (NB_COEFS):</dt><dd>The number of the coe
fficients used to generate the associated Coded Symbol.</t> fficients used to generate the associated coded symbol.</dd>
<t>The first source identifier (FIRST_SOURCE_ID): the first <dt>The First Source Identifier (FIRST_SOURCE_ID):</dt><dd>The first
Source Symbol ID used in the combination.</t> source symbol ID used in the combination.</dd>
<t> <dt>
Number of bits for each edge block (b_id): the number of Number of Bits for Each Edge Block (b_id):</dt><dd>The n
bits needed to store the edge. umber of bits needed to store the edge.
</t> </dd>
<t>Information about the Source Symbol IDs (id_bit_vector): <dt>Information about the Source Symbol IDs (id_bit_vector):</dt><dd
if I=01, store the edge blocks as b_id * (NB_IDS * 2 - 1). If I=10, store in a >If I is set to 0b01, store the edge blocks as b_id * (NB_IDS * 2 - 1).
compressed way the edge blocks.</t> If I is set to 0b10, store the edge blocks in a compressed way.</dd>
<t>The coefficients (coef_bit_vector): The coefficients sto <dt>The Coefficients (coef_bit_vector):</dt><dd>The coefficients sto
red depending on the CCGI (4 or 8 bits for each coefficient).</t> red depending on the CCGI (4 or 8 bits for each coefficient).</dd>
<t>Padding: padding to have an Encoding Vector size multipl <dt>Padding:</dt><dd>Padding to have an encoding vector size that is
e of 32-bit (for the id and coefficient part).</t> a multiple of 32 bits (for the ID and coefficient part).</dd>
</list> </dl>
</t> <t>The source symbol IDs are organized as a sorted list of 32-bit
<!-- ==================================== --> unsigned integers. Depending on the feedback, the source symbol IDs in the list
<t>The Source Symbol IDs are organized as a sorted list of 32-bit <bcp14>MAY</bcp14> be successive or not. If they are successive, the boundaries
unsigned integers. Depending on the feedback, the Source Symbol IDs MAY be succ are stored in the encoding vector; it just needs 2*32 bits of information. If n
essive or not in the list. If they are successive, the boundaries are stored in ot, the full list or the edge blocks <bcp14>MAY</bcp14> be stored and a differen
the Encoding Vector: it just needs 2*32-bit of information. If not, the full lis tial transform to reduce the number of bits needed to represent an identifier <b
t or the edge blocks MAY be stored, and a differential transform to reduce the n cp14>MAY</bcp14> be used.</t>
umber of bits needed to represent an identifier MAY be used.</t> <t>For the following subsections, let's take as an example the generation of an
<t>For the following subsections, let's take as an example the ge encoding vector for a coded symbol that is a linear combination of the source sy
neration of an encoding vector for a Coded Symbol which is a linear combination mbols with IDs 1, 2, 3, 5, 6, 8, 9, and 10 (or as edge blocks: [1..3], [5..6], [
of the Source Symbols with IDs 1,2,3,5,6,8,9 and 10 (or as edge blocks: [1..3],[ 8..10]).</t>
5..6],[8..10])</t> <t>There are several ways to store the source symbol IDs into the enco
<t>There are several ways to store the Source Symbols IDs into th ding vector:
e encoding vector: </t>
<list style="symbols"> <ul spacing="normal">
<t>If no information about the Source Symbol IDs is needed, the <li>If no information about the source symbol IDs is needed, the fie
field I MUST be set to 0b00: no b_id and no id_bit_vector field</t> ld I <bcp14>MUST</bcp14> be set to 0b00: no b_id and no id_bit_vector field.</l
<t>If the edge blocks are stored without compression, the field i>
I MUST be set to 0b01. In this case, set b_id to 32 (as a symbol id is 32 bits), <li>If the edge blocks are stored without compression, the field I <
and store into id_bit_vectors the list as 32 bits unsigned integers: 1,3,5,6,8, bcp14>MUST</bcp14> be set to 0b01.
10</t> In this case, set b_id to 32 (as a Symbol ID is 32 bits), and store the list of
<t>If the Source Symbols Ids are stored as a list with compressi 32-bit unsigned integers (1, 3, 4, 5, 6, 10) into id_bit_vectors.</li>
on, the field I MUST be set to 0b10. In this case, see <xref target="compressing <li>If the source symbol IDs are stored as a list with compression,
-encoding-vector" pageno="false" format="default" /> but rather than compressing the field I <bcp14>MUST</bcp14> be set to 0b10. In this case, see <xref target="
the edge blocks, we compress the full list of the Source Symbol IDs.</t> compressing-encoding-vector" format="default"/>, but rather than compressing the
<t>If the edge blocks are stored with compression, the field I M edge blocks, we compress the full list of the source symbol IDs.</li>
UST be set to 0b11. In this case, see <xref target="compressing-encoding-vector" <li>If the edge blocks are stored with compression, the field I <bcp
pageno="false" format="default" />.</t> 14>MUST</bcp14> be set to 0b11. In this case, see <xref target="compressing-enco
</list> ding-vector" format="default"/>.</li>
</t> </ul>
<section anchor="compressing-encoding-vector" title="Compressed l <section anchor="compressing-encoding-vector" numbered="true" toc="def
ist of Source Symbol IDs" numbered="true" toc="default"> ault">
<!-- ==================================== --> <name>Compressed List of Source Symbol IDs</name>
<t>Let's continue with our Coded Symbol defined in the previou <t>Let's continue with our coded symbol defined in the previou
s section. The Source Symbols IDs used in the linear combination are: [1..3],[5. s section. The source symbol IDs used in the linear combination are: [1..3], [5.
.6],[8..10].</t> .6], [8..10].</t>
<t> If we want to compress and store this list into the encodi <t> If we want to compress and store this list into the encoding vec
ng vector, we MUST follow this procedure: tor, we <bcp14>MUST</bcp14> follow this procedure:
<list style="numbers"> </t>
<t>Keep the first element in the packet as the first_sou <ol spacing="normal" type="1"><li>Keep the first element in the pack
rce_id: 1.</t> et as the first_source_id: 1.</li>
<t>Apply a differential transform to the other elements <li>Apply a differential transform to the other elements
([3,5,6,8,10]) which removes the element i-1 to the element i, starting with the ([3, 5, 6, 8, 10]) that removes the element i-1 to the element i,
first_source_id as i0, and get the list L = [2,2,1,2,2]</t> starting with the first_source_id as i0, and get the list L =
<t>Compute b, the number of bits needed to store all the [2, 2, 1, 2, 2].</li> <li>Compute b, the number of bits needed to
elements, which is ceil(log2(max(L))), where max(L) represents the maximum of t store all the elements, which is ceil(log2(max(L))), where
he elements of the list L: here, 2 bits.</t> max(L) represents the maximum of the elements of the list L;
<t>Write b in the corresponding field, and write all the here, it is 2 bits.</li>
b * [(2 * NB blocks) - 1] elements in a bit vector, here: 10 10 01 10 10.</t> <li>Write b in the corresponding field, and write all the b * [(2
</list> * NB blocks) - 1] elements in a bit vector here: 10, 10, 01, 10, 10.</li>
</t> </ol>
</section> </section>
<section anchor="decompressing-encoding-vector" title="Decompress <section anchor="decompressing-encoding-vector" numbered="true" toc="d
ing the Source Symbol IDs" numbered="true" toc="default"> efault">
<!-- ==================================== --> <name>Decompressing the Source Symbol IDs</name>
<t>When a Tetrys Decoding Block wants to reverse the operation <t>When a Tetrys decoding block wants to reverse the operation
s, this algorithm is used:</t> s, this algorithm is used:</t>
<t> <ol spacing="normal" type="1"><li>Rebuild the list of the transmitte
<list style="numbers"> d elements by reading the bit vector and b: [10, 10, 01, 10, 10] =&gt; [2, 2, 1,
<t>Rebuild the list of the transmitted elements by readi 2, 2].</li>
ng the bit vector and b: [10 10 01 10 10] =&gt; [2,2,1,2,2]</t> <li>Apply the reverse transform by adding successively the element
<t>Apply the reverse transform by adding successively th s, starting with first_source_id: [1, 1 + 2, (1 + 2) + 2, (1 + 2 + 2) + 1, ...]
e elements, starting with first_source_id: [1,1+2,(1+2)+2,(1+2+2)+1,...] =&gt; [ =&gt; [1, 3, 5, 6, 8, 10].</li>
1,3,5,6,8,10]</t> <li>Rebuild the blocks using the list and first_source_id: [1..3],
<t>Rebuild the blocks using the list and first_source_id [5..6], [8..10].</li>
: [1..3],[5..6],[8..10].</t> </ol>
</list> </section>
</t> </section>
</section> </section>
</section> <section anchor="ack-packet" numbered="true" toc="default">
</section> <name>Window Update Packet Format</name>
<section anchor="ack-packet" title="Window Update Packet Format" number <t>A Tetrys decoder <bcp14>MAY</bcp14> send window update packets
ed="true" toc="default"> back to another building block. They contain information about what the packets
<!-- ==================================== --> received, decoded, or dropped, and other information such as a packet loss rate
<t>A Tetrys Decoder MAY send back to another building block some Win or the size of the decoding buffers. They are used to optimize the content of th
dow Update packets. They contain information about what the packets received, de e encoding window. The window update packets are <bcp14>OPTIONAL</bcp14>; hence,
coded or dropped, and other information such as a packet loss rate or the size o they could be omitted or lost in transmission without impacting the protocol be
f the decoding buffers. They are used to optimize the content of the encoding wi havior.</t>
ndow. The window update packets are OPTIONAL, and hence they could be omitted or <figure anchor="fig-ack-pkt">
lost in transmission without impacting the protocol behavior.</t> <name>Window Update Packet Format</name>
<figure anchor="fig-ack-pkt" title="Window Update Packet Format" sup <artwork name="" type="" align="left" alt=""><![CDATA[
press-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt=""
width="" height="">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Common Packet Header / / Common Packet Header /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nb_missing_src | | nb_missing_src |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nb_not_used_coded_symb | | nb_not_used_coded_symb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first_src_id | | first_src_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| plr | sack_size | | | plr | sack_size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
/ SACK Vector / / SACK Vector /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t>Common Packet Header: a common packet header (as common header fo <dl spacing="normal">
rmat) where Packet Type=2.</t> <dt>Common Packet Header:</dt><dd>A common packet header (as common head
<t>nb_missing_src: the number of missing Source Symbols in the recei er format) where packet type is set to 0b10.</dd>
ver since the beginning of the session.</t> <dt>nb_missing_src:</dt><dd>The number of missing source symbols in the
<!-- <t>Nb of not already used Coded Symbols: the number of not alre receiver since the beginning of the session.</dd>
ady used Coded Symbols in the receiver that have not already been used for decod <dt>nb_not_used_coded_symb:</dt><dd>The number of coded symbols at t
ing. Meaning the number of linear combinations containing at least 2 unknown Sou he receiver that have not already been used for decoding (e.g., the linear combi
rce Symbols.</t> --> nations contain at least two unknown source symbols).</dd>
<t>nb_not_used_coded_symb: the number of Coded Symbols at the receiv <dt>first_src_id:</dt><dd>ID of the first source symbol to consider in the selec
er that have not already been used for decoding (e.g., the linear combinations c tive acknowledgment (SACK) vector.</dd>
ontain at least 2 unknown Source Symbols).</t> <dt>plr:</dt><dd>Packet loss ratio expressed as a percentage normalized to an 8-
<t>first_src_id: ID of the first Source Symbol to consider in the SA bit unsigned integer. For example, 2.5% will be stored as floor(2.5 * 256/100) =
CK vector.</t> 6. Conversely, if 6 is the stored value, the corresponding packet loss ratio ex
<t>plr: packet loss ratio expressed as a percentage normalized to a pressed as a percentage is 6*100/256 = 2.34%. This value is used in the case of
8-bit unsigned integer. For example, 2.5 % will be stored as floor(2.5 * 256/100 dynamic code rate or for a statistical purpose. The choice of calculation is lef
) = 6. Conversely, if 6 is the stored value, the corresponding packet loss ratio t to the Tetrys decoder, depending on a window observation, but should be the PL
expressed as a percentage is 6*100/256 = 2.34 %. This value is used in the case R seen before decoding.</dd>
of dynamic Code Rate or for statistical purpose. The choice of calculation is l <dt>sack_size:</dt><dd>The size of the SACK vector in 32-bit words. For
eft to the Tetrys Decoder, depending on a window observation, but should be the instance, with a value of 2, the SACK vector is 64 bits long.</dd>
PLR seen before decoding.</t> <dt>SACK vector:</dt><dd>Bit vector indicating symbols that must be remo
<t>sack_size: the size of the SACK vector in 32-bit words. For insta ved in the encoding window from the first source symbol ID. In most cases, these
nce, with value 2, the SACK vector is 64 bits long.</t> symbols were received by the receiver. The other cases concern some events with
<t>SACK vector: bit vector indicating symbols that must be removed i non-recoverable packets (i.e., in the case of a burst of losses) where it is be
n the encoding window from the first Source Symbol ID. In most cases, these symb tter to drop and abandon some packets and remove them from the encoding window t
ols were received by the receiver. The other cases concern some events with non- o allow the recovery of the following packets.
recoverable packets (for example in the case of a burst of losses) where it is b The "First Source Symbol" is included in this bit
etter to drop and abandon some packets, and thus to remove them from the encodin vector.
g window, to allow the recovery of the following packets. A bit equal to 1 at the i-th position means that this window update packet remov
The "First Source Symbol" is included in this bi es the source symbol of the ID equal to "First Source Symbol ID" + i from the en
t vector. coding window.</dd>
A bit equal to 1 at the i-th position means that </dl>
this window update packet removes the Source Symbol of ID equal to "First Source
Symbol ID" + i from the encoding window.</t>
</section>
</section>
<!-- <section anchor="ccgi" title="The Coding Coefficient Generator Identif
ier" numbered="true" toc="default">
<t>The Coding Coefficient Generator Identifier define a function or
an algorithm to build the coding coefficients used to generate the Coded Symbols
. They MUST be known by all the Tetrys encoders or decoders.</t>
<t>0: Vandermonde based coefficients over a finite field with 2^^4 e
lements,defined by the primitive polynomial 1+x+x^^4. Each coefficient is built
as alpha^( (source_symbol_id*coded-symbol_id) % 16), with alpha the root of the
primitive polynomial.</t>
<t>1: Vandermonde based coefficients over a finite field with 2^^8 e
lements,defined by the primitive polynomial 1+x^^2+x^^3+x^^4+x^^8. Each coeffici
ent is built as alpha^( (source_symbol_id*coded-symbol_id) % 256), with alpha th
e root of the primitive polynomial.</t>
<section anchor="ccgi_example" title="how to use the CCGI" numbered="tr
ue" toc="default">
<t>At the generation of a Coded Symbol, the Tetrys Encoder generates an
Encoding Vector containing the IDs of the Source Symbols stored in the Elastic
Encoding Window. For each Source Symbol, a finite field coefficient is determine
d using a Coding Coefficient Generator. This generator MAY take as input the Sou
rce Symbol ID and the Coded Symbol ID and MAY determine a coefficient in a deter
ministic way. A typical example of such a deterministic function is a generator
matrix where the rows are indexed by the Source Symbol IDs and the columns by th
e Coded Symbol IDs. For example, the entries of this matrix MAY be built from a
Vandermonde structure, like Reed-Solomon codes, or a sparse binary matrix, like
Low-Density Generator Matrix codes. Finally, the Coded Symbol is the sum of the
Source Symbols multiplied by their corresponding coefficients.</t>
<t>Suppose we want to generate the Coded Symbol 2 as a linear combinati
on of the Source Symbols 1,2,4. The coefficients will be alpha ^( (1 * 1) % 256)
, alpha ^( (1 * 2) % 256), alpha ^( (1 * 4) % 256).</t>
</section>
</section> </section>
--> </section>
<section anchor="research" numbered="true" toc="default">
<!-- ===================================================================== <name>Research Issues</name>
== --> <t>The present document describes the baseline protocol, allowing communic
<section anchor="research" title="Research Issues" numbered="true" toc="de ations between a Tetrys encoder and Tetrys decoder. In practice, Tetrys can be
fault"> used either as a standalone protocol or embedded inside an existing protocol, an
d either above, within, or below the transport layer. There are different resea
<t>The present document describes the baseline protocol, allowing communications rch questions related to each of these scenarios that should be investigated for
between a Tetrys encoder and a Tetrys decoder. In practice, Tetrys can be used future protocol improvements. We summarize them in the following subsections.</
either as a standalone protocol or embedded inside an existing protocol, and ei t>
ther above, within or below the transport layer. There are different research q <section anchor="transport-issue" numbered="true" toc="default">
uestions related to each of these scenarios that should be investigated for futu <name>Interaction with Congestion Control</name>
re protocol improvements. We summarize them in the following subsections.</t> <t>
The Tetrys and congestion control components generate two separate channels (see
<section anchor="transport-issue" title="Interaction with Congestion Co <xref target="RFC9265" sectionFormat="comma" section="2.1"/>):
ntrol" numbered="true" toc="default">
<t>
The Tetrys and congestion control components generate two separate channels (see
<xref target="RFC9265" pageno="false" format="default" />, section 2.1):
<list style="symbols">
<t>the Tetrys channel carries source and Coded Packets (from the sender t
o the receiver) and information from the receiver to the sender (e.g., signaling
which symbols have been recovered, loss rate prior and/or after decoding, etc.)
;</t>
<t>the congestion control channel carries packets from a sender to a rece
iver, and packets signaling information about the network (e.g., number of packe
ts received versus lost, Explicit Congestion Notification (ECN) marks, etc.) fro
m the receiver to the sender. </t>
</list>
In practice, depending on how Tetrys is deployed (i.e., above, within or below t
he transport layer), <xref target="RFC9265" pageno="false" format="default" /> i
dentifies and discusses several topics. They are briefly listed below and adapte
d to the particular case of Tetrys:
<list style="symbols">
<t>congestion related losses may be hidden if Tetrys is deployed below th
e transport layer without any precaution (i.e., Tetrys recovering packets lost b
ecause of a congested router), which can severely impact the the congestion cont
rol efficiency. An approach is suggested to avoid hiding such signals in <xref t
arget="RFC9265" pageno="false" format="default" />, section 5;</t>
<t>having Tetrys and non-Tetrys flows sharing the same network links can
raise fairness issues between these flows. The situation depends in particular o
n whether some of these flows are congestion controlled and not others, and whic
h type of congestion control is used. The details are out of scope of this docum
ent, but may have major impacts in practice;</t>
<t>coding rate adaptation within Tetrys can have major impacts on congest
ion control if done inappropriately. This topic is discussed more in detail in <
xref target="adaptive"/>;</t>
<t>Tetrys can leverage on multipath transmissions, the Tetrys packets bei
ng sent to the same receiver through multiple paths. Since paths can largely dif
fer, a per-path flow control and congestion control adaptation could be needed;<
/t>
<t>protecting several application flows within a single Tetrys flow raise
s additional questions. This topic is discussed more in detail in <xref target="
tunnel"/>.</t>
</list>
</t> </t>
<ul spacing="normal">
<!-- <t> <li>The Tetrys channel carries source and coded packets (from the send
Tetrys coding and congestion control MAY be seen as two separate channels (the n er to the receiver) and information from the receiver to the sender (e.g., signa
otion of channel corresponds to that of <xref target="RFC9265" pageno="false" fo ling which symbols have been recovered, loss rate before and/or after decoding,
rmat="default" />, section 2.1). In practice, implementations MAY interact with etc.).</li>
both channels by sharing information from one channel to the other one. This r <li>The congestion control channel carries packets from a sender to a
aises several concerns that must be tackled when Tetrys is jointly used with a c receiver and packets signaling information about the network (e.g., number of pa
ongestion-controlled transport protocol. For example, the Encoding Window or the ckets received versus lost, Explicit Congestion Notification (ECN) marks, etc.)
Code Rate COULD be adjusted by some feedback from the congestion-control channe from the receiver to the sender. </li>
l. All these numerous research issues are discussed in a separate document, <xr </ul>
ef target="RFC9265" pageno="false" format="default" />, which investigates end-t <t>
o-end unicast data transfer with FEC coding in the application (above the transp The following topics, which are identified and discussed by <xref target="RFC926
ort layer), within the transport layer, or directly below the transport; the rel 5" format="default"/>, are adapted to the particular deployment cases of Tetrys
ationship between transport layer and application requirements; and the case of (i.e., above, within, or below the transport layer):
transport multipath and multi-streams applications. </t>
</t> <ul spacing="normal">
<li>Congestion-related losses may be hidden if Tetrys is deployed belo
w the transport layer without any precaution (i.e., Tetrys recovering packets lo
st because of a congested router), which can severely impact the congestion cont
rol efficiency. An approach is suggested to avoid hiding such signals in <xref t
arget="RFC9265" sectionFormat="comma" section="5"/>.</li>
<li>Tetrys and non-Tetrys flows sharing the same network links can rai
se fairness issues between these flows. In particular, the situation depends on
whether some of these flows and not others are congestion controlled and which t
ype of congestion control is used. The details are out of scope of this document
, but may have major impacts in practice.</li>
<li>Coding rate adaptation within Tetrys can have major impacts on con
gestion control if done inappropriately. This topic is discussed more in detail
in <xref target="adaptive" format="default"/>.</li>
<li>Tetrys can leverage multipath transmissions, with the Tetrys packe
ts being sent to the same receiver through multiple paths. Since paths can large
ly differ, a per-path flow control and congestion control adaptation could be ne
eded.</li>
<li>Protecting several application flows within a single Tetrys flow r
aises additional questions. This topic is discussed more in detail in <xref targ
et="tunnel" format="default"/>.</li>
</ul>
</section> </section>
<section anchor="adaptive" numbered="true" toc="default">
<section anchor="adaptive" title="Adaptive Coding Rate" numbered="true" <name>Adaptive Coding Rate</name>
toc="default"> <t>
When the network conditions (e.g., delay and loss rate) strongly vary over time,
<t> an adaptive coding rate can be used to increase or reduce the amount of coded p
When the network conditions (e.g., delay and loss rate) strongly vary ackets among a transmission dynamically (i.e., the added redundancy) with the he
over time, an adaptive coding rate can be used to increase or reduce the amount lp of a dedicated algorithm similar to <xref target="A-FEC" format="default"/>.
of Coded Packets among a transmission dynamically (i.e., the added redundancy), Once again, the strategy differs depending on which layer Tetrys is deployed (i.
with the help of a dedicated algorithm, similarly to <xref target="A-FEC" pagen e., above, within, or below the transport layer). Basically, we can split these
o="false" format="default" />. Once again, the strategy differs, depending on wh strategies into two distinct classes: Tetrys deployment inside the transport lay
ich layer Tetrys is deployed (i.e., above, within or below the transport layer). er versus outside the transport layer (i.e., above or below). A deployment withi
Basically, we can slice these strategies in two distinct classes: when Tetrys i n the transport layer means
s deployed inside the transport layer, versus outside (i.e., above or below). A that interactions between transport protocol mechanisms such as error recovery,
deployment within the transport layer obviously means that interactions between congestion control, and/or flow control are envisioned. Otherwise, deploying Tet
transport protocol micro-mechanisms, such as the error recovery mechanism, the c rys within a transport protocol that is not congestion controlled, like UDP, wou
ongestion control, the flow control or both, are envisioned. Otherwise, deployin ld not bring out any other advantage than deploying it below or above the transp
g Tetrys within a non congestion controlled transport protocol, like UDP, would ort layer.
not bring out any other advantage than deploying it below or above the transport </t>
layer. <t>The impact deploying a FEC mechanism within the transport layer is fu
</t> rther discussed in <xref target="RFC9265" sectionFormat="of" section="4"/>, wher
e considerations concerning the interactions between congestion control and codi
<t>The impact deploying a FEC mechanism within the transport layer is ng rates, or the impact of fairness, are investigated. This adaptation may be do
further discussed in <xref target="RFC9265" pageno="false" format="default" />, ne jointly with the congestion control mechanism of a transport layer protocol a
section 4, where considerations concerning the interactions between congestion s proposed by <xref target="CTCP" format="default"/>. This allows the use of mon
control and coding rates, or the impact of fairness, are investigated. This adap itored congestion control metrics (e.g., RTT, congestion events, or current cong
tation may be done jointly with the congestion control mechanism of a transport estion window size) to adapt the coding rate conjointly with the computed transp
layer protocol, as proposed by <xref target="CTCP"/>. This allows the use of mon ort sending rate. The rationale is to compute an amount of repair traffic that d
itored congestion control metrics (e.g., RTT, congestion events, or current cong oes not lead to congestion. This joint optimization is mandatory to prevent flo
estion window size) to adapt the coding rate conjointly with the computed transp ws from consuming the whole available capacity as discussed in <xref target="I-D
ort sending rate. The rationale is to compute an amount of repair traffic that d .singh-rmcat-adaptive-fec" format="default"/>, where the authors point out that
oes not lead to congestion. This joint optimization is mandatory to prevent flow an increase in the repair ratio should be done conjointly with a decrease in the
s to consume the whole available capacity as also discussed in <xref target="I-D source sending rate.
.singh-rmcat-adaptive-fec" /> where the authors point out that an increase in th </t>
e repair ratio should be done conjointly with a decrease in the source sending r <t>
ate. Finally, adapting a coding rate can also be done outside the transpor
</t> t layer without considering transport-layer metrics. In particular, this adaptat
ion may be done jointly with the network as proposed in <xref target="RED-FEC" f
<t> ormat="default"/>. In this paper, the authors propose a Random Early Detection F
Finally, adapting a coding rate can also be done outside the transpor EC mechanism in the context of video transmission over wireless networks. Briefl
t layer and without considering transport layer metrics. In particular, this ada y, the idea is to add more redundancy packets if the queue at the access point i
ptation may be done jointly with the network as proposed in <xref target="RED-FE s less occupied and vice versa. A first theoretical attempt for video delivery w
C" pageno="false" format="default" />. In this paper, the authors propose a Rand ith Tetrys has been proposed <xref target="THAI" format="default"/>. This approa
om Early Detection FEC mechanism in the context of video transmission over wirel ch is interesting as it illustrates a joint collaboration between the applicatio
ess networks. Briefly, the idea is to add more redundancy packets if the queue a n requirements and the network conditions and combines both signals coming from
t the access point is less occupied and vice versa. A first theoretical attempt the application needs and the network state (i.e., signals below or above the tr
for video delivery has been proposed <xref target="THAI" pageno="false" format=" ansport layer).
default" /> with Tetrys. This approach is interesting as it illustrates a joint </t>
collaboration between the application requirements and the network conditions an <t>
d combines both signals coming from the application needs and the network state
(i.e., signals below or above the transport layer).
</t>
<t>
To conclude, there are multiple ways to enable an adaptive coding rat e. However, all of them depend on: To conclude, there are multiple ways to enable an adaptive coding rat e. However, all of them depend on:
<list style="symbols"> </t>
<t>the signal metrics that can be monitored and used to adapt the <ul spacing="normal">
coding rate;</t> <li>the signal metrics that can be monitored and used to adapt the cod
<t>the transport layer used, whether congestion controlled or not ing rate;</li>
;</t> <li>the transport layer used, whether it is congestion controlled or n
<t>the objective sought (e.g., to minimize congestion, or to fit ot; and</li>
application requirements).</t> <li>the objective sought (e.g., to minimize congestion or to fit appli
</list> cation requirements).</li>
</t> </ul>
</section>
<section anchor="tunnel" title="Using Tetrys Below The IP Layer For Tun
neling" numbered="true" toc="default">
<t>
The use of Tetrys to protect an aggregate of flows, typically when Tetrys is use
d for tunneling, to recover from IP datagram losses, raises research questions.
When redundancy is applied without flow differentiation, this may come in contra
diction with the service requirements of individual flows, some of them may be m
ore penalized by high latency and jitter than by partial reliability, while othe
r flows may have opposite requirements.
In practice head-of-line blocking will impact all flows in a similar manner desp
ite their different needs, which asks for more elaborate strategies inside Tetry
s.
<!-- Note this research issue joins the topics discussed in the IRTF LOOPS worki
ng group <xref target="I-D.li-tsvwg-loops-problem-opportunities" pageno="false"
format="default" />. -->
</t>
</section>
</section> </section>
<!-- ===================================================================== <section anchor="tunnel" numbered="true" toc="default">
== --> <name>Using Tetrys below the IP Layer for Tunneling</name>
<section anchor="security" title="Security Considerations" numbered="true"
toc="default">
<!-- ==================================== -->
<t> <t>
First of all, it must be clear that the use of FEC protection to a data The use of Tetrys to protect an aggregate of flows raises research quest
stream does not provide, per se, any kind of security, but, on the contrary, rai ions when Tetrys is used to recover from IP datagram losses while tunneling. Ap
ses security risks. plying redundancy without flow differentiation may contradict the service requir
The situation with Tetrys is mostly similar to that of other content del ements of individual flows: some flows may be penalized more by high latency and
ivery protocols making use of FEC protection, and this is well described in FECF jitter than by partial reliability, while other flows may be penalized more by
RAME <xref target="RFC6363" pageno="false" format="default" />. partial reliability. In practice, head-of-line blocking impacts all flows in a
This section leverages on this reference, adding new considerations to c similar manner despite their different needs, which indicates that more elaborat
omply with Tetrys specificities when meaningful. e strategies inside Tetrys are needed.
</t> </t>
</section>
<section anchor="security-problem-statement" title="Problem Statement" n </section>
umbered="true" toc="default"> <section anchor="security" numbered="true" toc="default">
<t> <name>Security Considerations</name>
An attacker can either target the content, the protocol, or the networ <t>
k. First of all, it must be clear that the use of FEC protection on a data
The consequences will largely differ, reflecting various types of goal stream does not provide any kind of security per se. On the contrary, the use of
s, like gaining access to confidential content, corrupting the content, compromi FEC protection on a data stream raises security risks.
zing the Tetrys Encoder and/or Tetrys Decoder, or compromizing the network behav The situation with Tetrys is mostly similar to that of other content del
ior. ivery protocols making use of FEC protection; this is well described in FECFRAME
In particular, several of these attacks aim at creating a Denial-of-Se <xref target="RFC6363" format="default"/>.
rvice (DoS), with consequences that may be limited to a single node (e.g., the T This section builds on this reference, adding new considerations to comp
etrys Decoder), or that may impact all the nodes attached to the targeted networ ly with Tetrys specificities when meaningful.
k (e.g., by making flows non-responsive to congestion signals). </t>
</t> <section anchor="security-problem-statement" numbered="true" toc="default"
<t> >
<name>Problem Statement</name>
<t>
An attacker can either target the content, protocol, or network.
The consequences will largely differ reflecting various types of goals
, like gaining access to confidential content, corrupting the content, compromis
ing the Tetrys encoder and/or Tetrys decoder, or compromising the network behavi
or.
In particular, several of these attacks aim at creating a Denial-of-Se
rvice (DoS) with consequences that may be limited to a single node (e.g., the Te
trys decoder), or that may impact all the nodes attached to the targeted network
(e.g., by making flows unresponsive to congestion signals).
</t>
<t>
In the following sections, we discuss these attacks, according to the component targeted by the attacker. In the following sections, we discuss these attacks, according to the component targeted by the attacker.
</t> </t>
</section> </section>
<section anchor="security-attack-against-data-flow" numbered="true" toc="d
<section anchor="security-attack-against-data-flow" title="Attacks again efault">
st the Data Flow" numbered="true" toc="default"> <name>Attacks against the Data Flow</name>
<t> <t>
An attacker may want to access a confidential content, by eavesdroppin An attacker may want to access confidential content by eavesdropping t
g the traffic between the Tetrys Encoder/Decoder. he traffic between the Tetrys encoder/decoder.
Traffic encryption is the usual approach to mitigate this risk, and th Traffic encryption is the usual approach to mitigate this risk, and th
is encryption can be done either on the source flow, above Tetrys, or below Tetr is encryption can be applied to the source flow upstream of the Tetrys encoder o
ys, on the output packets, both Source and Coded Packets. r to the output packets downstream of the Tetrys encoder.
The choice on where to apply encryption depends on various criteria, i The choice on where to apply encryption depends on various criteria,
n particular the attacker model (e.g., when encryption happens below Tetrys, the in particular the attacker model (e.g., when encryption happens
security risk is assumed to be on the interconnection network). below Tetrys, the security risk is assumed to be on the
</t> interconnection network).
<t> </t>
An attacker may also want to corrupt the content (e.g., by injecting f <t>
orged or modified Source and Coded Packets to prevent the Tetrys Decoder to reco An attacker may also want to corrupt the content (e.g., by injecting f
ver the original source flow). orged or modified source and coded packets to prevent the Tetrys decoder from re
covering the original source flow).
Content integrity and source authentication services at the packet lev el are then needed to mitigate this risk. Content integrity and source authentication services at the packet lev el are then needed to mitigate this risk.
Here, these services need to be provided below Tetrys in order to enab Here, these services need to be provided below Tetrys in order to enab
le the receiver to drop undesired packets and only transfer legitimate packets t le the receiver to drop undesired packets and only transfer legitimate packets t
o the Tetrys Decoder. o the Tetrys decoder.
It should be noted that forging or modifying Feedback Packets will not It should be noted that forging or modifying feedback packets will not
corrupt the content, although it will certainly compromize Tetrys operation (se corrupt the content, although it will certainly compromise Tetrys operation (se
e next section). e <xref target="security-attack-against-signaling"/>).
</t> </t>
</section> </section>
<section anchor="security-attack-against-signaling" numbered="true" toc="d
efault">
<name>Attacks against Signaling</name>
<t>
Attacks on signaling information (e.g., by forging or modifying feedba
ck packets to falsify the good reception or recovery of source content) can easi
ly prevent the Tetrys decoder from recovering the source flow, thereby creating
a DoS.
In order to prevent this type of attack, content integrity and source
authentication services at the packet level are needed for the feedback flow fro
m the Tetrys decoder to the Tetrys encoder as well.
These services need to be provided below Tetrys in order to drop undes
ired packets and only transfer legitimate feedback packets to the Tetrys encoder
.
</t>
<t>
Conversely, an attacker in position to selectively drop feedback packe
ts (instead of modifying them) will not severely impact the function of Tetrys s
ince it is naturally robust when challenged with such losses.
However, it will have side impacts, such as the use of bigger linear s
ystems (since the Tetrys encoder cannot remove well-received or decoded source p
ackets from its linear system), which mechanically increases computational costs
on both sides (encoder and decoder).
</t>
</section>
<section anchor="security-attack-against-network" numbered="true" toc="def
ault">
<name>Attacks against the Network</name>
<t>
Tetrys can react to congestion signals (<xref target="transport-issue"
format="default"/>) in order to provide a certain level of fairness with other
flows on a shared network.
This ability could be exploited by an attacker to create or reinforce
congestion events (e.g., by forging or modifying feedback packets) that can pote
ntially impact a significant number of nodes attached to the network.
In order to mitigate the risk, content integrity and source authentica
tion services at the packet level are needed to enable the receiver to drop unde
sired packets and only transfer legitimate packets to the Tetrys encoder and dec
oder.
</t>
</section>
<section anchor="security-baseline-security" numbered="true" toc="default"
>
<name>Baseline Security Operation</name>
<t>
Tetrys can benefit from an IPsec / Encapsulating Security Payload (IPs
ec/ESP) <xref target="RFC4303" format="default"/> that provides confidentiality,
origin authentication, integrity, and anti-replay services in particular.
IPsec/ESP can be used to protect the Tetrys data flows (both directions)
against attackers located within the interconnection network or attackers in pos
ition to eavesdrop traffic, inject forged traffic, or replay legitimate traffic.
</t>
</section>
</section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<section anchor="security-attack-against-signaling" title="Attacks again <displayreference target="I-D.singh-rmcat-adaptive-fec" to="RMCAT-ADAPTIVE-FEC"/
st Signaling" numbered="true" toc="default"> >
<t>
Attacks on signaling information (e.g., by forging or modifying Feedba
ck Packets to pretend the good reception or recovery of source content) can easi
ly prevent the Tetrys Decoder to recover the source flow, thereby creating a DoS
.
In order to prevent this type of attack, content integrity and source
authentication services at the packet level are needed for the feedback flow, fr
om the Tetrys Decoder to the Tetrys Encoder, as well.
These services need to be provided below Tetrys, in order to drop unde
sired packets and only transfer legitimate Feedback Packets to the Tetrys Encode
r.
</t>
<t>
On the opposite, an attacker in position to selectively drop Feedback
Packets (instead of modifying them) will not severily impact Tetrys functionning
, since Tetrys is naturally robust in front of such losses.
However it will have side impacts, like the use of bigger linear syste
ms (since the Tetrys Encoder cannot remove well received or decoded source packe
ts from its linear system), which mechanically increases computational costs on
both sides, encoder and decoder.
</t>
</section>
<section anchor="security-attack-against-network" title="Attacks against <references>
the Network" numbered="true" toc="default"> <name>References</name>
<t> <references>
Tetrys can react to congestion signals (<xref target="transport-issue" <name>Normative References</name>
/>) in order to provide a certain level of fairness with other flows on a share <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
d network. 119.xml"/>
This ability could be exploited by an attacker to create or reinforce <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
congestion events (e.g., by forging or modifying Feedback Packets), which can po 174.xml"/>
tentially impact a significant number of nodes attached to the network. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
Here also, in order to mitigate the risk, content integrity and source 052.xml"/>
authentication services at the packet level are needed to enable the receiver t <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
o drop undesired packets and only transfer legitimate packets to the Tetrys Enco 445.xml"/>
der and Decoder. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</t> 303.xml"/>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
510.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
651.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
740.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
363.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
8406.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
680.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
265.xml"/>
</references>
<references>
<name>Informative References</name>
<section anchor="security-baseline-security" title="Baseline Security Op <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
eration" numbered="true" toc="default"> .singh-rmcat-adaptive-fec.xml"/>
<t>
Tetrys can benefit from an IPsec/Encapsulating Security Payload (IPsec
/ESP) <xref target="RFC4303" pageno="false" format="default" />, that provides i
n particular confidentiality, origin authentication, integrity, and anti-replay
services.
IPsec/ESP can be useful to protect the Tetrys data flows (both directions
) against attackers located within the interconnection network, in position to e
avesdrop traffic, or inject forged traffic, or replay legitimate traffic.
</t>
</section>
</section> <reference anchor="AHL-00" target="https://doi.org/10.1109/18.850663">
<front>
<title>Network information flow</title>
<author initials="R." surname="Ahlswede">
<organization/>
</author>
<author initials="N." surname="Cai">
<organization/>
</author>
<author initials="S." surname="Li">
<organization/>
</author>
<author initials="R." surname="Yeung">
<organization/>
</author>
<date month="July" year="2000"/>
</front>
<seriesInfo name="DOI" value="10.1109/18.850663"/>
<refcontent>IEEE Transactions on Information Theory, Vol. 46, Issue 4,
pp. 1204-1216</refcontent>
</reference>
<!-- <reference anchor="Tetrys" target="https://doi.org/10.1109/IWSSC.2008.46
<section anchor="security" title="Security Considerations" numbered="true" 56755">
toc="default"> <front>
<t> <title>Rethinking reliability for long-delay networks</title>
Tetrys inherits a subset of the security issues described in FECFRAM <author initials="J." surname="Lacan">
E <organization/>
<xref target="RFC8680" pageno="false" format="default" /> </author>
and in particular in sections "9.2.2. Content Corruption" and "9.3. <author initials="E." surname="Lochin">
Attacks against the FEC Parameters". As an application layer end-to-end protocol <organization/>
, security considerations of Tetrys should also be comparable to those of HTTP/2 </author>
with TLS. <date month="October" year="2008"/>
The considerations from Section 10 of HTTP2 </front>
<xref target="RFC7540" pageno="false" format="default" /> <seriesInfo name="DOI" value="10.1109/IWSSC.2008.4656755"/>
also apply in addition to those listed here. <refcontent>International Workshop on Satellite and Space Communicatio
</t> ns, Toulouse, France, pp. 90-94</refcontent>
</section> </reference>
<section anchor="iana" title="IANA Considerations" numbered="true" toc="de <reference anchor="Tetrys-RT" target="http://dx.doi.org/10.1109/TMM.2011
fault"> .2126564">
<!-- ==================================== --> <front>
<t>This document does not ask for any IANA registration.</t> <title>On-the-Fly Erasure Coding for Real-Time Video Applications</t
</section> itle>
<section anchor="implementation" title="Implementation Status" numbered="t <author initials="P." surname="Tournoux">
rue" toc="default"> <organization/>
<t>Editor's notes: RFC Editor, please remove this section motivated by </author>
RFC 7942 before publishing the RFC. Thanks!</t> <author initials="E." surname="Lochin">
<t>An implementation of Tetrys exists: <organization/>
<list> </author>
<t>organization: ISAE-SUPAERO</t> <author initials="J." surname="Lacan">
<t>Description: This is a proprietary implementation made by ISAE <organization/>
-SUPAERO</t> </author>
<t>Maturity: "production"</t> <author initials="A." surname="Bouabdallah">
<t>Coverage: this software implements TETRYS with some modificati <organization/>
ons</t> </author>
<t>Licensing: proprietary</t> <author initials="V." surname="Roca">
<t>Implementation experience: maximum</t> <organization/>
<t>Information update date: January 2022</t> </author>
<t>Contact: jonathan.detchart@isae-supaero.fr</t> <date month="August" year="2011"/>
</list> </front>
</t> <seriesInfo name="DOI" value="10.1109/TMM.2011.2126564"/>
</section> <refcontent>IEEE Transactions on Multimedia, Vol. 13, Issue 4, pp. 797
<section anchor="ack" title="Acknowledgments" numbered="true" toc="default -812</refcontent>
"> </reference>
<!-- ==================================== -->
<t>First, the authors want sincerely to thank Marie-Jose Montpetit for <reference anchor="CTCP" target="https://arxiv.org/abs/1212.2291">
continuous help and support on Tetrys. Marie-Jo, many thanks!</t> <front>
<t>The authors also wish to thank NWCRG group members for numerous disc <title>Network Coded TCP (CTCP)</title>
ussions on on-the-fly coding that helped finalize this document.</t> <author initials="M." surname="Kim">
<t>Finally, the authors would like to thank Colin Perkins for providing </author>
comments and feedback on the document.</t> <author initials="J." surname="Cloud">
</section> </author>
</middle> <author initials="A." surname="ParandehGheibi">
<back> </author>
<references title="Normative References"> <author initials="L." surname="Urbina">
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc </author>
2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2 <author initials="K." surname="Fouli">
119.xml"> </author>
<front> <author initials="D." surname="Leith">
<title>Keywords for use in RFCs to Indicate Requirement Levels</t </author>
itle> <author initials="M." surname="Medard">
<author initials="S." surname="Bradner" fullname="S. Bradner"> </author>
<organization /> <date month="April" year="2013"/>
</author> </front>
<date year="1997" month="March" /> <seriesInfo name="arXiv" value="1212.2291v3"/>
<abstract> </reference>
<t>In many standards track documents, several words are used t
o signify the requirements in the specification. These words are often capitali <reference anchor="A-FEC" target="https://doi.org/10.1109/INFCOM.1999.75
zed. This document defines these words as they should be interpreted in IETF doc 2166">
uments. This document specifies an Internet Best Current Practices for the Inte <front>
rnet Community, and requests discussion and suggestions for improvements.</t> <title>Adaptive FEC-based error control for Internet telephony</titl
</abstract> e>
</front> <author initials="J." surname="Bolot">
<seriesInfo name="BCP" value="14" /> <organization/>
<seriesInfo name="RFC" value="2119" /> </author>
<seriesInfo name="DOI" value="10.17487/RFC2119" /> <author initials="S." surname="Fosse-Parisis">
</reference> <organization/>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc </author>
8174"> <author initials="D." surname="Towsley">
<front> <organization/>
<title> </author>
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words <date month="March" year="1999"/>
</title> </front>
<author initials="B." surname="Leiba" fullname="B. Leiba"> <refcontent>IEEE INFOCOM '99, Conference on Computer Communications, N
<organization/> ew York, NY, USA, Vol. 3, pp. 1453-1460</refcontent>
</author> <seriesInfo name="DOI" value="10.1109/INFCOM.1999.752166"/>
<date year="2017" month="May"/> </reference>
<abstract>
<t> <reference anchor="RED-FEC" target="https://doi.org/10.1109/TBC.2008.200
RFC 2119 specifies common key words that may be used in protoc 1713">
ol specifications. This document aims to reduce the ambiguity by clarifying that <front>
only UPPERCASE usage of the key words have the defined special meanings. <title>A RED-FEC Mechanism for Video Transmission Over WLANs</title>
</t> <author initials="C." surname="Lin">
</abstract> <organization/>
</front> </author>
<seriesInfo name="BCP" value="14"/> <author initials="C." surname="Shieh">
<seriesInfo name="RFC" value="8174"/> <organization/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> </author>
</reference> <author initials="N." surname="Chilamkurti">
<?rfc include="reference.RFC.3452.xml"?> <organization/>
<?rfc include="reference.RFC.4303.xml"?> </author>
<?rfc include="reference.RFC.5510.xml"?> <author initials="C." surname="Ke">
<?rfc include="reference.RFC.5651.xml"?> <organization/>
<?rfc include="reference.RFC.5740.xml"?> </author>
<?rfc include="reference.RFC.6363.xml"?> <author initials="W." surname="Hwang">
<!-- <?rfc include="reference.RFC.7540.xml"?>--> <organization/>
<?rfc include="reference.RFC.8406.xml"?> </author>
<?rfc include="reference.RFC.8680.xml"?> <date month="September" year="2008"/>
<?rfc include="reference.RFC.9265.xml"?> </front>
</references> <refcontent>IEEE Transactions on Broadcasting, Vol. 54, Issue 3, pp. 5
<references title="Informative References"> 17-524</refcontent>
<!-- <?rfc include="reference.I-D.li-tsvwg-loops-problem-opportunities.x <seriesInfo name="DOI" value="10.1109/TBC.2008.2001713"/>
ml"?> --> </reference>
<?rfc include="reference.I-D.singh-rmcat-adaptive-fec.xml"?>
<reference anchor="AHL-00" quote-title="true"> <reference anchor="THAI" target="https://doi.org/10.1016/j.image.2014.02
<front> .003">
<title>Network information flow</title> <front>
<author initials="R." surname="Ahlswede"> <title>Joint on-the-fly network coding/video quality adaptation for
<organization /> real-time delivery</title>
</author> <author initials="T." surname="Tran Thai">
<author initials="" surname="Ning Cai"> <organization/>
<organization /> </author>
</author> <author initials="J." surname="Lacan">
<author initials="S.-Y.R." surname="Li"> <organization/>
<organization /> </author>
</author> <author initials="E." surname="Lochin">
<author initials="R.W." surname="Yeung"> <organization/>
<organization /> </author>
</author> <date month="April" year="2014"/>
<date month="July" year="2000" /> </front>
</front> <refcontent>Signal Processing: Image Communication, Vol. 29 Issue 4, p
<seriesInfo name="IEEE Transactions on Information Theory" value="vo p. 449-461</refcontent>
l.46, no.4, pp.1204,1216" /> <seriesInfo name="DOI" value="10.1016/j.image.2014.02.003"/>
</reference> </reference>
<reference anchor="Tetrys" quote-title="true">
<front>
<title>Rethinking reliability for long-delay networks</title>
<author initials="J." surname="Lacan">
<organization />
</author>
<author initials="E." surname="Lochin">
<organization />
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="International Workshop on Satellite and Space Comm
unications 2008" value="(IWSSC08)" />
</reference>
<reference anchor="Tetrys-RT" quote-title="true">
<front>
<title>On-the-fly erasure coding for real-time video applications
</title>
<author initials="P.U." surname="Tournoux">
<organization />
</author>
<author initials="E." surname="Lochin">
<organization />
</author>
<author initials="J." surname="Lacan">
<organization />
</author>
<author initials="A." surname="Bouabdallah">
<organization />
</author>
<author initials="V." surname="Roca">
<organization />
</author>
<date month="August" year="2011" />
</front>
<seriesInfo name="IEEE Transactions on Multimedia, Vol 13, Issue 4,
August 2011" value="(TMM.2011)" />
</reference>
<reference anchor="CTCP">
<front>
<title>Network Coded TCP (CTCP)</title>
<author initials="M" surname="Kim (et al.)">
</author>
<date year="2013"/>
</front>
<seriesInfo name="arXiv" value="1212.2291v3"/>
</reference>
<reference anchor="A-FEC" quote-title="true">
<front>
<title>Adaptive FEC-based error control for Internet telephony</t
itle>
<author initials="J." surname="Bolot">
<organization />
</author>
<author initials="S." surname="Fosse-Parisis">
<organization />
</author>
<author initials="D." surname="Towsley">
<organization />
</author>
<date year="1999" />
</front>
<seriesInfo name="IEEE INFOCOM 99, pp. 1453-1460 vol. 3" value="DOI
10.1109/INFCOM.1999.752166" />
</reference>
<reference anchor="RED-FEC" quote-title="true">
<front>
<title>A RED-FEC Mechanism for Video Transmission Over WLANs</tit
le>
<author initials="C." surname="Lin">
<organization />
</author>
<author initials="C." surname="Shieh">
<organization />
</author>
<author initials="N. K." surname="Chilamkurti">
<organization />
</author>
<author initials="C." surname="Ke">
<organization />
</author>
<author initials="H. S." surname="Hwang">
<organization />
</author>
<date month="September" year="2008" />
</front>
<seriesInfo name="IEEE Transactions on Broadcasting, vol. 54, no. 3,
pp. 517-524" value="DOI 10.1109/TBC.2008.2001713" />
</reference>
<reference anchor="THAI" quote-title="true">
<front>
<title>Joint on-the-fly network coding/video quality adaptation f
or real-time delivery</title>
<author initials="T." surname="Tran-Thai">
<organization />
</author>
<author initials="J." surname="Lacan">
<organization />
</author>
<author initials="E." surname="Lochin">
<organization />
</author>
<date year="2014" />
</front>
<seriesInfo name="Signal Processing: Image Communication, vol. 29 (n
o. 4), pp. 449-461" value="ISSN 0923-5965" />
</reference>
</references> </references>
</back> </references>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>First, the authors want sincerely to thank <contact fullname="Marie-
Jose
Montpetit"/> for continuous help and support on Tetrys. Marie-Jo, many thanks!</
t>
<t>The authors also wish to thank NWCRG group members for numerous discuss
ions on
on-the-fly coding that helped finalize this document.</t>
<t>Finally, the authors would like to thank <contact fullname="Colin Perki
ns"/> for
providing comments and feedback on the document.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 50 change blocks. 
1287 lines changed or deleted 1139 lines changed or added

This html diff was produced by rfcdiff 1.48.