<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id$ -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category="exp" consensus="true" docName="draft-irtf-nwcrg-tetrys-04" number="9407" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
   <?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
   <?rfc toc="yes"?>
   <?rfc tocompact="yes"?>
   <?rfc tocdepth="3"?>
   <?rfc tocindent="yes"?>
   <?rfc symrefs="yes"?>
   <?rfc sortrefs="yes"?>
   <?rfc comments="yes"?>
   <?rfc inline="yes"?>
   <?rfc compact="yes"?>
   <?rfc subcompact="no"?>
   <?rfc iprnotified="no" ?>
   <?rfc strict="yes" ?> xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

   <front>
    <title abbrev="Tetrys Network Coding Protocol">Tetrys, an Protocol">Tetrys: An On-the-Fly Network Coding Protocol</title>
    <seriesInfo name="RFC" value="9407"/>
    <author fullname="Jonathan Detchart" initials="J." surname="Detchart">
      <organization>ISAE-SUPAERO</organization>
      <address>
        <postal>
          <street>10, avenue Edouard Belin</street>
               <street>BP 54032</street>
          <extaddr>BP 54032</extaddr>
          <city>Toulouse CEDEX 4</city>
          <code>31055</code>
          <country>France</country>
        </postal>
        <email>jonathan.detchart@isae-supaero.fr</email>
      </address>
    </author>
    <author fullname="Emmanuel Lochin" initials="E." surname="Lochin">
      <organization>ENAC</organization>
      <address>
        <postal>
          <street>7, avenue Edouard Belin</street>
          <city>Toulouse</city>
          <code>31400</code>
          <country>France</country>
        </postal>
        <email>emmanuel.lochin@enac.fr</email>
      </address>
    </author>
    <author fullname="Jerome Lacan" initials="J." surname="Lacan">
      <organization>ISAE-SUPAERO</organization>
      <address>
        <postal>
          <street>10, avenue Edouard Belin</street>
               <street>BP 54032</street>
          <extaddr>BP 54032</extaddr>
          <city>Toulouse CEDEX 4</city>
          <code>31055</code>
          <country>France</country>
        </postal>
        <email>jerome.lacan@isae-supaero.fr</email>
      </address>
    </author>
    <author fullname="Vincent Roca" initials="V." surname="Roca">
      <organization>INRIA</organization>
      <address>
        <postal>
          <street>655, avenue de l'Europe</street>
               <street>Inovallee; Montbonnot</street>
               <city>ST ISMIER cedex</city>
          <extaddr>Inovallee; Montbonnot</extaddr>
          <city>St Ismier CEDEX</city>
          <code>38334</code>
          <country>France</country>
        </postal>
        <email>vincent.roca@inria.fr</email>
      </address>
    </author>
    <date year="2023" month="June" />
      <area />
      <workgroup>NWCRG</workgroup>
    <workgroup>Coding for Efficient NetWork Communications</workgroup>
    <keyword>Network Coding</keyword>
    <abstract>
      <t>This document describes Tetrys, which is an On-The-Fly Network Coding (NC) on-the-fly network coding protocol that can be used to transport delay-sensitive and loss-sensitive data over a lossy network. Tetrys may recover from erasures within an RTT-independent delay, delay thanks to the transmission of Coded Packets. coded packets.
This document is a record of the experience gained by the authors while developing and testing the Tetrys protocol in real conditions.</t>
      <t>
            This document is a product of the Coding for Efficient Network NetWork Communications Research Group (NWCRG).
It conforms to the NWCRG taxonomy<xref target="RFC8406" />. taxonomy described in RFC 8406.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction" numbered="true" toc="default">
         <!-- ==================================== -->
      <name>Introduction</name>
         <t>This document is a product of and represents the collaborative work
	   and consensus of the Coding for Efficient Network NetWork Communications
	   Research Group (NWCRG). It is not an IETF product and is not or an IETF standard.</t>
         <t>
            This
      <t>This document describes Tetrys, a novel erasure which is an on-the-fly network coding protocol.
            protocol that can be used to transport delay-sensitive and
            loss-sensitive data over a lossy network.
            Network codes were introduced in the early 2000s <xref
            target="AHL-00" pageno="false" format="default" /> format="default"/> to address the limitations of
            transmission over the Internet (delay, capacity capacity, and packet
            loss). While network codes have seen some deployment fairly
            recently in the Internet community, the use of application layer application-layer
            erasure codes in the IETF has already been standardized in the RMT
            <xref target="RFC3452" pageno="false" format="default" /> target="RFC5052" format="default"/> <xref target="RFC5445" format="default"/>
            and the FECFRAME
            <xref target="RFC8680" pageno="false" format="default" />
            working groups. format="default"/>
            Working Groups. The protocol presented here may be seen as a network coding network-coding extension to standard unicast transport protocols (or even multicast or anycast with a few modifications).  The current proposal may be considered a combination of network erasure coding and feedback mechanisms
            <xref target="Tetrys" pageno="false" format="default" />, format="default"/> <xref target="Tetrys-RT" pageno="false" format="default"/>
            . format="default"/>.
      </t>
      <t>The main innovation of the Tetrys protocol is in the generation of Coded Packets coded packets from an Elastic Encoding Window. elastic encoding window. This window is filled by any Source Packets source packets coming from an input flow and is periodically updated with the receiver feedback.
These feedback messages provide to the sender with information about the
highest sequence number received or rebuilt, which can enable the flushing the
corresponding Source Packets source packets stored in the encoding window. The size of this
window may be fixed or dynamically updated. If the window is full, incoming Source Packets
source packets replace older sources source packets which that are dropped. As a matter of
fact, its limit should be correctly sized.

Finally, Tetrys allows to deal dealing with losses on both the forward and return paths and in particular, is particularly resilient to acknowledgment losses. All these operations are further detailed in <xref target="tetrys_basic_functions" pageno="false" format="default" />.</t> format="default"/>.</t>
      <t>With Tetrys, a Coded Packet coded packet is a linear combination over a finite field of the data Source Packets source packets belonging to the coding window.

The coefficients finite field's choice of coefficients, as finite fields elements, is a trade-off between the best erasure recovery performance (finite fields of 256 elements) and the system constraints (finite fields of 16 elements is are preferred) and is driven by the application.</t>
      <t>Thanks to the Elastic Encoding Window, elastic encoding window, the Coded Packets coded packets are built on-the-fly, on-the-fly by using a predefined method to choose the coefficients. The redundancy ratio may be dynamically adjusted, adjusted and the coefficients may be generated in different ways, ways during the transmission. Compared to FEC Forward Error Correction (FEC) block codes, this allows reducing reduces the bandwidth use and the decoding delay.</t>
      <t>The description of the design description of the Tetrys protocol in this document is complemented by a record of the experience gained by the authors while developing and testing the Tetrys protocol in realistic conditions. In particular, several research issues are discussed in <xref target="research" pageno="false" format="default" /> format="default"/> following our own experience and observations.</t>
      <section title="Requirements Notation" numbered="true" toc="default">
            <!-- ==================================== -->
        <name>Requirements Notation</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP14 BCP&nbsp;14 <xref target="RFC2119" pageno="false" format="default" /> target="RFC2119"/> <xref target="RFC8174" pageno="false" format="default" /> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="terminology" title="Definitions, Notations and Abbreviations" numbered="true" toc="default">
         <!-- ==================================== -->
      <name>Definitions, Notations, and Abbreviations</name>
                <t>
                  The notation used in this document is based on the NWCRG taxonomy
                  <xref target="RFC8406" pageno="false" format="default" />
                  . format="default"/>.
      </t>
         <t>
            <list style="empty">
               <t>Source Symbol: a
<dl spacing="normal" newline="false">
        <dt>Source Symbol:</dt><dd>A symbol that is transmitted between the ingress and egress of the network.</t>
               <t>Coded Symbol: a network.</dd>
        <dt>Coded Symbol:</dt><dd>A linear combination over a finite field of a set of Source Symbols.</t>
               <t>Source source symbols.</dd>
        <dt>Source Symbol ID: a ID:</dt><dd>A sequence number to identify the Source Symbols.</t>
               <t>Coded source symbols.</dd>
        <dt>Coded Symbol ID: a ID:</dt><dd>A sequence number to identify the Coded Symbols.</t>
               <t>Encoding Coefficients: elements coded symbols.</dd>
        <dt>Encoding Coefficients:</dt><dd>Elements of the finite field characterizing the linear combination used to generate Coded Symbols.</t>
               <t>Encoding Vector: a coded symbols.</dd>
        <dt>Encoding Vector:</dt><dd>A set of the coding coefficients and input Source Symbol IDs.</t>
               <t>Source Packet: a Source Packet source symbol IDs.</dd>
        <dt>Source Packet:</dt><dd>A source packet contains a Source Symbol source symbol with its associated IDs.</t>
               <t>Coded Packet: a Coded Packet IDs.</dd>
        <dt>Coded Packet:</dt><dd>A coded packet contains a Coded Symbol, coded symbol, the Coded Symbol's coded symbol's ID, and Encoding Vector.</t>
               <t>Input Symbol: a encoding vector.</dd>
        <dt>Input Symbol:</dt><dd>A symbol at the input of the Tetrys Encoder.</t>
               <t>Output Symbol: a encoder.</dd>
        <dt>Output Symbol:</dt><dd>A symbol generated by the Tetrys Encoder. encoder. For a non-systematic mode, all Output Symbols output symbols are Coded Symbols. coded symbols. For a systematic mode, Output Symbols MAY output symbols <bcp14>MAY</bcp14> be the Input Symbols input symbols and a number of Coded Symbols coded symbols that are linear combinations of the Input Symbols + input symbols plus the Encoding Vectors.</t>
               <t>Feedback Packet: a Feedback Packet encoding vectors.</dd>
        <dt>Feedback Packet:</dt><dd>A feedback packet is a packet containing information about the decoded or received Source Symbols. source symbols. It MAY <bcp14>MAY</bcp14> also contain additional information about the Packet Error Rate or the number of various packets in the receiver decoding window.</t>
               <t>Elastic window.</dd>
        <dt>Elastic Encoding Window: an Window:</dt><dd>An encoder-side buffer that stores all the non-acknowledged Source Packets unacknowledged source packets of the input flow involved in the coding process.</t>
               <t>Coding process.</dd>
