wdiff rfc9407.original rfc9407.txt

NWCRG

Internet Research Task Force (IRTF) J. Detchart
Internet-Draft
Request for Comments: 9407 ISAE-SUPAERO
Intended status:
Category: Experimental E. Lochin
Expires: 21 May 2023
ISSN: 2070-1721 ENAC
J. Lacan
ISAE-SUPAERO
V. Roca
INRIA
17 November 2022

Tetrys, an
June 2023

Tetrys: An On-the-Fly Network Coding Protocol
draft-irtf-nwcrg-tetrys-04

Abstract

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.

This document is a product of the Coding for Efficient Network NetWork
Communications Research Group (NWCRG). It conforms to the NWCRG
taxonomy[RFC8406].
taxonomy described in RFC 8406.

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 not an Internet Standards Track specification; it is
published for examination, experimental implementation, and BCP 79.

Internet-Drafts are working documents
evaluation.

This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering Research Task
Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. (IRTF). The list IRTF publishes the results of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts Internet-related
research and development activities. These results might not be
suitable for deployment. This RFC represents the consensus of the
Coding for Efficient NetWork Communications Research Group of the
Internet Research Task Force (IRTF). Documents approved for
publication by the IRSG are draft documents valid not candidates for a maximum any level of Internet
Standard; see Section 2 of six months RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 21 May 2023.
https://www.rfc-editor.org/info/rfc9407.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Definitions, Notations Notations, and Abbreviations . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Tetrys Basic Functions . . . . . . . . . . . . . . . . . . . 7
4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. The Elastic Encoding Window . . . . . . . . . . . . . . . 8
4.3. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Common Header Format . . . . . . . . . . . . . . . . . . 8
5.1.1. Header Extensions . . . . . . . . . . . . . . . . . . 10
5.2. Source Packet Format . . . . . . . . . . . . . . . . . . 11
5.3. Coded Packet Format . . . . . . . . . . . . . . . . . . . 12
5.3.1. The Encoding Vector . . . . . . . . . . . . . . . . . 13
5.4. Window Update Packet Format . . . . . . . . . . . . . . . 17
6. Research Issues . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Interaction with Congestion Control . . . . . . . . . . . 18
6.2. Adaptive Coding Rate . . . . . . . . . . . . . . . . . . 19
6.3. Using Tetrys Below The below the IP Layer For for Tunneling . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 21
7.2. Attacks against the Data Flow . . . . . . . . . . . . . . 21
7.3. Attacks against Signaling . . . . . . . . . . . . . . . . 22
7.4. Attacks against the Network . . . . . . . . . . . . . . . 22
7.5. Baseline Security Operation . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1.
9.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2.
9.2. Informative References . . . . . . . . . . . . . . . . . 25
Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26

1. Introduction

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.

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 [AHL-00] 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 [RFC3452] [RFC5052] [RFC5445] and the
FECFRAME [RFC8680] working groups. 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
[Tetrys], [Tetrys-RT] . [Tetrys] [Tetrys-RT].

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 Section 4.

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.

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.

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
Section 6 following our own experience and observations.

1.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2. Definitions, Notations Notations, and Abbreviations

The notation used in this document is based on the NWCRG taxonomy
[RFC8406] .
[RFC8406].

Source Symbol: a A symbol that is transmitted between the ingress and
egress of the network.

Coded Symbol: a A linear combination over a finite field of a set of
Source Symbols.
source symbols.

Source Symbol ID: a A sequence number to identify the Source
Symbols. source symbols.

Coded Symbol ID: a A sequence number to identify the Coded Symbols. coded symbols.

Encoding Coefficients: elements Elements of the finite field characterizing
the linear combination used to generate Coded Symbols. coded symbols.

Encoding Vector: a A set of the coding coefficients and input Source
Symbol source
symbol IDs.

Source Packet: a Source Packet A source packet contains a Source Symbol source symbol with its
associated IDs.

