< draft-irtf-nwcrg-tetrys-01.txt   draft-irtf-nwcrg-tetrys-02.txt >
NWCRG J. Detchart NWCRG J. Detchart
Internet-Draft ISAE-SUPAERO Internet-Draft ISAE-SUPAERO
Intended status: Experimental E. Lochin Intended status: Experimental E. Lochin
Expires: 13 August 2022 ENAC Expires: October 26, 2022 ENAC
J. Lacan J. Lacan
ISAE-SUPAERO ISAE-SUPAERO
V. Roca V. Roca
INRIA INRIA
9 February 2022 April 24, 2022
Tetrys, an On-the-Fly Network Coding Protocol Tetrys, an On-the-Fly Network Coding Protocol
draft-irtf-nwcrg-tetrys-01 draft-irtf-nwcrg-tetrys-02
Abstract Abstract
This document describes Tetrys, an On-The-Fly Network Coding (NC) This document describes Tetrys, an On-The-Fly Network Coding (NC)
protocol that MAY be used to transport delay and loss-sensitive data protocol that MAY be used to transport delay and loss-sensitive data
over a lossy network. Tetrys MAY recover from erasures within an over a lossy network. Tetrys MAY recover from erasures within an
RTT-independent delay, thanks to the transmission of coded packets. RTT-independent delay, thanks to the transmission of Coded Packets.
This document is a record of the experience gained by the authors This document is a record of the experience gained by the authors
while developing and testing in real conditions the Tetrys protocol. while developing and testing in real conditions the Tetrys protocol.
This document is a product of the Coding for Efficient Network This document is a product of the Coding for Efficient Network
Communications Research Group (NWCRG). It conforms to the NWCRG Communications Research Group (NWCRG). It conforms to the NWCRG
taxonomy[RFC8406]. taxonomy[RFC8406].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 August 2022. This Internet-Draft will expire on October 26, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Revised BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Definitions, Notations and Abbreviations . . . . . . . . . . 4 2. Definitions, Notations and Abbreviations . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Tetrys Basic Functions . . . . . . . . . . . . . . . . . . . 6 4. Tetrys Basic Functions . . . . . . . . . . . . . . . . . . . 6
4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. The Elastic Encoding Window . . . . . . . . . . . . . . . 7 4.2. The Elastic Encoding Window . . . . . . . . . . . . . . . 7
4.3. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Common Header Format . . . . . . . . . . . . . . . . . . 7 5.1. Common Header Format . . . . . . . . . . . . . . . . . . 7
5.1.1. Header Extensions . . . . . . . . . . . . . . . . . . 9 5.1.1. Header Extensions . . . . . . . . . . . . . . . . . . 9
5.2. Source Packet Format . . . . . . . . . . . . . . . . . . 11 5.2. Source Packet Format . . . . . . . . . . . . . . . . . . 10
5.3. Coded Packet Format . . . . . . . . . . . . . . . . . . . 11 5.3. Coded Packet Format . . . . . . . . . . . . . . . . . . . 11
5.3.1. The Encoding Vector . . . . . . . . . . . . . . . . . 12 5.3.1. The Encoding Vector . . . . . . . . . . . . . . . . . 12
5.4. Acknowledgement Packet Format . . . . . . . . . . . . . . 15 5.4. Window Update Packet Format . . . . . . . . . . . . . . . 16
6. Research Issues . . . . . . . . . . . . . . . . . . . . . . . 17 6. Research Issues . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Interaction with Congestion Control . . . . . . . . . . . 17 6.1. Interaction with Congestion Control . . . . . . . . . . . 18
6.2. Adaptive Coding Rate . . . . . . . . . . . . . . . . . . 18 6.2. Adaptive Coding Rate . . . . . . . . . . . . . . . . . . 19
6.3. Using Tetrys Below The IP Layer For Tunneling . . . . . . 19 6.3. Using Tetrys Below The IP Layer For Tunneling . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document is a product of and represents the collaborative work This document is a product of and represents the collaborative work
and consensus of the Coding for Efficient Network Communications and consensus of the Coding for Efficient Network Communications
Research Group (NWCRG). It is not an IETF product and is not an IETF Research Group (NWCRG). It is not an IETF product and is not an IETF
standard. standard.
This document describes Tetrys, a novel erasure coding protocol. This document describes Tetrys, a novel erasure coding protocol.
Network codes were introduced in the early 2000s [AHL-00] to address Network codes were introduced in the early 2000s [AHL-00] to address
the limitations of transmission over the Internet (delay, capacity the limitations of transmission over the Internet (delay, capacity
and packet loss). While the use of network codes is fairly recent in and packet loss). While the use of network codes is fairly recent in
the Internet community, the use of application layer erasure codes in the Internet community, the use of application layer erasure codes in
the IETF has already been standardized in the RMT [RFC3452] and the the IETF has already been standardized in the RMT [RFC3452] and the
FECFRAME [RFC8680] working groups. The protocol presented here MAY FECFRAME [RFC8680] working groups. The protocol presented here MAY
be seen as a network coding extension to classic unicast transport be seen as a network coding extension to standard unicast transport
protocols (or even multicast or anycast with a few modifications). protocols (or even multicast or anycast with a few modifications).
The current proposal MAY be considered a combination of network The current proposal MAY be considered a combination of network
erasure coding and feedback mechanisms [Tetrys], [Tetrys-RT] . erasure coding and feedback mechanisms [Tetrys], [Tetrys-RT] .
The main innovation of the Tetrys protocol is in the generation of The main innovation of the Tetrys protocol is in the generation of
coded packets from an elastic encoding window. This window is filled Coded Packets from an Elastic Encoding Window. This window is filled
by any source packets coming from an input flow and is periodically by any Source Packets coming from an input flow and is periodically
updated with the receiver's feedbacks. These feedbacks return to the updated with the receiver's feedbacks. These feedbacks return to the
sender the highest sequence number received or rebuilt, which allows sender the highest sequence number received or rebuilt, which allows
to flush the corresponding source packets stored in the encoding to flush the corresponding Source Packets stored in the encoding
window. The size of this window MAY be fixed or dynamically updated. window. The size of this window MAY be fixed or dynamically updated.
If the window is full, incoming source packets replace older sources If the window is full, incoming Source Packets replace older sources
packets which are dropped. As a matter of fact, its limit should be packets which are dropped. As a matter of fact, its limit should be
correctly sized. Finally, Tetrys allows to deal with losses on both correctly sized. Finally, Tetrys allows to deal with losses on both
the forward and return paths and in particular, is resilient to the forward and return paths and in particular, is resilient to
acknowledgment losses. acknowledgment losses. All these operations are further detailed in
Section Section 4.
With Tetrys, a coded packet is a linear combination over a finite With Tetrys, a Coded Packet is a linear combination over a finite
field of the data source packets belonging to the coding window. The field of the data Source Packets belonging to the coding window. The
coefficients finite field's choice is a trade-off between the best coefficients finite field's choice is a trade-off between the best
erasure recovery performance (finite fields of 256 elements) and the erasure recovery performance (finite fields of 256 elements) and the
system constraints (finite fields of 16 elements is prefered) and is system constraints (finite fields of 16 elements is preferred) and is
driven by the application. driven by the application.
Thanks to the elastic encoding window, the coded packets are built Thanks to the Elastic Encoding Window, the Coded Packets are built
on-the-fly, by using an algorithm or a function to choose the on-the-fly, by using a predefined method to choose the coefficients.
coefficients. The redundancy ratio MAY be dynamically adjusted, and The redundancy ratio MAY be dynamically adjusted, and the
the coefficients MAY be generated in different ways along with a coefficients MAY be generated in different ways, during the
transmission. Compared to FEC block codes, this allows reducing the transmission. Compared to FEC block codes, this allows reducing the
bandwidth use and the decoding delay. bandwidth use and the decoding delay.
This document is a record of the experience gained by the authors The design of Tetrys protocol detailed in this document is completed
while developing and testing in real conditions the Tetrys protocol. by a record of the experience gained by the authors while developing
and testing in real conditions the Tetrys protocol. In particular,
several research issues are discussed in Section 6 following our own
experience and observations.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] . document are to be interpreted as described in [RFC2119] .
2. Definitions, Notations and Abbreviations 2. Definitions, Notations and Abbreviations
The notation used in this document is based on the NWCRG taxonomy The notation used in this document is based on the NWCRG taxonomy
[RFC8406] . [RFC8406] .
Source symbol: a symbol that has to be transmitted between the Source Symbol: a symbol that has to be transmitted between the
ingress and egress of the network. ingress and egress of the network.
Coded symbol: a linear combination over a finite field of a set of Coded Symbol: a linear combination over a finite field of a set of
source symbols. Source Symbols.
Source symbol ID: a sequence number to identify the source Source Symbol ID: a sequence number to identify the Source
symbols. Symbols.
Coded symbol ID: a sequence number to identify the coded symbols. Coded Symbol ID: a sequence number to identify the Coded Symbols.
Encoding coefficients: elements of the finite field characterizing Encoding Coefficients: elements of the finite field characterizing
the linear combination used to generate coded symbols. the linear combination used to generate Coded Symbols.
Encoding vector: a set of the coding coefficients and input source Encoding Vector: a set of the coding coefficients and input Source
symbol IDs. Symbol IDs.
Source packet: a source packet contains a source symbol with its Source Packet: a Source Packet contains a Source Symbol with its
associated IDs. associated IDs.
Coded packet: a coded packet contains a coded symbol, the coded Coded Packet: a Coded Packet contains a Coded Symbol, the Coded
symbol's ID, and encoding vector. Symbol's ID, and Encoding Vector.
Input symbol: a symbol at the input of the Tetrys Encoding Input Symbol: a symbol at the input of the Tetrys Encoder.
Building Block.
Output symbol: a symbol generated by the Tetrys Encoding Building Output Symbol: a symbol generated by the Tetrys Encoder. For a
Block. For a non-systematic mode, all output symbols are coded non-systematic mode, all Output Symbols are Coded Symbols. For a
symbols. For a systematic mode, output symbols MAY be the input systematic mode, Output Symbols MAY be the Input Symbols and a
symbols and a number of coded symbols that are linear combinations number of Coded Symbols that are linear combinations of the Input
of the input symbols + the encoding vectors. Symbols + the Encoding Vectors.
Feedback packet: a feedback packet is a packet containing Feedback Packet: a Feedback Packet is a packet containing
information about the decoded or received source symbols. It MAY information about the decoded or received Source Symbols. It MAY
also bring additional information about the Packet Error Rate or also bring additional information about the Packet Error Rate or
the number of various packets in the receiver decoding window. the number of various packets in the receiver decoding window.
Elastic Encoding Window: an encoder-side buffer that stores all Elastic Encoding Window: an encoder-side buffer that stores all
the non-acknowledged source packets of the input flow involved in the non-acknowledged Source Packets of the input flow involved in
the coding process. the coding process.
Coding Coefficient Generator Identifier: a unique identifier that Coding Coefficient Generator Identifier: a unique identifier that
defines a function or an algorithm allowing to generate the defines a function or an algorithm allowing to generate the
encoding vector. Encoding Vector.
Code rate: Define the rate between the number of input symbols and Code Rate: Define the rate between the number of Input Symbols and
the number of output symbols. the number of Output Symbols.
3. Architecture 3. Architecture
3.1. Use Cases 3.1. Use Cases
Tetrys is well suited, but not limited to the use case where there is Tetrys is well suited, but not limited to, the use case where there
a single flow originated by a single source, with intra stream coding is a single flow originated by a single source, with intra stream
at a single encoding node. Note that the input stream MAY be a coding at a single encoding node. Note that the input stream MAY be
multiplex of several upper layer streams. Transmission MAY be over a a multiplex of several upper layer streams. Transmission MAY be over
single path or multiple paths. This is the simplest use-case, that a single path or multiple paths. This is the simplest use-case, that
is very much aligned with currently proposed scenarios for end-to-end is very much aligned with currently proposed scenarios for end-to-end
streaming. streaming.
3.2. Overview 3.2. Overview
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| App | | App | | App | | App |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
| ^ | ^
| source source | | Source Source |
| symbols symbols | | Symbols Symbols |
| | | |
v | v |
+----------+ +----------+ +----------+ +----------+
| | output packets | | | | output packets | |
| Tetrys |--------------->| Tetrys | | Tetrys |--------------->| Tetrys |
| Encoder |feedback packets| Decoder | | Encoder |Feedback Packets| Decoder |
| |<---------------| | | |<---------------| |
+----------+ +----------+ +----------+ +----------+
Figure 1: Tetrys Architecture Figure 1: Tetrys Architecture
The Tetrys protocol features several key functionalities. The The Tetrys protocol features several key functionalities. The
mandatory features are: mandatory features are:
* on-the-fly encoding; o on-the-fly encoding;
* decoding; o decoding;
* signaling, to carry in particular the symbol identifiers in the
o signaling, to carry in particular the symbol identifiers in the
encoding window and the associated coding coefficients when encoding window and the associated coding coefficients when
meaningful; meaningful;
* feedback management; o feedback management;
* elastic window management; o elastic window management;
* Tetrys packet header creation and processing; o Tetrys packet header creation and processing;
and the optional features are : and the optional features are :
* channel estimation; o channel estimation;
* dynamic adjustment of the code rate and flow control; o dynamic adjustment of the Code Rate and flow control;
* congestion control management (if appropriate). See Section 6.1 o congestion control management (if appropriate). See Section 6.1
for further details; for further details;
Several building blocks provide these functionalities: Several building blocks provide these functionalities:
* The Tetrys Building Block: this BB is used during encoding, and o The Tetrys Building Block: this BB embeds both the Tetrys Decoder
decoding processes. It must be noted that Tetrys does not mandate and Tetrys Encoder and thus, is used during encoding, and decoding
a specific building block. Instead, any building block compatible processes. It must be noted that Tetrys does not mandate a
with the elastic encoding window feature of Tetrys MAY be used. 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 o The Window Management Building Block: this building block is in
charge of managing the encoding window at a Tetrys sender. charge of managing the encoding window at a Tetrys sender.
To ease the addition of future components and services, Tetrys adds a To ease the addition of future components and services, Tetrys adds a
header extension mechanism, compatible with that of LCT [RFC5651], header extension mechanism, compatible with that of LCT [RFC5651],
NORM [RFC5740], FECFRAME [RFC8680]. NORM [RFC5740], FECFRAME [RFC8680].
4. Tetrys Basic Functions 4. Tetrys Basic Functions
4.1. Encoding 4.1. Encoding
At the beginning of a transmission, a Tetrys Encoder MUST choose an At the beginning of a transmission, a Tetrys Encoder MUST choose an
initial code rate (added redundancy) as it doesn't know the packet initial Code Rate (added redundancy) as it doesn't know the packet
loss rate of the channel. In the steady state, depending on the loss rate of the channel. In the steady state, depending on the Code
code-rate, the Tetrys Encoder MAY generate coded symbols when it Rate, the Tetrys Encoder MAY generate Coded Symbols when it receives
receives a source symbol from the application or some feedback from a Source Symbol from the application or some feedback from the
the decoding blocks. decoding blocks.
When a Tetrys Encoder needs to generate a coded symbol, it considers When a Tetrys Encoder needs to generate a Coded Symbol, it considers
the set of source symbols stored in the Elastic Encoding Window and the set of Source Symbols stored in the Elastic Encoding Window and
generates an encoding vector with the coded symbol. These source generates an Encoding Vector with the Coded Symbol. These Source
symbols are the set of source symbols that are not yet acknowledged Symbols are the set of Source Symbols that are not yet acknowledged
by the receiver. For each source symbol, a finite field coefficient by the receiver. For each Source Symbol, a finite field coefficient
is determined using a Coding Coefficient Generator. This generator is determined using a Coding Coefficient Generator. This generator
MAY take as input the source symbol identifiers and the coded symbol MAY take as input the Source Symbol IDs and the Coded Symbol ID and
identifier and MAY determine a coefficient in a deterministic way as MAY determine a coefficient in a deterministic way as presented in
presented in Section 5.3. Finally, the coded symbol is the sum of Section 5.3. Finally, the Coded Symbol is the sum of the Source
the source symbols multiplied by their corresponding coefficients. Symbols multiplied by their corresponding coefficients.
A Tetrys Encoder SHOULD set a limit to the Elastic Encoding Window A Tetrys Encoder SHOULD set a limit to the Elastic Encoding Window
maximum size. This controls the algorithmic complexity at the maximum size. This controls the algorithmic complexity at the
encoder and decoder by limiting the size of linear combinations. It encoder and decoder by limiting the size of linear combinations. It
is also needed in situations where acknowledgment packets are all is also needed in situations where window update packets are all lost
lost or absent. or absent.
4.2. The Elastic Encoding Window 4.2. The Elastic Encoding Window
When an input source symbol is passed to a Tetrys Encoder, it is When an input Source Symbol is passed to a Tetrys Encoder, it is
added to the Elastic Encoding Window. This window MUST have a limit added to the Elastic Encoding Window. This window MUST have a limit
set by the encoding building Block. If the Elastic Encoding Window set by the encoding building Block. If the Elastic Encoding Window
reached its limit, the window slides over the symbols: the first reached its limit, the window slides over the symbols: the first
(oldest) symbol is removed, and the newest symbol is added. As an (oldest) symbol is removed, and the newest symbol is added. As an
element of the coding window, this symbol is included in the next element of the coding window, this symbol is included in the next
linear combinations created to generate the coded symbols. linear combinations created to generate the Coded Symbols.
As explained below, the Tetrys Decoder sends periodic feedback As explained below, the Tetrys Decoder sends periodic feedback
indicating the received or decoded source symbols. When the sender indicating the received or decoded Source Symbols. When the sender
receives the information that a source symbol was received or decoded receives the information that a Source Symbol was received or decoded
by the receiver, it removes this symbol from the coding window. by the receiver, it removes this symbol from the coding window.
4.3. Decoding 4.3. Decoding
A classical matrix inversion is sufficient to recover the erased A standard Gaussian elimination is sufficient to recover the erased
source symbols, when the matrix rank enables it. Source Symbols, when the matrix rank enables it.
5. Packet Format 5. Packet Format
5.1. Common Header Format 5.1. Common Header Format
All types of Tetrys packets share the same common header format (see All types of Tetrys packets share the same common header format (see
Figure 2 ). Figure 2).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C |S| Reserved | HDR_LEN | Packet Type | | V | C |S| Reserved | HDR_LEN | PKT_TYPE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*C bits) | | Congestion Control Information (CCI, length = 32*C bits) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S bits) | | Transport Session Identifier (TSI, length = 32*S bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) | | Header Extensions (if applicable) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Common Header Format Figure 2: Common Header Format
As already noted above in the document, this format is inspired and As already noted above in the document, this format is inspired and
inherits from the LCT header format [RFC5651] with slight inherits from the LCT header format [RFC5651] with slight
modifications. modifications.
* Tetrys version number (V): 4 bits. Indicates the Tetrys version o Tetrys version number (V): 4 bits. Indicates the Tetrys version
number. The Tetrys version number for this specification is 1. number. The Tetrys version number for this specification is 1.
* Congestion control flag (C): 2 bits. C=0 indicates the Congestion o Congestion control flag (C): 2 bits. C=0 indicates the Congestion
Control Information (CCI) field is 0 bits in length. C=1 Control Information (CCI) field is 0 bits in length. C=1
indicates the CCI field is 32 bits in length. C=2 indicates the indicates the CCI field is 32 bits in length. C=2 indicates the
CCI field is 64 bits in length. C=3 indicates the CCI field is 96 CCI field is 64 bits in length. C=3 indicates the CCI field is 96
bits in length. bits in length.
* Transport Session Identifier flag (S): 1 bit. This is the number o 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 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. in length, i.e., the length is either 0 bits or 32 bits.
* Reserved (Resv): 9 bits. These bits are reserved. In this o Reserved (Resv): 9 bits. These bits are reserved. In this
version of the specification, they MUST be set to zero by senders version of the specification, they MUST be set to zero by senders
and MUST be ignored by receivers. and MUST be ignored by receivers.
* Header length (HDR_LEN): 8 bits. The total length of the Tetrys o 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 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 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., 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 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 it exists and there is no other header, or to the end of the
packet if there are no other headers or packet payload. packet if there are no others headers or packet payload.
* Packet Type: 8 bits. Type of packet. There is 3 types of o PKT_TYPE: Tetrys packet type, 8 bits. Type of packet. There is 3
packets: the source packets (0) defined in Section 5.2, the coded types of packets: the PKT_TYPE_SOURCE (0) defined in Section 5.2,
packets (1) defined in Section 5.3 and the acknowledgment packets the PKT_TYPE_CODED (1) defined in Section 5.3 and the
(3) defined in Section 5.4. PKT_TYPE_WND_UPT (3), for window update packets defined in
Section 5.4.
* Congestion Control Information (CCI): 0, 32, 64, or 96 bits Used o Congestion Control Information (CCI): 0, 32, 64, or 96 bits Used
to carry congestion control information. For example, the to carry congestion control information. For example, the
congestion control information could include layer numbers, congestion control information could include layer numbers,
logical channel numbers, and sequence numbers. This field is logical channel numbers, and sequence numbers. This field is
opaque for this specification. This field MUST be 0 bits (absent) opaque for this specification. This field MUST be 0 bits (absent)
if C=0. This field MUST be 32 bits if C=1. This field MUST be 64 if C=0. This field MUST be 32 bits if C=1. This field MUST be 64
bits if C=2. This field MUST be 96 bits if C=3. bits if C=2. This field MUST be 96 bits if C=3.
* Transport Session Identifier (TSI): 0 or 32 bits The TSI uniquely o Transport Session Identifier (TSI): 0 or 32 bits The TSI uniquely
identifies a session among all sessions from a particular tetrys identifies a session among all sessions from a particular Tetrys
encoder. The TSI is scoped by the IP address of the sender, and encoder. The TSI is scoped by the IP address of the sender, and
thus the IP address of the sender and the TSI together uniquely thus the IP address of the sender and the TSI together uniquely
identify the session. Although a TSI in conjunction with the IP identify the session. Although a TSI, conjointly with the IP
address of the sender always uniquely identifies a session, address of the sender, always uniquely identifies a session,
whether or not the TSI is included in the Tetrys header depends on whether the TSI is included in the Tetrys header depends on what
what is used as the TSI value. If the underlying transport is is used as the TSI value. If the underlying transport is UDP,
UDP, then the 16-bit UDP source port number MAY serve as the TSI then the 16-bit UDP source port number MAY serve as the TSI for
for the session. If there is no underlying TSI provided by the the session. If there is no underlying TSI provided by the
network, transport or any other layer, then the TSI MUST be network, transport or any other layer, then the TSI MUST be
included in the Tetrys header. included in the Tetrys header.
5.1.1. Header Extensions 5.1.1. Header Extensions
Header Extensions are used in Tetrys to accommodate optional header Header Extensions are used in Tetrys to accommodate optional header
fields that are not always used or have variable size. The presence fields that are not always used or have variable size. The presence
of Header Extensions MAY be inferred by the Tetrys header length of Header Extensions MAY be inferred by the Tetrys header length
(HDR_LEN). If HDR_LEN is larger than the length of the standard (HDR_LEN). If HDR_LEN is larger than the length of the standard
header, then the remaining header space is taken by Header header, then the remaining header space is taken by Header
skipping to change at page 10, line 14 skipping to change at page 10, line 8
There are two formats for Header Extensions, as depicted in Figure 3 There are two formats for Header Extensions, as depicted in Figure 3
. The first format is used for variable-length extensions, with . The first format is used for variable-length extensions, with
Header Extension Type (HET) values between 0 and 127. The second Header Extension Type (HET) values between 0 and 127. The second
format is used for fixed-length (one 32-bit word) extensions, using format is used for fixed-length (one 32-bit word) extensions, using
HET values from 128 to 255. HET values from 128 to 255.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | | | HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . .
. Header Extension Content (HEC) . . Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) | | HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Header Extension Format Figure 3: Header Extension Format
* Header Extension Type (HET): 8 bits The type of the Header o Header Extension Type (HET): 8 bits The type of the Header
Extension. This document defines several possible types. Extension. This document defines several possible types.
Additional types may be defined in future versions of this Additional types may be defined in future versions of this
specification. HET values from 0 to 127 are used for variable- specification. HET values from 0 to 127 are used for variable-
length Header Extensions. HET values from 128 to 255 are used for length Header Extensions. HET values from 128 to 255 are used for
fixed-length 32-bit Header Extensions. fixed-length 32-bit Header Extensions.
* Header Extension Length (HEL): 8 bits The length of the whole o Header Extension Length (HEL): 8 bits The length of the whole
Header Extension field, expressed in multiples of 32-bit words. Header Extension field, expressed in multiples of 32-bit words.
This field MUST be present for variable-length extensions (HETs This field MUST be present for variable-length extensions (HETs
between 0 and 127) and MUST NOT be present for fixed-length between 0 and 127) and MUST NOT be present for fixed-length
extensions (HETs between 128 and 255). extensions (HETs between 128 and 255).
* Header Extension Content (HEC): variable length The content of the o Header Extension Content (HEC): variable length The content of the
Header Extension. The format of this sub-field depends on the Header Extension. The format of this subfield depends on the
Header Extension Type. For fixed-length Header Extensions, the Header Extension Type. For fixed-length Header Extensions, the
HEC is 24 bits. For variable-length Header Extensions, the HEC HEC is 24 bits. For variable-length Header Extensions, the HEC
field has variable size, as specified by the HEL field. Note that field has variable size, as specified by the HEL field. Note that
the length of each Header Extension MUST be a multiple of 32 bits. the length of each Header Extension MUST be a multiple of 32 bits.
Also, note that the total size of the Tetrys header, including all Also, note that the total size of the Tetrys header, including all
Header Extensions and all optional header fields, cannot exceed Header Extensions and all optional header fields, cannot exceed
255 32-bit words. 255 32-bit words.
5.2. Source Packet Format 5.2. Source Packet Format
A source packet is a Common Packet Header encapsulation, a Source A Source Packet is a Common Packet Header encapsulation, a Source
Symbol ID and a source symbol (payload). The source symbols MAY have Symbol ID and a Source Symbol (payload). The Source Symbols MAY have
variable sizes. variable sizes.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Common Packet Header / / Common Packet Header /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Symbol ID | | Source Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Payload / / Payload /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Source Packet Format Figure 4: Source Packet Format
Common Packet Header: a common packet header (as common header Common Packet Header: a common packet header (as common header
format) where Packet Type=0. format) where Packet Type=0.
Source Symbol ID: the sequence number to identify a source symbol. Source Symbol ID: the sequence number to identify a Source Symbol.
Payload: the payload (source symbol) Payload: the payload (Source Symbol)
5.3. Coded Packet Format 5.3. Coded Packet Format
A coded packet is the encapsulation of a Common Packet Header, a A Coded Packet is the encapsulation of a Common Packet Header, a
Coded Symbol ID, the associated Encoding Vector, and a coded symbol Coded Symbol ID, the associated Encoding Vector, and a Coded Symbol
(payload). As the source symbols MAY have variable sizes, all the (payload). As the Source Symbols MAY have variable sizes, all the
source symbol sizes need to be encoded. To generate this encoded Source Symbol sizes need to be encoded. To generate this encoded
payload size, as a 16-bit unsigned value, the linear combination uses payload size, as a 16-bit unsigned value, the linear combination uses
the same coefficients as the coded payload. The result MUST be the same coefficients as the coded payload. The result MUST be
stored in the coded packet as the Encoded Payload Size (16 bits): as stored in the Coded Packet as the Encoded Payload Size (16 bits): as
it is an optional field, the encoding vector MUST signal the use of it is an optional field, the Encoding Vector MUST signal the use of
variable source symbol sizes with the field V (see Section 5.3.1 ). variable Source Symbol sizes with the field V (see Section 5.3.1).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Common Packet Header / / Common Packet Header /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Coded Symbol ID | | Coded Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 30 skipping to change at page 12, line 30
| | | |
/ Payload / / Payload /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Coded Packet Format Figure 5: Coded Packet Format
Common Packet Header: a common packet header (as common header Common Packet Header: a common packet header (as common header
format) where Packet Type=1. format) where Packet Type=1.
Coded Symbol ID: the sequence number to identify a coded symbol. Coded Symbol ID: the sequence number to identify a Coded Symbol.
Encoding Vector: an encoding vector to define the linear combination Encoding Vector: an Encoding Vector to define the linear combination
used (coefficients and source symbols). used (coefficients and Source Symbols).
Encoded Payload Size: the coded payload size used if the source Encoded Payload Size: the coded payload size used if the Source
symbols have a variable size (optional,Section 5.3.1). Symbols have a variable size (optional,Section 5.3.1).
Payload: the coded symbol. Payload: the Coded Symbol.
5.3.1. The Encoding Vector 5.3.1. The Encoding Vector
An encoding vector contains all the information about the linear An Encoding Vector contains all the information about the linear
combination used to generate a coded symbol. The information combination used to generate a Coded Symbol. The information
includes the source identifiers and the coefficients used for each includes the source identifiers and the coefficients used for each
source symbol. It MAY be stored in different ways depending on the Source Symbol. It MAY be stored in different ways depending on the
situation. situation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EV_LEN | CCGI | I |C|V| NB_IDS | NB_COEFS | | EV_LEN | CCGI | I |C|V| NB_IDS | NB_COEFS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FIRST_SOURCE_ID | | FIRST_SOURCE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| b_id | | | b_id | |
+-+-+-+-+-+-+-+-+ id_bit_vector +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ id_bit_vector +-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ coef_bit_vector +-+-+-+-+-+-+-+ + coef_bit_vector +-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Encoding Vector Format Figure 6: Encoding Vector Format
* Encoding Vector Length (EV_LEN) (8-bits): size in units of 32-bit o Encoding Vector Length (EV_LEN) (8-bits): size in units of 32-bit
words. words.
* Coding Coefficient Generator Identifier (CCGI): 4-bit ID to o Coding Coefficient Generator Identifier (CCGI): 4-bit ID to
identify the algorithm or the function used to generate the identify the algorithm or the function used to generate the
coefficients. As a CCGI is included in each encoded vector, it coefficients. As a CCGI is included in each encoded vector, it
MAY dynamically change between the generation of 2 coded symbols. MAY dynamically change between the generation of 2 Coded Symbols.
The CCCGI defines a function or an algorithm to build the coding The CCGI builds the coding coefficients used to generate the Coded
coefficients used to generate the coded symbols. They MUST be Symbols. They MUST be known by all the Tetrys encoders or
known by all the Tetrys encoders or decoders. decoders. The two RLC FEC schemes specified in this document
reuse the 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
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 coefficients over a finite field with 2^^4 0: Vandermonde based coefficients over the finite field
elements,defined by the primitive polynomial 1+x+x^^4. Each GF(2^(4)), as defined below. Each coefficient is built as
coefficient is built as alpha^( (source_symbol_id*coded- alpha^( (source_symbol_id*coded-symbol_id) % 16), with alpha
symbol_id) % 16), with alpha the root of the primitive the root of the primitive polynomial.
polynomial.
- 1: Vandermonde based coefficients over a finite field with 2^^8 1: Vandermonde based coefficients over the finite field
elements,defined by the primitive polynomial GF(2^(8)), as defined below. Each coefficient is built as
1+x^^2+x^^3+x^^4+x^^8. Each coefficient is built as alpha^( alpha^( (source_symbol_id*coded-symbol_id) % 256), with alpha
(source_symbol_id*coded-symbol_id) % 256), with alpha the root the root of the primitive polynomial.
of the primitive polynomial.
- Suppose we want to generate the coded symbol 2 as a linear Suppose we want to generate the Coded Symbol 2 as a linear
combination of the source symbols 1,2,4 using CCGI=1. The combination of the Source Symbols 1,2,4 using CCGI=1. The
coefficients will be alpha ^( (1 * 1) % 256), alpha ^( (1 * 2) coefficients will be alpha ^( (1 * 1) % 256), alpha ^( (1 * 2)
% 256), alpha ^( (1 * 4) % 256). % 256), alpha ^( (1 * 4) % 256).
* Store the Source symbol IDs (I) (2 bits): o Store the Source Symbol ID Format (I) (2 bits):
- 00 means there is no source symbol ID information. * 00 means there is no Source Symbol ID information.
- 01 means the encoding vector contains the edge blocks of the * 01 means the Encoding Vector contains the edge blocks of the
source symbol IDs without compression. Source Symbol IDs without compression.
- 10 means the encoding vector contains the compressed list of * 10 means the Encoding Vector contains the compressed list of
the source symbol IDs. the Source Symbol IDs.
- 11 means the encoding vector contains the compressed edge * 11 means the Encoding Vector contains the compressed edge
blocks of the source symbol IDs. blocks of the Source Symbol IDs.
* Store the coefficients (C): 1 bit to know if an encoding vector o Store the Encoding Coefficients (C): 1 bit to indicate if an
contains information about the coefficients used. Encoding Vector contains information about the coefficients used.
* Having source symbols with variable size (V): set V to 1 if the o Having Source Symbols with Variable Size Encoding (V): set V to 1
combination which refers to the encoding vector is a combination if the combination which refers to the Encoding Vector is a
of source symbols with variable sizes. In this case, the coded combination of Source Symbols with variable sizes. In this case,
packets MUST have the 'Encoded Payload Size' field. the Coded Packets MUST have the 'Encoded Payload Size' field.
* NB_IDS: the number of source IDs stored in the encoding vector o NB_IDS: the number of source IDs stored in the Encoding Vector
(depending on I). (depending on I).
* Number of coefficients (NB_COEFS): The number of the coefficients o Number of coefficients (NB_COEFS): The number of the coefficients
used to generate the associated coded symbol. used to generate the associated Coded Symbol.
* The first source Identifier (FIRST_SOURCE_ID): the first source o The first source identifier (FIRST_SOURCE_ID): the first Source
symbol ID used in the combination. Symbol ID used in the combination.
* Number of bits for each edge block (b_id): the number of bits o Number of bits for each edge block (b_id): the number of bits
needed to store the edge. needed to store the edge.
* Information about the source symbol IDs (id_bit_vector): if I=01, o Information about the Source Symbol IDs (id_bit_vector): if I=01,
store the edge blocks as b_id * (NB_IDS * 2 - 1). If I=10, store store the edge blocks as b_id * (NB_IDS * 2 - 1). If I=10, store
in a compressed way the edge blocks. in a compressed way the edge blocks.
* The coefficients (coef_bit_vector): The coefficients stored o The coefficients (coef_bit_vector): The coefficients stored
depending on the CCGI (4 or 8 bits for each coeffecient). depending on the CCGI (4 or 8 bits for each coefficient).
* Padding: padding to have an Encoding Vector size multiple of o Padding: padding to have an Encoding Vector size multiple of
32-bit (for the id and coefficient part). 32-bit (for the id and coefficient part).
The source symbol identifers are organized as a sorted list of 32-bit The Source Symbol IDs are organized as a sorted list of 32-bit
unsigned integers. Depending on the feedback, the source symbol unsigned integers. Depending on the feedback, the Source Symbol IDs
identifers MAY be successive or not in the list. If they are MAY be successive or not in the list. If they are successive, the
successive, the boundaries are stored in the encoding vector: it just boundaries are stored in the Encoding Vector: it just needs 2*32-bit
needs 2*32-bit of information. If not, the edge blocks MAY be stored of information. If not, the edge blocks MAY be stored directly, or a
directly, or a differential transform to reduce the number of bits differential transform to reduce the number of bits needed to
needed to represent an identifer MAY be used: represent an identifier MAY be used
5.3.1.1. Compressed list of Source symbol IDs For example, the Coded Symbol 3 is a linear combination of the Source
Symbols 1,2,3,5,6,8,9,10 (each type of symbol has its own ID space).
This linear combination can be represented with only the edge blocks
: [1,3],[5,6],[8,10]
o We don't want to store the Source Symbol IDs (set I to 0b00), no
b_id and no id_bit_vector field
o We want to store the edge blocks without compression (set I to
0b01). In this case, set b_id to 32 (as a symbol id is 32 bits),
and store into id_bit_vectors the list as 32 bits unsigned
integers: 1,3,5,6,8,10
o We want to store the edge blocks with compression (set I to 0b10).
In this case, see the section Section 5.3.1.1 but rather than
compressing the edge blocks, we compress the full list of the
Source Symbol IDs.
o We want to store the edge blocks with compression (set I to 0b11)
In this case, see the section Section 5.3.1.1.
5.3.1.1. Compressed list of Source Symbol IDs
Assume the symbol IDs used in the combination are: Assume the symbol IDs used in the combination are:
[1..3],[5..6],[8..10]. [1..3],[5..6],[8..10].
1. Keep the first element in the packet as the first_source_id: 1. 1. Keep the first element in the packet as the first_source_id: 1.
2. Apply a differential transform to the others elements 2. Apply a differential transform to the other elements
([3,5,6,8,10]) which removes the element i-1 to the element i, ([3,5,6,8,10]) which removes the element i-1 to the element i,
starting with the first_source_id as i0, and get the list L => 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, 3. Compute b, the number of bits needed to store all the elements,
which is ceil(log2(max(L))): here, 2 bits. which is ceil(log2(max(L))), where max(L) represents the maximum
of the elements of the list L: here, 2 bits.
4. Write b in the corresponding field, and write all the b * [(2 * 4. 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. NB blocks) - 1] elements in a bit vector, here: 10 10 01 10 10.
5.3.1.2. Decompressing the Source symbol IDs 5.3.1.2. Decompressing the Source Symbol IDs
When a Tetrys Decoding Building Block wants to reverse the When a Tetrys Decoding Block wants to reverse the operations, this
operations, this algorithm is used: algorithm is used:
1. Rebuild the list of the transmitted elements by reading the bit 1. Rebuild the list of the transmitted elements by reading the bit
vector and b: [10 10 01 10 10] => [2,2,1,2,2] vector and b: [10 10 01 10 10] => [2,2,1,2,2]
2. Apply the reverse transform by adding successively the elements, 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,...] => starting with first_source_id: [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: 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. Acknowledgement Packet Format 5.4. Window Update Packet Format
A Tetrys Decoding Building Block MAY send back to another building A Tetrys Decoder MAY send back to another building block some Window
block some Acknowledgement packets. They contain information about Update packets. They contain information about what the packets
what it has received or decoded, and other information such as a received, decoded or dropped, and other information such as a packet
packet loss rate or the size of the decoding buffers. The loss rate or the size of the decoding buffers. They are used to
acknowledgment packets are OPTIONAL hence they could be omitted or optimize the content of the encoding window. The window update
lost in transmission without impacting the protocol behavior. packets are OPTIONAL, and hence they could be omitted or lost in
transmission without impacting the protocol behavior.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Common Packet Header / / Common Packet Header /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nb of missing source symbols | | nb_missing_src |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nb of not already used coded symbols | | nb_not_used_coded_symb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Source Symbol ID | | first_src_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLR | SACK size | | | plr | sack_size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
/ SACK Vector / / SACK Vector /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Acknowledgement Packet Format Figure 7: Window Update Packet Format
Common Packet Header: a common packet header (as common header Common Packet Header: a common packet header (as common header
format) where Packet Type=2. format) where Packet Type=2.
Nb missing source symbols: the number of missing source symbols in nb_missing_src: the number of missing Source Symbols in the receiver
the receiver since the beginning of the session. since the beginning of the session.
Nb of not already used coded symbols: the number of coded symbols at nb_not_used_coded_symb: the number of Coded Symbols at the receiver
the receiver that have not already been used for decoding (e.g., the that have not already been used for decoding (e.g., the linear
linear combinations contain at least 2 unknown source symbols). combinations contain at least 2 unknown Source Symbols).
First Source Symbol ID: ID of the first source symbol to consider for first_src_id: ID of the first Source Symbol to consider in the SACK
acknowledgment. vector.
PLR: packet loss ratio expressed as a percentage normalized to a plr: packet loss ratio expressed as a percentage normalized to a
8-bit unsigned integer. For example, 2.5 % will be stored as 8-bit unsigned integer. For example, 2.5 % will be stored as
floor(2.5 * 256/100). This value is used in the case of dynamic code floor(2.5 * 256/100) = 6. Conversely, if 6 is the stored value, the
rate or for statistical purpose. The choice of calculation is left 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 statistical purpose. The choice of calculation is left
to the Tetrys Decoder, depending on a window observation, but should to the Tetrys Decoder, depending on a window observation, but should
be the PLR seen before decoding. be the PLR seen before decoding.
SACK size: the size of the SACK vector in 32-bit words. For sack_size: the size of the SACK vector in 32-bit words. For
instance, with value 2, the SACK vector is 64 bits long. instance, with value 2, the SACK vector is 64 bits long.
SACK vector: bit vector indicating the acknowledged symbols from the SACK vector: bit vector indicating symbols that must be removed in
first source symbol ID. The "First Source Symbol" is included in the encoding window from the first Source Symbol ID. In most cases,
this bit vector. A bit equal to 1 at the i-th position means that these symbols were received by the receiver. The other cases concern
this acknowledgment packet acknowledges the source symbol of ID equal some events with non-recoverable packets (for example in the case of
to "First Source Symbol ID" + i. a burst of losses) where it is better to drop and abandon some
packets, and thus to 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 ID
equal to "First Source Symbol ID" + i from the encoding window.
6. Research Issues 6. Research Issues
The present document describes the baseline protocol, allowing The present document describes the baseline protocol, allowing
communications between a Tetrys encoder and a Tetrys decoder. In communications between a Tetrys encoder and a Tetrys decoder. In
practice, Tetrys can be used either as a standalone protocol or practice, Tetrys can be used either as a standalone protocol or
embedded inside an existing protocol, and either above, within or embedded inside an existing protocol, and either above, within or
below the transport layer. All these situations raise manifold below the transport layer. All these situations raise manyfold
research questions to come up with a complete protocol solution, that research questions to come up with a complete protocol solution, that
we briefly discuss hereafter. we briefly discuss hereafter.
6.1. Interaction with Congestion Control 6.1. Interaction with Congestion Control
The Tetrys and congestion control components generate two separate The Tetrys and congestion control components generate two separate
channels (see [I-D.irtf-nwcrg-coding-and-congestion], section 2.1): channels (see [I-D.irtf-nwcrg-coding-and-congestion], section 2.1):
* the Tetrys channel carries source and coded packets (from the o the Tetrys channel carries source and Coded Packets (from the
sender to the receiver) and information from the receiver to the sender to the receiver) and information from the receiver to the
sender (e.g., signaling which symbols have been recovered, loss sender (e.g., signaling which symbols have been recovered, loss
rate prior and/or after decoding, etc.); rate prior and/or after decoding, etc.);
* the congestion control channel carries packets from a sender to a o the congestion control channel carries packets from a sender to a
receiver, and packets signaling information about the network receiver, and packets signaling information about the network
(e.g., number of packets received versus lost, Explicit Congestion (e.g., number of packets received versus lost, Explicit Congestion
Notification (ECN) marks, etc.) from the receiver to the sender. Notification (ECN) marks, etc.) from the receiver to the sender.
In practice, depending on how Tetrys is deployed (i.e., above, within In practice, depending on how Tetrys is deployed (i.e., above, within
or below the transport layer), [I-D.irtf-nwcrg-coding-and-congestion] or below the transport layer), [I-D.irtf-nwcrg-coding-and-congestion]
identifies and discusses several topics. They are briefly listed identifies and discusses several topics. They are briefly listed
below and adapted to the particular case of Tetrys: below and adapted to the particular case of Tetrys:
* congestion related losses MAY be hidden if Tetrys is deployed o congestion related losses MAY be hidden if Tetrys is deployed
below the transport layer without any precaution (i.e., Tetrys below the transport layer without any precaution (i.e., Tetrys
recovering packets lost because of a congested router), which can recovering packets lost because of a congested router), which can
severely impact the the congestion control efficiency. An severely impact the the congestion control efficiency. An
approach is suggested to avoid hiding such signals in approach is suggested to avoid hiding such signals in
[I-D.irtf-nwcrg-coding-and-congestion], section 5; [I-D.irtf-nwcrg-coding-and-congestion], section 5;
* having Tetrys and non-Tetrys flows sharing the same network links o having Tetrys and non-Tetrys flows sharing the same network links
can raise fairness issues between these flows. The situation can raise fairness issues between these flows. The situation
depends in particular on whether some of these flows are depends in particular on whether some of these flows are
congestion controlled and not others, and which type of congestion congestion controlled and not others, and which type of congestion
control is used. The details are out of scope of this document control is used. The details are out of scope of this document,
but may have major impacts in practice; but may have major impacts in practice;
* coding rate adaptation within Tetrys can have major impacts on o coding rate adaptation within Tetrys can have major impacts on
congestion control if done inappropriately. This topic is congestion control if done inappropriately. This topic is
discussed more in detail in Section 6.2; discussed more in detail in Section 6.2;
* Tetrys can leverage on multipath transmissions, the Tetrys packets o Tetrys can leverage on multipath transmissions, the Tetrys packets
being sent to the same receiver through multiple paths. Since being sent to the same receiver through multiple paths. Since
paths can largely differ, a per-path flow control and congestion paths can largely differ, a per-path flow control and congestion
control adaptation could be needed; control adaptation could be needed;
* protecting several application flows within a single Tetrys flow o protecting several application flows within a single Tetrys flow
raises additional questions. This topic is discussed more in raises additional questions. This topic is discussed more in
detail in Section 6.3. detail in Section 6.3.
6.2. Adaptive Coding Rate 6.2. Adaptive Coding Rate
When the network conditions (e.g., delay and loss rate) strongly vary 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 over time, an adaptive coding rate can be used to increase or reduce
the amount of coded packets among a transmission dynamically (i.e., the amount of Coded Packets among a transmission dynamically (i.e.,
the added redundancy), with the help of a dedicated algorithm, the added redundancy), with the help of a dedicated algorithm,
similarly to [A-FEC]. Once again, the strategy differs, depending on similarly to [A-FEC]. Once again, the strategy differs, depending on
which layer Tetrys is deployed (i.e., above, within or below the which layer Tetrys is deployed (i.e., above, within or below the
transport layer). Basically, we can slice these strategies in two transport layer). Basically, we can slice these strategies in two
distincts classes: when Tetrys is deployed inside the transport distinct classes: when Tetrys is deployed inside the transport layer,
layer, versus outside (i.e., above or below). A deployment within versus outside (i.e., above or below). A deployment within the
the transport layer obviously means that interactions between transport layer obviously means that interactions between transport
transport protocol micro-mechanisms, such as the error recovery protocol micro-mechanisms, such as the error recovery mechanism, the
mechanism, the congestion control, the flow control or both, are congestion control, the flow control or both, are envisioned.
envisionned. Otherwise, deploying Tetrys within a non congestion Otherwise, deploying Tetrys within a non congestion controlled
controlled transport protocol, like UDP, would not bring out any transport protocol, like UDP, would not bring out any other advantage
other advantage than deploying it below or above the transport layer. than deploying it below or above the transport layer.
The impact deploying a FEC mechanism within the transport layer is The impact deploying a FEC mechanism within the transport layer is
further discussed in [I-D.irtf-nwcrg-coding-and-congestion], section further discussed in [I-D.irtf-nwcrg-coding-and-congestion], section
4, where considerations concerning the interactions between 4, where considerations concerning the interactions between
congestion control and coding rates, or the impact of fairness, are congestion control and coding rates, or the impact of fairness, are
investigated. This adaptation MAY be done jointly with the investigated. This adaptation MAY be done jointly with the
congestion control mechanism of a transport layer protocol as congestion control mechanism of a transport layer protocol, as
proposed by [CTCP]. This allows the use of monitored congestion proposed by [CTCP]. This allows the use of monitored congestion
control metrics (e.g., RTT, congestion events, or current congestion control metrics (e.g., RTT, congestion events, or current congestion
window size) to adapt the coding rate conjointly with the computed window size) to adapt the coding rate conjointly with the computed
transport sending rate. The rationale is to compute an amount of transport sending rate. The rationale is to compute an amount of
repair traffic that does not lead to congestion. This joint repair traffic that does not lead to congestion. This joint
optimization is mandatory to prevent flows to consume the whole optimization is mandatory to prevent flows to consume the whole
available capacity as also discussed in available capacity as also discussed in
[I-D.singh-rmcat-adaptive-fec] where the authors point out that an [I-D.singh-rmcat-adaptive-fec] where the authors point out that an
increase of the repair ratio should be done conjointly with a increase in the repair ratio should be done conjointly with a
decrease of the source sending rate. decrease in the source sending rate.
Finally, adapting a coding rate can also be done outside the Finally, adapting a coding rate can also be done outside the
transport layer and without considering transport layer metrics. In transport layer and without considering transport layer metrics. In
particular, this adaptation MAY be done jointly with the network as particular, this adaptation MAY be done jointly with the network as
proposed in [RED-FEC]. In this paper, the authors propose a Random proposed in [RED-FEC]. In this paper, the authors propose a Random
Early Detection FEC mechanism in the context of video transmission Early Detection FEC mechanism in the context of video transmission
over wireless networks. In brief, the idea is to add more redundancy over wireless networks. Briefly, the idea is to add more redundancy
packets if the queue at the access point is less occupied and vice packets if the queue at the access point is less occupied and vice
versa. A first theoretical attempt for video delivery has been versa. A first theoretical attempt for video delivery has been
proposed [THAI] with Tetrys. This approach is interesting as it proposed [THAI] with Tetrys. This approach is interesting as it
illustrates a joint collaboration between the application illustrates a joint collaboration between the application
requirements and the network conditions and combines both signals requirements and the network conditions and combines both signals
coming from the application needs and the network state (i.e., coming from the application needs and the network state (i.e.,
signals below or above the transport layer). signals below or above the transport layer).
To conclude, there are multiple ways to enable an adaptive coding To conclude, there are multiple ways to enable an adaptive coding
rate. However, all of them depend on: rate. However, all of them depend on:
* the signal metrics that can be monitored and used to adapt the o the signal metrics that can be monitored and used to adapt the
coding rate; coding rate;
* the transport layer used, whether congestion controlled or not; o the transport layer used, whether congestion controlled or not;
* the objective seeked (e.g., to minimize congestion, or to fit o the objective sought (e.g., to minimize congestion, or to fit
application requirements). application requirements).
6.3. Using Tetrys Below The IP Layer For Tunneling 6.3. Using Tetrys Below The IP Layer For Tunneling
The use of Tetrys to protect an aggregate of flows, typically when The use of Tetrys to protect an aggregate of flows, typically when
Tetrys is used for tunneling, to recover from IP datagram losses, Tetrys is used for tunneling, to recover from IP datagram losses,
raises research questions. When redundancy is applied without flow raises research questions. When redundancy is applied without flow
differentiation, this may come in contradiction with the service differentiation, this may come in contradiction with the service
requirements of individual flows, some of them may be more penalized requirements of individual flows, some of them may be more penalized
by high latency and jitter than by partial reliability, while other by high latency and jitter than by partial reliability, while other
skipping to change at page 20, line 45 skipping to change at page 21, line 45
Licensing: proprietary Licensing: proprietary
Implementation experience: maximum Implementation experience: maximum
Information update date: January 2022 Information update date: January 2022
Contact: jonathan.detchart@isae-supaero.fr Contact: jonathan.detchart@isae-supaero.fr
10. Acknowledgments 10. Acknowledgments
First, the authors want to sincerely thank Marie-Jose Montpetit for First, the authors want sincerely to thank Marie-Jose Montpetit for
continuous help and support on Tetrys. Marie-Jo, many thanks! continuous help and support on Tetrys. Marie-Jo, many thanks!
The authors also wish to thank NWCRG group members for numerous The authors also wish to thank NWCRG group members for numerous
discussions on on-the-fly coding that helped finalize this document. discussions on on-the-fly coding that helped finalize this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.irtf-nwcrg-coding-and-congestion] [I-D.irtf-nwcrg-coding-and-congestion]
Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding
and congestion control in transport", Work in Progress, and congestion control in transport", draft-irtf-nwcrg-
Internet-Draft, draft-irtf-nwcrg-coding-and-congestion-10, coding-and-congestion-12 (work in progress), February
15 January 2022, <https://www.ietf.org/archive/id/draft- 2022.
irtf-nwcrg-coding-and-congestion-10.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Keywords for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., and J. Crowcroft, "Forward Error Correction (FEC) M., and J. Crowcroft, "Forward Error Correction (FEC)
Building Block", RFC 3452, DOI 10.17487/RFC3452, December Building Block", RFC 3452, DOI 10.17487/RFC3452, December
2002, <https://www.rfc-editor.org/info/rfc3452>. 2002, <https://www.rfc-editor.org/info/rfc3452>.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., 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] Luby, M., Watson, M., and L. Vicisano, "Layered Coding [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651, Transport (LCT) Building Block", RFC 5651,
DOI 10.17487/RFC5651, October 2009, DOI 10.17487/RFC5651, October 2009,
<https://www.rfc-editor.org/info/rfc5651>. <https://www.rfc-editor.org/info/rfc5651>.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport "NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
<https://www.rfc-editor.org/info/rfc5740>. <https://www.rfc-editor.org/info/rfc5740>.
skipping to change at page 22, line 10 skipping to change at page 23, line 17
DOI 10.17487/RFC8680, January 2020, DOI 10.17487/RFC8680, January 2020,
<https://www.rfc-editor.org/info/rfc8680>. <https://www.rfc-editor.org/info/rfc8680>.
11.2. Informative References 11.2. Informative References
[A-FEC] Bolot, J., Fosse-Parisis, S., and D. Towsley, "Adaptive [A-FEC] Bolot, J., Fosse-Parisis, S., and D. Towsley, "Adaptive
FEC-based error control for Internet telephony", IEEE FEC-based error control for Internet telephony", IEEE
INFOCOM 99, pp. 1453-1460 vol. 3 DOI INFOCOM 99, pp. 1453-1460 vol. 3 DOI
10.1109/INFCOM.1999.752166, 1999. 10.1109/INFCOM.1999.752166, 1999.
[AHL-00] Ahlswede, R., Ning Cai, Li, S.-Y.R., and R.W. Yeung, [AHL-00] Ahlswede, R., Ning Cai, Li, S., and R. Yeung, "Network
"Network information flow", IEEE Transactions on information flow", IEEE Transactions on Information
Information Theory vol.46, no.4, pp.1204,1216, July 2000. Theory vol.46, no.4, pp.1204,1216, July 2000.
[CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)",
arXiv 1212.2291v3, 2013. arXiv 1212.2291v3, 2013.
[I-D.li-tsvwg-loops-problem-opportunities] [I-D.li-tsvwg-loops-problem-opportunities]
Li, Y., Zhou, X., Boucadair, M., Wang, J., and F. Qin, Li, Y., Zhou, X., Boucadair, M., Wang, J., and F. Qin,
"LOOPS (Localized Optimizations on Path Segments) Problem "LOOPS (Localized Optimizations on Path Segments) Problem
Statement and Opportunities for Network-Assisted Statement and Opportunities for Network-Assisted
Performance Enhancement", Work in Progress, Internet- Performance Enhancement", draft-li-tsvwg-loops-problem-
Draft, draft-li-tsvwg-loops-problem-opportunities-06, 13 opportunities-06 (work in progress), July 2020.
July 2020, <https://www.ietf.org/archive/id/draft-li-
tsvwg-loops-problem-opportunities-06.txt>.
[I-D.singh-rmcat-adaptive-fec] [I-D.singh-rmcat-adaptive-fec]
Singh, V., Nagy, M., Ott, J., and L. Eggert, "Congestion Singh, V., Nagy, M., Ott, J., and L. Eggert, "Congestion
Control Using FEC for Conversational Media", Work in Control Using FEC for Conversational Media", draft-singh-
Progress, Internet-Draft, draft-singh-rmcat-adaptive-fec- rmcat-adaptive-fec-03 (work in progress), March 2016.
03, 20 March 2016, <https://www.ietf.org/archive/id/draft-
singh-rmcat-adaptive-fec-03.txt>.
[RED-FEC] Lin, C., Shieh, C., Chilamkurti, N. K., Ke, C., and H. S. [RED-FEC] Lin, C., Shieh, C., Chilamkurti, N., Ke, C., and H. Hwang,
Hwang, "A RED-FEC Mechanism for Video Transmission Over "A RED-FEC Mechanism for Video Transmission Over WLANs",
WLANs", IEEE Transactions on Broadcasting, vol. 54, no. 3, IEEE Transactions on Broadcasting, vol. 54, no. 3, pp.
pp. 517-524 DOI 10.1109/TBC.2008.2001713, September 2008. 517-524 DOI 10.1109/TBC.2008.2001713, September 2008.
[Tetrys] Lacan, J. and E. Lochin, "Rethinking reliability for long- [Tetrys] Lacan, J. and E. Lochin, "Rethinking reliability for long-
delay networks", International Workshop on Satellite and delay networks", International Workshop on Satellite and
Space Communications 2008 (IWSSC08), October 2008. Space Communications 2008 (IWSSC08), October 2008.
[Tetrys-RT] [Tetrys-RT]
Tournoux, P.U., Lochin, E., Lacan, J., Bouabdallah, A., Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and
and V. Roca, "On-the-fly erasure coding for real-time V. Roca, "On-the-fly erasure coding for real-time video
video applications", IEEE Transactions on Multimedia, Vol applications", IEEE Transactions on Multimedia, Vol 13,
13, Issue 4, August 2011 (TMM.2011), August 2011. Issue 4, August 2011 (TMM.2011), August 2011.
[THAI] Tran-Thai, T., Lacan, J., and E. Lochin, "Joint on-the-fly [THAI] Tran-Thai, T., Lacan, J., and E. Lochin, "Joint on-the-fly
network coding/video quality adaptation for real-time network coding/video quality adaptation for real-time
delivery", Signal Processing: Image Communication, vol. 29 delivery", Signal Processing: Image Communication, vol. 29
(no. 4), pp. 449-461 ISSN 0923-5965, 2014. (no. 4), pp. 449-461 ISSN 0923-5965, 2014.
Authors' Addresses Authors' Addresses
Jonathan Detchart Jonathan Detchart
ISAE-SUPAERO ISAE-SUPAERO
10, avenue Edouard Belin 10, avenue Edouard Belin
BP 54032 BP 54032
31055 Toulouse CEDEX 4 Toulouse CEDEX 4 31055
France France
Email: jonathan.detchart@isae-supaero.fr Email: jonathan.detchart@isae-supaero.fr
Emmanuel Lochin Emmanuel Lochin
ENAC ENAC
7, avenue Edouard Belin 7, avenue Edouard Belin
31400 Toulouse Toulouse 31400
France France
Email: emmanuel.lochin@enac.fr Email: emmanuel.lochin@enac.fr
Jerome Lacan Jerome Lacan
ISAE-SUPAERO ISAE-SUPAERO
10, avenue Edouard Belin 10, avenue Edouard Belin
BP 54032 BP 54032
31055 Toulouse CEDEX 4 Toulouse CEDEX 4 31055
France France
Email: jerome.lacan@isae-supaero.fr Email: jerome.lacan@isae-supaero.fr
Vincent Roca Vincent Roca
INRIA INRIA
655, avenue de l'Europe 655, avenue de l'Europe
Inovallee; Montbonnot Inovallee; Montbonnot
38334 ST ISMIER cedex ST ISMIER cedex 38334
France France
Email: vincent.roca@inria.fr Email: vincent.roca@inria.fr
 End of changes. 155 change blocks. 
300 lines changed or deleted 350 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/