<dt>Coding Coefficient Generator Identifier: a Identifier (CCGI):</dt><dd>A unique identifier that
defines a function or an algorithm allowing to generate the Encoding Vector.</t>
               <t>Code Rate: Define generation of the encoding
vector.</dd>
        <dt>Code Rate:</dt><dd>Defines the rate between the number of Input Symbols input symbols and the number of Output Symbols.</t>
            </list>
         </t> output symbols.</dd>
      </dl>
    </section>
    <section anchor="tetrys_architecture" title="Architecture" numbered="true" toc="default">
         <!-- ==================================== -->
      <name>Architecture</name>
         <section anchor="use_cases" title="Use Cases" numbered="true" toc="default">
            <!-- ==================================== -->
        <name>Use Cases</name>
            <t>Tetrys is well suited, but not limited to, limited, to the use case where
            there is a single flow originated by a single source, source with intra stream intra-stream
            coding at a single encoding node. Note that the input
            stream MAY <bcp14>MAY</bcp14> be a multiplex of several upper layer upper-layer
            streams.  Transmission MAY <bcp14>MAY</bcp14> be over a single path or
            multiple paths.
This is the simplest use-case, use case that is very much quite
            aligned with currently proposed scenarios for end-to-end
            streaming.</t>
      </section>
      <section anchor="protocol_overview" title="Overview" numbered="true" toc="default">
            <!-- ==================================== -->
        <name>Overview</name>
            <figure anchor="fig-archi-tetrys" title="Tetrys Architecture" suppress-title="false" align="left" alt="" width="" height=""> anchor="fig-archi-tetrys">
          <name>Tetrys Architecture</name>
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""> alt=""><![CDATA[
   +----------+                +----------+
   |          |                |          |
   |    App   |                |    App   |
   |          |                |          |
   +----------+                +----------+
        |                           ^
        |  Source           Source  |
        |  Symbols          Symbols |
        |                           |
        v                           |
   +----------+                +----------+
   |          | output packets Output Packets |          |
   |  Tetrys  |---------------&gt;|  |--------------->|  Tetrys  |
   |  Encoder |Feedback Packets|  Decoder |
   |          |&lt;---------------|          |<---------------|          |
   +----------+                +----------+
</artwork>
]]></artwork>
        </figure>
        <t>
               The Tetrys protocol features several key functionalities. The mandatory features are:
               <list style="symbols">
                  <t>on-the-fly encoding;</t>
                  <t>decoding;</t>
                  <t>signaling, include:
        </t>
        <ul spacing="normal">
          <li>on-the-fly encoding;</li>
          <li>decoding;</li>
          <li>signaling, to carry in particular the symbol identifiers IDs in the encoding window and the associated coding coefficients when meaningful;</t>
                  <t>feedback management;</t>
                  <t>elastic meaningful;</li>
          <li>feedback management;</li>
          <li>elastic window management;</t>
                  <t>Tetrys management; and</li>
          <li>Tetrys packet header creation and processing;</t>
               </list>
            </t>
            <t>
               and the processing.</li>
        </ul>
        <t>The optional features are :
               <list style="symbols">
                  <t>channel estimation;</t>
                  <t>dynamic include:
        </t>
        <ul spacing="normal">
          <li>channel estimation;</li>
          <li>dynamic adjustment of the Code Rate code rate and flow control;</t>
                  <t> control; and</li>
          <li>
                     congestion control management (if appropriate). See <xref
                     target="transport-issue" /> format="default"/> for further details;
                  </t>
               </list>
            </t>
                     details.
                  </li>
        </ul>
        <t>
               Several building blocks provide these the following functionalities:
               <list style="symbols">
                  <t>The
        </t>
        <dl spacing="normal">
          <dt>The Tetrys Building Block: this BB Block:</dt><dd>This building block embeds
          both the Tetrys Decoder decoder and Tetrys Encoder and encoder; thus, it is used during encoding,
          encoding and decoding processes. It must be noted that Tetrys does
          not mandate a specific building block.  Instead, any building block
          compatible with the Elastic Encoding Window elastic encoding window feature of Tetrys may be used.</t>
                  <t>
                     The
          used.</dd>
          <dt>The Window Management Building Block: this Block:</dt><dd>This building block
                     is in charge of managing the encoding window at a Tetrys
                     sender.
                  </t>
               </list>
            </t>
                  </dd>
        </dl>
        <t>
               To ease the addition of future components and services, Tetrys adds a header extension mechanism, mechanism that is compatible with that of LCT Layered Coding Transport (LCT)
               <xref target="RFC5651" />, NORM format="default"/>, NACK-Oriented Reliable Multicast (NORM)
               <xref target="RFC5740" />, FECFRAME format="default"/>, and FEC Framework (FECFRAME)
               <xref target="RFC8680" />. format="default"/>.
        </t>
            <!--	VR: pas d'accord... JL: OK, a discuter.
			<t>Tetrys uses three building blocks to provide a reliable protocol:</t>
			<t>    - The Tetrys Encoding Building Block creates some linear combinations of all the non-acknowledged Input Symbols. An upper limit can be set to avoid big computations. Each linear combination is called a Coded Symbol. It is associated to an Encoding Vector, which MUST defines the Input Symbols and MAY define the coefficients used in the combinations. If not, a Coding Coefficient Generator Identifier (CCGI) is used to identify the function or the algorithm used to rebuild the coefficients.</t>
			<t>    - The Tetrys Relaying Building Block transmits input packets received from the source or a relay node to a relay node or the destination 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 process).</t>
			<t>    - The Tetrys Decoding Building Block stores all the 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 packet containing information about the acknowledgment of received and decoded Source Symbols.
				When this information is received by a Tetrys Encoding 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 window. Each generated Output Symbols is encapsulated in an output packet format. </t>
			-->
         </section>
    </section>
    <section anchor="tetrys_basic_functions" title="Tetrys Basic Functions" numbered="true" toc="default">
         <!-- ==================================== -->
      <name>Tetrys Basic Functions</name>
         <section anchor="encoding" title="Encoding" numbered="true" toc="default">
            <!-- ==================================== -->
        <name>Encoding</name>
            <t>At the beginning of a transmission, a Tetrys Encoder MUST encoder <bcp14>MUST</bcp14> choose an initial Code Rate (added redundancy) code rate that adds redundancy as it doesn't know the packet loss rate of the channel.
In the steady state, depending on the Code Rate, the Tetrys Encoder MAY encoder <bcp14>MAY</bcp14> generate Coded Symbols coded symbols when it receives a Source Symbol source symbol from the application or some feedback from the decoding blocks.</t> blocks depending on the code rate.</t>
        <t>When a Tetrys Encoder encoder needs to generate a Coded Symbol, coded symbol, it considers the set of Source Symbols source symbols stored in the Elastic Encoding Window elastic encoding window and generates an Encoding Vector encoding vector with the Coded Symbol. coded symbol. These Source Symbols source symbols are the set of Source Symbols source symbols that are not yet acknowledged by the receiver. For each Source Symbol, source symbol, a finite field coefficient is determined using a Coding Coefficient Generator.
This generator MAY <bcp14>MAY</bcp14> take as input the Source Symbol source symbol IDs and the Coded Symbol coded symbol ID as an input and MAY <bcp14>MAY</bcp14> determine a coefficient in a deterministic way as presented in <xref target="coded-packet" pageno="false" format="default" />. format="default"/>. Finally, the Coded Symbol coded symbol is the sum of the Source Symbols source symbols multiplied by their corresponding coefficients.</t>
        <t>A Tetrys Encoder SHOULD encoder <bcp14>MUST</bcp14> set a limit to the Elastic Encoding Window elastic encoding 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 situations where all window update packets are all lost or absent.</t>
      </section>
      <section anchor="windowing" title="The Elastic Encoding Window" numbered="true" toc="default">
            <!-- ==================================== -->
        <name>The Elastic Encoding Window</name>
            <t>When an input Source Symbol source symbol is passed to a Tetrys Encoder, encoder, it is added to the Elastic Encoding Window. elastic encoding window. This window MUST <bcp14>MUST</bcp14> have a limit set by the encoding building Block. block.