Coded Packet: a Coded Packet A coded packet contains a Coded Symbol, coded symbol, the Coded
Symbol's coded
symbol's ID, and Encoding Vector. encoding vector.

Input Symbol: a A symbol at the input of the Tetrys Encoder. encoder.

Output Symbol: a A symbol generated by the Tetrys Encoder. encoder. For a
non-systematic non-
systematic mode, all Output Symbols output symbols are Coded Symbols. coded symbols. For a
systematic mode, Output Symbols output symbols MAY 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. encoding vectors.

Feedback Packet: a Feedback Packet A feedback packet is a packet containing
information about the decoded or received Source Symbols. 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 An encoder-side buffer that stores all the non-acknowledged Source Packets
unacknowledged source packets of the input flow involved in the
coding process.

Coding Coefficient Generator Identifier: a Identifier (CCGI): A unique identifier
that defines a function or an algorithm allowing to generate the
Encoding Vector. generation of
the encoding vector.

Code Rate: Define Defines the rate between the number of Input Symbols input symbols and
the number of Output Symbols. output symbols.

3. Architecture

3.1. Use Cases

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 be
a multiplex of several upper layer upper-layer streams. Transmission MAY 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.

3.2. Overview

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

Figure 1: Tetrys Architecture

The Tetrys protocol features several key functionalities. The
mandatory features are: include:

* on-the-fly encoding;

* decoding;

* signaling, to carry in particular the symbol identifiers IDs in the encoding
window and the associated coding coefficients when meaningful;

* feedback management;

* elastic window management; and

* Tetrys packet header creation and processing;

and the processing.

The optional features are : include:

* channel estimation;

* dynamic adjustment of the Code Rate code rate and flow control; and

* congestion control management (if appropriate). See Section 6.1
for further details; details.

Several building blocks provide these the following functionalities:

The Tetrys Building Block: this BB 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.

The Window Management Building Block: this This building block is in
charge of managing the encoding window at a Tetrys sender.

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) [RFC5651],
NORM NACK-Oriented Reliable Multicast
(NORM) [RFC5740], FECFRAME and FEC Framework (FECFRAME) [RFC8680].

4. Tetrys Basic Functions

4.1. Encoding

At the beginning of a transmission, a Tetrys Encoder encoder MUST 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 encoder
MAY generate Coded Symbols coded symbols when it receives a Source Symbol source symbol from the
application or some feedback from the decoding blocks. blocks depending on
the code rate.

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 take as input the Source Symbol source symbol IDs and the Coded Symbol coded symbol ID as an input
and MAY determine a coefficient in a deterministic way as presented
in Section 5.3. Finally, the Coded Symbol coded symbol is the sum of the Source
Symbols source
symbols multiplied by their corresponding coefficients.

A Tetrys Encoder SHOULD encoder MUST 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.

4.2. The Elastic Encoding Window

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 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. coded symbols.

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.

4.3. Decoding

A standard Gaussian elimination is sufficient to recover the erased
Source Symbols,
source symbols when the matrix rank enables it.

5. Packet Format

5.1. Common Header Format

All types of Tetrys packets share the same common header format (see
Figure 2).

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

Figure 2: Common Header Format

As already noted above in the document, above, this format is inspired by, and inherits from from, the
LCT header format [RFC5651] with slight modifications.

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=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.

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,
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, 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.

* PKT_TYPE:

Tetrys packet type, type (PKT_TYPE): 8 bits. Type of packet. There is 3 are three types of
packets: the PKT_TYPE_SOURCE (0) (0b00) defined in Section 5.2, the
PKT_TYPE_CODED (1) (0b01) defined in Section 5.3 and the
PKT_TYPE_WND_UPT (3), (0b11) for window update packets defined in
Section 5.4.

Congestion Control Information (CCI): 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 be 0 bits (absent)
if C=0. C is set to 0b00. This field MUST be 32 bits if C=1. C is set to
0b01. This field MUST be 64 bits if C=2. C is set to 0b10. This field
MUST be 96 bits if C=3.

* C is set to 0b11.

