Source Symbol:

A symbol that is transmitted between the ingress and egress of the network.

Coded Symbol:

A linear combination over a finite field of a set of source symbols.

Source Symbol ID:

A sequence number to identify the source symbols.

Coded Symbol ID:

A sequence number to identify the coded symbols.

Encoding Coefficients:

Elements of the finite field characterizing the linear combination used to generate coded symbols.

Encoding Vector:

A set of the coding coefficients and input source symbol IDs.

Source Packet:

A source packet contains a source symbol with its associated IDs.

Coded Packet:

A coded packet contains a coded symbol, the coded symbol's ID, and encoding vector.

Input Symbol:

A symbol at the input of the Tetrys encoder.

Output Symbol:

A symbol generated by the Tetrys encoder. For a non-systematic mode, all output symbols are coded symbols. For a systematic mode, output symbols MAY be the input symbols and a number of coded symbols that are linear combinations of the input symbols plus the encoding vectors.

Feedback Packet:

A feedback packet is a packet containing information about the decoded or received source symbols. It MAY also contain additional information about the Packet Error Rate or the number of various packets in the receiver decoding window.

Elastic Encoding Window:

An encoder-side buffer that stores all the unacknowledged source packets of the input flow involved in the coding process.

Coding Coefficient Generator Identifier (CCGI):

A unique identifier thatdefines a function or an algorithm allowing the generation of the encodingvector.

Code Rate:

Defines the rate between the number of input symbols and the number of output symbols.

   +----------+                +----------+
   |          |                |          |
   |    App   |                |    App   |
   |          |                |          |
   +----------+                +----------+
        |                           ^
        |  Source           Source  |
        |  Symbols          Symbols |
        |                           |
        v                           |
   +----------+                +----------+
   |          | Output Packets |          |
   |  Tetrys  |--------------->|  Tetrys  |
   |  Encoder |Feedback Packets|  Decoder |
   |          |<---------------|          |
   +----------+                +----------+

• on-the-fly encoding;
• decoding;
• signaling, to carry in particular the symbol IDs in the encoding window and the associated coding coefficients when meaningful;
• feedback management;
• elastic window management; and
• Tetrys packet header creation and processing.

• channel estimation;
• dynamic adjustment of the code rate and flow control; and
• congestion control management (if appropriate). See Section 6.1 for further details.

The Tetrys Building Block:

This building block embeds both the Tetrys decoder and Tetrys encoder; thus, it is used during 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 feature of Tetrys may be used.

The Window Management Building Block:

This building block is in charge of managing the encoding window at a Tetrys sender.

 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)              |
|                          ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tetrys version number (V):

4 bits. Indicates the Tetrys version number. The Tetrys version number for this specification is 1.

Congestion control flag (C):

2 bits. C set to 0b00 indicates the Congestion Control Information (CCI) field is 0 bits in length. C set to 0b01 indicates the CCI field is 32 bits in length. C set to 0b10 indicates the CCI field is 64 bits in length. C set to 0b11 indicates the CCI field is 96 bits in length.

Transport Session Identifier flag (S):

1 bit. This is the number of full 32-bit words in the TSI field. The TSI field is 32*S bits in length; i.e., the length is either 0 bits or 32 bits.

Reserved (Resv):

9 bits. These bits are reserved. In this version of the specification, they MUST be set to zero by senders and MUST be ignored by receivers.

Header length (HDR_LEN):

8 bits. The total length of the Tetrys header in units of 32-bit words. The length of the Tetrys header MUST 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, to the packet payload if it exists and there is no other header, or to the end of the packet if there are no other headers or packet payload.

Tetrys packet type (PKT_TYPE):

8 bits. There are three types of packets: the PKT_TYPE_SOURCE (0b00) defined in Section 5.2, the PKT_TYPE_CODED (0b01) defined in Section 5.3 and the PKT_TYPE_WND_UPT (0b11) for window update packets defined in Section 5.4.

Congestion Control Information (CCI):

0, 32, 64, or 96 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 be 0 bits (absent) if C is set to 0b00. This field MUST be 32 bits if C is set to 0b01. This field MUST be 64 bits if C is set to 0b10. This field MUST be 96 bits if C is set to 0b11.

Transport Session Identifier (TSI):