If the Elastic Encoding Window elastic encoding window has reached its limit, the window slides over the symbols: the symbols. The first (oldest) symbol is removed, and the newest 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> coded symbols.</t>
        <t>As explained below, the Tetrys Decoder decoder sends periodic feedback indicating the received or decoded Source Symbols. source symbols. When the sender receives the information that a Source Symbol source symbol was received or decoded by the receiver, it removes this symbol from the coding window.</t>
      </section>
      <section anchor="decoding" title="Decoding" numbered="true" toc="default">
            <!-- ==================================== -->
        <name>Decoding</name>
            <t>A standard Gaussian elimination is sufficient to recover the erased Source Symbols, source symbols when the matrix rank enables it.</t>
      </section>
    </section>
    <section anchor="encapsulation-format" title="Packet Format" numbered="true" toc="default">
         <!-- ==================================== -->
      <name>Packet Format</name>
         <section anchor="common-packet-header-format" title="Common Header Format" numbered="true" toc="default">
            <!-- ==================================== -->
        <name>Common Header Format</name>
            <t>
               All types of Tetrys packets share the same common header format (see <xref target="fig-common-header-format" pageno="false" format="default" />). format="default"/>).
        </t>
        <figure anchor="fig-common-header-format" title="Common anchor="fig-common-header-format">
          <name>Common Header Format" suppress-title="false" align="left" alt="" width="" height=""> Format</name>
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""> alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   V   | C |S|     Reserved    |   HDR_LEN     |    PKT_TYPE   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Congestion Control Information (CCI, length = 32*C bits)    |
|                          ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Transport Session Identifier (TSI, length = 32*S bits)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Header Extensions (if applicable)              |
|                          ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
]]></artwork>
        </figure>
            </t>
        <t>As already noted above in the document, above, this format is inspired by, and inherits from from, the LCT header format <xref target="RFC5651" pageno="false" format="default" /> format="default"/> with slight modifications.</t>
            <t>
               <list style="symbols">
                  <t>Tetrys
        <dl spacing="normal">
          <dt>Tetrys version number (V): 4 (V):</dt><dd>4 bits.
			      Indicates the Tetrys version number.  The Tetrys version number for this specification is 1.</t>
                  <t>
                     Congestion 1.</dd>
          <dt>Congestion control flag (C): 2 (C):</dt><dd>2 bits.
                   C=0  C set to 0b00
                     indicates the Congestion Control Information (CCI) field
                     is 0 bits in length.  C=1  C set to 0b01 indicates the CCI field is 32
                     bits in length. C=2 C set to 0b10 indicates the CCI field is 64 bits in
                     length.  C=3  C set to 0b11 indicates the CCI field is 96 bits in
                     length.
                  </t>
                  <t>Transport
                  </dd>
          <dt>Transport Session Identifier flag (S): 1 (S):</dt><dd>1 bit.
      			 This is the number of full 32-bit words in the TSI field.  The TSI field is 32*S bits in length, length; i.e., the length is either 0 bits or 32 bits.</t>
                  <t>Reserved (Resv): 9 bits.</dd>
          <dt>Reserved (Resv):</dt><dd>9 bits. These bits are reserved.  In this version of the specification, they MUST <bcp14>MUST</bcp14> be set to zero by senders and MUST <bcp14>MUST</bcp14> be ignored by receivers.</t>
                  <t>Header receivers.</dd>
          <dt>Header length (HDR_LEN): 8 (HDR_LEN):</dt><dd>8 bits.  The total length of
          the Tetrys header in units of 32-bit words. The length of the Tetrys
          header MUST <bcp14>MUST</bcp14> be a multiple of 32 bits.  This field may
          be used to directly access the portion of the packet beyond the
          Tetrys header, i.e., to the first next header if it exists, or to the
          packet payload if it exists and there is no other header, or to the
          end of the packet if there are no others other headers or packet payload.</t>
                  <t>PKT_TYPE: Tetrys
          payload.</dd>
<dt>Tetrys packet type, 8 type (PKT_TYPE):</dt><dd>8 bits.
				Type of packet.
				There is 3 are three types of packets: the PKT_TYPE_SOURCE (0) (0b00) defined in <xref target="source-packet" pageno="false" format="default" />, format="default"/>, the PKT_TYPE_CODED (1) (0b01) defined in <xref target="coded-packet" pageno="false" format="default" /> format="default"/> and the PKT_TYPE_WND_UPT (3), (0b11) for window update packets defined in <xref target="ack-packet" pageno="false" format="default" />.</t>
            <t>Congestion format="default"/>.</dd>
          <dt>Congestion Control Information (CCI): 0, (CCI):</dt><dd>0, 32, 64, or 96 bits bits.
			      Used to carry congestion control information.  For example, the
			      congestion control information could include layer numbers,
			      logical channel numbers, and sequence numbers.  This field is
			      opaque for this specification.
			      This field MUST <bcp14>MUST</bcp14> be 0 bits (absent) if C=0. C is set to 0b00.
			      This field MUST <bcp14>MUST</bcp14> be 32 bits if C=1. C is set to 0b01.
			      This field MUST <bcp14>MUST</bcp14> be 64 bits if C=2. C is set to 0b10.
			      This field MUST <bcp14>MUST</bcp14> be 96 bits if C=3.</t>
                  <t>
                     Transport C is set to 0b11.</dd>

          <dt>Transport Session Identifier (TSI): 0 (TSI):</dt><dd>0 or 32 bits bits.
			      The TSI uniquely identifies a session among all sessions from a
			      particular Tetrys encoder. The TSI is scoped by the IP address of the
			      sender, and thus
			      sender; thus, the IP address of the sender and the TSI together
			      uniquely identify the session.
Although a TSI, TSI always uniquely identifies a session conjointly with
			      the IP address of the sender, always uniquely identifies a session, whether the TSI is included in the Tetrys header depends on
			      what is used as the TSI value.  If the underlying transport is
			      UDP, then the 16-bit UDP source port number MAY <bcp14>MAY</bcp14> serve as the TSI
			      for the session.
                     <!-- If the TSI value appears multiple times in a
			      packet, then all occurrences MUST be the same value. -->
                     If there is
			      no underlying TSI provided by the network, transport transport, or any other
			      layer, then the TSI MUST <bcp14>MUST</bcp14> be included in the Tetrys header.
                  </t>
               </list>
            </t>
                  </dd>
        </dl>
        <section anchor="header-extension-format" title="Header Extensions" numbered="true" toc="default">
               <!-- ==================================== -->
          <name>Header Extensions</name>
               <t>Header Extensions extensions are used in Tetrys to accommodate optional header fields that are not always used or have variable size. sizes.
				The presence of Header Extensions MAY header extensions <bcp14>MAY</bcp14> be inferred by the Tetrys header length (HDR_LEN).
				If HDR_LEN is larger than the length of the standard header, then the remaining header space is taken by Header Extensions.</t> header extensions.</t>
          <t>If present, Header Extensions MUST header extensions <bcp14>MUST</bcp14> be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting a packet.
				The default action for unrecognized Header Extensions header extensions is to ignore them.
				This allows for the future introduction of backward-compatible enhancements to Tetrys without changing the Tetrys version number.
				Non-backward-compatible
				Header Extensions CANNOT extensions that are not backward-compatible <bcp14>MUST NOT</bcp14> be introduced without changing the Tetrys version number.</t>
          <t>
                  There are two formats for Header Extensions header extensions as depicted in <xref target="fig:header_extension" pageno="false" format="default" /> :
                  <list style="symbols">
                     <t>The target="fig_header_extension" format="default"/>:
          </t>
          <ul spacing="normal">
            <li>The first format is used for variable-length extensions, extensions with Header Extension Type header extension type (HET) values between 0 and 127.</t>
                     <t>The 127.</li>
            <li>The second format is used for fixed-length (one 32-bit word) extensions, extensions using HET values from 128 to 255.</t>
                  </list>
               </t> 255.</li>
          </ul>
          <figure anchor="fig:header_extension" title="Header anchor="fig_header_extension">
            <name>Header Extension Format" suppress-title="false" align="left" alt="" width="" height=""> Format</name>
            <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""> alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  HET (&lt;=127) (<=127)  |       HEL     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
.                                                               .
.              Header Extension Content (HEC)                   .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  HET (&gt;=128) (>=128)  |       Header Extension Content (HEC)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
]]></artwork>
          </figure>
               <t>
                  <list style="symbols">
                     <t>Header