Transport Session Identifier (TSI): 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 serve as the TSI for the
session. If there is no underlying TSI provided by the network, transport
transport, or any other layer, then the TSI MUST be included in
the Tetrys header.

5.1.1. Header Extensions

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 header extensions MAY 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. header
extensions.

If present, Header Extensions header extensions MUST 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 MUST NOT be introduced without changing the
Tetrys version number.

There are two formats for Header Extensions header extensions as depicted in Figure 3 : 3:

* The first format is used for variable-length extensions, extensions with
Header Extension Type
header extension type (HET) values between 0 and 127.

* The second format is used for fixed-length (one 32-bit word)
extensions,
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Header Extension Format
*

Header Extension Type (HET): 8 bits 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. variable-
length header extensions. HET values from 128 to 255 are used for fixed-length
fixed-length, 32-bit Header Extensions.

* header extensions.

Header Extension Length (HEL): 8 bits bits. The length of the whole Header Extension field,
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): variable length 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 header extension MUST 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.

5.2. Source Packet Format

A Source Packet 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 source symbols MAY
have variable sizes.

Figure 4: Source Packet Format

Common Packet Header: a A common packet header (as common header
format) where Packet Type=0. packet type is set to 0b00.

Source Symbol ID: the The sequence number to identify a Source Symbol. source symbol.

Payload: the The payload (Source Symbol) (source symbol).

5.3. Coded Packet Format

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 source symbols MAY 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 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 encoding vector MUST signal the use of
variable Source Symbol source symbol sizes with the field V (see Section 5.3.1).

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

Figure 5: Coded Packet Format

Common Packet Header: a A common packet header (as common header
format) where Packet Type=1. packet type is set to 0b01.

Coded Symbol ID: the The sequence number to identify a Coded Symbol. coded symbol.

Encoding Vector: an Encoding Vector An encoding vector to define the linear combination
used (coefficients and Source Symbols). source symbols).

Encoded Payload Size: the The coded payload size used if the Source
Symbols source
symbols have a variable size (optional,Section (optional, Section 5.3.1).

Payload: the Coded Symbol. The coded symbol.

5.3.1. The Encoding Vector

An Encoding Vector 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 be stored in different ways depending on the
situation.

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

Figure 6: Encoding Vector Format

Encoding Vector Length (EV_LEN) (8-bits): (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 the function used to generate the coefficients. As a
CCGI is included in each encoded vector, it MAY 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
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 [RFC5510], 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^(8)), 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) + x^(4) + x^(3) + x^(2) + 1

With GF(2^(4)), 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) + x + 1

- 0: Vandermonde based

* 0b00: Vandermonde-based coefficients over the finite field
GF(2^(4)),
GF(2^(4)) as defined below. Each coefficient is built as
alpha^( (source_symbol_id*coded-symbol_id) % 16), with alpha
the root of the primitive polynomial.

- 1: Vandermonde based

* 0b01: Vandermonde-based coefficients over the finite field
GF(2^(8)),
GF(2^(8)) 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 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^( (1 * 1) % 256), alpha^(
(1 * 2) % 256), and alpha^( (1 * 4) % 256).

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

- 00
* 0b00 means there is no Source Symbol source symbol ID information.

- 01

* 0b01 means the Encoding Vector encoding vector contains the edge blocks of the
Source Symbol
source symbol IDs without compression.

- 10

* 0b10 means the Encoding Vector encoding vector contains the compressed list of
the Source Symbol source symbol IDs.

- 11

* 0b11 means the Encoding Vector encoding vector contains the compressed edge
blocks of the Source Symbol source symbol IDs.

Store the Encoding Coefficients (C): 1 bit to indicate if an
Encoding Vector
encoding vector contains information about the coefficients used.

Having Source Symbols with Variable Size Encoding (V): set 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 coded packets MUST have the 'Encoded Payload Size' field.

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

Number of coefficients Coefficients (NB_COEFS): The number of the coefficients
used to generate the associated Coded Symbol.

* coded symbol.