0 or 32 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; thus, the IP address of the sender and the TSI together uniquely identify the session. Although a TSI always uniquely identifies a session conjointly with the IP address of the sender, 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 serve as the TSI for the session. If there is no underlying TSI provided by the network, transport, or any other layer, then the TSI MUST be included in the Tetrys header.

• The first format is used for variable-length extensions with header extension type (HET) values between 0 and 127.
• The second format is used for fixed-length (one 32-bit word) extensions using HET values from 128 to 255.

 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 (<=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 (>=128)  |       Header Extension Content (HEC)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Header Extension Type (HET):

8 bits. The type of the 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. HET values from 128 to 255 are used for fixed-length, 32-bit header extensions.

Header Extension Length (HEL):

8 bits. The length of the whole header extension field expressed in multiples of 32-bit words. This field MUST be present for variable-length extensions (HETs between 0 and 127) and MUST NOT be present for fixed-length extensions (HETs between 128 and 255).

Header Extension Content (HEC):

Length of the variable. The content of the header extension. The format of this subfield depends on the header extension type. For fixed-length header extensions, the HEC is 24 bits. For variable-length header extensions, the HEC field has a variable size as specified by the HEL field. Note that the length of each header extension MUST be a multiple of 32 bits. Additionally, the total size of the Tetrys header, including all header extensions and optional header fields, cannot exceed 255 32-bit words.

 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                            /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Common Packet Header:

A common packet header (as common header format) where packet type is set to 0b00.

Source Symbol ID:

The sequence number to identify a source symbol.

Payload:

The payload (source symbol).

 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                            /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Common Packet Header:

A common packet header (as common header format) where packet type is set to 0b01.

Coded Symbol ID:

The sequence number to identify a coded symbol.

Encoding Vector:

An encoding vector to define the linear combination used (coefficients and source symbols).

Encoded Payload Size:

The coded payload size used if the source symbols have a variable size (optional, Section 5.3.1).

Payload:

The coded symbol.

 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   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Encoding Vector Length (EV_LEN):

8 bits. The size in units of 32-bit words.

Coding Coefficient Generator Identifier (CCGI):

4-bit ID to identify the algorithm or function used to generate the coefficients. As a CCGI is included in each encoded vector, it MAY dynamically change between the generation of two coded symbols. The CCGI builds the coding coefficients used to generate the coded symbols. They MUST be known by all the Tetrys encoders or decoders. The two RLC FEC schemes specified in this document reuse the finite fields defined in RFC 5510, Section 8.1. More specifically, the elements of the field GF(2^(m)) 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⁽⁸⁾), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 8. The following irreducible polynomial is used for GF(2⁽⁸⁾):

x⁽⁸⁾ + x⁽⁴⁾ + x⁽³⁾ + x⁽²⁾ + 1

With GF(2⁽⁴⁾), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 4. The following irreducible polynomial is used for GF(2⁽⁴⁾):

x⁽⁴⁾ + x + 1

• 0b00: Vandermonde-based coefficients over the finite field GF(2⁽⁴⁾) as defined below. Each coefficient is built as alpha^{( (source_symbol_id*coded-symbol_id) % 16)}, with alpha the root of the primitive polynomial.
• 0b01: Vandermonde-based coefficients over the finite field GF(2⁽⁸⁾) as defined below. Each coefficient is built as alpha^{( (source_symbol_id*coded-symbol_id) % 256)}, with alpha the root of the primitive polynomial.
• Suppose we want to generate the coded symbol 2 as a linear combination of the source symbols 1, 2, and 4 using CCGI set to 0b01. The coefficients will be alpha^{( (1 * 1) % 256)}, alpha^{( (1 * 2) % 256)}, and alpha^{( (1 * 4) % 256)}.

Store the Source Symbol ID Format (I) (2 bits):

• 0b00 means there is no source symbol ID information.
• 0b01 means the encoding vector contains the edge blocks of the source symbol IDs without compression.
• 0b10 means the encoding vector contains the compressed list of the source symbol IDs.
• 0b11 means the encoding vector contains the compressed edge blocks of the source symbol IDs.

Store the Encoding Coefficients (C):

1 bit to indicate if an encoding vector contains information about the coefficients used.