<dl spacing="normal">
            <dt>Header Extension Type (HET): 8 bits

				<t>The (HET):</dt><dd>8 bits. The type of the Header Extension. header extension. This document defines several possible types.
				Additional types may be defined in future versions of this specification.
				HET values from 0 to 127 are used for variable-length Header Extensions. header extensions.
				HET values from 128 to 255 are used for fixed-length fixed-length, 32-bit Header Extensions.</t>
            </t>
                     <t>Header header extensions.</dd>
              <dt>Header Extension Length (HEL): 8 bits
				<t>The (HEL):</dt><dd>8 bits. The length of the whole Header Extension field, header extension field expressed in multiples of 32-bit words.
				This field MUST <bcp14>MUST</bcp14> be present for variable-length extensions (HETs between 0 and 127) and MUST NOT <bcp14>MUST NOT</bcp14> be present for fixed-length extensions (HETs between 128 and 255).</t></t>
                     <t>Header 255).</dd>
              <dt>Header Extension Content (HEC): variable length
				<t>The (HEC):</dt><dd>Length of the variable. The content of the Header Extension. header extension.
				The format of this subfield depends on the Header Extension Type. header extension type.
				For fixed-length Header Extensions, header extensions, the HEC is 24 bits.
				For variable-length Header Extensions, header extensions, the HEC field has a variable size, size as specified by the HEL field.
				Note that the length of each Header Extension MUST header extension <bcp14>MUST</bcp14> be a multiple of 32 bits.
				Also, note that
				Additionally, the total size of the Tetrys header, including all Header Extensions header extensions and all optional header fields, cannot exceed 255 32-bit words.</t></t>
                  </list>
               </t> words.</dd>
</dl>
        </section>
      </section>
      <section anchor="source-packet" title="Source Packet Format" numbered="true" toc="default">
            <!-- ==================================== -->
            <t>A Source
        <name>Source Packet Format</name>
            <t>A source packet is a Common Packet Header common packet header encapsulation, a Source Symbol ID source symbol ID, and a Source Symbol source symbol (payload). The Source Symbols MAY source symbols <bcp14>MAY</bcp14> have variable sizes.</t>
        <figure anchor="fig-src-pkt" title="Source anchor="fig-src-pkt">
          <name>Source Packet Format" suppress-title="false" align="left" alt="" width="" height=""> Format</name>
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""> alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                      Common Packet Header                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Source Symbol ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                            Payload                            /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
]]></artwork>
        </figure>
            <t>Common
<dl spacing="normal">
        <dt>Common Packet Header: a Header:</dt><dd>A common packet header (as common header format) where Packet Type=0.</t>
            <t>Source packet type is set to 0b00.</dd>
        <dt>Source Symbol ID: the ID:</dt><dd>The sequence number to identify a Source Symbol.</t>
            <t>Payload: the source symbol.</dd>
        <dt>Payload:</dt><dd>The payload (Source Symbol)</t> (source symbol).</dd>
</dl>
      </section>
      <section anchor="coded-packet" title="Coded Packet Format" numbered="true" toc="default">
            <!-- ==================================== -->
        <name>Coded Packet Format</name>
            <t>
               A Coded Packet coded packet is the encapsulation of a Common Packet Header, common packet header, a Coded Symbol coded symbol ID, the associated Encoding Vector, encoding vector, and a Coded Symbol coded symbol (payload).
               As the Source Symbols MAY source symbols <bcp14>MAY</bcp14> have variable sizes, all the Source Symbol source symbol sizes need to be encoded. To generate this encoded payload size, size as a 16-bit unsigned value, the linear combination uses the same coefficients as the coded payload. The result MUST <bcp14>MUST</bcp14> be stored in the Coded Packet coded packet as the Encoded Payload Size encoded payload size (16 bits): as bits). As it is an optional field, the Encoding Vector MUST encoding vector <bcp14>MUST</bcp14> signal the use of variable Source Symbol source symbol sizes with the field V (see <xref target="unified-encoding-vector-format" pageno="false" format="default" />). format="default"/>).
        </t>
        <figure anchor="fig-rpr-pkt" title="Coded anchor="fig-rpr-pkt">
          <name>Coded Packet Format" suppress-title="false" align="left" alt="" width="" height=""> Format</name>
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""> alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                      Common Packet Header                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Coded Symbol ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                         Encoding Vector                       /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Encoded Payload Size      |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
/                            Payload                            /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               </artwork>
]]></artwork>
        </figure>
            <t>Common
<dl spacing="normal">
        <dt>Common Packet Header: a Header:</dt><dd>A common packet header (as common header format) where Packet Type=1.</t>
            <t>Coded packet type is set to 0b01.</dd>
        <dt>Coded Symbol ID: the ID:</dt><dd>The sequence number to identify a Coded Symbol.</t>
            <t>Encoding Vector: an Encoding Vector coded symbol.</dd>
        <dt>Encoding Vector:</dt><dd>An encoding vector to define the linear combination used (coefficients and Source Symbols).</t>
            <t>Encoded source symbols).</dd>
        <dt>Encoded Payload Size: the Size:</dt><dd>The coded payload size used if the Source Symbols source symbols have a variable size (optional,<xref (optional, <xref target="unified-encoding-vector-format" pageno="false" format="default" />).</t>
            <t>Payload: the Coded Symbol.</t> format="default"/>).</dd>
        <dt>Payload:</dt><dd>The coded symbol.</dd>
</dl>
        <section anchor="unified-encoding-vector-format" title="The Encoding Vector" numbered="true" toc="default">
            <t>An
          <name>The Encoding Vector Vector</name>
          <t>An encoding vector contains all the information about the linear combination used to generate a Coded Symbol. coded symbol. The information includes the source identifiers and the coefficients used for each Source Symbol. source symbol. It MAY <bcp14>MAY</bcp14> be stored in different ways depending on the situation.</t>
          <figure anchor="fig-unif-enc-vec" title="Encoding anchor="fig-unif-enc-vec">
            <name>Encoding Vector Format" suppress-title="false" align="left" alt="" width="" height=""> Format</name>
            <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""> alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     EV_LEN    |  CCGI | I |C|V|    NB_IDS     |   NB_COEFS    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        FIRST_SOURCE_ID                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     b_id      |                                               |
+-+-+-+-+-+-+-+-+            id_bit_vector        +-+-+-+-+-+-+-+
|                                                 |   Padding   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                          coef_bit_vector        +-+-+-+-+-+-+-+
|                                                 |   Padding   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  </artwork>
]]></artwork>
          </figure>
               <t>
                  <list style="symbols">
                     <t>Encoding
<dl>
            <dt>Encoding Vector Length (EV_LEN) (8-bits): (EV_LEN):</dt><dd>8 bits. The size in
            units of 32-bit words.</t>
                     <t>Coding words.</dd>
              <dt>Coding Coefficient Generator Identifier (CCGI): 4-bit (CCGI):</dt><dd><t>4-bit ID to identify the algorithm or the function used to generate the coefficients. As a CCGI is included in each encoded vector, it MAY <bcp14>MAY</bcp14> dynamically change between the generation of 2 Coded Symbols. two coded symbols.
                     The CCGI builds the coding coefficients used to generate the Coded Symbols. coded symbols. They MUST <bcp14>MUST</bcp14> be known by all the Tetrys encoders or decoders.
                     The two RLC FEC schemes specified in this document reuse the Finite Fields finite fields defined in <xref target="RFC5510" pageno="false" format="default" />, Section 8.1. sectionFormat="comma" section="8.1"/>.
More specifically, the elements of the field GF(2^(m)) GF(2<sup>(m)</sup>) are represented by polynomials with binary coefficients (i.e., over GF(2)) and with degree lower or equal to m-1. The addition between two elements is defined as the addition of binary polynomials in GF(2), which is equivalent to a bitwise XOR operation on the binary representation of these elements.
                     With GF(2^(8)), GF(2<sup>(8)</sup>), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 8. The following irreducible polynomial is used for GF(2^(8)):

      x^(8) GF(2<sup>(8)</sup>):</t>

     <t indent="3">x<sup>(8)</sup> + x^(4) x<sup>(4)</sup> + x^(3) x<sup>(3)</sup> + x^(2) x<sup>(2)</sup> + 1

                    With GF(2^(4)), 1</t>

                    <t>With GF(2<sup>(4)</sup>), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 4. The following irreducible polynomial is used for GF(2^(4)):

      x^(4) GF(2<sup>(4)</sup>):</t>

      <t indent="3">x<sup>(4)</sup> + x + 1
                        <list style="ccgi">
                           <t>0: Vandermonde based
              </t>
              <ul spacing="normal">
                <li>0b00: Vandermonde-based coefficients over the finite field GF(2^(4)), GF(2<sup>(4)</sup>) as defined below. Each coefficient is built as alpha^( alpha<sup>( (source_symbol_id*coded-symbol_id) % 16), 16)</sup>, with alpha the root of the primitive polynomial.</t>
                           <t>1: Vandermonde based polynomial.</li>
                <li>0b01: Vandermonde-based coefficients over the finite field GF(2^(8)), GF(2<sup>(8)</sup>) as defined below. Each coefficient is built as alpha^( alpha<sup>( (source_symbol_id*coded-symbol_id) % 256), 256)</sup>, with alpha the root of the primitive polynomial.</t>
                           <t>Suppose polynomial.</li>
                <li>Suppose we want to generate the Coded Symbol coded symbol 2 as a linear combination of the Source Symbols 1,2,4 source symbols 1, 2, and 4 using CCGI=1. CCGI set to 0b01. The coefficients will be alpha^( alpha<sup>( (1 * 1) % 256), alpha^( 256)</sup>, alpha<sup>( (1 * 2) % 256), alpha^( 256)</sup>, and alpha<sup>( (1 * 4) % 256).</t>
                        </list>
                     </t>
                     <!-- <t>Store the Source Symbol IDs (I) (1 bit): if equal to 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> 256)</sup>.</li>
              </ul></dd>
              <dt>
                        Store the Source Symbol ID Format (I) (2 bits):
                        <list style="symbols">
                           <t>00
              </dt><dd>
              <ul spacing="normal">
                <li>0b00 means there is no Source Symbol source symbol ID information.</t>
                           <t>01 information.</li>
                <li>0b01 means the Encoding Vector encoding vector contains the edge blocks of the Source Symbol source symbol IDs without compression.</t>
                           <t>10 compression.</li>
                <li>0b10 means the Encoding Vector encoding vector contains the compressed list of the Source Symbol IDs.</t>
                           <t>11 source symbol IDs.</li>
                <li>0b11 means the Encoding Vector encoding vector contains the compressed edge blocks of the Source Symbol IDs.</t>
                        </list>
                     </t>
                     <t>Store source symbol IDs.</li>
              </ul>
            </dd>
            <dt>Store the Encoding Coefficients (C): 1 (C):</dt><dd>1 bit to indicate if an Encoding Vector encoding vector contains information about the coefficients used.</t>
                     <t>Having used.</dd>
            <dt>Having Source Symbols with Variable Size Encoding (V): set (V):</dt><dd>Set V to 1 0b01 if the combination which that refers to the Encoding Vector encoding vector is a combination of Source Symbols source symbols with variable sizes. In this case, the Coded Packets MUST coded packets <bcp14>MUST</bcp14> have the 'Encoded Payload Size' field.</t>
                     <t>NB_IDS: the field.</dd>
            <dt>NB_IDS:</dt><dd>The number of source IDs stored in the Encoding Vector encoding vector (depending on I).</t>
                     <t>Number I).</dd>
            <dt>Number of coefficients (NB_COEFS): The Coefficients (NB_COEFS):</dt><dd>The number of the coefficients used to generate the associated Coded Symbol.</t>
                     <t>The coded symbol.</dd>
            <dt>The First Source Identifier (FIRST_SOURCE_ID):</dt><dd>The first source identifier (FIRST_SOURCE_ID): the first Source Symbol symbol ID used in the combination.</t>
                     <t> combination.</dd>
            <dt>
                        Number of bits Bits for each edge block (b_id): the Each Edge Block (b_id):</dt><dd>The number of bits needed to store the edge.
                     </t>
                     <t>Information
                     </dd>
            <dt>Information about the Source Symbol IDs (id_bit_vector): if I=01, (id_bit_vector):</dt><dd>If I is set to 0b01, store the edge blocks as b_id * (NB_IDS * 2 - 1).