The first source identifier First Source Identifier (FIRST_SOURCE_ID): the The first Source
Symbol source
symbol ID used in the combination.

Number of bits Bits for each edge block Each Edge Block (b_id): the The number of bits needed
to store the edge.

Information about the Source Symbol IDs (id_bit_vector): if I=01, 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.

* way.

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

Padding: padding 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).

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
in the list MAY 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 be
stored,
stored and a differential transform to reduce the number of bits
needed to represent an identifier MAY be used.

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]) [1..3], [5..6], [8..10]).

There are several ways to store the Source Symbols source symbol IDs into the
encoding vector:

* If no information about the Source Symbol source symbol IDs is needed, the field
I MUST be set to 0b00: no b_id and no id_bit_vector field 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 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 integers (1, 3,
4, 5, 6, 10) into id_bit_vectors.

* If the Source Symbols Ids 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 5.3.1.1, but rather than compressing the edge blocks, we
compress the full list of the Source Symbol 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.

5.3.1.1. Compressed list List of Source Symbol IDs

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]. [1..3],
[5..6], [8..10].

If we want to compress and store this list into the encoding vector,
we MUST follow this procedure:

1. Keep the first element in the packet as the first_source_id: 1.

2. 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] [2, 2, 1, 2,
2].

3. 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.

4. 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, 10, 01, 10,
10.

5.3.1.2. Decompressing the Source Symbol IDs

When a Tetrys Decoding Block decoding block wants to reverse the operations, this
algorithm is used:

1. Rebuild the list of the transmitted elements by reading the bit
vector and b: [10 10 01 10 [10, 10, 01, 10, 10] => [2,2,1,2,2] [2, 2, 1, 2, 2].

2. 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, ...] =>
[1,3,5,6,8,10] [1, 3, 5, 6, 8, 10].

3. Rebuild the blocks using the list and first_source_id:
[1..3],[5..6],[8..10]. [1..3],
[5..6], [8..10].

5.4. Window Update Packet Format

A Tetrys Decoder decoder MAY 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 OPTIONAL; hence, they could be omitted or lost in
transmission without impacting the protocol behavior.

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

Figure 7: Window Update Packet Format

Common Packet Header: a A common packet header (as common header
format) where Packet Type=2. packet type is set to 0b10.

nb_missing_src: the The number of missing Source Symbols source symbols in the receiver
since the beginning of the session.

nb_not_used_coded_symb: the 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). source symbols).

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

plr: packet 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.

sack_size: the 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 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.

6. Research Issues

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.

6.1. Interaction with Congestion Control

The Tetrys and congestion control components generate two separate
channels (see [RFC9265], section Section 2.1):

* the 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.); etc.).

* the 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.

In practice, depending on how Tetrys is deployed (i.e., above, within
or below the transport layer), [RFC9265] identifies and discusses
several topics. They

The following topics, which are briefly listed below identified and discussed by
[RFC9265], are adapted to the particular case deployment cases of Tetrys: Tetrys
(i.e., above, within, or below the transport layer):

* congestion related 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 [RFC9265],
section 5; Section 5.

* having 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; practice.

* coding 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; 6.2.

* 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; needed.

* protecting Protecting several application flows within a single Tetrys flow
raises additional questions. This topic is discussed more in
detail in Section 6.3.

6.2. Adaptive Coding Rate

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 [A-FEC]. 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.

The impact deploying a FEC mechanism within the transport layer is
further discussed in Section 4 of [RFC9265], 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 [CTCP]. 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
[I-D.singh-rmcat-adaptive-fec]
[RMCAT-ADAPTIVE-FEC], where the authors point out that an increase in
the repair ratio should be done conjointly with a decrease in the
source sending rate.

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 [RED-FEC]. 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 [THAI] with Tetrys. [THAI]. 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).

To conclude, there are multiple ways to enable an adaptive coding
rate. However, all of them depend on:

* 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, congestion or to fit
application requirements).

6.3. Using Tetrys Below The below the IP Layer For for Tunneling

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. Tetrys are needed.