Having Source Symbols with Variable Size Encoding (V):

Set V to 0b01 if the combination that refers to the encoding vector is a combination of source symbols with variable sizes. In this case, the coded packets MUST have the 'Encoded Payload Size' field.

NB_IDS:

The number of source IDs stored in the encoding vector (depending on I).

Number of Coefficients (NB_COEFS):

The number of the coefficients used to generate the associated coded symbol.

The First Source Identifier (FIRST_SOURCE_ID):

The first source symbol ID used in the combination.

Number of Bits for Each Edge Block (b_id):

The number of bits needed to store the edge.

Information about the Source Symbol IDs (id_bit_vector):

If I is set to 0b01, store the edge blocks as b_id * (NB_IDS * 2 - 1). If I is set to 0b10, store the edge blocks in a compressed way.

The Coefficients (coef_bit_vector):

The coefficients stored depending on the CCGI (4 or 8 bits for each coefficient).

Padding:

Padding to have an encoding vector size that is a multiple of 32 bits (for the ID and coefficient part).

• If no information about the source symbol IDs is needed, the field I MUST be set to 0b00: no b_id and no id_bit_vector field.
• If the edge blocks are stored without compression, the field I MUST be set to 0b01. In this case, set b_id to 32 (as a Symbol ID is 32 bits), and store the list of 32-bit unsigned integers (1, 3, 4, 5, 6, 10) into id_bit_vectors.
• If the source symbol IDs are stored as a list with compression, the field I MUST be set to 0b10. In this case, see Section 5.3.1.1, but rather than compressing the edge blocks, we compress the full list of the source symbol IDs.
• If the edge blocks are stored with compression, the field I MUST be set to 0b11. In this case, see Section 5.3.1.1.

1. Apply a differential transform to the other elements ([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].
2. 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; here, it is 2 bits.
3. Write b in the corresponding field, and write all the b * [(2 * NB blocks) - 1] elements in a bit vector here: 10, 10, 01, 10, 10.

1. 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, 3, 5, 6, 8, 10].
2. Rebuild the blocks using the list and first_source_id: [1..3], [5..6], [8..10].

 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                          /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Common Packet Header:

A common packet header (as common header format) where packet type is set to 0b10.

nb_missing_src:

The number of missing source symbols in the receiver since the beginning of the session.

nb_not_used_coded_symb:

The number of coded symbols at the receiver that have not already been used for decoding (e.g., the linear combinations contain at least two unknown source symbols).

first_src_id:

ID of the first source symbol to consider in the selective acknowledgment (SACK) vector.

plr:

Packet loss ratio expressed as a percentage normalized to an 8-bit unsigned integer. For example, 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%. This value is used in the case of dynamic code rate or for a statistical purpose. The choice of calculation is left to the Tetrys decoder, depending on a window observation, but should be the PLR seen before decoding.

sack_size:

The size of the SACK vector in 32-bit words. For instance, with a value of 2, the SACK vector is 64 bits long.

SACK vector:

Bit vector indicating symbols that must be removed in the encoding window from the first source symbol ID. In most cases, these symbols were received by the receiver. The other cases concern some events with non-recoverable packets (i.e., in the case of a burst of losses) where it is better to drop and abandon some packets and remove them from the encoding 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 of the ID equal to "First Source Symbol ID" + i from the encoding window.

• The Tetrys channel carries source and 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 before and/or after decoding, etc.).
• The congestion control channel carries packets from a sender to a 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.

• 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 congestion control efficiency. An approach is suggested to avoid hiding such signals in RFC 9265, Section 5.
• Tetrys and non-Tetrys flows sharing the same network links can raise fairness issues between these flows. In particular, the situation depends on whether some of these flows and not others are congestion controlled and which type of congestion control is used. The details are out of scope of this document, but may have major impacts in practice.
• Coding rate adaptation within Tetrys can have major impacts on congestion control if done inappropriately. This topic is discussed more in detail in Section 6.2.
• Tetrys can leverage 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.
• Protecting several application flows within a single Tetrys flow raises additional questions. This topic is discussed more in detail in Section 6.3.

• the signal metrics that can be monitored and used to adapt the coding rate;
• the transport layer used, whether it is congestion controlled or not; and
• the objective sought (e.g., to minimize congestion or to fit application requirements).

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4303]