If I=10, I is set to 0b10, store the edge blocks in a compressed way the edge blocks.</t>
                     <t>The coefficients (coef_bit_vector): The way.</dd>
            <dt>The Coefficients (coef_bit_vector):</dt><dd>The coefficients stored depending on the CCGI (4 or 8 bits for each coefficient).</t>
                     <t>Padding: padding coefficient).</dd>
            <dt>Padding:</dt><dd>Padding to have an Encoding Vector encoding vector size that is a multiple of 32-bit 32 bits (for the id ID and coefficient part).</t>
                  </list>
               </t>
                  <!-- ==================================== --> part).</dd>
          </dl>
               <t>The Source Symbol source symbol IDs are organized as a sorted list of 32-bit unsigned integers. Depending on the feedback, the Source Symbol source symbol IDs MAY in the list <bcp14>MAY</bcp14> be successive or not in the list. not. If they are successive, the boundaries are stored in the Encoding Vector: encoding vector; it just needs 2*32-bit 2*32 bits of information. If not, the full list or the edge blocks MAY <bcp14>MAY</bcp14> be stored, stored and a differential transform to reduce the number of bits needed to represent an identifier MAY <bcp14>MAY</bcp14> be used.</t>
<t>For the following subsections, let's take as an example the generation of an encoding vector for a Coded Symbol which coded symbol that is a linear combination of the Source Symbols source symbols with IDs 1,2,3,5,6,8,9 1, 2, 3, 5, 6, 8, 9, and 10 (or as edge blocks: [1..3],[5..6],[8..10])</t> [1..3], [5..6], [8..10]).</t>
          <t>There are several ways to store the Source Symbols source symbol IDs into the encoding vector:
               <list style="symbols">
                <t>If
          </t>
          <ul spacing="normal">
            <li>If no information about the Source Symbol source symbol IDs is needed, the field I  MUST  <bcp14>MUST</bcp14> be set to 0b00: no b_id and no id_bit_vector field</t>
                <t>If field.</li>
            <li>If the edge blocks are stored without compression, the field I MUST <bcp14>MUST</bcp14> be set to 0b01.
In this case, set b_id to 32 (as a symbol id Symbol ID is 32 bits), and store into id_bit_vectors the list as 32 bits of 32-bit unsigned integers: 1,3,5,6,8,10</t>
                <t>If integers (1, 3, 4, 5, 6, 10) into id_bit_vectors.</li>
            <li>If the Source Symbols Ids source symbol IDs are stored as a list with compression, the field I MUST <bcp14>MUST</bcp14> be set to 0b10. In this case, see <xref target="compressing-encoding-vector" pageno="false" format="default" /> format="default"/>, but rather than compressing the edge blocks, we compress the full list of the Source Symbol IDs.</t>
                <t>If source symbol IDs.</li>
            <li>If the edge blocks are stored with compression, the field I MUST <bcp14>MUST</bcp14> be set to 0b11. In this case, see <xref target="compressing-encoding-vector" pageno="false" format="default" />.</t>
               </list>
               </t> format="default"/>.</li>
          </ul>
          <section anchor="compressing-encoding-vector" title="Compressed list numbered="true" toc="default">
            <name>Compressed List of Source Symbol IDs" numbered="true" toc="default">
                  <!-- ==================================== --> IDs</name>
                  <t>Let's continue with our Coded Symbol coded symbol defined in the previous section. The Source Symbols source symbol IDs used in the linear combination are: [1..3],[5..6],[8..10].</t> [1..3], [5..6], [8..10].</t>
            <t> If we want to compress and store this list into the encoding vector, we MUST <bcp14>MUST</bcp14> follow this procedure:
                     <list style="numbers">
                        <t>Keep
            </t>
            <ol spacing="normal" type="1"><li>Keep the first element in the packet as the first_source_id: 1.</t>
                        <t>Apply 1.</li>
              <li>Apply a differential transform to the other elements ([3,5,6,8,10]) which
              ([3, 5, 6, 8, 10]) that removes the element i-1 to the element i,
              starting with the first_source_id as i0, and get the list L = [2,2,1,2,2]</t>
                        <t>Compute
              [2, 2, 1, 2, 2].</li> <li>Compute b, the number of bits needed to
              store all the elements, which is ceil(log2(max(L))), where
              max(L) represents the maximum of the elements of the list L: L;
              here, it is 2 bits.</t>
                        <t>Write bits.</li>
              <li>Write b in the corresponding field, and write all the b * [(2 * NB blocks) - 1] elements in a bit vector, vector here: 10 10 01 10 10.</t>
                     </list>
                  </t> 10, 10, 01, 10, 10.</li>
            </ol>
          </section>
          <section anchor="decompressing-encoding-vector" title="Decompressing numbered="true" toc="default">
            <name>Decompressing the Source Symbol IDs" numbered="true" toc="default">
                  <!-- ==================================== --> IDs</name>
                  <t>When a Tetrys Decoding Block decoding block wants to reverse the operations, this algorithm is used:</t>
                  <t>
                     <list style="numbers">
                        <t>Rebuild
            <ol spacing="normal" type="1"><li>Rebuild the list of the transmitted elements by reading the bit vector and b: [10 10 01 10 [10, 10, 01, 10, 10] =&gt; [2,2,1,2,2]</t>
                        <t>Apply [2, 2, 1, 2, 2].</li>
              <li>Apply the reverse transform by adding successively the elements, starting with first_source_id: [1,1+2,(1+2)+2,(1+2+2)+1,...] [1, 1 + 2, (1 + 2) + 2, (1 + 2 + 2) + 1, ...] =&gt; [1,3,5,6,8,10]</t>
                        <t>Rebuild [1, 3, 5, 6, 8, 10].</li>
              <li>Rebuild the blocks using the list and first_source_id: [1..3],[5..6],[8..10].</t>
                     </list>
                  </t> [1..3], [5..6], [8..10].</li>
            </ol>
          </section>
        </section>
      </section>
      <section anchor="ack-packet" title="Window Update Packet Format" numbered="true" toc="default">
            <!-- ==================================== -->
        <name>Window Update Packet Format</name>
              <t>A Tetrys Decoder MAY decoder <bcp14>MAY</bcp14> send window update packets back to another building block some Window Update packets. block. They contain information about what the packets received, decoded decoded, or dropped, and other information such as a packet loss rate or the size of the decoding buffers. They are used to optimize the content of the encoding window. The window update packets are OPTIONAL, and hence <bcp14>OPTIONAL</bcp14>; hence, they could be omitted or lost in transmission without impacting the protocol behavior.</t>
        <figure anchor="fig-ack-pkt" title="Window anchor="fig-ack-pkt">
          <name>Window Update Packet Format" suppress-title="false" align="left" alt="" width="" height=""> Format</name>
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""> alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                      Common Packet Header                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        nb_missing_src                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   nb_not_used_coded_symb                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         first_src_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      plr      |   sack_size   |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
/                          SACK Vector                          /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
]]></artwork>
        </figure>
            <t>Common
