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