7. Security Considerations

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 [RFC6363]. This section leverages builds on this
reference, adding new considerations to comply with Tetrys
specificities when meaningful.

7.1. Problem Statement

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

In the following sections, we discuss these attacks, according to the
component targeted by the attacker.

7.2. Attacks against the Data Flow

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

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). Section 7.3).

7.3. Attacks against Signaling

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.

On the opposite, encoder.

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 well-
received or decoded source packets from its linear system), which
mechanically increases computational costs on both sides, encoder sides (encoder and decoder.
decoder).

7.4. Attacks against the Network

Tetrys can react to congestion signals (Section 6.1) 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.

7.5. Baseline Security Operation

Tetrys can benefit from an IPsec/Encapsulating IPsec / Encapsulating Security Payload
(IPsec/ESP) [RFC4303], [RFC4303] that provides in particular confidentiality, origin
authentication, integrity, and anti-replay services. IPsec/
ESP 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.

8. IANA Considerations

This document does not ask for any has no IANA registration. actions.

9. Implementation Status

Editor's notes: RFC Editor, please remove this section motivated by
RFC 7942 before publishing the RFC. Thanks!

An implementation of Tetrys exists:

organization: ISAE-SUPAERO

Description: This is a proprietary implementation made by ISAE-
SUPAERO

Maturity: "production"

Coverage: this software implements TETRYS with some modifications

Licensing: proprietary

Implementation experience: maximum

Information update date: January 2022

Contact: jonathan.detchart@isae-supaero.fr

10. Acknowledgments

First, the authors want sincerely to thank Marie-Jose Montpetit for
continuous help and support on Tetrys. Marie-Jo, many thanks!

The authors also wish to thank NWCRG group members for numerous
discussions on on-the-fly coding that helped finalize this document.

Finally, the authors would like to thank Colin Perkins for providing
comments and feedback on the document.

11. References

11.1.

9.1. Normative References

[RFC2119] Bradner, S., "Keywords "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>.

[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., Crowcroft, J., and RFC Publisher, "Forward Error
Correction (FEC) Building Block", RFC 3452,
DOI 10.17487/RFC3452, December 2002,
<https://www.rfc-editor.org/info/rfc3452>.

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

[RFC5052] Watson, M., Luby, M., 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] Watson, M., "Basic Forward Error Correction (FEC)
Schemes", RFC 5445, DOI 10.17487/RFC5445, March 2009,
<https://www.rfc-editor.org/info/rfc5445>.

[RFC5510] Lacan, J., Roca, V., Peltotalo, J., Peltotalo, S., and RFC
Publisher, 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] Luby, M., Watson, M., Vicisano, L., and RFC Publisher, L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651,
DOI 10.17487/RFC5651, October 2009,
<https://www.rfc-editor.org/info/rfc5651>.

[RFC5740] Adamson, B., Bormann, C., Handley, M., Macker, J., and RFC
Publisher, 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] Watson, M., Begen, A., Roca, V., and RFC Publisher, V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>.

[RFC8174] Leiba, B., "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] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M.,
Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P.,
Sivakumar, S., and RFC Publisher,
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] Roca, V., Begen, A., V. and RFC Publisher, 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] Kuhn, N., Lochin, E., Michel, F., Welzl, M., and RFC
Publisher, 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>.

11.2.

9.2. Informative References

[A-FEC] Bolot, J., Fosse-Parisis, S., and D. Towsley, "Adaptive
FEC-based error control for Internet telephony", IEEE
INFOCOM 99, '99, Conference on Computer Communications, New
York, NY, USA, Vol. 3, pp. 1453-1460 vol. 3 1453-1460,
DOI 10.1109/INFCOM.1999.752166, 1999. March 1999,
<https://doi.org/10.1109/INFCOM.1999.752166>.