<dl spacing="normal">
        <dt>Common Packet Header: a Header:</dt><dd>A common packet header (as common header format) where Packet Type=2.</t>
            <t>nb_missing_src: the packet type is set to 0b10.</dd>
        <dt>nb_missing_src:</dt><dd>The number of missing Source Symbols source symbols in the receiver since the beginning of the session.</t>
            <!-- <t>Nb of not already used Coded Symbols: the number of not already used Coded Symbols in the receiver that have not already been used for decoding. Meaning the number of linear combinations containing at least 2 unknown Source Symbols.</t> -->
            <t>nb_not_used_coded_symb: the session.</dd>
            <dt>nb_not_used_coded_symb:</dt><dd>The number of Coded Symbols coded symbols at the receiver that have not already been used for decoding (e.g., the linear combinations contain at least 2 two unknown Source Symbols).</t>
            <t>first_src_id: ID source symbols).</dd>
<dt>first_src_id:</dt><dd>ID of the first Source Symbol source symbol to consider in the SACK vector.</t>
            <t>plr: packet selective acknowledgment (SACK) vector.</dd>
<dt>plr:</dt><dd>Packet loss ratio expressed as a percentage normalized to a an 8-bit unsigned integer. For example, 2.5 % 2.5% will be stored as floor(2.5 * 256/100) = 6. Conversely, if 6 is the stored value, the corresponding packet loss ratio expressed as a percentage is 6*100/256 = 2.34 %. 2.34%. This value is used in the case of dynamic Code Rate code rate or for a statistical purpose. The choice of calculation is left to the Tetrys Decoder, decoder, depending on a window observation, but should be the PLR seen before decoding.</t>
            <t>sack_size: the decoding.</dd>
        <dt>sack_size:</dt><dd>The size of the SACK vector in 32-bit words. For instance, with a value of 2, the SACK vector is 64 bits long.</t>
            <t>SACK vector: bit long.</dd>
        <dt>SACK vector:</dt><dd>Bit vector indicating symbols that must be removed in the encoding window from the first Source Symbol source symbol ID. In most cases, these symbols were received by the receiver. The other cases concern some events with non-recoverable packets (for example (i.e., in the case of a burst of losses) where it is better to drop and abandon some packets, packets and thus to remove them from the encoding window, window to allow the recovery of the following packets.
				The "First Source Symbol" is included in this bit vector.
A bit equal to 1 at the i-th position means that this window update packet removes the Source Symbol source symbol of the ID equal to "First Source Symbol ID" + i from the encoding window.</t>
         </section>
      </section>

     <!-- <section anchor="ccgi" title="The Coding Coefficient Generator Identifier" 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 elements,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 elements,defined by the primitive polynomial 1+x^^2+x^^3+x^^4+x^^8. Each coefficient is built as alpha^( (source_symbol_id*coded-symbol_id) % 256), with alpha the root of the primitive polynomial.</t>
         <section anchor="ccgi_example" title="how to use the CCGI" numbered="true" 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 determined using a Coding Coefficient Generator. This generator MAY take as input the Source Symbol ID and the Coded Symbol ID and MAY determine a coefficient in a deterministic 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 the 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 combination of the Source Symbols 1,2,4. The coefficients will be alpha ^( (1 * 1) % 256), alpha ^( (1 * 2) % 256), alpha ^( (1 * 4) % 256).</t> window.</dd>
</dl>
      </section>
    </section>
      -->

      <!-- ======================================================================= -->
      <section anchor="research" title="Research Issues" numbered="true" toc="default">
      <name>Research Issues</name>
      <t>The present document describes the baseline protocol, allowing communications between a Tetrys encoder and a Tetrys decoder.  In practice, Tetrys can be used either as a standalone protocol or embedded inside an existing protocol, and either above, within within, or below the transport layer.  There are different research questions related to each of these scenarios that should be investigated for future protocol improvements. We summarize them in the following subsections.</t>
      <section anchor="transport-issue" title="Interaction with Congestion Control" numbered="true" toc="default">
        <name>Interaction with Congestion Control</name>
        <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 sectionFormat="comma" section="2.1"/>):
</t>
        <ul spacing="normal">
          <li>The Tetrys channel carries source and Coded Packets coded packets (from the sender to the receiver) and information from the receiver to the sender (e.g., signaling which symbols have been recovered, loss rate prior before and/or after decoding, etc.);</t>
	<t>the etc.).</li>
          <li>The congestion control channel carries packets from a sender to a receiver, receiver and packets signaling information about the network (e.g., number of packets received versus lost, Explicit Congestion Notification (ECN) marks, etc.) from the receiver to the sender. </t>
</list>
In practice, depending on how Tetrys is deployed (i.e., above, within or below the transport layer), </li>
        </ul>
        <t>
The following topics, which are identified and discussed by <xref target="RFC9265" pageno="false" format="default" /> identifies and discusses several topics. They format="default"/>, are briefly listed below and adapted to the particular case deployment cases of Tetrys:
<list style="symbols">
	<t>congestion related Tetrys (i.e., above, within, or below the transport layer):
</t>
        <ul spacing="normal">
          <li>Congestion-related losses may be hidden if Tetrys is deployed below the transport layer without any precaution (i.e., Tetrys recovering packets lost because of a congested router), which can severely impact the the congestion control efficiency. An approach is suggested to avoid hiding such signals in <xref target="RFC9265" pageno="false" format="default" />, section 5;</t>
	<t>having Tetrys sectionFormat="comma" section="5"/>.</li>
          <li>Tetrys and non-Tetrys flows sharing the same network links can raise fairness issues between these flows. The In particular, the situation depends in particular on whether some of these flows and not others are congestion controlled and not others, and which type of congestion control is used. The details are out of scope of this document, but may have major impacts in practice;</t>
	<t>coding practice.</li>
          <li>Coding rate adaptation within Tetrys can have major impacts on congestion control if done inappropriately. This topic is discussed more in detail in <xref target="adaptive"/>;</t>
	<t>Tetrys target="adaptive" format="default"/>.</li>
          <li>Tetrys can leverage on multipath transmissions, with the Tetrys packets being sent to the same receiver through multiple paths. Since paths can largely differ, a per-path flow control and congestion control adaptation could be needed;</t>
	<t>protecting needed.</li>
          <li>Protecting several application flows within a single Tetrys flow raises additional questions. This topic is discussed more in detail in <xref target="tunnel"/>.</t>
</list>
</t>

<!-- <t>
Tetrys coding and congestion control MAY be seen as two separate channels (the notion of channel corresponds to that of <xref target="RFC9265" pageno="false" format="default" />, section 2.1).  In practice, implementations MAY interact with both channels by sharing information from one channel to the other one.  This raises several concerns that must be tackled when Tetrys is jointly used with a congestion-controlled transport protocol. For example, the Encoding Window or the Code Rate COULD be adjusted by some feedback from the congestion-control channel.  All these numerous research issues are discussed in a separate document, <xref target="RFC9265" pageno="false" format="default" />, which investigates end-to-end unicast data transfer with FEC coding in the application (above the transport layer), within the transport layer, or directly below the transport; the relationship between transport layer and application requirements; and the case of transport multipath and multi-streams applications.
            </t>
--> target="tunnel" format="default"/>.</li>
        </ul>
         </section>
      <section anchor="adaptive" title="Adaptive Coding Rate" numbered="true" toc="default">
        <name>Adaptive Coding Rate</name>
        <t>