S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.

[RFC5052]

M. Watson, M. Luby, and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI 10.17487/RFC5052, August 2007,
<https://www.rfc-editor.org/info/rfc5052>.

[RFC5445]

M. Watson, "Basic Forward Error Correction (FEC) Schemes", RFC 5445, DOI 10.17487/RFC5445, March 2009,
<https://www.rfc-editor.org/info/rfc5445>.

[RFC5510]

J. Lacan, V. Roca, J. Peltotalo, and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, DOI 10.17487/RFC5510, April 2009,
<https://www.rfc-editor.org/info/rfc5510>.

[RFC5651]

M. Luby, M. Watson, and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, DOI 10.17487/RFC5651, October 2009,
<https://www.rfc-editor.org/info/rfc5651>.

[RFC5740]

B. Adamson, C. Bormann, M. Handley, and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
<https://www.rfc-editor.org/info/rfc5740>.

[RFC6363]

M. Watson, A. Begen, and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8406]

B. Adamson, C. Adjih, J. Bilbao, V. Firoiu, F. Fitzek, S. Ghanem, E. Lochin, A. Masucci, M-J. Montpetit, M. Pedersen, G. Peralta, V. Roca, Saxena, and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018,
<https://www.rfc-editor.org/info/rfc8406>.

[RFC8680]

V. Roca, and A. Begen, "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes", RFC 8680, DOI 10.17487/RFC8680, January 2020,
<https://www.rfc-editor.org/info/rfc8680>.

[RFC9265]

N. Kuhn, E. Lochin, F. Michel, and M. Welzl, "Forward Erasure Correction (FEC) Coding and Congestion Control in Transport", RFC 9265, DOI 10.17487/RFC9265, July 2022,
<https://www.rfc-editor.org/info/rfc9265>.

[A-FEC]

J. Bolot, S. Fosse-Parisis, and D. Towsley, "Adaptive FEC-based error control for Internet telephony", DOI 10.1109/INFCOM.1999.752166, March 1999,
<https://doi.org/10.1109/INFCOM.1999.752166>.

[AHL-00]

R. Ahlswede, N. Cai, S. Li, and R. Yeung, "Network information flow", DOI 10.1109/18.850663, July 2000,
<https://doi.org/10.1109/18.850663>.

[CTCP]

M. Kim, J. Cloud, A. ParandehGheibi, L. Urbina, K. Fouli, D. Leith, and M. Medard, "Network Coded TCP (CTCP)", arXiv 1212.2291v3, April 2013,
<https://arxiv.org/abs/1212.2291>.

[RED-FEC]

C. Lin, C. Shieh, N. Chilamkurti, C. Ke, and W. Hwang, "A RED-FEC Mechanism for Video Transmission Over WLANs", DOI 10.1109/TBC.2008.2001713, September 2008,
<https://doi.org/10.1109/TBC.2008.2001713>.

[RMCAT-ADAPTIVE-FEC]

NetApp, V. Singh, M. Nagy, J. Ott, and L. Eggert, "Congestion Control Using FEC for Conversational Media", Internet-Draft draft-singh-rmcat-adaptive-fec-03, March 2016,
<https://datatracker.ietf.org/doc/html/draft-singh-rmcat-adaptive-fec-03>.

[Tetrys]

J. Lacan, and E. Lochin, "Rethinking reliability for long-delay networks", DOI 10.1109/IWSSC.2008.4656755, October 2008,
<https://doi.org/10.1109/IWSSC.2008.4656755>.

[Tetrys-RT]

P. Tournoux, E. Lochin, J. Lacan, A. Bouabdallah, and V. Roca, "On-the-Fly Erasure Coding for Real-Time Video Applications", DOI 10.1109/TMM.2011.2126564, August 2011,
<http://dx.doi.org/10.1109/TMM.2011.2126564>.

[THAI]

T. Tran Thai, J. Lacan, and E. Lochin, "Joint on-the-fly network coding/video quality adaptation for real-time delivery", DOI 10.1016/j.image.2014.02.003, April 2014,
<https://doi.org/10.1016/j.image.2014.02.003>.

Jonathan Detchart

Emmanuel Lochin

Jerome Lacan

Vincent Roca