< draft-detchart-nwcrg-tetrys-07.txt   draft-detchart-nwcrg-tetrys-08.txt >
NWCRG J. Detchart NWCRG J. Detchart
Internet-Draft ISAE-SUPAERO Internet-Draft ISAE-SUPAERO
Intended status: Experimental E. Lochin Intended status: Experimental E. Lochin
Expires: February 12, 2022 ENAC Expires: April 20, 2022 ENAC
J. Lacan J. Lacan
ISAE-SUPAERO ISAE-SUPAERO
V. Roca V. Roca
INRIA INRIA
August 11, 2021 October 17, 2021
Tetrys, an On-the-Fly Network Coding protocol Tetrys, an On-the-Fly Network Coding protocol
draft-detchart-nwcrg-tetrys-07 draft-detchart-nwcrg-tetrys-08
Abstract Abstract
This document is a product of the Coding for Efficient Network
Communications Research Group (NWCRG). It conforms to the directions
found in the NWCRG taxonomy [RFC8406] .
This document describes Tetrys, an On-The-Fly Network Coding (NC) This document describes Tetrys, an On-The-Fly Network Coding (NC)
protocol that can be used to transport delay and loss-sensitive data protocol that can be used to transport delay and loss-sensitive data
over a lossy network. Tetrys can recover from erasures within an over a lossy network. Tetrys can recover from erasures within an
RTT-independent delay, thanks to the transmission of coded packets. RTT-independent delay, thanks to the transmission of coded packets.
It can be used for both unicast, multicast and anycast It can be used for both unicast, multicast and anycast
communications. communications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 40 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2022. This Internet-Draft will expire on April 20, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Definitions, Notations and Abbreviations . . . . . . . . . . 3 2. Definitions, Notations and Abbreviations . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Common Header Format . . . . . . . . . . . . . . . . . . 6 4.1. Common Header Format . . . . . . . . . . . . . . . . . . 6
4.1.1. Header Extensions . . . . . . . . . . . . . . . . . . 8 4.1.1. Header Extensions . . . . . . . . . . . . . . . . . . 8
4.2. Source Packet Format . . . . . . . . . . . . . . . . . . 9 4.2. Source Packet Format . . . . . . . . . . . . . . . . . . 9
4.3. Coded Packet Format . . . . . . . . . . . . . . . . . . . 10 4.3. Coded Packet Format . . . . . . . . . . . . . . . . . . . 10
4.4. Acknowledgement Packet Format . . . . . . . . . . . . . . 11 4.4. Acknowledgement Packet Format . . . . . . . . . . . . . . 11
5. The Coding Coefficient Generator Identifiers . . . . . . . . 13 5. The Coding Coefficient Generator Identifiers . . . . . . . . 13
5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Table of Identifiers . . . . . . . . . . . . . . . . . . 13 5.2. Table of Identifiers . . . . . . . . . . . . . . . . . . 13
6. Tetrys Basic Functions . . . . . . . . . . . . . . . . . . . 13 6. Tetrys Basic Functions . . . . . . . . . . . . . . . . . . . 13
6.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Encoding Vector Formats . . . . . . . . . . . . . . . 14 6.1.1. Encoding Vector Formats . . . . . . . . . . . . . . . 14
6.2. The Elastic Encoding Window . . . . . . . . . . . . . . . 17 6.2. The Elastic Encoding Window . . . . . . . . . . . . . . . 17
6.3. Recoding . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3.1. Principle . . . . . . . . . . . . . . . . . . . . . . 18
6.3.2. Generating a coded symbol at an intermediate node . . 18
6.4. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Research Issues . . . . . . . . . . . . . . . . . . . . . . . 18 7. Research Issues . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Interaction with Existing Congestion-Controlled Transport 7.1. Interaction with Existing Congestion-Controlled Transport
Protocol . . . . . . . . . . . . . . . . . . . . . . . . 19 Protocol . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Adaptive Coding Rate . . . . . . . . . . . . . . . . . . 19 7.2. Adaptive Coding Rate . . . . . . . . . . . . . . . . . . 18
7.3. Using Tetrys Above The IP Layer For Tunneling . . . . . . 19 7.3. Using Tetrys Above The IP Layer For Tunneling . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This document describes Tetrys, a novel network coding protocol. This document describes Tetrys, a novel network coding protocol.
Network codes were introduced in the early 2000s [AHL-00] to address Network codes were introduced in the early 2000s [AHL-00] to address
the limitations of transmission over the Internet (delay, capacity the limitations of transmission over the Internet (delay, capacity
and packet loss). While the use of network codes is fairly recent in and packet loss). While the use of network codes is fairly recent in
the Internet community, the use of application layer erasure codes in the Internet community, the use of application layer erasure codes in
the IETF has already been standardized in the RMT [RMT] and the the IETF has already been standardized in the RMT [RFC3452] and the
FECFRAME [FECFRAME] working groups. The protocol presented here can FECFRAME [RFC8680] working groups. The protocol presented here can
be seen as a network coding extension to standards solutions. The be seen as a network coding extension to standards solutions. The
current proposal can be considered a combination of network erasure current proposal can be considered a combination of network erasure
coding and feedback mechanisms [Tetrys]. coding and feedback mechanisms [Tetrys] .
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 periodically updated coded packets from an elastic encoding window. This window is filled
with the receiver's feedbacks. This update is done in so that any by any source packets coming from an input flow and is periodically
source packets coming from an input flow are included in the encoding updated with the receiver's feedbacks. These feedbacks return to the
window as long as it is not acknowledged or the encoding window did sender the highest sequence number received or rebuilt, which allows
not reach a size limit. This mechanism allows for losses on both the to flush the corresponding source packets stored in the window. The
forward and return paths and in particular, is resilient to size of this window can be fixed or dynamically updated. If the
acknowledgment losses. window is full, incoming source packets are dropped. As a matter of
fact, its limit should be correctly sized. Finally, Tetrys allows to
deal with losses on both the forward and return paths and in
particular, is resilient to acknowledgment losses.
With Tetrys, a coded packet is a linear combination over a finite With Tetrys, a coded packet is a linear combination over a finite
field of the data source packets belonging to the coding window. The field of the data source packets belonging to the coding window. The
coefficients finite field's choice is a trade-off between the best coefficients finite field's choice is a trade-off between the best
performance (with non-binary coefficients) and the system constraints performance (with non-binary coefficients) and the system constraints
(binary codes in an energy-constrained environment) and is driven by (binary codes in an energy-constrained environment) and is driven by
the application. the application.
Thanks to the elastic encoding window, the coded packets are built Thanks to the elastic encoding window, the coded packets are built
on-the-fly, by using an algorithm or a function to choose the on-the-fly, by using an algorithm or a function to choose the
coefficients. The redundancy ratio can be dynamically adjusted, and coefficients. The redundancy ratio can be dynamically adjusted, and
the coefficients can be generated in different ways along with a the coefficients can be generated in different ways along with a
transmission. Compared to FEC block codes, this allows reducing the transmission. Compared to FEC block codes, this allows reducing the
bandwidth use and the decoding delay. bandwidth use and the decoding delay.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119] .
2. Definitions, Notations and Abbreviations 2. Definitions, Notations and Abbreviations
The terminology used in this document is presented below. It is
aligned with the FECFRAME terminology conjointly with recent
activities in the Network Coding Research Group.
Source symbol: a symbol that has to be transmitted between the Source symbol: a symbol that has to be transmitted between the
ingress and egress of the network. ingress and egress of the network.
Coded symbol: a linear combination over a finite field of a set of Coded symbol: a linear combination over a finite field of a set of
source symbols. source symbols.
Source symbol ID: a sequence number to identify the source Source symbol ID: a sequence number to identify the source
symbols. symbols.
Coded symbol ID: a sequence number to identify the coded symbols. Coded symbol ID: a sequence number to identify the coded symbols.
Encoding coefficients: elements of the finite field characterizing Encoding coefficients: elements of the finite field characterizing
the linear combination used to generate coded symbols. the linear combination used to generate coded symbols.
Encoding vector: a set of the encoding coefficients and input Encoding vector: a set of the coding coefficients and input source
source symbol IDs. symbol IDs.
Source packet: a source packet contains a source symbol with its Source packet: a source packet contains a source symbol with its
associated IDs. associated IDs.
Coded packet: a coded packet contains a coded symbol, the coded Coded packet: a coded packet contains a coded symbol, the coded
symbol's ID, and encoding vector. symbol's ID, and encoding vector.
Input symbol: a symbol at the input of the Tetrys Encoding Input symbol: a symbol at the input of the Tetrys Encoding
Building Block. Building Block.
skipping to change at page 5, line 7 skipping to change at page 5, line 10
Coding Coefficient Generator Identifier: a unique identifier that Coding Coefficient Generator Identifier: a unique identifier that
defines a function or an algorithm allowing to generate the defines a function or an algorithm allowing to generate the
encoding vector. encoding vector.
Code rate: Define the rate between the number of input symbols and Code rate: Define the rate between the number of input symbols and
the number of output symbols. the number of output symbols.
3. Architecture 3. Architecture
-- Editor's note: The architecture used in this document should be The notation used in this document is based on the NWCRG taxonomy
aligned with the future NC Architecture document [NWCRG-ARCH]. -- [RFC8406] .
3.1. Use Cases 3.1. Use Cases
Tetrys is well suited, but not limited to the use case where there is Tetrys is well suited, but not limited to the use case where there is
a single flow originated by a single source, with intra stream coding a single flow originated by a single source, with intra stream coding
at a single encoding node. Note that the input stream can be a at a single encoding node. Note that the input stream can be a
multiplex of several upper layer streams. Transmission can be over a multiplex of several upper layer streams. Transmission can be over a
single path or multiple paths. Besides, the flow can be sent in single path or multiple paths. Besides, the flow can be sent in
unicast, multicast, or anycast mode. This is the simplest use-case, unicast, multicast, or anycast mode. This is the simplest use-case,
that is very much aligned with currently proposed scenarios for end- that is very much aligned with currently proposed scenarios for end-
to-end streaming. to-end 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 | | | | output packets | |
| Tetrys |--------------->| Tetrys |--------------->| Tetrys | | Tetrys |--------------->| Tetrys |
| Encoder |feedback packets| Recoder |feedback packets| Decoder | | Encoder |feedback packets| Decoder |
| |<---------------| |<---------------| | | |<---------------| |
+----------+ +----------+ +----------+ +----------+ +----------+
Figure 1: Tetrys Architecture Figure 1: Tetrys Architecture
The Tetrys protocol features several key functionalities: The Tetrys protocol features several key functionalities. The
mandatory features are :
o On-the-fly encoding;
o Recoding;
o Decoding; o on-the-fly encoding;
o Signaling, to carry in particular the symbol identifiers in the o decoding;
o signaling, to carry in particular the symbol identifiers in the
encoding window and the associated coding coefficients when encoding window and the associated coding coefficients when
meaningful, in a manner that was previously used in FEC; meaningful, in a manner that was previously used in FEC;
o Feedback management; o feedback management;
o Elastic window management;
o Channel estimation; o elastic window management;
o Dynamic adjustment of the code rate and flow control; o Tetrys packet header creation and processing;
o Congestion control management (if appropriate); and the optional features are :
-- Editor's note: must be discussed -- o channel estimation;
o Tetrys packet header creation and processing; o dynamic adjustment of the code rate and flow control;
o -- Editor's note: something else? -- o congestion control management (if appropriate). See
Section Section 7.1 for further details;
Several building blocks provide these functionalities: Several building blocks provide these functionalities:
o The Tetrys Building Block: this BB is used during encoding, o The Tetrys Building Block: this BB is used during encoding, and
recoding, and decoding processes. It must be noted that Tetrys decoding processes. It must be noted that Tetrys does not mandate
does not mandate a specific building block. Instead, any building a specific building block. Instead, any building block compatible
block compatible with the elastic encoding window feature of with the elastic encoding window feature of Tetrys can be used.
Tetrys can be used.
o The Window Management Building Block: this building block is in o The Window Management Building Block: this building block is in
charge of managing the encoding window at a Tetrys sender. charge of managing the encoding window at a Tetrys sender.
-- Editor's note: Is it worth moving it in a dedicated BB? To
be discussed --
o Other ? o Other ?
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, NORM, header extension mechanism, compatible with that of LCT [RFC5651] ,
FECFRAME [REFS]. NORM [RFC5740] , FECFRAME [RFC8680] .
4. Packet Format 4. Packet Format
4.1. Common Header Format 4.1. Common Header Format
All types of Tetrys packets share the same common header format (see All types of Tetrys packets share the same common header format (see
Figure 2). Figure 2 ).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C |S| Reserved | HDR_LEN | Packet Type | | V | C |S| Reserved | HDR_LEN | Packet Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*C bits) | | Congestion Control Information (CCI, length = 32*C bits) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S bits) | | Transport Session Identifier (TSI, length = 32*S bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) | | Header Extensions (if applicable) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Common Header Format Figure 2: Common Header Format
-- Editor's note: this format inherits from the LCT header format As already noted above in the document, this format is compatible
(RFC 5651) with slight modifications. -- with LCT and inherits from the LCT header format [RFC5651] with
slight modifications.
o Tetrys version number (V): 4 bits. Indicates the Tetrys version o Tetrys version number (V): 4 bits. Indicates the Tetrys version
number. The Tetrys version number for this specification is 1. number. The Tetrys version number for this specification is 1.
o Congestion control flag (C): 2 bits. C=0 indicates the Congestion o Congestion control flag (C): 2 bits. C=0 indicates the Congestion
Control Information (CCI) field is 0 bits in length. C=1 Control Information (CCI) field is 0 bits in length. C=1
indicates the CCI field is 32 bits in length. C=2 indicates the indicates the CCI field is 32 bits in length. C=2 indicates the
CCI field is 64 bits in length. C=3 indicates the CCI field is 96 CCI field is 64 bits in length. C=3 indicates the CCI field is 96
bits in length. bits in length.
-- Editor's note: version number and congestion control to be
discussed --
o Transport Session Identifier flag (S): 1 bit. This is the number o Transport Session Identifier flag (S): 1 bit. This is the number
of full 32-bit words in the TSI field. The TSI field is 32*S bits of full 32-bit words in the TSI field. The TSI field is 32*S bits
in length, i.e., the length is either 0 bits or 32 bits. in length, i.e., the length is either 0 bits or 32 bits.
o Reserved (Resv): 9 bits. These bits are reserved. In this o Reserved (Resv): 9 bits. These bits are reserved. In this
version of the specification, they MUST be set to zero by senders version of the specification, they MUST be set to zero by senders
and MUST be ignored by receivers. and MUST be ignored by receivers.
o Header length (HDR_LEN): 8 bits. The total length of the Tetrys o Header length (HDR_LEN): 8 bits. The total length of the Tetrys
header in units of 32-bit words. The length of the Tetrys header header in units of 32-bit words. The length of the Tetrys header
skipping to change at page 8, line 44 skipping to change at page 8, line 44
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 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. Non-backward-compatible Header
Extensions CANNOT be introduced without changing the Tetrys version Extensions CANNOT be introduced without changing the Tetrys version
number. 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 Header . The first format is used for variable-length extensions, with
Extension Type (HET) values between 0 and 127. The second format is Header Extension Type (HET) values between 0 and 127. The second
used for fixed-length (one 32-bit word) extensions, using HET values format is used for fixed-length (one 32-bit word) extensions, using
from 128 to 255. HET values from 128 to 255.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | | | HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . .
. Header Extension Content (HEC) . . Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 36 skipping to change at page 10, line 36
Payload: the payload (source symbol) Payload: the payload (source symbol)
4.3. Coded Packet Format 4.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 CAN have variable sizes, each (payload). As the source symbols CAN have variable sizes, each
source symbol size need to be encoded. The result must be stored in source symbol size need to be encoded. The result must be stored in
the coded packet as the Encoded Payload Size (16 bits): as it is an the coded packet as the Encoded Payload Size (16 bits): as it is an
optional field, the encoding vector MUST signal the use of variable optional field, the encoding vector MUST signal the use of variable
source symbol sizes with the field V (see Section 6.1.1.2). source symbol sizes with the field V (see Section 6.1.1.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Common Packet Header / / Common Packet Header /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Coded Symbol ID | | Coded Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 36 skipping to change at page 11, line 36
Common Packet Header: a common packet header (as common header Common Packet Header: a common packet header (as common header
format) where Packet Type=1. format) where Packet Type=1.
Coded Symbol ID: the sequence number to identify a coded symbol. Coded Symbol ID: the sequence number to identify a coded symbol.
Encoding Vector: an encoding vector to define the linear combination Encoding Vector: an encoding vector to define the linear combination
used (coefficients and source symbols). used (coefficients and source symbols).
Encoded Payload Size: the coded payload size used if the source Encoded Payload Size: the coded payload size used if the source
symbols have a variable size (optional, Section 6.1.1.2)). symbols have a variable size (optional, Section 6.1.1.2 )).
Payload: the coded symbol. Payload: the coded symbol.
4.4. Acknowledgement Packet Format 4.4. Acknowledgement Packet Format
A Tetrys Decoding Building Block or Tetrys Recoding Building Block A Tetrys Decoding Building Block MAY send back to another building
MAY send back to another building block some Acknowledgement packets. block some Acknowledgement packets. They contain information about
They contain information about what it has received and/or decoded, what it has received and/or decoded, and other information such as a
and other information such as a packet loss rate or the size of the packet loss rate or the size of the decoding buffers. The
decoding buffers. The acknowledgment packets are OPTIONAL hence they acknowledgment packets are OPTIONAL hence they could be omitted or
could be omitted or lost in transmission without impacting the lost in transmission without impacting the protocol behavior.
protocol behavior.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Common Packet Header / / Common Packet Header /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nb of missing source symbols | | Nb of missing source symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 40 skipping to change at page 12, line 40
Nb missing source symbols: the number of missing source symbols in Nb missing source symbols: the number of missing source symbols in
the receiver since the beginning of the session. the receiver since the beginning of the session.
Nb of not already used coded symbols: the number of coded symbols at Nb of not already used coded symbols: the number of coded symbols at
the receiver that have not already been used for decoding (e.g., the the receiver that have not already been used for decoding (e.g., the
linear combinations contain at least 2 unknown source symbols). linear combinations contain at least 2 unknown source symbols).
First Source Symbol ID: ID of the first source symbol to consider for First Source Symbol ID: ID of the first source symbol to consider for
acknowledgment. acknowledgment.
PLR: packet loss ratio expressed as a percentage. PLR: packet loss ratio expressed as a percentage. This value is used
in the case of dynamic code rate or for statistical purpose. The
choice of calculation is left to the appreciation of the developer
but 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 value 2, the SACK vector is 64 bits long.
SACK vector: bit vector indicating the acknowledged symbols from the SACK vector: bit vector indicating the acknowledged symbols from the
first source symbol ID. The "First Source Symbol" is included in first source symbol ID. The "First Source Symbol" is included in
this bit vector. A bit equal to 1 at the i-th position means that this bit vector. A bit equal to 1 at the i-th position means that
this acknowledgment packet acknowledges the source symbol of ID equal this acknowledgment packet acknowledges the source symbol of ID equal
to "First Source Symbol ID" + i. to "First Source Symbol ID" + i.
5. The Coding Coefficient Generator Identifiers 5. The Coding Coefficient Generator Identifiers
5.1. Definition 5.1. Definition
The Coding Coefficient Generator Identifiers define a function or an The Coding Coefficient Generator Identifiers define a function or an
algorithm to build the coding coefficients used to generate the coded algorithm to build the coding coefficients used to generate the coded
symbols. They MUST be known by all the Tetrys encoders, recoders or symbols. They MUST be known by all the Tetrys encoders or decoders.
decoders.
5.2. Table of Identifiers 5.2. Table of Identifiers
0000: GF2 (or GF(2**1)) Vandermonde based coefficients. Each 0000: GF2 (or GF(2**1)) Vandermonde based coefficients. Each
coefficient is built as alpha^( (source_symbol_id*coded-symbol_id) % coefficient is built as alpha^( (source_symbol_id*coded-symbol_id) %
2). 2).
0001: GF16 (or GF(2**4)) Vandermonde based coefficients. Each 0001: GF16 (or GF(2**4)) Vandermonde based coefficients. Each
coefficient is built as alpha^( (source_symbol_id*coded-symbol_id) % coefficient is built as alpha^( (source_symbol_id*coded-symbol_id) %
16). 16).
skipping to change at page 13, line 41 skipping to change at page 13, line 40
6. Tetrys Basic Functions 6. Tetrys Basic Functions
6.1. Encoding 6.1. Encoding
At the beginning of a transmission, a Tetrys Encoding Building Block At the beginning of a transmission, a Tetrys Encoding Building Block
or MUST choose an initial code rate (added redundancy) as it doesn't or MUST choose an initial code rate (added redundancy) as it doesn't
know the packet loss rate of the channel. In the steady state, know the packet loss rate of the channel. In the steady state,
depending on the code-rate, the Tetrys Encoding Building Block CAN depending on the code-rate, the Tetrys Encoding Building Block CAN
generate coded symbols when it receives a source symbol from the generate coded symbols when it receives a source symbol from the
application or some feedback from the decoding or recoding blocks. application or some feedback from the decoding blocks.
When a Tetrys Encoding Building Block needs to generate a coded When a Tetrys Encoding Building Block needs to generate a coded
symbol, it considers the set of source symbols stored in the Elastic symbol, it considers the set of source symbols stored in the Elastic
Encoding Window. These source symbols are the set of source symbols Encoding Window. These source symbols are the set of source symbols
that are not yet acknowledged by the receiver. that are not yet acknowledged by the receiver.
A Tetrys Encoding Building Block SHOULD set a limit to the Elastic A Tetrys Encoding Building Block SHOULD set a limit to the Elastic
Encoding Window maximum size. This controls the algorithmic Encoding Window maximum size. This controls the algorithmic
complexity at the encoder and decoder by limiting the size of linear complexity at the encoder and decoder by limiting the size of linear
combinations. It is also needed in situations where acknowledgment combinations. It is also needed in situations where acknowledgment
skipping to change at page 16, line 28 skipping to change at page 16, line 28
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Encoding Vector Format Figure 7: Encoding Vector Format
o Encoding Vector Length (EV_LEN) (8-bits): size in units of 32-bit o Encoding Vector Length (EV_LEN) (8-bits): size in units of 32-bit
words. words.
o Coding Coefficient Generator Identifier (CCGI): 4-bit ID to o Coding Coefficient Generator Identifier (CCGI): 4-bit ID to
identify the algorithm or the function used to generate the identify the algorithm or the function used to generate the
coefficients (see Section 5). As a CCGI is included in each coefficients (see Section 5 ). As a CCGI is included in each
encoded vector, it can dynamically change between the generation encoded vector, it can dynamically change between the generation
of 2 coded symbols. of 2 coded symbols.
o Store the Source symbol IDs (I) (2 bits): o Store the Source symbol IDs (I) (2 bits):
* 00 means there is no source symbol ID information. * 00 means there is no source symbol ID information.
* 01 means the encoding vector contains the edge blocks of the * 01 means the encoding vector contains the edge blocks of the
source symbol IDs without compression. source symbol IDs without compression.
skipping to change at page 17, line 15 skipping to change at page 17, line 15
o Number of IDs used to store the source symbol IDs (NB_IDS): the o Number of IDs used to store the source symbol IDs (NB_IDS): the
number of IDs stored (depending on I). number of IDs stored (depending on I).
o Number of coefficients (NB_COEFS): The number of the coefficients o Number of coefficients (NB_COEFS): The number of the coefficients
used to generate the associated coded symbol. used to generate the associated coded symbol.
o The first source Identifier (FIRST_SOURCE_ID): the first source o The first source Identifier (FIRST_SOURCE_ID): the first source
symbol ID used in the combination. symbol ID used in the combination.
o Number of bits for each edge block (b_id): the number of bits o Number of bits for each edge block (b_id): the number of bits
needed to store the edge (see Section 6.1.1.1). needed to store the edge (see Section 6.1.1.1 ).
o Information about the source symbol IDs (id_bit_vector): if I=01, o Information about the source symbol IDs (id_bit_vector): if I=01,
store the edge blocks as b_id * (NB_IDS * 2 - 1). If I=10, store store the edge blocks as b_id * (NB_IDS * 2 - 1). If I=10, store
in a compressed way the edge blocks. in a compressed way the edge blocks.
o Number of bits needed to store each coefficient (b_coef): the o Number of bits needed to store each coefficient (b_coef): the
number of bits used to store the coefficients. number of bits used to store the coefficients.
o The coefficients (coef_bit_vector): The coefficients stored (as a o The coefficients (coef_bit_vector): The coefficients stored (as a
vector of b_coef * NB_COEFS). vector of b_coef * NB_COEFS).
skipping to change at page 17, line 42 skipping to change at page 17, line 42
When an input source symbol is passed to a Tetrys Encoding Building When an input source symbol is passed to a Tetrys Encoding Building
Block, it is added to the Elastic Encoding Window. This window MUST Block, it is added to the Elastic Encoding Window. This window MUST
have a limit set by the encoding building Block (depending on the use have a limit set by the encoding building Block (depending on the use
case: unicast, multicast, file transfer, real-time transfer, ...). case: unicast, multicast, file transfer, real-time transfer, ...).
If the Elastic Encoding Window reached its limit, the window slides If the Elastic Encoding Window reached its limit, the window slides
over the symbols: the first (oldest) symbols are removed. Then, a over the symbols: the first (oldest) symbols are removed. Then, a
packet containing this symbol can be sent onto the network. As an packet containing this symbol can be sent onto the network. 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 receiver or the recoder sends periodic As explained below, the receiver sends periodic feedback indicating
feedback indicating the received or decoded source symbols. In the the received or decoded source symbols. In the case of unicast
case of unicast transmission, when the sender receives the transmission, when the sender receives the information that a source
information that a source symbol was received and/or decoded by the symbol was received and/or decoded by the receiver, it removes this
receiver, it removes this symbol from the coding window. symbol from the coding window.
In a multicast transmission: In a multicast transmission:
o If the acknowledgment packets are not enabled, the coding window o If the acknowledgment packets are not enabled, the coding window
grows up to a limit. When the limit is reached, the oldest grows up to a limit. When the limit is reached, the oldest
symbols are removed from the coding window. symbols are removed from the coding window.
o If the acknowledgment packets are enabled, a source symbol is o If the acknowledgment packets are enabled, a source symbol is
removed from the coding window when all the receivers have removed from the coding window when all the receivers have
received or decoded it or when the coding window reaches its received or decoded it or when the coding window reaches its
limit. limit.
6.3. Recoding 6.3. Decoding
6.3.1. Principle
A Tetrys Recoding Block maintains a list of the ID of the source
symbols included in the Elastic Coding Window of the sender. It also
stores a set of received source and coded symbols able to regenerate
the set or a subset of the Elastic Coding Window symbols. In other
words, if R1, ..., Rt represent t received symbols and S1, ..., Sk
represent the set or a subset of the source symbols of the Elastic
Coding Window, there exists a t*k-matrix M such that (R1, ..., Rt).M
= (S1, ..., Sk).
6.3.2. Generating a coded symbol at an intermediate node
At the generation of a coded symbol, the Tetrys Recoding Building
Block generates an encoding vector containing the IDs of the source
symbols stored in the Elastic Encoding Window or in the subset of the
Elastic Encoding Window that it can regenerate. The Tetrys Recoding
Building Block then generates a new coded symbol ID different from
the received coded symbol IDs. From this coded symbol ID and the
source symbol IDs of (S1, ..., Sk), a finite field coefficient is
determined using a Coding Coefficient Generator. Let (a1, ...,ak)
denote the obtained coefficients. To compute the linear combination
(s1, ..., Sk).transpose(a1, ..., ak) the Tetrys Recoding Building
block computes the vector v = (a1, ...,ak).transpose(M) and then
computes the coded symbol R = (R1, ..., Rt).transpose(v). It can be
verified that the new coded symbol is obtained without any decoding
operation.
6.4. Decoding
A classical matrix inversion is sufficient to recover the source A classical matrix inversion is sufficient to recover the source
symbols. symbols.
7. Research Issues 7. Research Issues
The design of Tetrys protocol presented in this document provides the The design of Tetrys protocol presented in this document provides the
baseline allowing communication between a Tetrys encoder and a Tetrys baseline allowing communication between a Tetrys encoder and a Tetrys
decoder. At this stage, the detailed specifications only focus on decoder. At this stage, the detailed specifications only focus on
the coding and decoding aspects. The objective of this document is the coding and decoding aspects. The objective of this document is
skipping to change at page 19, line 17 skipping to change at page 18, line 36
such as opening/closing procedures and timeout/reset, we identified such as opening/closing procedures and timeout/reset, we identified
the following research issues that would need further discussion. the following research issues that would need further discussion.
7.1. Interaction with Existing Congestion-Controlled Transport Protocol 7.1. Interaction with Existing Congestion-Controlled Transport Protocol
Tetrys coding and congestion control can be seen as two separate Tetrys coding and congestion control can be seen as two separate
channels. In practice, implementations may mix the signals exchanged channels. In practice, implementations may mix the signals exchanged
on these channels. This raises several concerns that must be tackled on these channels. This raises several concerns that must be tackled
when considering using Tetrys conjointly with a congestion-controlled when considering using Tetrys conjointly with a congestion-controlled
transport protocol. All these numerous research issues are discussed transport protocol. All these numerous research issues are discussed
in a separate document [I-D.irtf-nwcrg-coding-and-congestion]. In in a separate document [I-D.irtf-nwcrg-coding-and-congestion] . In
particular, this document investigates end-to-end unicast data particular, this document investigates end-to-end unicast data
transfer with FEC coding in the application (above the transport), transfer with FEC coding in the application (above the transport),
within the transport, or directly below the transport; the within the transport, or directly below the transport; the
relationship between transport layer and application requirements; relationship between transport layer and application requirements;
and the case of transport multipath and multi-streams applications. and the case of transport multipath and multi-streams applications.
7.2. Adaptive Coding Rate 7.2. Adaptive Coding Rate
In a particular context, a redundancy adaptation algorithm might be In a particular context, a redundancy adaptation algorithm might be
considered helpful or mandatory when the network condition (e.g., considered helpful or mandatory when the network condition (e.g.,
delay, loss rate) strongly varies over time. Hence, it requires an delay, loss rate) strongly varies over time. Hence, it requires an
enhanced mechanism for erasure codes to adapt to network dynamics enhanced mechanism for erasure codes to adapt to network dynamics
similarly to [A-FEC]. However, the dynamic adaptation of an on-the- similarly to [A-FEC] . However, the dynamic adaptation of an on-the-
fly coding rate is slightly more complex than a block code. fly coding rate is slightly more complex than a block code.
Furthermore, this adaptation can be done conjointly with the network Furthermore, this adaptation can be done conjointly with the network
as proposed in [RED-FEC]. In this paper, the authors propose a as proposed in [RED-FEC] . In this paper, the authors propose a
Random Early Detection FEC mechanism in the context of video Random Early Detection FEC mechanism in the context of video
transmission over wireless networks. In brief, the idea is to add transmission over wireless networks. In brief, the idea is to add
more redundancy packets if the queue at the access point is less more redundancy packets if the queue at the access point is less
occupied and vice versa. A first theoretical attempt for video occupied and vice versa. A first theoretical attempt for video
delivery has been proposed [THAI] with Tetrys. However, this kind of delivery has been proposed [THAI] with Tetrys. However, this kind of
algorithms should deserve more research to be deployed in practice. algorithms should deserve more research to be deployed in practice.
7.3. Using Tetrys Above The IP Layer For Tunneling 7.3. Using Tetrys Above The IP Layer For Tunneling
The use of Tetrys to protect from losses an aggregate of flows raise The use of Tetrys to protect from losses an aggregate of flows raise
various issues. This occurs when an encoding mechanism is enabled various issues. This occurs when an encoding mechanism is enabled
below the IP layer and builds redundancy without flows below the IP layer and builds redundancy without flows
differentiation. This is typically the case in a tunnel. The main differentiation. This is typically the case in a tunnel. The main
problem relates to head-of-line blocking when decoding multiple problem relates to head-of-line blocking when decoding multiple
flows. The number of source packets might vary following their own flows. The number of source packets might vary following their own
loss probability and lead to decoding blocking in waiting for source loss probability and lead to decoding blocking in waiting for source
data packets to be suppressed from a given repair packet. This kind data packets to be suppressed from a given repair packet. This kind
of issue could lead to a decrease of the decoding performance and of issue could lead to a decrease of the decoding performance and
should be further investigated. Note this research issue joins the should be further investigated. Note this research issue joins the
topics discussed in the IRTF LOOPS working group topics discussed in the IRTF LOOPS working group
[I-D.li-tsvwg-loops-problem-opportunities]. [I-D.li-tsvwg-loops-problem-opportunities] .
8. Security Considerations 8. Security Considerations
Tetrys inherits a subset of the security issues described as those Tetrys inherits a subset of the security issues described as those
described in FECFRAME [FECFRAME] and in particular in sections described in FECFRAME [RFC8680] and in particular in sections "9.2.2.
"9.2.2. Content Corruption" and "9.3. Attacks against the FEC Content Corruption" and "9.3. Attacks against the FEC Parameters".
Parameters". As an application layer end-to-end protocol, security As an application layer end-to-end protocol, security considerations
considerations of Tetrys should also be comparable to those of HTTP/2 of Tetrys should also be comparable to those of HTTP/2 with TLS. The
with TLS. The considerations from Section 10 of HTTP2 [HTTP2] also considerations from Section 10 of HTTP2 [RFC7540] also apply in
apply in addition to those listed here. addition to those listed here.
9. Privacy Considerations 9. Privacy Considerations
N/A N/A
10. IANA Considerations 10. IANA Considerations
N/A N/A
11. Acknowledgments 11. Acknowledgments
skipping to change at page 20, line 43 skipping to change at page 20, line 14
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words 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., and J. Crowcroft, "Forward Error Correction (FEC)
Building Block", RFC 3452, DOI 10.17487/RFC3452, December
2002, <https://www.rfc-editor.org/info/rfc3452>.
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651,
DOI 10.17487/RFC5651, October 2009,
<https://www.rfc-editor.org/info/rfc5651>.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
<https://www.rfc-editor.org/info/rfc5740>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J.,
Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
S. Sivakumar, "Taxonomy of Coding Techniques for Efficient
Network Communications", RFC 8406, DOI 10.17487/RFC8406,
June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[RFC8680] Roca, V. and A. Begen, "Forward Error Correction (FEC)
Framework Extension to Sliding Window Codes", RFC 8680,
DOI 10.17487/RFC8680, January 2020,
<https://www.rfc-editor.org/info/rfc8680>.
12.2. Informative References 12.2. Informative References
[A-FEC] Bolot, J., Fosse-Parisis, S., and D. Towsley, "Adaptive [A-FEC] Bolot, J., Fosse-Parisis, S., and D. Towsley, "Adaptive
FEC-based error control for Internet telephony", IEEE FEC-based error control for Internet telephony", IEEE
INFOCOM 99, pp. 1453-1460 vol. 3 DOI INFOCOM 99, pp. 1453-1460 vol. 3 DOI
10.1109/INFCOM.1999.752166, 1999. 10.1109/INFCOM.1999.752166, 1999.
[AHL-00] Ahlswede, R., Ning Cai, Li, S., and R. Yeung, "Network [AHL-00] Ahlswede, R., Ning Cai, Li, S., and R. Yeung, "Network
information flow", IEEE Transactions on Information information flow", IEEE Transactions on Information
Theory vol.46, no.4, pp.1204,1216, July 2000. Theory vol.46, no.4, pp.1204,1216, July 2000.
[FECFRAME]
Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", Request for Comments 6363,
October 2011.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol Version 2 (HTTP/2)", Request for Comments 7540,
October 2015.
[I-D.irtf-nwcrg-coding-and-congestion] [I-D.irtf-nwcrg-coding-and-congestion]
Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding
and congestion control in transport", draft-irtf-nwcrg- and congestion control in transport", draft-irtf-nwcrg-
coding-and-congestion-09 (work in progress), June 2021. coding-and-congestion-09 (work in progress), June 2021.
[I-D.li-tsvwg-loops-problem-opportunities] [I-D.li-tsvwg-loops-problem-opportunities]
Li, Y., Zhou, X., Boucadair, M., Wang, J., and F. Qin, Li, Y., Zhou, X., Boucadair, M., Wang, J., and F. Qin,
"LOOPS (Localized Optimizations on Path Segments) Problem "LOOPS (Localized Optimizations on Path Segments) Problem
Statement and Opportunities for Network-Assisted Statement and Opportunities for Network-Assisted
Performance Enhancement", draft-li-tsvwg-loops-problem- Performance Enhancement", draft-li-tsvwg-loops-problem-
opportunities-06 (work in progress), July 2020. opportunities-06 (work in progress), July 2020.
[NWCRG-ARCH]
NWCRG, "Network Coding Architecture", TBD TBD.
[RED-FEC] Lin, C., Shieh, C., Chilamkurti, N., Ke, C., and H. Hwang, [RED-FEC] Lin, C., Shieh, C., Chilamkurti, N., Ke, C., and H. Hwang,
"A RED-FEC Mechanism for Video Transmission Over WLANs", "A RED-FEC Mechanism for Video Transmission Over WLANs",
IEEE Transactions on Broadcasting, vol. 54, no. 3, pp. IEEE Transactions on Broadcasting, vol. 54, no. 3, pp.
517-524 DOI 10.1109/TBC.2008.2001713, September 2008. 517-524 DOI 10.1109/TBC.2008.2001713, September 2008.
[RMT] Vicisano, L., Gemmel, J., Rizzo, L., Handley, M., and J.
Crowcroft, "Forward Error Correction (FEC) Building
Block", Request for Comments 3452, December 2002.
[Tetrys] Lacan, J. and E. Lochin, "Rethinking reliability for long- [Tetrys] Lacan, J. and E. Lochin, "Rethinking reliability for long-
delay networks", International Workshop on Satellite and delay networks", International Workshop on Satellite and
Space Communications 2008 (IWSSC08), October 2008. Space Communications 2008 (IWSSC08), October 2008.
[THAI] Tran-Thai, T., Lacan, J., and E. Lochin, "Joint on-the-fly [THAI] Tran-Thai, T., Lacan, J., and E. Lochin, "Joint on-the-fly
network coding/video quality adaptation for real-time network coding/video quality adaptation for real-time
delivery", Signal Processing: Image Communication, vol. 29 delivery", Signal Processing: Image Communication, vol. 29
(no. 4), pp. 449-461 ISSN 0923-5965, 2014. (no. 4), pp. 449-461 ISSN 0923-5965, 2014.
Authors' Addresses Authors' Addresses
 End of changes. 54 change blocks. 
165 lines changed or deleted 143 lines changed or added

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