rfc9407.original   rfc9407.txt 
NWCRG J. Detchart Internet Research Task Force (IRTF) J. Detchart
Internet-Draft ISAE-SUPAERO Request for Comments: 9407 ISAE-SUPAERO
Intended status: Experimental E. Lochin Category: Experimental E. Lochin
Expires: 21 May 2023 ENAC ISSN: 2070-1721 ENAC
J. Lacan J. Lacan
ISAE-SUPAERO ISAE-SUPAERO
V. Roca V. Roca
INRIA INRIA
17 November 2022 June 2023
Tetrys, an On-the-Fly Network Coding Protocol Tetrys: An On-the-Fly Network Coding Protocol
draft-irtf-nwcrg-tetrys-04
Abstract Abstract
This document describes Tetrys, an On-The-Fly Network Coding (NC) This document describes Tetrys, which is an on-the-fly network coding
protocol that can be used to transport delay-sensitive and loss- protocol that can be used to transport delay-sensitive and loss-
sensitive data over a lossy network. Tetrys may recover from sensitive data over a lossy network. Tetrys may recover from
erasures within an RTT-independent delay, thanks to the transmission erasures within an RTT-independent delay thanks to the transmission
of Coded Packets. This document is a record of the experience gained of coded packets. This document is a record of the experience gained
by the authors while developing and testing the Tetrys protocol in by the authors while developing and testing the Tetrys protocol in
real conditions. real conditions.
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 described in RFC 8406.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Research Task
time. It is inappropriate to use Internet-Drafts as reference Force (IRTF). The IRTF publishes the results of Internet-related
material or to cite them other than as "work in progress." 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 not candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 21 May 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9407.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 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.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation
2. Definitions, Notations and Abbreviations . . . . . . . . . . 4 2. Definitions, Notations, and Abbreviations
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Architecture
3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Use Cases
3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Overview
4. Tetrys Basic Functions . . . . . . . . . . . . . . . . . . . 7 4. Tetrys Basic Functions
4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Encoding
4.2. The Elastic Encoding Window . . . . . . . . . . . . . . . 8 4.2. The Elastic Encoding Window
4.3. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Decoding
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Packet Format
5.1. Common Header Format . . . . . . . . . . . . . . . . . . 8 5.1. Common Header Format
5.1.1. Header Extensions . . . . . . . . . . . . . . . . . . 10 5.1.1. Header Extensions
5.2. Source Packet Format . . . . . . . . . . . . . . . . . . 11 5.2. Source Packet Format
5.3. Coded Packet Format . . . . . . . . . . . . . . . . . . . 12 5.3. Coded Packet Format
5.3.1. The Encoding Vector . . . . . . . . . . . . . . . . . 13 5.3.1. The Encoding Vector
5.4. Window Update Packet Format . . . . . . . . . . . . . . . 17 5.4. Window Update Packet Format
6. Research Issues . . . . . . . . . . . . . . . . . . . . . . . 18 6. Research Issues
6.1. Interaction with Congestion Control . . . . . . . . . . . 18 6.1. Interaction with Congestion Control
6.2. Adaptive Coding Rate . . . . . . . . . . . . . . . . . . 19 6.2. Adaptive Coding Rate
6.3. Using Tetrys Below The IP Layer For Tunneling . . . . . . 21 6.3. Using Tetrys below the IP Layer for Tunneling
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations
7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 21 7.1. Problem Statement
7.2. Attacks against the Data Flow . . . . . . . . . . . . . . 21 7.2. Attacks against the Data Flow
7.3. Attacks against Signaling . . . . . . . . . . . . . . . . 22 7.3. Attacks against Signaling
7.4. Attacks against the Network . . . . . . . . . . . . . . . 22 7.4. Attacks against the Network
7.5. Baseline Security Operation . . . . . . . . . . . . . . . 23 7.5. Baseline Security Operation
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 9. References
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 Acknowledgments
11.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 or an IETF
standard. standard.
This document describes Tetrys, a novel erasure coding protocol. This document describes Tetrys, which is an on-the-fly network coding
Network codes were introduced in the early 2000s [AHL-00] to address protocol that can be used to transport delay-sensitive and loss-
the limitations of transmission over the Internet (delay, capacity sensitive data over a lossy network. Network codes were introduced
and packet loss). While network codes have seen some deployment in the early 2000s [AHL-00] to address the limitations of
fairly recently in the Internet community, the use of application transmission over the Internet (delay, capacity, and packet loss).
layer erasure codes in the IETF has already been standardized in the While network codes have seen some deployment fairly recently in the
RMT [RFC3452] and the FECFRAME [RFC8680] working groups. The Internet community, the use of application-layer erasure codes in the
protocol presented here may be seen as a network coding extension to IETF has already been standardized in the RMT [RFC5052] [RFC5445] and
standard unicast transport protocols (or even multicast or anycast FECFRAME [RFC8680] Working Groups. The protocol presented here may
with a few modifications). The current proposal may be considered a be seen as a network-coding extension to standard unicast transport
combination of network erasure coding and feedback mechanisms protocols (or even multicast or anycast with a few modifications).
[Tetrys], [Tetrys-RT] . The current proposal may be considered a combination of network
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 feedback. These feedback messages provide updated with the receiver feedback. These feedback messages provide
to the sender with information about the highest sequence number to the sender information about the highest sequence number received
received or rebuilt, which can enable flushing the corresponding or rebuilt, which can enable the flushing the corresponding source
Source Packets stored in the encoding window. The size of this packets stored in the encoding window. The size of this window may
window may be fixed or dynamically updated. If the window is full, be fixed or dynamically updated. If the window is full, incoming
incoming Source Packets replace older sources packets which are source packets replace older source packets that are dropped. As a
dropped. As a matter of fact, its limit should be correctly sized. matter of fact, its limit should be correctly sized. Finally, Tetrys
Finally, Tetrys allows to deal with losses on both the forward and allows dealing with losses on both the forward and return paths and
return paths and in particular, is resilient to acknowledgment is particularly resilient to acknowledgment losses. All these
losses. All these operations are further detailed in Section 4. operations are further detailed in 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 choice of coefficients, as finite fields elements, is a trade-off
erasure recovery performance (finite fields of 256 elements) and the between the best erasure recovery performance (finite fields of 256
system constraints (finite fields of 16 elements is preferred) and is elements) and the system constraints (finite fields of 16 elements
driven by the application. are preferred) and is 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 a predefined method to choose the coefficients. on-the-fly by using a predefined method to choose the coefficients.
The redundancy ratio may be dynamically adjusted, and the The redundancy ratio may be dynamically adjusted and the coefficients
coefficients may be generated in different ways, during the may be generated in different ways during the transmission. Compared
transmission. Compared to FEC block codes, this allows reducing the to Forward Error Correction (FEC) block codes, this reduces the
bandwidth use and the decoding delay. bandwidth use and the decoding delay.
The description of the design of the Tetrys protocol in this document The design description of the Tetrys protocol in this document is
is complemented by a record of the experience gained by the authors complemented by a record of the experience gained by the authors
while developing and testing the Tetrys protocol in realistic while developing and testing the Tetrys protocol in realistic
conditions. In particular, several research issues are discussed in conditions. In particular, several research issues are discussed in
Section 6 following our own experience and observations. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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 is transmitted between the ingress Source Symbol: A symbol that is transmitted between the ingress and
and egress of the network. 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 Encoder. Input Symbol: A symbol at the input of the Tetrys encoder.
Output Symbol: a symbol generated by the Tetrys Encoder. For a Output Symbol: A symbol generated by the Tetrys encoder. For a non-
non-systematic mode, all Output Symbols are Coded Symbols. For a systematic mode, all output symbols are coded symbols. For a
systematic mode, Output Symbols MAY be the Input Symbols and a systematic mode, output symbols MAY be the input symbols and a
number of Coded Symbols that are linear combinations of the Input number of coded symbols that are linear combinations of the input
Symbols + the Encoding Vectors. symbols plus 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 contain additional information about the Packet Error Rate or also contain 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
the non-acknowledged Source Packets of the input flow involved in unacknowledged source packets of the input flow involved in the
the coding process. coding process.
Coding Coefficient Generator Identifier: a unique identifier that Coding Coefficient Generator Identifier (CCGI): A unique identifier
defines a function or an algorithm allowing to generate the that defines a function or an algorithm allowing the generation of
Encoding Vector. the encoding vector.
Code Rate: Define the rate between the number of Input Symbols and Code Rate: Defines 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 Tetrys is well suited, but not limited, to the use case where there
is a single flow originated by a single source, with intra stream is a single flow originated by a single source with intra-stream
coding at a single encoding node. Note that the input stream MAY be coding at a single encoding node. Note that the input stream MAY be
a multiplex of several upper layer streams. Transmission MAY be over a multiplex of several upper-layer streams. Transmission MAY be over
a 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 quite 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 include:
* on-the-fly encoding; * on-the-fly encoding;
* decoding; * decoding;
* signaling, to carry in particular the symbol identifiers in the * signaling, to carry in particular the symbol IDs in the encoding
encoding window and the associated coding coefficients when window and the associated coding coefficients when meaningful;
meaningful;
* feedback management; * feedback management;
* elastic window management; * elastic window management; and
* Tetrys packet header creation and processing; * Tetrys packet header creation and processing.
and the optional features are : The optional features include:
* channel estimation; * channel estimation;
* dynamic adjustment of the Code Rate and flow control; * dynamic adjustment of the code rate and flow control; and
* congestion control management (if appropriate). See Section 6.1 * 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 the following functionalities:
* The Tetrys Building Block: this BB embeds both the Tetrys Decoder The Tetrys Building Block: This building block embeds both the
and Tetrys Encoder and thus, is used during encoding, and decoding Tetrys decoder and Tetrys encoder; thus, it is used during
processes. It must be noted that Tetrys does not mandate a encoding and decoding processes. It must be noted that Tetrys
specific building block. Instead, any building block compatible does not mandate a specific building block. Instead, any building
with the Elastic Encoding Window feature of Tetrys may be used. block compatible with the elastic encoding window feature of
Tetrys may be used.
* The Window Management Building Block: this building block is in 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 that is compatible with that of Layered
NORM [RFC5740], FECFRAME [RFC8680]. Coding Transport (LCT) [RFC5651], NACK-Oriented Reliable Multicast
(NORM) [RFC5740], and FEC Framework (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 that adds redundancy as it doesn't know the packet
loss rate of the channel. In the steady state, depending on the Code loss rate of the channel. In the steady state, the Tetrys encoder
Rate, the Tetrys Encoder MAY generate Coded Symbols when it receives MAY generate coded symbols when it receives a source symbol from the
a Source Symbol from the application or some feedback from the application or some feedback from the decoding blocks depending on
decoding blocks. the code rate.
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 IDs and the Coded Symbol ID and MAY take the source symbol IDs and the coded symbol ID as an input
MAY determine a coefficient in a deterministic way as presented in and MAY determine a coefficient in a deterministic way as presented
Section 5.3. Finally, the Coded Symbol is the sum of the Source in Section 5.3. Finally, the coded symbol is the sum of 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 MUST 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 window update packets are all lost is also needed in situations where all window update packets are 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 has 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 standard Gaussian elimination 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
skipping to change at page 8, line 48 skipping to change at line 356
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 noted above, this format is inspired by, and inherits from, the
inherits from the LCT header format [RFC5651] with slight LCT header format [RFC5651] with slight modifications.
modifications.
* Tetrys version number (V): 4 bits. Indicates the Tetrys version 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 Congestion control flag (C): 2 bits. C set to 0b00 indicates the
Control Information (CCI) field is 0 bits in length. C=1 Congestion Control Information (CCI) field is 0 bits in length. C
indicates the CCI field is 32 bits in length. C=2 indicates the set to 0b01 indicates the CCI field is 32 bits in length. C set
CCI field is 64 bits in length. C=3 indicates the CCI field is 96 to 0b10 indicates the CCI field is 64 bits in length. C set to
bits in length. 0b11 indicates the CCI field is 96 bits in length.
* Transport Session Identifier flag (S): 1 bit. This is the number Transport Session Identifier flag (S): 1 bit. This is the number of
of full 32-bit words in the TSI field. The TSI field is 32*S bits full 32-bit words in the TSI field. The TSI field is 32*S bits in
in length, i.e., the length is either 0 bits or 32 bits. length; i.e., the length is either 0 bits or 32 bits.
* Reserved (Resv): 9 bits. These bits are reserved. In this Reserved (Resv): 9 bits. These bits are reserved. In this version
version of the specification, they MUST be set to zero by senders of the specification, they MUST be set to zero by senders and MUST
and MUST be ignored by receivers. be ignored by receivers.
* Header length (HDR_LEN): 8 bits. The total length of the Tetrys 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, to the packet payload if it
it exists and there is no other header, or to the end of the exists and there is no other header, or to the end of the packet
packet if there are no others headers or packet payload. if there are no other headers or packet payload.
* PKT_TYPE: Tetrys packet type, 8 bits. Type of packet. There is 3 Tetrys packet type (PKT_TYPE): 8 bits. There are three types of
types of packets: the PKT_TYPE_SOURCE (0) defined in Section 5.2, packets: the PKT_TYPE_SOURCE (0b00) defined in Section 5.2, the
the PKT_TYPE_CODED (1) defined in Section 5.3 and the PKT_TYPE_CODED (0b01) defined in Section 5.3 and the
PKT_TYPE_WND_UPT (3), for window update packets defined in PKT_TYPE_WND_UPT (0b11) for window update packets defined in
Section 5.4. Section 5.4.
* Congestion Control Information (CCI): 0, 32, 64, or 96 bits Used 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 is set to 0b00. This field MUST be 32 bits if C is set to
bits if C=2. This field MUST be 96 bits if C=3. 0b01. This field MUST be 64 bits if C is set to 0b10. This field
MUST be 96 bits if C is set to 0b11.
* Transport Session Identifier (TSI): 0 or 32 bits The TSI uniquely 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; thus,
thus the IP address of the sender and the TSI together uniquely the IP address of the sender and the TSI together uniquely
identify the session. Although a TSI, conjointly with the IP identify the session. Although a TSI always uniquely identifies a
address of the sender, always uniquely identifies a session, session conjointly with the IP address of the sender, whether the
whether the TSI is included in the Tetrys header depends on what TSI is included in the Tetrys header depends on what is used as
is used as the TSI value. If the underlying transport is UDP, the TSI value. If the underlying transport is UDP, then the
then the 16-bit UDP source port number MAY serve as the TSI for 16-bit UDP source port number MAY serve as the TSI for the
the session. If there is no underlying TSI provided by the session. If there is no underlying TSI provided by the network,
network, transport or any other layer, then the TSI MUST be transport, or any other layer, then the TSI MUST be included in
included in the Tetrys header. 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 sizes. 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
Extensions. extensions.
If present, Header Extensions MUST be processed to ensure that they If present, header extensions MUST be processed to ensure that they
are recognized before performing any congestion control procedure or are recognized before performing any congestion control procedure or
otherwise accepting a packet. The default action for unrecognized otherwise accepting a packet. The default action for unrecognized
Header Extensions is to ignore them. This allows the future header extensions is to ignore them. This allows for the future
introduction of backward-compatible enhancements to Tetrys without introduction of backward-compatible enhancements to Tetrys without
changing the Tetrys version number. Non-backward-compatible Header changing the Tetrys version number. Header extensions that are not
Extensions CANNOT be introduced without changing the Tetrys version backward-compatible MUST NOT be introduced without changing the
number. Tetrys version number.
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. header extension type (HET) values between 0 and 127.
* The second format is used for fixed-length (one 32-bit word) * The second format is used for fixed-length (one 32-bit word)
extensions, using HET values from 128 to 255. extensions using 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 Header Extension Type (HET): 8 bits. The type of the header
extension. This document defines several possible types.
The type of the Header Extension. This document defines several Additional types may be defined in future versions of this
possible types. Additional types may be defined in future specification. HET values from 0 to 127 are used for variable-
versions of this specification. HET values from 0 to 127 are used length header extensions. HET values from 128 to 255 are used for
for variable-length Header Extensions. HET values from 128 to 255 fixed-length, 32-bit header extensions.
are used for fixed-length 32-bit Header Extensions.
* Header Extension Length (HEL): 8 bits
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for
variable-length extensions (HETs between 0 and 127) and MUST NOT
be present for fixed-length extensions (HETs between 128 and 255).
* Header Extension Content (HEC): variable length Header Extension Length (HEL): 8 bits. The length of the whole
header extension field expressed in multiples of 32-bit words.
This field MUST be present for variable-length extensions (HETs
between 0 and 127) and MUST NOT be present for fixed-length
extensions (HETs between 128 and 255).
The content of the Header Extension. The format of this subfield Header Extension Content (HEC): Length of the variable. The content
depends on the Header Extension Type. For fixed-length Header of the header extension. The format of this subfield depends on
Extensions, the HEC is 24 bits. For variable-length Header the header extension type. For fixed-length header extensions,
Extensions, the HEC field has variable size, as specified by the the HEC is 24 bits. For variable-length header extensions, the
HEL field. Note that the length of each Header Extension MUST be HEC field has a variable size as specified by the HEL field. Note
a multiple of 32 bits. Also, note that the total size of the that the length of each header extension MUST be a multiple of 32
Tetrys header, including all Header Extensions and all optional bits. Additionally, the total size of the Tetrys header,
header fields, cannot exceed 255 32-bit words. including all header extensions and optional header fields, cannot
exceed 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
variable sizes. have 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 is set to 0b00.
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 46 skipping to change at line 541
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Payload Size | | | Encoded Payload Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
/ 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 is set to 0b01.
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 Encoding Vector Length (EV_LEN): 8 bits. The size in units of
words. 32-bit words.
* Coding Coefficient Generator Identifier (CCGI): 4-bit ID to Coding Coefficient Generator Identifier (CCGI): 4-bit ID to identify
identify the algorithm or the function used to generate the the algorithm or function used to generate the coefficients. As a
coefficients. As a CCGI is included in each encoded vector, it CCGI is included in each encoded vector, it MAY dynamically change
MAY dynamically change between the generation of 2 Coded Symbols. between the generation of two coded symbols. The CCGI builds the
The CCGI builds the coding coefficients used to generate the Coded coding coefficients used to generate the coded symbols. They MUST
Symbols. They MUST be known by all the Tetrys encoders or be known by all the Tetrys encoders or decoders. The two RLC FEC
decoders. The two RLC FEC schemes specified in this document schemes specified in this document reuse the finite fields defined
reuse the Finite Fields defined in [RFC5510], Section 8.1. More in [RFC5510], Section 8.1. More specifically, the elements of the
specifically, the elements of the field GF(2^(m)) are represented field GF(2^(m)) are represented by polynomials with binary
by polynomials with binary coefficients (i.e., over GF(2)) and coefficients (i.e., over GF(2)) and with degree lower or equal to
degree lower or equal to m-1. The addition between two elements m-1. The addition between two elements is defined as the addition
is defined as the addition of binary polynomials in GF(2), which of binary polynomials in GF(2), which is equivalent to a bitwise
is equivalent to a bitwise XOR operation on the binary XOR operation on the binary representation of these elements.
representation of these elements. With GF(2^(8)), multiplication With GF(2^(8)), multiplication between two elements is the
between two elements is the multiplication modulo a given multiplication modulo a given irreducible polynomial of degree 8.
irreducible polynomial of degree 8. The following irreducible The following irreducible polynomial is used for GF(2^(8)):
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 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. multiplication modulo a given irreducible polynomial of degree 4.
The following irreducible polynomial is used for GF(2^(4)): x^(4) The following irreducible polynomial is used for GF(2^(4)):
+ x + 1
- 0: Vandermonde based coefficients over the finite field x^(4) + x + 1
GF(2^(4)), as defined below. Each coefficient is built as
* 0b00: Vandermonde-based coefficients over the finite field
GF(2^(4)) as defined below. Each coefficient is built as
alpha^( (source_symbol_id*coded-symbol_id) % 16), with alpha alpha^( (source_symbol_id*coded-symbol_id) % 16), with alpha
the root of the primitive polynomial. the root of the primitive polynomial.
- 1: Vandermonde based coefficients over the finite field * 0b01: Vandermonde-based coefficients over the finite field
GF(2^(8)), as defined below. Each coefficient is built as GF(2^(8)) as defined below. Each coefficient is built as
alpha^( (source_symbol_id*coded-symbol_id) % 256), with alpha alpha^( (source_symbol_id*coded-symbol_id) % 256), with alpha
the root of the primitive polynomial. the root 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, and 4 using CCGI set to
coefficients will be alpha^( (1 * 1) % 256), alpha^( (1 * 2) % 0b01. The coefficients will be alpha^( (1 * 1) % 256), alpha^(
256), alpha^( (1 * 4) % 256). (1 * 2) % 256), and alpha^( (1 * 4) % 256).
* Store the Source Symbol ID Format (I) (2 bits):
- 00 means there is no Source Symbol ID information. Store the Source Symbol ID Format (I) (2 bits):
* 0b00 means there is no source symbol ID information.
- 01 means the Encoding Vector contains the edge blocks of the * 0b01 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 * 0b10 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 * 0b11 means the encoding vector contains the compressed edge
blocks of the Source Symbol IDs. blocks of the source symbol IDs.
* Store the Encoding Coefficients (C): 1 bit to indicate if an Store the Encoding Coefficients (C): 1 bit to indicate if an
Encoding Vector contains information about the coefficients used. encoding vector contains information about the coefficients used.
* Having Source Symbols with Variable Size Encoding (V): set V to 1 Having Source Symbols with Variable Size Encoding (V): Set V to 0b01
if the combination which refers to the Encoding Vector is a if the combination that refers to the encoding vector is a
combination of Source Symbols with variable sizes. In this case, combination of source symbols with variable sizes. In this case,
the Coded 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 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 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 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 Number of Bits for Each Edge Block (b_id): The number of bits needed
needed to store the edge. to store the edge.
* Information about the Source Symbol IDs (id_bit_vector): if I=01, Information about the Source Symbol IDs (id_bit_vector): If I is set
store the edge blocks as b_id * (NB_IDS * 2 - 1). If I=10, store to 0b01, store the edge blocks as b_id * (NB_IDS * 2 - 1). If I
in a compressed way the edge blocks. is set to 0b10, store the edge blocks in a compressed way.
* The coefficients (coef_bit_vector): The coefficients stored The Coefficients (coef_bit_vector): The coefficients stored
depending on the CCGI (4 or 8 bits for each coefficient). depending on the CCGI (4 or 8 bits for each coefficient).
* Padding: padding to have an Encoding Vector size multiple of Padding: Padding to have an encoding vector size that is a multiple
32-bit (for the id and coefficient part). of 32 bits (for the ID and coefficient part).
The Source Symbol IDs 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 IDs unsigned integers. Depending on the feedback, the source symbol IDs
MAY be successive or not in the list. If they are successive, the in the list MAY be successive or not. If they are successive, the
boundaries are stored in the Encoding Vector: it just needs 2*32-bit boundaries are stored in the encoding vector; it just needs 2*32 bits
of information. If not, the full list or the edge blocks MAY be of information. If not, the full list or the edge blocks MAY be
stored, and a differential transform to reduce the number of bits stored and a differential transform to reduce the number of bits
needed to represent an identifier MAY be used. needed to represent an identifier MAY be used.
For the following subsections, let's take as an example the For the following subsections, let's take as an example the
generation of an encoding vector for a Coded Symbol which is a linear generation of an encoding vector for a coded symbol that is a linear
combination of the Source Symbols with IDs 1,2,3,5,6,8,9 and 10 (or combination of the source symbols with IDs 1, 2, 3, 5, 6, 8, 9, and
as edge blocks: [1..3],[5..6],[8..10]) 10 (or as edge blocks: [1..3], [5..6], [8..10]).
There are several ways to store the Source Symbols IDs into the There are several ways to store the source symbol IDs into the
encoding vector: encoding vector:
* If no information about the Source Symbol IDs is needed, the field * If no information about the source symbol IDs is needed, the field
I MUST be set to 0b00: no b_id and no id_bit_vector field I MUST be set to 0b00: no b_id and no id_bit_vector field.
* If the edge blocks are stored without compression, the field I * 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 MUST be set 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 is 32 bits), and store the list of 32-bit unsigned integers (1, 3,
unsigned integers: 1,3,5,6,8,10 4, 5, 6, 10) into id_bit_vectors.
* If the Source Symbols Ids are stored as a list with compression, * If the source symbol IDs are stored as a list with compression,
the field I MUST be set to 0b10. In this case, see the field I MUST be set to 0b10. In this case, see
Section 5.3.1.1 but rather than compressing the edge blocks, we Section 5.3.1.1, but rather than compressing the edge blocks, we
compress the full list of the Source Symbol IDs. compress the full list of the source symbol IDs.
* If the edge blocks are stored with compression, the field I MUST * 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. be set to 0b11. In this case, see Section 5.3.1.1.
5.3.1.1. Compressed list of Source Symbol IDs 5.3.1.1. Compressed List of Source Symbol IDs
Let's continue with our Coded Symbol defined in the previous section. Let's continue with our coded symbol defined in the previous section.
The Source Symbols IDs used in the linear combination are: The source symbol IDs used in the linear combination are: [1..3],
[1..3],[5..6],[8..10]. [5..6], [8..10].
If we want to compress and store this list into the encoding vector, If we want to compress and store this list into the encoding vector,
we MUST follow this procedure: we MUST follow this procedure:
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 other elements 2. Apply a differential transform to the other elements ([3, 5, 6,
([3,5,6,8,10]) which removes the element i-1 to the element i, 8, 10]) that removes the element i-1 to the element i, starting
starting with the first_source_id as i0, and get the list L = with the first_source_id as i0, and get the list L = [2, 2, 1, 2,
[2,2,1,2,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))), where max(L) represents the maximum which is ceil(log2(max(L))), where max(L) represents the maximum
of the elements of the list L: here, 2 bits. of the elements of the list L; here, it is 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 Block wants to reverse the operations, this When a Tetrys decoding block wants to reverse the 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 +
[1,3,5,6,8,10] 2) + 1, ...] => [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],
[1..3],[5..6],[8..10]. [5..6], [8..10].
5.4. Window Update Packet Format 5.4. Window Update Packet Format
A Tetrys Decoder MAY send back to another building block some Window A Tetrys decoder MAY send window update packets back to another
Update packets. They contain information about what the packets building block. They contain information about what the packets
received, decoded or dropped, and other information such as a packet received, decoded, or dropped, and other information such as a packet
loss rate or the size of the decoding buffers. They are used to loss rate or the size of the decoding buffers. They are used to
optimize the content of the encoding window. The window update optimize the content of the encoding window. The window update
packets are OPTIONAL, and hence they could be omitted or lost in packets are OPTIONAL; hence, they could be omitted or lost in
transmission without impacting the protocol behavior. 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_missing_src | | nb_missing_src |
skipping to change at page 17, line 37 skipping to change at line 768
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| plr | sack_size | | | plr | sack_size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
/ SACK Vector / / SACK Vector /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Window Update 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 is set to 0b10.
nb_missing_src: the number of missing Source Symbols in the receiver nb_missing_src: The number of missing source symbols in the receiver
since the beginning of the session. since the beginning of the session.
nb_not_used_coded_symb: the number of Coded Symbols at the receiver nb_not_used_coded_symb: The number of coded symbols at the receiver
that have not already been used for decoding (e.g., the linear that have not already been used for decoding (e.g., the linear
combinations contain at least 2 unknown Source Symbols). combinations contain at least two unknown source symbols).
first_src_id: ID of the first Source Symbol to consider in the SACK first_src_id: ID of the first source symbol to consider in the
vector. selective acknowledgment (SACK) vector.
plr: packet loss ratio expressed as a percentage normalized to a plr: Packet loss ratio expressed as a percentage normalized to an
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) = 6. Conversely, if 6 is the stored value, the floor(2.5 * 256/100) = 6. Conversely, if 6 is the stored value,
corresponding packet loss ratio expressed as a percentage is the corresponding packet loss ratio expressed as a percentage is
6*100/256 = 2.34 %. This value is used in the case of dynamic Code 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 rate or for a statistical purpose. The choice of calculation is
to the Tetrys Decoder, depending on a window observation, but should left to the Tetrys decoder, depending on a window observation, but
be the PLR seen before decoding. should 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 a value of 2, the SACK vector is 64 bits long.
SACK vector: bit vector indicating symbols that must be removed in SACK vector: Bit vector indicating symbols that must be removed in
the encoding window from the first Source Symbol ID. In most cases, the encoding window from the first source symbol ID. In most
these symbols were received by the receiver. The other cases concern cases, these symbols were received by the receiver. The other
some events with non-recoverable packets (for example in the case of cases concern some events with non-recoverable packets (i.e., in
a burst of losses) where it is better to drop and abandon some the case of a burst of losses) where it is better to drop and
packets, and thus to remove them from the encoding window, to allow abandon some packets and remove them from the encoding window to
the recovery of the following packets. The "First Source Symbol" is allow the recovery of the following packets. The "First Source
included in this bit vector. A bit equal to 1 at the i-th position Symbol" is included in this bit vector. A bit equal to 1 at the
means that this window update packet removes the Source Symbol of ID i-th position means that this window update packet removes the
equal to "First Source Symbol ID" + i from the encoding window. source symbol of the 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 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. There are different research questions below the transport layer. There are different research questions
related to each of these scenarios that should be investigated for related to each of these scenarios that should be investigated for
future protocol improvements. We summarize them in the following future protocol improvements. We summarize them in the following
subsections. subsections.
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 [RFC9265], section 2.1): channels (see [RFC9265], Section 2.1):
* the Tetrys channel carries source and Coded Packets (from the * 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 before and/or after decoding, etc.).
* the congestion control channel carries packets from a sender to a * 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 The following topics, which are identified and discussed by
or below the transport layer), [RFC9265] identifies and discusses [RFC9265], are adapted to the particular deployment cases of Tetrys
several topics. They are briefly listed below and adapted to the (i.e., above, within, or below the transport layer):
particular case of Tetrys:
* congestion related losses may be hidden if Tetrys is deployed * 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 congestion control efficiency. An approach is
approach is suggested to avoid hiding such signals in [RFC9265], suggested to avoid hiding such signals in [RFC9265], Section 5.
section 5;
* having Tetrys and non-Tetrys flows sharing the same network links * Tetrys and non-Tetrys flows sharing the same network links can
can raise fairness issues between these flows. The situation raise fairness issues between these flows. In particular, the
depends in particular on whether some of these flows are situation depends on whether some of these flows and not others
congestion controlled and not others, and which type of congestion are congestion controlled and which type of congestion control is
control is used. The details are out of scope of this document, used. The details are out of scope of this document, but may have
but may have major impacts in practice; major impacts in practice.
* coding rate adaptation within Tetrys can have major impacts on * 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 * Tetrys can leverage multipath transmissions, with the Tetrys
being sent to the same receiver through multiple paths. Since packets being sent to the same receiver through multiple paths.
paths can largely differ, a per-path flow control and congestion Since paths can largely differ, a per-path flow control and
control adaptation could be needed; congestion control adaptation could be needed.
* protecting several application flows within a single Tetrys flow * 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 similar
similarly to [A-FEC]. Once again, the strategy differs, depending on to [A-FEC]. Once again, the strategy differs depending on which
which layer Tetrys is deployed (i.e., above, within or below the layer Tetrys is deployed (i.e., above, within, or below the transport
transport layer). Basically, we can slice these strategies in two layer). Basically, we can split these strategies into two distinct
distinct classes: when Tetrys is deployed inside the transport layer, classes: Tetrys deployment inside the transport layer versus outside
versus outside (i.e., above or below). A deployment within the the transport layer (i.e., above or below). A deployment within the
transport layer obviously means that interactions between transport transport layer means that interactions between transport protocol
protocol micro-mechanisms, such as the error recovery mechanism, the mechanisms such as error recovery, congestion control, and/or flow
congestion control, the flow control or both, are envisioned. control are envisioned. Otherwise, deploying Tetrys within a
Otherwise, deploying Tetrys within a non congestion controlled transport protocol that is not congestion controlled, like UDP, would
transport protocol, like UDP, would not bring out any other advantage not bring out any other advantage than deploying it below or above
than deploying it below or above the transport layer. 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 [RFC9265], section 4, where considerations further discussed in Section 4 of [RFC9265], where considerations
concerning the interactions between congestion control and coding concerning the interactions between congestion control and coding
rates, or the impact of fairness, are investigated. This adaptation rates, or the impact of fairness, are investigated. This adaptation
may be done jointly with the congestion control mechanism of a may be done jointly with the congestion control mechanism of a
transport layer protocol, as proposed by [CTCP]. This allows the use transport layer protocol as proposed by [CTCP]. This allows the use
of monitored congestion control metrics (e.g., RTT, congestion of monitored congestion control metrics (e.g., RTT, congestion
events, or current congestion window size) to adapt the coding rate events, or current congestion window size) to adapt the coding rate
conjointly with the computed transport sending rate. The rationale conjointly with the computed transport sending rate. The rationale
is to compute an amount of repair traffic that does not lead to is to compute an amount of repair traffic that does not lead to
congestion. This joint optimization is mandatory to prevent flows to congestion. This joint optimization is mandatory to prevent flows
consume the whole available capacity as also discussed in from consuming the whole available capacity as discussed in
[I-D.singh-rmcat-adaptive-fec] where the authors point out that an [RMCAT-ADAPTIVE-FEC], where the authors point out that an increase in
increase in the repair ratio should be done conjointly with a the repair ratio should be done conjointly with a decrease in the
decrease in the source sending rate. 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 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. Briefly, 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 with Tetrys
proposed [THAI] with Tetrys. This approach is interesting as it has been proposed [THAI]. 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 * 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; * the transport layer used, whether it is congestion controlled or
not; and
* the objective sought (e.g., to minimize congestion, or to fit * 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 raises research
Tetrys is used for tunneling, to recover from IP datagram losses, questions when Tetrys is used to recover from IP datagram losses
raises research questions. When redundancy is applied without flow while tunneling. Applying redundancy without flow differentiation
differentiation, this may come in contradiction with the service may contradict the service requirements of individual flows: some
requirements of individual flows, some of them may be more penalized flows may be penalized more by high latency and jitter than by
by high latency and jitter than by partial reliability, while other partial reliability, while other flows may be penalized more by
flows may have opposite requirements. In practice head-of-line partial reliability. In practice, head-of-line blocking impacts all
blocking will impact all flows in a similar manner despite their flows in a similar manner despite their different needs, which
different needs, which asks for more elaborate strategies inside indicates that more elaborate strategies inside Tetrys are needed.
Tetrys.
7. Security Considerations 7. Security Considerations
First of all, it must be clear that the use of FEC protection to a First of all, it must be clear that the use of FEC protection on a
data stream does not provide, per se, any kind of security, but, on data stream does not provide any kind of security per se. On the
the contrary, raises security risks. The situation with Tetrys is contrary, the use of FEC protection on a data stream raises security
mostly similar to that of other content delivery protocols making use risks. The situation with Tetrys is mostly similar to that of other
of FEC protection, and this is well described in FECFRAME [RFC6363]. content delivery protocols making use of FEC protection; this is well
This section leverages on this reference, adding new considerations described in FECFRAME [RFC6363]. This section builds on this
to comply with Tetrys specificities when meaningful. reference, adding new considerations to comply with Tetrys
specificities when meaningful.
7.1. Problem Statement 7.1. Problem Statement
An attacker can either target the content, the protocol, or the An attacker can either target the content, protocol, or network. The
network. The consequences will largely differ, reflecting various consequences will largely differ reflecting various types of goals,
types of goals, like gaining access to confidential content, like gaining access to confidential content, corrupting the content,
corrupting the content, compromizing the Tetrys Encoder and/or Tetrys compromising the Tetrys encoder and/or Tetrys decoder, or
Decoder, or compromizing the network behavior. In particular, compromising the network behavior. In particular, several of these
several of these attacks aim at creating a Denial-of-Service (DoS), attacks aim at creating a Denial-of-Service (DoS) with consequences
with consequences that may be limited to a single node (e.g., the that may be limited to a single node (e.g., the Tetrys decoder), or
Tetrys Decoder), or that may impact all the nodes attached to the that may impact all the nodes attached to the targeted network (e.g.,
targeted network (e.g., by making flows non-responsive to congestion by making flows unresponsive to congestion signals).
signals).
In the following sections, we discuss these attacks, according to the In the following sections, we discuss these attacks, according to the
component targeted by the attacker. component targeted by the attacker.
7.2. Attacks against the Data Flow 7.2. Attacks against the Data Flow
An attacker may want to access a confidential content, by An attacker may want to access confidential content by eavesdropping
eavesdropping the traffic between the Tetrys Encoder/Decoder. the traffic between the Tetrys encoder/decoder. Traffic encryption
Traffic encryption is the usual approach to mitigate this risk, and is the usual approach to mitigate this risk, and this encryption can
this encryption can be done either on the source flow, above Tetrys, be applied to the source flow upstream of the Tetrys encoder or to
or below Tetrys, on the output packets, both Source and Coded the output packets downstream of the Tetrys encoder. The choice on
Packets. The choice on where to apply encryption depends on various where to apply encryption depends on various criteria, in particular
criteria, in particular the attacker model (e.g., when encryption the attacker model (e.g., when encryption happens below Tetrys, the
happens below Tetrys, the security risk is assumed to be on the security risk is assumed to be on the interconnection network).
interconnection network).
An attacker may also want to corrupt the content (e.g., by injecting An attacker may also want to corrupt the content (e.g., by injecting
forged or modified Source and Coded Packets to prevent the Tetrys forged or modified source and coded packets to prevent the Tetrys
Decoder to recover the original source flow). Content integrity and decoder from recovering the original source flow). Content integrity
source authentication services at the packet level are then needed to and source authentication services at the packet level are then
mitigate this risk. Here, these services need to be provided below needed to mitigate this risk. Here, these services need to be
Tetrys in order to enable the receiver to drop undesired packets and provided below Tetrys in order to enable the receiver to drop
only transfer legitimate packets to the Tetrys Decoder. It should be undesired packets and only transfer legitimate packets to the Tetrys
noted that forging or modifying Feedback Packets will not corrupt the decoder. It should be noted that forging or modifying feedback
content, although it will certainly compromize Tetrys operation (see packets will not corrupt the content, although it will certainly
next section). compromise Tetrys operation (see Section 7.3).
7.3. Attacks against Signaling 7.3. Attacks against Signaling
Attacks on signaling information (e.g., by forging or modifying Attacks on signaling information (e.g., by forging or modifying
Feedback Packets to pretend the good reception or recovery of source feedback packets to falsify the good reception or recovery of source
content) can easily prevent the Tetrys Decoder to recover the source content) can easily prevent the Tetrys decoder from recovering the
flow, thereby creating a DoS. In order to prevent this type of source flow, thereby creating a DoS. In order to prevent this type
attack, content integrity and source authentication services at the of attack, content integrity and source authentication services at
packet level are needed for the feedback flow, from the Tetrys the packet level are needed for the feedback flow from the Tetrys
Decoder to the Tetrys Encoder, as well. These services need to be decoder to the Tetrys encoder as well. These services need to be
provided below Tetrys, in order to drop undesired packets and only provided below Tetrys in order to drop undesired packets and only
transfer legitimate Feedback Packets to the Tetrys Encoder. transfer legitimate feedback packets to the Tetrys encoder.
On the opposite, an attacker in position to selectively drop Feedback Conversely, an attacker in position to selectively drop feedback
Packets (instead of modifying them) will not severily impact Tetrys packets (instead of modifying them) will not severely impact the
functionning, since Tetrys is naturally robust in front of such function of Tetrys since it is naturally robust when challenged with
losses. However it will have side impacts, like the use of bigger such losses. However, it will have side impacts, such as the use of
linear systems (since the Tetrys Encoder cannot remove well received bigger linear systems (since the Tetrys encoder cannot remove well-
or decoded source packets from its linear system), which mechanically received or decoded source packets from its linear system), which
increases computational costs on both sides, encoder and decoder. mechanically increases computational costs on both sides (encoder and
decoder).
7.4. Attacks against the Network 7.4. Attacks against the Network
Tetrys can react to congestion signals (Section 6.1) in order to Tetrys can react to congestion signals (Section 6.1) in order to
provide a certain level of fairness with other flows on a shared provide a certain level of fairness with other flows on a shared
network. This ability could be exploited by an attacker to create or network. This ability could be exploited by an attacker to create or
reinforce congestion events (e.g., by forging or modifying Feedback reinforce congestion events (e.g., by forging or modifying feedback
Packets), which can potentially impact a significant number of nodes packets) that can potentially impact a significant number of nodes
attached to the network. Here also, in order to mitigate the risk, attached to the network. In order to mitigate the risk, content
content integrity and source authentication services at the packet integrity and source authentication services at the packet level are
level are needed to enable the receiver to drop undesired packets and needed to enable the receiver to drop undesired packets and only
only transfer legitimate packets to the Tetrys Encoder and Decoder. transfer legitimate packets to the Tetrys encoder and decoder.
7.5. Baseline Security Operation 7.5. Baseline Security Operation
Tetrys can benefit from an IPsec/Encapsulating Security Payload Tetrys can benefit from an IPsec / Encapsulating Security Payload
(IPsec/ESP) [RFC4303], that provides in particular confidentiality, (IPsec/ESP) [RFC4303] that provides confidentiality, origin
origin authentication, integrity, and anti-replay services. IPsec/ authentication, integrity, and anti-replay services in particular.
ESP can be useful to protect the Tetrys data flows (both directions) IPsec/ESP can be used to protect the Tetrys data flows (both
against attackers located within the interconnection network, in directions) against attackers located within the interconnection
position to eavesdrop traffic, or inject forged traffic, or replay network or attackers in position to eavesdrop traffic, inject forged
legitimate traffic. traffic, or replay legitimate traffic.
8. IANA Considerations 8. IANA Considerations
This document does not ask for any IANA registration. This document has no IANA 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 9. References
11.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Keywords for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words 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,
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)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., Peltotalo, S., and RFC [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Publisher, "Reed-Solomon Forward Error Correction (FEC) Correction (FEC) Building Block", RFC 5052,
Schemes", RFC 5510, DOI 10.17487/RFC5510, April 2009, 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., 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>. <https://www.rfc-editor.org/info/rfc5510>.
[RFC5651] Luby, M., Watson, M., Vicisano, L., and RFC Publisher, [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
"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., Macker, J., and RFC [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
Publisher, "NACK-Oriented Reliable Multicast (NORM) "NACK-Oriented Reliable Multicast (NORM) Transport
Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
November 2009, <https://www.rfc-editor.org/info/rfc5740>. <https://www.rfc-editor.org/info/rfc5740>.
[RFC6363] Watson, M., Begen, A., Roca, V., and RFC Publisher, [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
"Forward Error Correction (FEC) Framework", RFC 6363, Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011, DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>. <https://www.rfc-editor.org/info/rfc6363>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M., F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M.,
Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
Sivakumar, S., and RFC Publisher, "Taxonomy of Coding S. Sivakumar, "Taxonomy of Coding Techniques for Efficient
Techniques for Efficient Network Communications", Network Communications", RFC 8406, DOI 10.17487/RFC8406,
RFC 8406, DOI 10.17487/RFC8406, June 2018, June 2018, <https://www.rfc-editor.org/info/rfc8406>.
<https://www.rfc-editor.org/info/rfc8406>.
[RFC8680] Roca, V., Begen, A., and RFC Publisher, "Forward Error [RFC8680] Roca, V. and A. Begen, "Forward Error Correction (FEC)
Correction (FEC) Framework Extension to Sliding Window Framework Extension to Sliding Window Codes", RFC 8680,
Codes", RFC 8680, 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>.
[RFC9265] Kuhn, N., Lochin, E., Michel, F., Welzl, M., and RFC [RFC9265] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Forward
Publisher, "Forward Erasure Correction (FEC) Coding and Erasure Correction (FEC) Coding and Congestion Control in
Congestion Control in Transport", RFC 9265, Transport", RFC 9265, DOI 10.17487/RFC9265, July 2022,
DOI 10.17487/RFC9265, July 2022,
<https://www.rfc-editor.org/info/rfc9265>. <https://www.rfc-editor.org/info/rfc9265>.
11.2. Informative References 9.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, Conference on Computer Communications, New
10.1109/INFCOM.1999.752166, 1999. York, NY, USA, Vol. 3, pp. 1453-1460,
DOI 10.1109/INFCOM.1999.752166, March 1999,
<https://doi.org/10.1109/INFCOM.1999.752166>.
[AHL-00] Ahlswede, R., Ning Cai, Li, S.-Y.R., and R.W. Yeung, [AHL-00] Ahlswede, R., Cai, N., 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, Issue 4, pp. 1204-1216,
DOI 10.1109/18.850663, July 2000,
<https://doi.org/10.1109/18.850663>.
[CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", [CTCP] Kim, M., Cloud, J., ParandehGheibi, A., Urbina, L., Fouli,
arXiv 1212.2291v3, 2013. K., Leith, D., and M. Medard, "Network Coded TCP (CTCP)",
arXiv 1212.2291v3, April 2013,
<https://arxiv.org/abs/1212.2291>.
[I-D.singh-rmcat-adaptive-fec] [RED-FEC] Lin, C., Shieh, C., Chilamkurti, N., Ke, C., and W. Hwang,
"A RED-FEC Mechanism for Video Transmission Over WLANs",
IEEE Transactions on Broadcasting, Vol. 54, Issue 3, pp.
517-524, DOI 10.1109/TBC.2008.2001713, September 2008,
<https://doi.org/10.1109/TBC.2008.2001713>.
[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", Work in
Progress, Internet-Draft, draft-singh-rmcat-adaptive-fec- Progress, Internet-Draft, draft-singh-rmcat-adaptive-fec-
03, 20 March 2016, <https://www.ietf.org/archive/id/draft- 03, 20 March 2016, <https://datatracker.ietf.org/doc/html/
singh-rmcat-adaptive-fec-03.txt>. draft-singh-rmcat-adaptive-fec-03>.
[RED-FEC] Lin, C., Shieh, C., Chilamkurti, N. K., Ke, C., and H. S.
Hwang, "A RED-FEC Mechanism for Video Transmission Over
WLANs", IEEE Transactions on Broadcasting, vol. 54, no. 3,
pp. 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, Toulouse, France, pp. 90-94,
DOI 10.1109/IWSSC.2008.4656755, October 2008,
<https://doi.org/10.1109/IWSSC.2008.4656755>.
[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, pp. 797-812, DOI 10.1109/TMM.2011.2126564, August
2011, <http://dx.doi.org/10.1109/TMM.2011.2126564>.
[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. Issue 4, pp. 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 Authors' Addresses
Jonathan Detchart Jonathan Detchart
ISAE-SUPAERO ISAE-SUPAERO
10, avenue Edouard Belin
BP 54032 BP 54032
10, avenue Edouard Belin
31055 Toulouse CEDEX 4 31055 Toulouse CEDEX 4
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 31400 Toulouse
France France
Email: emmanuel.lochin@enac.fr Email: emmanuel.lochin@enac.fr
Jerome Lacan Jerome Lacan
ISAE-SUPAERO ISAE-SUPAERO
10, avenue Edouard Belin
BP 54032 BP 54032
10, avenue Edouard Belin
31055 Toulouse CEDEX 4 31055 Toulouse CEDEX 4
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
Inovallee; Montbonnot Inovallee; Montbonnot
38334 ST ISMIER cedex 655, avenue de l'Europe
38334 St Ismier CEDEX
France France
Email: vincent.roca@inria.fr Email: vincent.roca@inria.fr
 End of changes. 202 change blocks. 
634 lines changed or deleted 622 lines changed or added

This html diff was produced by rfcdiff 1.48.