When the network conditions (e.g., delay and loss rate) strongly vary over time, an adaptive coding rate can be used to increase or reduce the amount of Coded Packets coded packets among a transmission dynamically (i.e., the added redundancy), redundancy) with the help of a dedicated algorithm, similarly algorithm similar to <xref target="A-FEC" pageno="false" format="default" />. format="default"/>. Once again, the strategy differs, differs depending on which layer Tetrys is deployed (i.e., above, within within, or below the transport layer). Basically, we can slice split these strategies in into two distinct classes: when Tetrys is deployed deployment inside the transport layer, layer versus outside the transport layer (i.e., above or below). A deployment within the transport layer obviously means
that interactions between transport protocol micro-mechanisms, mechanisms such as the error recovery mechanism, the recovery, congestion control, the and/or flow control or both, are envisioned. Otherwise, deploying Tetrys within a non congestion controlled transport protocol, protocol that is not congestion controlled, like UDP, would not bring out any other advantage than deploying it below or above the transport layer.
        </t>
        <t>The impact deploying a FEC mechanism within the transport layer is further discussed in <xref target="RFC9265" pageno="false" format="default" />, section 4, sectionFormat="of" section="4"/>, where considerations concerning the interactions between congestion control and coding rates, or the impact of fairness, are investigated. This adaptation may be done jointly with the congestion control mechanism of a transport layer protocol, protocol as proposed by <xref target="CTCP"/>. target="CTCP" format="default"/>. This allows the use of monitored congestion control metrics (e.g., RTT, congestion events, or current congestion window size) to adapt the coding rate conjointly with the computed transport sending rate. The rationale is to compute an amount of repair traffic that does not lead to congestion.  This joint optimization is mandatory to prevent flows to consume from consuming the whole available capacity as also discussed in <xref target="I-D.singh-rmcat-adaptive-fec" /> format="default"/>, where the authors point out that an increase in the repair ratio should be done conjointly with a decrease in the source sending rate.
        </t>
        <t>
	    Finally, adapting a coding rate can also be done outside the transport layer and without considering transport layer transport-layer metrics. In particular, this adaptation may be done jointly with the network as proposed in <xref target="RED-FEC" pageno="false" format="default" />. format="default"/>. In this paper, the authors propose a Random Early Detection FEC mechanism in the context of video transmission over wireless networks. Briefly, the idea is to add more redundancy packets if the queue at the access point is less occupied and vice versa. A first theoretical attempt for video delivery with Tetrys has been proposed <xref target="THAI" pageno="false" format="default" /> with Tetrys. format="default"/>. This approach is interesting as it illustrates a joint collaboration between the application requirements and the network conditions and 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 rate. However, all of them depend on:
	    <list style="symbols">
	    	<t>the
        </t>
        <ul spacing="normal">
          <li>the signal metrics that can be monitored and used to adapt the coding rate;</t>
	    	<t>the rate;</li>
          <li>the transport layer used, whether it is congestion controlled or not;</t>
	    	<t>the not; and</li>
          <li>the objective sought (e.g., to minimize congestion, congestion or to fit application requirements).</t>
	    </list>
	    </t> requirements).</li>
        </ul>
      </section>
      <section anchor="tunnel" title="Using numbered="true" toc="default">
        <name>Using Tetrys Below The below the IP Layer For Tunneling" numbered="true" toc="default"> for Tunneling</name>
        <t>
        The use of Tetrys to protect an aggregate of flows, typically flows raises research questions when Tetrys is used for tunneling, to recover from IP datagram losses, raises research questions.
When losses while tunneling.  Applying redundancy is applied without flow differentiation, this differentiation may come in contradiction with contradict the service requirements of individual flows, flows: some of them flows may be more penalized more by high latency and jitter than by partial reliability, while other flows may have opposite requirements. be penalized more by partial reliability.  In practice practice, head-of-line blocking will impact impacts all flows in a similar manner despite their different needs, which asks for indicates that more elaborate strategies inside Tetrys.
<!-- Note this research issue joins the topics discussed in the IRTF LOOPS working group <xref target="I-D.li-tsvwg-loops-problem-opportunities" pageno="false" format="default" />. --> Tetrys are needed.
        </t>
      </section>
    </section>
      <!-- ======================================================================= -->
      <section anchor="security" title="Security Considerations" numbered="true" toc="default">
         <!-- ==================================== -->
      <name>Security Considerations</name>
        <t>
        First of all, it must be clear that the use of FEC protection to on a data stream does not provide, per se, provide any kind of security, but, on security per se. On the contrary, the use of FEC protection on a data stream raises security risks.
        The situation with Tetrys is mostly similar to that of other content delivery protocols making use of FEC protection, and protection; this is well described in FECFRAME <xref target="RFC6363" pageno="false" format="default" />. format="default"/>.
        This section leverages builds on this reference, adding new considerations to comply with Tetrys specificities when meaningful.
      </t>
      <section anchor="security-problem-statement" title="Problem Statement" numbered="true" toc="default">
        <name>Problem Statement</name>
        <t>
          An attacker can either target the content, the protocol, or the network.
          The consequences will largely differ, differ reflecting various types of goals, like gaining access to confidential content, corrupting the content, compromizing compromising the Tetrys Encoder encoder and/or Tetrys Decoder, decoder, or compromizing compromising the network behavior.
          In particular, several of these attacks aim at creating a Denial-of-Service (DoS), (DoS) with consequences that may be limited to a single node (e.g., the Tetrys Decoder), decoder), or that may impact all the nodes attached to the targeted network (e.g., by making flows non-responsive unresponsive to congestion signals).
        </t>
        <t>
          In the following sections, we discuss these attacks, according to the component targeted by the attacker.
        </t>
      </section>
      <section anchor="security-attack-against-data-flow" title="Attacks numbered="true" toc="default">
        <name>Attacks against the Data Flow" numbered="true" toc="default"> Flow</name>
        <t>
          An attacker may want to access a confidential content, content by eavesdropping the traffic between the Tetrys Encoder/Decoder. encoder/decoder.
          Traffic encryption is the usual approach to mitigate this risk, and this encryption can be done either on applied to the source flow, above Tetrys, flow upstream of the Tetrys encoder or below Tetrys, on to the output packets, both Source and Coded Packets. packets downstream of the Tetrys encoder.
          The choice on where to apply encryption depends on various criteria,
          in particular the attacker model (e.g., when encryption happens
          below Tetrys, the security risk is assumed to be on the
          interconnection network).
        </t>
        <t>
          An attacker may also want to corrupt the content (e.g., by injecting forged or modified Source source and Coded Packets coded packets to prevent the Tetrys Decoder to recover decoder from recovering the original source flow).
          Content integrity and source authentication services at the packet level are then needed to mitigate this risk.
          Here, these services need to be provided below Tetrys in order to enable the receiver to drop undesired packets and only transfer legitimate packets to the Tetrys Decoder. decoder.
          It should be noted that forging or modifying Feedback Packets feedback packets will not corrupt the content, although it will certainly compromize compromise Tetrys operation (see next section). <xref target="security-attack-against-signaling"/>).
        </t>
      </section>
      <section anchor="security-attack-against-signaling" title="Attacks against Signaling" numbered="true" toc="default">
        <name>Attacks against Signaling</name>
        <t>
          Attacks on signaling information (e.g., by forging or modifying Feedback Packets feedback packets to pretend falsify the good reception or recovery of source content) can easily prevent the Tetrys Decoder to recover 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, flow from the Tetrys Decoder decoder to the Tetrys Encoder, encoder as well.
          These services need to be provided below Tetrys, Tetrys in order to drop undesired packets and only transfer legitimate Feedback Packets feedback packets to the Tetrys Encoder. encoder.
        </t>
        <t>
          On the opposite,
          Conversely, an attacker in position to selectively drop Feedback Packets feedback packets (instead of modifying them) will not severily severely impact the function of Tetrys functionning, since Tetrys it is naturally robust in front of when challenged with such losses.
          However
          However, it will have side impacts, like such as the use of bigger linear systems (since the Tetrys Encoder encoder cannot remove well received well-received or decoded source packets from its linear system), which mechanically increases computational costs on both sides, encoder sides (encoder and decoder. decoder).
        </t>
      </section>
      <section anchor="security-attack-against-network" title="Attacks against the Network" numbered="true" toc="default">
        <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), which feedback packets) that can potentially impact a significant number of nodes attached to the network.
          Here also, in
          In order to mitigate the risk, content integrity and source authentication services at the packet level are needed to enable the receiver to drop undesired packets and only transfer legitimate packets to the Tetrys Encoder encoder and Decoder. decoder.
        </t>
      </section>
      <section anchor="security-baseline-security" title="Baseline Security Operation" numbered="true" toc="default">
        <name>Baseline Security Operation</name>
        <t>
          Tetrys can benefit from an IPsec/Encapsulating IPsec / Encapsulating Security Payload (IPsec/ESP) <xref target="RFC4303" pageno="false" format="default" />, format="default"/> that provides in particular confidentiality, origin authentication, integrity, and anti-replay services. services in particular.
  	IPsec/ESP can be useful used to protect the Tetrys data flows (both directions) against attackers located within the interconnection network, network or attackers in position to eavesdrop traffic, or inject forged traffic, or replay legitimate traffic.
        </t>
      </section>
    </section>

<!--
      <section anchor="security" title="Security Considerations" numbered="true" toc="default">
         <t>
            Tetrys inherits a subset of the security issues described in FECFRAME
            <xref target="RFC8680" pageno="false" format="default" />
            and in particular in sections "9.2.2. Content Corruption" and "9.3. Attacks against the FEC Parameters". As an application layer end-to-end protocol, security considerations of Tetrys should also be comparable to those of HTTP/2 with TLS.
        The considerations from Section 10 of HTTP2
            <xref target="RFC7540" pageno="false" format="default" />
            also apply in addition to those listed here.
         </t>
      </section>
-->
      <section anchor="iana" title="IANA Considerations" numbered="true" toc="default">
         <!-- ==================================== -->
      <name>IANA Considerations</name>