[AHL-00] Ahlswede, R., Ning Cai, N., Li, S.-Y.R., S., and R.W. R. Yeung, "Network
information flow", IEEE Transactions on Information Theory vol.46, no.4, pp.1204,1216,
Theory, Vol. 46, Issue 4, pp. 1204-1216,
DOI 10.1109/18.850663, July 2000. 2000,
<https://doi.org/10.1109/18.850663>.

[CTCP] Kim (et al.), Kim, M., Cloud, J., ParandehGheibi, A., Urbina, L., Fouli,
K., Leith, D., and M. Medard, "Network Coded TCP (CTCP)",
arXiv 1212.2291v3, 2013.

[I-D.singh-rmcat-adaptive-fec]
Singh, V., Nagy, M., Ott, J., and L. Eggert, "Congestion
Control Using FEC for Conversational Media", Work in
Progress, Internet-Draft, draft-singh-rmcat-adaptive-fec-
03, 20 March 2016, <https://www.ietf.org/archive/id/draft-
singh-rmcat-adaptive-fec-03.txt>. April 2013,
<https://arxiv.org/abs/1212.2291>.

[RED-FEC] Lin, C., Shieh, C., Chilamkurti, N. K., N., Ke, C., and H. S. W. Hwang,
"A RED-FEC Mechanism for Video Transmission Over WLANs",
IEEE Transactions on Broadcasting, vol. Vol. 54, no. Issue 3, pp. 517-524
517-524, DOI 10.1109/TBC.2008.2001713, September 2008. 2008,
<https://doi.org/10.1109/TBC.2008.2001713>.

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

[Tetrys] Lacan, J. and E. Lochin, "Rethinking reliability for long-
delay networks", International Workshop on Satellite and
Space Communications 2008 (IWSSC08), Communications, Toulouse, France, pp. 90-94,
DOI 10.1109/IWSSC.2008.4656755, October 2008. 2008,
<https://doi.org/10.1109/IWSSC.2008.4656755>.

[Tetrys-RT]
Tournoux, P.U., P., Lochin, E., Lacan, J., Bouabdallah, A., and
V. Roca, "On-the-fly erasure coding "On-the-Fly Erasure Coding for real-time
video applications", Real-Time Video
Applications", IEEE Transactions on Multimedia, Vol Vol. 13,
Issue 4, pp. 797-812, DOI 10.1109/TMM.2011.2126564, August 2011 (TMM.2011), August 2011.
2011, <http://dx.doi.org/10.1109/TMM.2011.2126564>.

[THAI] Tran-Thai, Tran Thai, T., Lacan, J., and E. Lochin, "Joint on-the-fly
network coding/video quality adaptation for real-time
delivery", Signal Processing: Image Communication, vol. Vol. 29
(no. 4),
Issue 4, pp. 449-461 ISSN 0923-5965, 2014. 449-461, DOI 10.1016/j.image.2014.02.003,
April 2014, <https://doi.org/10.1016/j.image.2014.02.003>.

Acknowledgments

First, the authors want sincerely to thank Marie-Jose Montpetit for
continuous help and support on Tetrys. Marie-Jo, many thanks!

The authors also wish to thank NWCRG group members for numerous
discussions on on-the-fly coding that helped finalize this document.

Finally, the authors would like to thank Colin Perkins for providing
comments and feedback on the document.

Authors' Addresses

Jonathan Detchart
ISAE-SUPAERO
BP 54032
10, avenue Edouard Belin
BP 54032
31055 Toulouse CEDEX 4
France
Email: jonathan.detchart@isae-supaero.fr

Emmanuel Lochin
ENAC
7, avenue Edouard Belin
31400 Toulouse
France
Email: emmanuel.lochin@enac.fr

Jerome Lacan
ISAE-SUPAERO
BP 54032
10, avenue Edouard Belin
BP 54032
31055 Toulouse CEDEX 4
France
Email: jerome.lacan@isae-supaero.fr

Vincent Roca
INRIA
Inovallee; Montbonnot
655, avenue de l'Europe
Inovallee; Montbonnot
38334 ST ISMIER cedex St Ismier CEDEX
France
Email: vincent.roca@inria.fr