<t>This document does not ask for any has no IANA registration.</t>
      </section>
      <section anchor="implementation" title="Implementation Status" numbered="true" toc="default">
         <t>Editor's notes: RFC Editor, please remove this section motivated by
   RFC 7942 before publishing the RFC.  Thanks!</t>
         <t>An implementation of Tetrys exists:
            <list>
               <t>organization: ISAE-SUPAERO</t>
               <t>Description: This is a proprietary implementation made by ISAE-SUPAERO</t>
               <t>Maturity: "production"</t>
               <t>Coverage: this software implements TETRYS with some modifications</t>
               <t>Licensing: proprietary</t>
               <t>Implementation experience: maximum</t>
               <t>Information update date: January 2022</t>
               <t>Contact: jonathan.detchart@isae-supaero.fr</t>
            </list>
         </t>
      </section>
      <section anchor="ack" title="Acknowledgments" numbered="true" toc="default">
         <!-- ==================================== -->
         <t>First, the authors want sincerely to thank 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 discussions on on-the-fly coding that helped finalize this document.</t>
         <t>Finally, the authors would like to thank Colin Perkins for providing comments and feedback on the document.</t> actions.</t>
    </section>
  </middle>
  <back>
      <references title="Normative References">
         <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
            <front>
               <title>Keywords for use in RFCs to Indicate Requirement Levels</title>
               <author initials="S." surname="Bradner" fullname="S. Bradner">
                  <organization />
               </author>
               <date year="1997" month="March" />
               <abstract>
                  <t>In many standards track documents, several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
               </abstract>
            </front>
            <seriesInfo name="BCP" value="14" />
            <seriesInfo name="RFC" value="2119" />
            <seriesInfo name="DOI" value="10.17487/RFC2119" />
         </reference>
         <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
            <front>
               <title>
               Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
               </title>
               <author initials="B." surname="Leiba" fullname="B. Leiba">
                  <organization/>
               </author>
               <date year="2017" month="May"/>
               <abstract>
                  <t>
                  RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
                  </t>
               </abstract>
            </front>
            <seriesInfo name="BCP" value="14"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
         </reference>
         <?rfc include="reference.RFC.3452.xml"?>
         <?rfc include="reference.RFC.4303.xml"?>
         <?rfc include="reference.RFC.5510.xml"?>
         <?rfc include="reference.RFC.5651.xml"?>
         <?rfc include="reference.RFC.5740.xml"?>
         <?rfc include="reference.RFC.6363.xml"?>
<!--         <?rfc include="reference.RFC.7540.xml"?>-->
         <?rfc include="reference.RFC.8406.xml"?>
         <?rfc include="reference.RFC.8680.xml"?>
	      <?rfc include="reference.RFC.9265.xml"?>

<displayreference target="I-D.singh-rmcat-adaptive-fec" to="RMCAT-ADAPTIVE-FEC"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5052.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5445.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5510.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5651.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5740.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6363.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.8680.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9265.xml"/>
      </references>
      <references title="Informative References">
	 <!-- <?rfc include="reference.I-D.li-tsvwg-loops-problem-opportunities.xml"?> -->
	 <?rfc include="reference.I-D.singh-rmcat-adaptive-fec.xml"?>
      <references>
        <name>Informative References</name>

	 <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.singh-rmcat-adaptive-fec.xml"/>

        <reference anchor="AHL-00" quote-title="true"> target="https://doi.org/10.1109/18.850663">
          <front>
            <title>Network information flow</title>
            <author initials="R." surname="Ahlswede">
                  <organization />
              <organization/>
            </author>
            <author initials="" surname="Ning Cai">
                  <organization /> initials="N." surname="Cai">
              <organization/>
            </author>
            <author initials="S.-Y.R." initials="S." surname="Li">
                  <organization />
              <organization/>
            </author>
            <author initials="R.W." initials="R." surname="Yeung">
                  <organization />
              <organization/>
            </author>
            <date month="July" year="2000" /> year="2000"/>
          </front>
          <seriesInfo name="IEEE name="DOI" value="10.1109/18.850663"/>
	  <refcontent>IEEE Transactions on Information Theory" value="vol.46, no.4, pp.1204,1216" /> Theory, Vol. 46, Issue 4, pp. 1204-1216</refcontent>
        </reference>

        <reference anchor="Tetrys" quote-title="true"> target="https://doi.org/10.1109/IWSSC.2008.4656755">
          <front>
            <title>Rethinking reliability for long-delay networks</title>
            <author initials="J." surname="Lacan">
                  <organization />
              <organization/>
            </author>
            <author initials="E." surname="Lochin">
                  <organization />
              <organization/>
            </author>
            <date month="October" year="2008" /> year="2008"/>
          </front>
	  <seriesInfo name="International name="DOI" value="10.1109/IWSSC.2008.4656755"/>
          <refcontent>International Workshop on Satellite and Space Communications 2008" value="(IWSSC08)" /> Communications, Toulouse, France, pp. 90-94</refcontent>
        </reference>

        <reference anchor="Tetrys-RT" quote-title="true"> target="http://dx.doi.org/10.1109/TMM.2011.2126564">
          <front>
               <title>On-the-fly erasure coding
            <title>On-the-Fly Erasure Coding for real-time video applications</title> Real-Time Video Applications</title>
            <author initials="P.U." initials="P." surname="Tournoux">
                  <organization />
              <organization/>
            </author>
            <author initials="E." surname="Lochin">
                  <organization />
              <organization/>
            </author>
            <author initials="J." surname="Lacan">
                  <organization />
              <organization/>
            </author>
            <author initials="A." surname="Bouabdallah">
                  <organization />
              <organization/>
            </author>
            <author initials="V." surname="Roca">
                  <organization />
              <organization/>
            </author>
            <date month="August" year="2011" /> year="2011"/>
          </front>
	  <seriesInfo name="IEEE name="DOI" value="10.1109/TMM.2011.2126564"/>
          <refcontent>IEEE Transactions on Multimedia, Vol Vol. 13, Issue 4, August 2011" value="(TMM.2011)" /> pp. 797-812</refcontent>
        </reference>

        <reference anchor="CTCP"> anchor="CTCP" target="https://arxiv.org/abs/1212.2291">
          <front>
            <title>Network Coded TCP (CTCP)</title>
            <author initials="M" surname="Kim (et al.)"> initials="M." surname="Kim">
            </author>
            <author initials="J." surname="Cloud">
	    </author>
            <author initials="A." surname="ParandehGheibi">
	    </author>
            <author initials="L." surname="Urbina">
	    </author>
            <author initials="K." surname="Fouli">
	    </author>
            <author initials="D." surname="Leith">
	    </author>
            <author initials="M." surname="Medard">
	    </author>
            <date month="April" year="2013"/>
          </front>
          <seriesInfo name="arXiv" value="1212.2291v3"/>
        </reference>

        <reference anchor="A-FEC" quote-title="true"> target="https://doi.org/10.1109/INFCOM.1999.752166">
          <front>
            <title>Adaptive FEC-based error control for Internet telephony</title>
            <author initials="J." surname="Bolot">
                  <organization />
              <organization/>
            </author>
            <author initials="S." surname="Fosse-Parisis">
                  <organization />
              <organization/>
            </author>
            <author initials="D." surname="Towsley">
                  <organization />
              <organization/>
            </author>
            <date year="1999" /> month="March" year="1999"/>
          </front>
            <seriesInfo name="IEEE
          <refcontent>IEEE INFOCOM 99, '99, Conference on Computer Communications, New York, NY, USA, Vol. 3, pp. 1453-1460 vol. 3" value="DOI 10.1109/INFCOM.1999.752166" /> 1453-1460</refcontent>
	  <seriesInfo name="DOI" value="10.1109/INFCOM.1999.752166"/>
        </reference>

        <reference anchor="RED-FEC" quote-title="true"> target="https://doi.org/10.1109/TBC.2008.2001713">
          <front>
            <title>A RED-FEC Mechanism for Video Transmission Over WLANs</title>
            <author initials="C." surname="Lin">
                  <organization />
              <organization/>
            </author>
            <author initials="C." surname="Shieh">
                  <organization />
              <organization/>
            </author>
            <author initials="N. K." initials="N." surname="Chilamkurti">
                  <organization />
              <organization/>
            </author>
            <author initials="C." surname="Ke">
                  <organization />
              <organization/>
            </author>
            <author initials="H. S." initials="W." surname="Hwang">
                  <organization />
              <organization/>
            </author>
            <date month="September" year="2008" /> year="2008"/>
          </front>
            <seriesInfo name="IEEE
          <refcontent>IEEE Transactions on Broadcasting, vol. Vol. 54, no. Issue 3, pp. 517-524" value="DOI 10.1109/TBC.2008.2001713" /> 517-524</refcontent>
	  <seriesInfo name="DOI" value="10.1109/TBC.2008.2001713"/>
        </reference>

        <reference anchor="THAI" quote-title="true"> target="https://doi.org/10.1016/j.image.2014.02.003">
          <front>
            <title>Joint on-the-fly network coding/video quality adaptation for real-time delivery</title>
            <author initials="T." surname="Tran-Thai">
                  <organization /> surname="Tran Thai">
              <organization/>
            </author>
            <author initials="J." surname="Lacan">
                  <organization />
              <organization/>
            </author>
            <author initials="E." surname="Lochin">
                  <organization />
              <organization/>
            </author>
            <date year="2014" /> month="April" year="2014"/>
          </front>
            <seriesInfo name="Signal
          <refcontent>Signal Processing: Image Communication, vol. Vol. 29 (no. 4), Issue 4, pp. 449-461" value="ISSN 0923-5965" /> 449-461</refcontent>
<seriesInfo name="DOI" value="10.1016/j.image.2014.02.003"/>
        </reference>
      </references>
    </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 discussions on
on-the-fly coding that helped finalize this document.</t>
      <t>Finally, the authors would like to thank <contact fullname="Colin Perkins"/> for
providing comments and feedback on the document.</t>
    </section>
  </back>
</rfc>