idnits 2.17.00 (12 Aug 2021) /tmp/idnits52475/draft-irtf-nwcrg-tetrys-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8406]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (April 24, 2022) is 20 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 711 -- Looks like a reference, but probably isn't: '3' on line 711 -- Looks like a reference, but probably isn't: '5' on line 711 -- Looks like a reference, but probably isn't: '6' on line 711 -- Looks like a reference, but probably isn't: '8' on line 711 -- Looks like a reference, but probably isn't: '10' on line 711 -- Looks like a reference, but probably isn't: '2' on line 707 ** Obsolete normative reference: RFC 3452 (Obsoleted by RFC 5052, RFC 5445) Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NWCRG J. Detchart 3 Internet-Draft ISAE-SUPAERO 4 Intended status: Experimental E. Lochin 5 Expires: October 26, 2022 ENAC 6 J. Lacan 7 ISAE-SUPAERO 8 V. Roca 9 INRIA 10 April 24, 2022 12 Tetrys, an On-the-Fly Network Coding Protocol 13 draft-irtf-nwcrg-tetrys-02 15 Abstract 17 This document describes Tetrys, an On-The-Fly Network Coding (NC) 18 protocol that MAY be used to transport delay and loss-sensitive data 19 over a lossy network. Tetrys MAY recover from erasures within an 20 RTT-independent delay, thanks to the transmission of Coded Packets. 21 This document is a record of the experience gained by the authors 22 while developing and testing in real conditions the Tetrys protocol. 24 This document is a product of the Coding for Efficient Network 25 Communications Research Group (NWCRG). It conforms to the NWCRG 26 taxonomy[RFC8406]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 26, 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 64 2. Definitions, Notations and Abbreviations . . . . . . . . . . 4 65 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Tetrys Basic Functions . . . . . . . . . . . . . . . . . . . 6 69 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. The Elastic Encoding Window . . . . . . . . . . . . . . . 7 71 4.3. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.1. Common Header Format . . . . . . . . . . . . . . . . . . 7 74 5.1.1. Header Extensions . . . . . . . . . . . . . . . . . . 9 75 5.2. Source Packet Format . . . . . . . . . . . . . . . . . . 10 76 5.3. Coded Packet Format . . . . . . . . . . . . . . . . . . . 11 77 5.3.1. The Encoding Vector . . . . . . . . . . . . . . . . . 12 78 5.4. Window Update Packet Format . . . . . . . . . . . . . . . 16 79 6. Research Issues . . . . . . . . . . . . . . . . . . . . . . . 18 80 6.1. Interaction with Congestion Control . . . . . . . . . . . 18 81 6.2. Adaptive Coding Rate . . . . . . . . . . . . . . . . . . 19 82 6.3. Using Tetrys Below The IP Layer For Tunneling . . . . . . 20 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 89 11.2. Informative References . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Introduction 94 This document is a product of and represents the collaborative work 95 and consensus of the Coding for Efficient Network Communications 96 Research Group (NWCRG). It is not an IETF product and is not an IETF 97 standard. 99 This document describes Tetrys, a novel erasure coding protocol. 100 Network codes were introduced in the early 2000s [AHL-00] to address 101 the limitations of transmission over the Internet (delay, capacity 102 and packet loss). While the use of network codes is fairly recent in 103 the Internet community, the use of application layer erasure codes in 104 the IETF has already been standardized in the RMT [RFC3452] and the 105 FECFRAME [RFC8680] working groups. The protocol presented here MAY 106 be seen as a network coding extension to standard unicast transport 107 protocols (or even multicast or anycast with a few modifications). 108 The current proposal MAY be considered a combination of network 109 erasure coding and feedback mechanisms [Tetrys], [Tetrys-RT] . 111 The main innovation of the Tetrys protocol is in the generation of 112 Coded Packets from an Elastic Encoding Window. This window is filled 113 by any Source Packets coming from an input flow and is periodically 114 updated with the receiver's feedbacks. These feedbacks return to the 115 sender the highest sequence number received or rebuilt, which allows 116 to flush the corresponding Source Packets stored in the encoding 117 window. The size of this window MAY be fixed or dynamically updated. 118 If the window is full, incoming Source Packets replace older sources 119 packets which are dropped. As a matter of fact, its limit should be 120 correctly sized. Finally, Tetrys allows to deal with losses on both 121 the forward and return paths and in particular, is resilient to 122 acknowledgment losses. All these operations are further detailed in 123 Section Section 4. 125 With Tetrys, a Coded Packet is a linear combination over a finite 126 field of the data Source Packets belonging to the coding window. The 127 coefficients finite field's choice is a trade-off between the best 128 erasure recovery performance (finite fields of 256 elements) and the 129 system constraints (finite fields of 16 elements is preferred) and is 130 driven by the application. 132 Thanks to the Elastic Encoding Window, the Coded Packets are built 133 on-the-fly, by using a predefined method to choose the coefficients. 134 The redundancy ratio MAY be dynamically adjusted, and the 135 coefficients MAY be generated in different ways, during the 136 transmission. Compared to FEC block codes, this allows reducing the 137 bandwidth use and the decoding delay. 139 The design of Tetrys protocol detailed in this document is completed 140 by a record of the experience gained by the authors while developing 141 and testing in real conditions the Tetrys protocol. In particular, 142 several research issues are discussed in Section 6 following our own 143 experience and observations. 145 1.1. Requirements Notation 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119] . 151 2. Definitions, Notations and Abbreviations 153 The notation used in this document is based on the NWCRG taxonomy 154 [RFC8406] . 156 Source Symbol: a symbol that has to be transmitted between the 157 ingress and egress of the network. 159 Coded Symbol: a linear combination over a finite field of a set of 160 Source Symbols. 162 Source Symbol ID: a sequence number to identify the Source 163 Symbols. 165 Coded Symbol ID: a sequence number to identify the Coded Symbols. 167 Encoding Coefficients: elements of the finite field characterizing 168 the linear combination used to generate Coded Symbols. 170 Encoding Vector: a set of the coding coefficients and input Source 171 Symbol IDs. 173 Source Packet: a Source Packet contains a Source Symbol with its 174 associated IDs. 176 Coded Packet: a Coded Packet contains a Coded Symbol, the Coded 177 Symbol's ID, and Encoding Vector. 179 Input Symbol: a symbol at the input of the Tetrys Encoder. 181 Output Symbol: a symbol generated by the Tetrys Encoder. For a 182 non-systematic mode, all Output Symbols are Coded Symbols. For a 183 systematic mode, Output Symbols MAY be the Input Symbols and a 184 number of Coded Symbols that are linear combinations of the Input 185 Symbols + the Encoding Vectors. 187 Feedback Packet: a Feedback Packet is a packet containing 188 information about the decoded or received Source Symbols. It MAY 189 also bring additional information about the Packet Error Rate or 190 the number of various packets in the receiver decoding window. 192 Elastic Encoding Window: an encoder-side buffer that stores all 193 the non-acknowledged Source Packets of the input flow involved in 194 the coding process. 196 Coding Coefficient Generator Identifier: a unique identifier that 197 defines a function or an algorithm allowing to generate the 198 Encoding Vector. 200 Code Rate: Define the rate between the number of Input Symbols and 201 the number of Output Symbols. 203 3. Architecture 205 3.1. Use Cases 207 Tetrys is well suited, but not limited to, the use case where there 208 is a single flow originated by a single source, with intra stream 209 coding at a single encoding node. Note that the input stream MAY be 210 a multiplex of several upper layer streams. Transmission MAY be over 211 a single path or multiple paths. This is the simplest use-case, that 212 is very much aligned with currently proposed scenarios for end-to-end 213 streaming. 215 3.2. Overview 217 +----------+ +----------+ 218 | | | | 219 | App | | App | 220 | | | | 221 +----------+ +----------+ 222 | ^ 223 | Source Source | 224 | Symbols Symbols | 225 | | 226 v | 227 +----------+ +----------+ 228 | | output packets | | 229 | Tetrys |--------------->| Tetrys | 230 | Encoder |Feedback Packets| Decoder | 231 | |<---------------| | 232 +----------+ +----------+ 234 Figure 1: Tetrys Architecture 236 The Tetrys protocol features several key functionalities. The 237 mandatory features are: 239 o on-the-fly encoding; 241 o decoding; 243 o signaling, to carry in particular the symbol identifiers in the 244 encoding window and the associated coding coefficients when 245 meaningful; 247 o feedback management; 249 o elastic window management; 251 o Tetrys packet header creation and processing; 253 and the optional features are : 255 o channel estimation; 257 o dynamic adjustment of the Code Rate and flow control; 259 o congestion control management (if appropriate). See Section 6.1 260 for further details; 262 Several building blocks provide these functionalities: 264 o The Tetrys Building Block: this BB embeds both the Tetrys Decoder 265 and Tetrys Encoder and thus, is used during encoding, and decoding 266 processes. It must be noted that Tetrys does not mandate a 267 specific building block. Instead, any building block compatible 268 with the Elastic Encoding Window feature of Tetrys MAY be used. 270 o The Window Management Building Block: this building block is in 271 charge of managing the encoding window at a Tetrys sender. 273 To ease the addition of future components and services, Tetrys adds a 274 header extension mechanism, compatible with that of LCT [RFC5651], 275 NORM [RFC5740], FECFRAME [RFC8680]. 277 4. Tetrys Basic Functions 279 4.1. Encoding 281 At the beginning of a transmission, a Tetrys Encoder MUST choose an 282 initial Code Rate (added redundancy) as it doesn't know the packet 283 loss rate of the channel. In the steady state, depending on the Code 284 Rate, the Tetrys Encoder MAY generate Coded Symbols when it receives 285 a Source Symbol from the application or some feedback from the 286 decoding blocks. 288 When a Tetrys Encoder needs to generate a Coded Symbol, it considers 289 the set of Source Symbols stored in the Elastic Encoding Window and 290 generates an Encoding Vector with the Coded Symbol. These Source 291 Symbols are the set of Source Symbols that are not yet acknowledged 292 by the receiver. For each Source Symbol, a finite field coefficient 293 is determined using a Coding Coefficient Generator. This generator 294 MAY take as input the Source Symbol IDs and the Coded Symbol ID and 295 MAY determine a coefficient in a deterministic way as presented in 296 Section 5.3. Finally, the Coded Symbol is the sum of the Source 297 Symbols multiplied by their corresponding coefficients. 299 A Tetrys Encoder SHOULD set a limit to the Elastic Encoding Window 300 maximum size. This controls the algorithmic complexity at the 301 encoder and decoder by limiting the size of linear combinations. It 302 is also needed in situations where window update packets are all lost 303 or absent. 305 4.2. The Elastic Encoding Window 307 When an input Source Symbol is passed to a Tetrys Encoder, it is 308 added to the Elastic Encoding Window. This window MUST have a limit 309 set by the encoding building Block. If the Elastic Encoding Window 310 reached its limit, the window slides over the symbols: the first 311 (oldest) symbol is removed, and the newest symbol is added. As an 312 element of the coding window, this symbol is included in the next 313 linear combinations created to generate the Coded Symbols. 315 As explained below, the Tetrys Decoder sends periodic feedback 316 indicating the received or decoded Source Symbols. When the sender 317 receives the information that a Source Symbol was received or decoded 318 by the receiver, it removes this symbol from the coding window. 320 4.3. Decoding 322 A standard Gaussian elimination is sufficient to recover the erased 323 Source Symbols, when the matrix rank enables it. 325 5. Packet Format 327 5.1. Common Header Format 329 All types of Tetrys packets share the same common header format (see 330 Figure 2). 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | V | C |S| Reserved | HDR_LEN | PKT_TYPE | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Congestion Control Information (CCI, length = 32*C bits) | 338 | ... | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Transport Session Identifier (TSI, length = 32*S bits) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Header Extensions (if applicable) | 343 | ... | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 2: Common Header Format 348 As already noted above in the document, this format is inspired and 349 inherits from the LCT header format [RFC5651] with slight 350 modifications. 352 o Tetrys version number (V): 4 bits. Indicates the Tetrys version 353 number. The Tetrys version number for this specification is 1. 355 o Congestion control flag (C): 2 bits. C=0 indicates the Congestion 356 Control Information (CCI) field is 0 bits in length. C=1 357 indicates the CCI field is 32 bits in length. C=2 indicates the 358 CCI field is 64 bits in length. C=3 indicates the CCI field is 96 359 bits in length. 361 o Transport Session Identifier flag (S): 1 bit. This is the number 362 of full 32-bit words in the TSI field. The TSI field is 32*S bits 363 in length, i.e., the length is either 0 bits or 32 bits. 365 o Reserved (Resv): 9 bits. These bits are reserved. In this 366 version of the specification, they MUST be set to zero by senders 367 and MUST be ignored by receivers. 369 o Header length (HDR_LEN): 8 bits. The total length of the Tetrys 370 header in units of 32-bit words. The length of the Tetrys header 371 MUST be a multiple of 32 bits. This field MAY be used to directly 372 access the portion of the packet beyond the Tetrys header, i.e., 373 to the first next header if it exists, or to the packet payload if 374 it exists and there is no other header, or to the end of the 375 packet if there are no others headers or packet payload. 377 o PKT_TYPE: Tetrys packet type, 8 bits. Type of packet. There is 3 378 types of packets: the PKT_TYPE_SOURCE (0) defined in Section 5.2, 379 the PKT_TYPE_CODED (1) defined in Section 5.3 and the 380 PKT_TYPE_WND_UPT (3), for window update packets defined in 381 Section 5.4. 383 o Congestion Control Information (CCI): 0, 32, 64, or 96 bits Used 384 to carry congestion control information. For example, the 385 congestion control information could include layer numbers, 386 logical channel numbers, and sequence numbers. This field is 387 opaque for this specification. This field MUST be 0 bits (absent) 388 if C=0. This field MUST be 32 bits if C=1. This field MUST be 64 389 bits if C=2. This field MUST be 96 bits if C=3. 391 o Transport Session Identifier (TSI): 0 or 32 bits The TSI uniquely 392 identifies a session among all sessions from a particular Tetrys 393 encoder. The TSI is scoped by the IP address of the sender, and 394 thus the IP address of the sender and the TSI together uniquely 395 identify the session. Although a TSI, conjointly with the IP 396 address of the sender, always uniquely identifies a session, 397 whether the TSI is included in the Tetrys header depends on what 398 is used as the TSI value. If the underlying transport is UDP, 399 then the 16-bit UDP source port number MAY serve as the TSI for 400 the session. If there is no underlying TSI provided by the 401 network, transport or any other layer, then the TSI MUST be 402 included in the Tetrys header. 404 5.1.1. Header Extensions 406 Header Extensions are used in Tetrys to accommodate optional header 407 fields that are not always used or have variable size. The presence 408 of Header Extensions MAY be inferred by the Tetrys header length 409 (HDR_LEN). If HDR_LEN is larger than the length of the standard 410 header, then the remaining header space is taken by Header 411 Extensions. 413 If present, Header Extensions MUST be processed to ensure that they 414 are recognized before performing any congestion control procedure or 415 otherwise accepting a packet. The default action for unrecognized 416 Header Extensions is to ignore them. This allows the future 417 introduction of backward-compatible enhancements to Tetrys without 418 changing the Tetrys version number. Non-backward-compatible Header 419 Extensions CANNOT be introduced without changing the Tetrys version 420 number. 422 There are two formats for Header Extensions, as depicted in Figure 3 423 . The first format is used for variable-length extensions, with 424 Header Extension Type (HET) values between 0 and 127. The second 425 format is used for fixed-length (one 32-bit word) extensions, using 426 HET values from 128 to 255. 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | HET (<=127) | HEL | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 433 . . 434 . Header Extension Content (HEC) . 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | HET (>=128) | Header Extension Content (HEC) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 3: Header Extension Format 445 o Header Extension Type (HET): 8 bits The type of the Header 446 Extension. This document defines several possible types. 447 Additional types may be defined in future versions of this 448 specification. HET values from 0 to 127 are used for variable- 449 length Header Extensions. HET values from 128 to 255 are used for 450 fixed-length 32-bit Header Extensions. 452 o Header Extension Length (HEL): 8 bits The length of the whole 453 Header Extension field, expressed in multiples of 32-bit words. 454 This field MUST be present for variable-length extensions (HETs 455 between 0 and 127) and MUST NOT be present for fixed-length 456 extensions (HETs between 128 and 255). 458 o Header Extension Content (HEC): variable length The content of the 459 Header Extension. The format of this subfield depends on the 460 Header Extension Type. For fixed-length Header Extensions, the 461 HEC is 24 bits. For variable-length Header Extensions, the HEC 462 field has variable size, as specified by the HEL field. Note that 463 the length of each Header Extension MUST be a multiple of 32 bits. 464 Also, note that the total size of the Tetrys header, including all 465 Header Extensions and all optional header fields, cannot exceed 466 255 32-bit words. 468 5.2. Source Packet Format 470 A Source Packet is a Common Packet Header encapsulation, a Source 471 Symbol ID and a Source Symbol (payload). The Source Symbols MAY have 472 variable sizes. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | | 478 / Common Packet Header / 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Source Symbol ID | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 / Payload / 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 4: Source Packet Format 490 Common Packet Header: a common packet header (as common header 491 format) where Packet Type=0. 493 Source Symbol ID: the sequence number to identify a Source Symbol. 495 Payload: the payload (Source Symbol) 497 5.3. Coded Packet Format 499 A Coded Packet is the encapsulation of a Common Packet Header, a 500 Coded Symbol ID, the associated Encoding Vector, and a Coded Symbol 501 (payload). As the Source Symbols MAY have variable sizes, all the 502 Source Symbol sizes need to be encoded. To generate this encoded 503 payload size, as a 16-bit unsigned value, the linear combination uses 504 the same coefficients as the coded payload. The result MUST be 505 stored in the Coded Packet as the Encoded Payload Size (16 bits): as 506 it is an optional field, the Encoding Vector MUST signal the use of 507 variable Source Symbol sizes with the field V (see Section 5.3.1). 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | | 513 / Common Packet Header / 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Coded Symbol ID | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | | 519 / Encoding Vector / 520 | | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Encoded Payload Size | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 524 | | 525 / Payload / 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Figure 5: Coded Packet Format 531 Common Packet Header: a common packet header (as common header 532 format) where Packet Type=1. 534 Coded Symbol ID: the sequence number to identify a Coded Symbol. 536 Encoding Vector: an Encoding Vector to define the linear combination 537 used (coefficients and Source Symbols). 539 Encoded Payload Size: the coded payload size used if the Source 540 Symbols have a variable size (optional,Section 5.3.1). 542 Payload: the Coded Symbol. 544 5.3.1. The Encoding Vector 546 An Encoding Vector contains all the information about the linear 547 combination used to generate a Coded Symbol. The information 548 includes the source identifiers and the coefficients used for each 549 Source Symbol. It MAY be stored in different ways depending on the 550 situation. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | EV_LEN | CCGI | I |C|V| NB_IDS | NB_COEFS | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | FIRST_SOURCE_ID | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | b_id | | 560 +-+-+-+-+-+-+-+-+ id_bit_vector +-+-+-+-+-+-+-+ 561 | | Padding | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | | 564 + coef_bit_vector +-+-+-+-+-+-+-+ 565 | | Padding | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Figure 6: Encoding Vector Format 570 o Encoding Vector Length (EV_LEN) (8-bits): size in units of 32-bit 571 words. 573 o Coding Coefficient Generator Identifier (CCGI): 4-bit ID to 574 identify the algorithm or the function used to generate the 575 coefficients. As a CCGI is included in each encoded vector, it 576 MAY dynamically change between the generation of 2 Coded Symbols. 577 The CCGI builds the coding coefficients used to generate the Coded 578 Symbols. They MUST be known by all the Tetrys encoders or 579 decoders. The two RLC FEC schemes specified in this document 580 reuse the Finite Fields defined in [RFC5510], Section 8.1. More 581 specifically, the elements of the field GF(2^(m)) are represented 582 by polynomials with binary coefficients (i.e., over GF(2)) and 583 degree lower or equal to m-1. The addition between two elements 584 is defined as the addition of binary polynomials in GF(2), which 585 is equivalent to a bitwise XOR operation on the binary 586 representation of these elements. With GF(2^(8)), multiplication 587 between two elements is the multiplication modulo a given 588 irreducible polynomial of degree 8. The following irreducible 589 polynomial is used for GF(2^(8)): x^(8) + x^(4) + x^(3) + x^(2) + 590 1 With GF(2^(4)), multiplication between two elements is the 591 multiplication modulo a given irreducible polynomial of degree 4. 592 The following irreducible polynomial is used for GF(2^(4)): x^(4) 593 + x + 1 595 0: Vandermonde based coefficients over the finite field 596 GF(2^(4)), as defined below. Each coefficient is built as 597 alpha^( (source_symbol_id*coded-symbol_id) % 16), with alpha 598 the root of the primitive polynomial. 600 1: Vandermonde based coefficients over the finite field 601 GF(2^(8)), as defined below. Each coefficient is built as 602 alpha^( (source_symbol_id*coded-symbol_id) % 256), with alpha 603 the root of the primitive polynomial. 605 Suppose we want to generate the Coded Symbol 2 as a linear 606 combination of the Source Symbols 1,2,4 using CCGI=1. The 607 coefficients will be alpha ^( (1 * 1) % 256), alpha ^( (1 * 2) 608 % 256), alpha ^( (1 * 4) % 256). 610 o Store the Source Symbol ID Format (I) (2 bits): 612 * 00 means there is no Source Symbol ID information. 614 * 01 means the Encoding Vector contains the edge blocks of the 615 Source Symbol IDs without compression. 617 * 10 means the Encoding Vector contains the compressed list of 618 the Source Symbol IDs. 620 * 11 means the Encoding Vector contains the compressed edge 621 blocks of the Source Symbol IDs. 623 o Store the Encoding Coefficients (C): 1 bit to indicate if an 624 Encoding Vector contains information about the coefficients used. 626 o Having Source Symbols with Variable Size Encoding (V): set V to 1 627 if the combination which refers to the Encoding Vector is a 628 combination of Source Symbols with variable sizes. In this case, 629 the Coded Packets MUST have the 'Encoded Payload Size' field. 631 o NB_IDS: the number of source IDs stored in the Encoding Vector 632 (depending on I). 634 o Number of coefficients (NB_COEFS): The number of the coefficients 635 used to generate the associated Coded Symbol. 637 o The first source identifier (FIRST_SOURCE_ID): the first Source 638 Symbol ID used in the combination. 640 o Number of bits for each edge block (b_id): the number of bits 641 needed to store the edge. 643 o Information about the Source Symbol IDs (id_bit_vector): if I=01, 644 store the edge blocks as b_id * (NB_IDS * 2 - 1). If I=10, store 645 in a compressed way the edge blocks. 647 o The coefficients (coef_bit_vector): The coefficients stored 648 depending on the CCGI (4 or 8 bits for each coefficient). 650 o Padding: padding to have an Encoding Vector size multiple of 651 32-bit (for the id and coefficient part). 653 The Source Symbol IDs are organized as a sorted list of 32-bit 654 unsigned integers. Depending on the feedback, the Source Symbol IDs 655 MAY be successive or not in the list. If they are successive, the 656 boundaries are stored in the Encoding Vector: it just needs 2*32-bit 657 of information. If not, the edge blocks MAY be stored directly, or a 658 differential transform to reduce the number of bits needed to 659 represent an identifier MAY be used 661 For example, the Coded Symbol 3 is a linear combination of the Source 662 Symbols 1,2,3,5,6,8,9,10 (each type of symbol has its own ID space). 663 This linear combination can be represented with only the edge blocks 664 : [1,3],[5,6],[8,10] 666 o We don't want to store the Source Symbol IDs (set I to 0b00), no 667 b_id and no id_bit_vector field 669 o We want to store the edge blocks without compression (set I to 670 0b01). In this case, set b_id to 32 (as a symbol id is 32 bits), 671 and store into id_bit_vectors the list as 32 bits unsigned 672 integers: 1,3,5,6,8,10 674 o We want to store the edge blocks with compression (set I to 0b10). 675 In this case, see the section Section 5.3.1.1 but rather than 676 compressing the edge blocks, we compress the full list of the 677 Source Symbol IDs. 679 o We want to store the edge blocks with compression (set I to 0b11) 680 In this case, see the section Section 5.3.1.1. 682 5.3.1.1. Compressed list of Source Symbol IDs 684 Assume the symbol IDs used in the combination are: 685 [1..3],[5..6],[8..10]. 687 1. Keep the first element in the packet as the first_source_id: 1. 689 2. Apply a differential transform to the other elements 690 ([3,5,6,8,10]) which removes the element i-1 to the element i, 691 starting with the first_source_id as i0, and get the list L => 692 [2,2,1,2,2] 694 3. Compute b, the number of bits needed to store all the elements, 695 which is ceil(log2(max(L))), where max(L) represents the maximum 696 of the elements of the list L: here, 2 bits. 698 4. Write b in the corresponding field, and write all the b * [(2 * 699 NB blocks) - 1] elements in a bit vector, here: 10 10 01 10 10. 701 5.3.1.2. Decompressing the Source Symbol IDs 703 When a Tetrys Decoding Block wants to reverse the operations, this 704 algorithm is used: 706 1. Rebuild the list of the transmitted elements by reading the bit 707 vector and b: [10 10 01 10 10] => [2,2,1,2,2] 709 2. Apply the reverse transform by adding successively the elements, 710 starting with first_source_id: [1,1+2,(1+2)+2,(1+2+2)+1,...] => 711 [1,3,5,6,8,10] 713 3. Rebuild the blocks using the list and first_source_id: 714 [1..3],[5..6],[8..10]. 716 5.4. Window Update Packet Format 718 A Tetrys Decoder MAY send back to another building block some Window 719 Update packets. They contain information about what the packets 720 received, decoded or dropped, and other information such as a packet 721 loss rate or the size of the decoding buffers. They are used to 722 optimize the content of the encoding window. The window update 723 packets are OPTIONAL, and hence they could be omitted or lost in 724 transmission without impacting the protocol behavior. 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | | 730 / Common Packet Header / 731 | | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | nb_missing_src | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | nb_not_used_coded_symb | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | first_src_id | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | plr | sack_size | | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 741 | | 742 / SACK Vector / 743 | | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Figure 7: Window Update Packet Format 748 Common Packet Header: a common packet header (as common header 749 format) where Packet Type=2. 751 nb_missing_src: the number of missing Source Symbols in the receiver 752 since the beginning of the session. 754 nb_not_used_coded_symb: the number of Coded Symbols at the receiver 755 that have not already been used for decoding (e.g., the linear 756 combinations contain at least 2 unknown Source Symbols). 758 first_src_id: ID of the first Source Symbol to consider in the SACK 759 vector. 761 plr: packet loss ratio expressed as a percentage normalized to a 762 8-bit unsigned integer. For example, 2.5 % will be stored as 763 floor(2.5 * 256/100) = 6. Conversely, if 6 is the stored value, the 764 corresponding packet loss ratio expressed as a percentage is 765 6*100/256 = 2.34 %. This value is used in the case of dynamic Code 766 Rate or for statistical purpose. The choice of calculation is left 767 to the Tetrys Decoder, depending on a window observation, but should 768 be the PLR seen before decoding. 770 sack_size: the size of the SACK vector in 32-bit words. For 771 instance, with value 2, the SACK vector is 64 bits long. 773 SACK vector: bit vector indicating symbols that must be removed in 774 the encoding window from the first Source Symbol ID. In most cases, 775 these symbols were received by the receiver. The other cases concern 776 some events with non-recoverable packets (for example in the case of 777 a burst of losses) where it is better to drop and abandon some 778 packets, and thus to remove them from the encoding window, to allow 779 the recovery of the following packets. The "First Source Symbol" is 780 included in this bit vector. A bit equal to 1 at the i-th position 781 means that this window update packet removes the Source Symbol of ID 782 equal to "First Source Symbol ID" + i from the encoding window. 784 6. Research Issues 786 The present document describes the baseline protocol, allowing 787 communications between a Tetrys encoder and a Tetrys decoder. In 788 practice, Tetrys can be used either as a standalone protocol or 789 embedded inside an existing protocol, and either above, within or 790 below the transport layer. All these situations raise manyfold 791 research questions to come up with a complete protocol solution, that 792 we briefly discuss hereafter. 794 6.1. Interaction with Congestion Control 796 The Tetrys and congestion control components generate two separate 797 channels (see [I-D.irtf-nwcrg-coding-and-congestion], section 2.1): 799 o the Tetrys channel carries source and Coded Packets (from the 800 sender to the receiver) and information from the receiver to the 801 sender (e.g., signaling which symbols have been recovered, loss 802 rate prior and/or after decoding, etc.); 804 o the congestion control channel carries packets from a sender to a 805 receiver, and packets signaling information about the network 806 (e.g., number of packets received versus lost, Explicit Congestion 807 Notification (ECN) marks, etc.) from the receiver to the sender. 809 In practice, depending on how Tetrys is deployed (i.e., above, within 810 or below the transport layer), [I-D.irtf-nwcrg-coding-and-congestion] 811 identifies and discusses several topics. They are briefly listed 812 below and adapted to the particular case of Tetrys: 814 o congestion related losses MAY be hidden if Tetrys is deployed 815 below the transport layer without any precaution (i.e., Tetrys 816 recovering packets lost because of a congested router), which can 817 severely impact the the congestion control efficiency. An 818 approach is suggested to avoid hiding such signals in 819 [I-D.irtf-nwcrg-coding-and-congestion], section 5; 821 o having Tetrys and non-Tetrys flows sharing the same network links 822 can raise fairness issues between these flows. The situation 823 depends in particular on whether some of these flows are 824 congestion controlled and not others, and which type of congestion 825 control is used. The details are out of scope of this document, 826 but may have major impacts in practice; 828 o coding rate adaptation within Tetrys can have major impacts on 829 congestion control if done inappropriately. This topic is 830 discussed more in detail in Section 6.2; 832 o Tetrys can leverage on multipath transmissions, the Tetrys packets 833 being sent to the same receiver through multiple paths. Since 834 paths can largely differ, a per-path flow control and congestion 835 control adaptation could be needed; 837 o protecting several application flows within a single Tetrys flow 838 raises additional questions. This topic is discussed more in 839 detail in Section 6.3. 841 6.2. Adaptive Coding Rate 843 When the network conditions (e.g., delay and loss rate) strongly vary 844 over time, an adaptive coding rate can be used to increase or reduce 845 the amount of Coded Packets among a transmission dynamically (i.e., 846 the added redundancy), with the help of a dedicated algorithm, 847 similarly to [A-FEC]. Once again, the strategy differs, depending on 848 which layer Tetrys is deployed (i.e., above, within or below the 849 transport layer). Basically, we can slice these strategies in two 850 distinct classes: when Tetrys is deployed inside the transport layer, 851 versus outside (i.e., above or below). A deployment within the 852 transport layer obviously means that interactions between transport 853 protocol micro-mechanisms, such as the error recovery mechanism, the 854 congestion control, the flow control or both, are envisioned. 855 Otherwise, deploying Tetrys within a non congestion controlled 856 transport protocol, like UDP, would not bring out any other advantage 857 than deploying it below or above the transport layer. 859 The impact deploying a FEC mechanism within the transport layer is 860 further discussed in [I-D.irtf-nwcrg-coding-and-congestion], section 861 4, where considerations concerning the interactions between 862 congestion control and coding rates, or the impact of fairness, are 863 investigated. This adaptation MAY be done jointly with the 864 congestion control mechanism of a transport layer protocol, as 865 proposed by [CTCP]. This allows the use of monitored congestion 866 control metrics (e.g., RTT, congestion events, or current congestion 867 window size) to adapt the coding rate conjointly with the computed 868 transport sending rate. The rationale is to compute an amount of 869 repair traffic that does not lead to congestion. This joint 870 optimization is mandatory to prevent flows to consume the whole 871 available capacity as also discussed in 872 [I-D.singh-rmcat-adaptive-fec] where the authors point out that an 873 increase in the repair ratio should be done conjointly with a 874 decrease in the source sending rate. 876 Finally, adapting a coding rate can also be done outside the 877 transport layer and without considering transport layer metrics. In 878 particular, this adaptation MAY be done jointly with the network as 879 proposed in [RED-FEC]. In this paper, the authors propose a Random 880 Early Detection FEC mechanism in the context of video transmission 881 over wireless networks. Briefly, the idea is to add more redundancy 882 packets if the queue at the access point is less occupied and vice 883 versa. A first theoretical attempt for video delivery has been 884 proposed [THAI] with Tetrys. This approach is interesting as it 885 illustrates a joint collaboration between the application 886 requirements and the network conditions and combines both signals 887 coming from the application needs and the network state (i.e., 888 signals below or above the transport layer). 890 To conclude, there are multiple ways to enable an adaptive coding 891 rate. However, all of them depend on: 893 o the signal metrics that can be monitored and used to adapt the 894 coding rate; 896 o the transport layer used, whether congestion controlled or not; 898 o the objective sought (e.g., to minimize congestion, or to fit 899 application requirements). 901 6.3. Using Tetrys Below The IP Layer For Tunneling 903 The use of Tetrys to protect an aggregate of flows, typically when 904 Tetrys is used for tunneling, to recover from IP datagram losses, 905 raises research questions. When redundancy is applied without flow 906 differentiation, this may come in contradiction with the service 907 requirements of individual flows, some of them may be more penalized 908 by high latency and jitter than by partial reliability, while other 909 flows may have opposite requirements. In practice head-of-line 910 blocking will impact all flows in a similar manner despite their 911 different needs, which asks for more elaborate strategies inside 912 Tetrys. Note this research issue joins the topics discussed in the 913 IRTF LOOPS working group [I-D.li-tsvwg-loops-problem-opportunities]. 915 7. Security Considerations 917 Tetrys inherits a subset of the security issues described in FECFRAME 918 [RFC8680] and in particular in sections "9.2.2. Content Corruption" 919 and "9.3. Attacks against the FEC Parameters". As an application 920 layer end-to-end protocol, security considerations of Tetrys should 921 also be comparable to those of HTTP/2 with TLS. The considerations 922 from Section 10 of HTTP2 [RFC7540] also apply in addition to those 923 listed here. 925 8. IANA Considerations 927 This document does not ask for any IANA registration. 929 9. Implementation Status 931 Editor's notes: RFC Editor, please remove this section motivated by 932 RFC 7942 before publishing the RFC. Thanks! 934 An implementation of Tetrys exists: 936 organization: ISAE-SUPAERO 938 Description: This is a proprietary implementation made by ISAE- 939 SUPAERO 941 Maturity: "production" 943 Coverage: this software implements TETRYS with some modifications 945 Licensing: proprietary 947 Implementation experience: maximum 949 Information update date: January 2022 951 Contact: jonathan.detchart@isae-supaero.fr 953 10. Acknowledgments 955 First, the authors want sincerely to thank Marie-Jose Montpetit for 956 continuous help and support on Tetrys. Marie-Jo, many thanks! 958 The authors also wish to thank NWCRG group members for numerous 959 discussions on on-the-fly coding that helped finalize this document. 961 11. References 963 11.1. Normative References 965 [I-D.irtf-nwcrg-coding-and-congestion] 966 Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding 967 and congestion control in transport", draft-irtf-nwcrg- 968 coding-and-congestion-12 (work in progress), February 969 2022. 971 [RFC2119] Bradner, S., "Keywords for use in RFCs to Indicate 972 Requirement Levels", BCP 14, RFC 2119, 973 DOI 10.17487/RFC2119, March 1997, 974 . 976 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 977 M., and J. Crowcroft, "Forward Error Correction (FEC) 978 Building Block", RFC 3452, DOI 10.17487/RFC3452, December 979 2002, . 981 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 982 "Reed-Solomon Forward Error Correction (FEC) Schemes", 983 RFC 5510, DOI 10.17487/RFC5510, April 2009, 984 . 986 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 987 Transport (LCT) Building Block", RFC 5651, 988 DOI 10.17487/RFC5651, October 2009, 989 . 991 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 992 "NACK-Oriented Reliable Multicast (NORM) Transport 993 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 994 . 996 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 997 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 998 DOI 10.17487/RFC7540, May 2015, 999 . 1001 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 1002 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 1003 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 1004 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 1005 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 1006 June 2018, . 1008 [RFC8680] Roca, V. and A. Begen, "Forward Error Correction (FEC) 1009 Framework Extension to Sliding Window Codes", RFC 8680, 1010 DOI 10.17487/RFC8680, January 2020, 1011 . 1013 11.2. Informative References 1015 [A-FEC] Bolot, J., Fosse-Parisis, S., and D. Towsley, "Adaptive 1016 FEC-based error control for Internet telephony", IEEE 1017 INFOCOM 99, pp. 1453-1460 vol. 3 DOI 1018 10.1109/INFCOM.1999.752166, 1999. 1020 [AHL-00] Ahlswede, R., Ning Cai, Li, S., and R. Yeung, "Network 1021 information flow", IEEE Transactions on Information 1022 Theory vol.46, no.4, pp.1204,1216, July 2000. 1024 [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", 1025 arXiv 1212.2291v3, 2013. 1027 [I-D.li-tsvwg-loops-problem-opportunities] 1028 Li, Y., Zhou, X., Boucadair, M., Wang, J., and F. Qin, 1029 "LOOPS (Localized Optimizations on Path Segments) Problem 1030 Statement and Opportunities for Network-Assisted 1031 Performance Enhancement", draft-li-tsvwg-loops-problem- 1032 opportunities-06 (work in progress), July 2020. 1034 [I-D.singh-rmcat-adaptive-fec] 1035 Singh, V., Nagy, M., Ott, J., and L. Eggert, "Congestion 1036 Control Using FEC for Conversational Media", draft-singh- 1037 rmcat-adaptive-fec-03 (work in progress), March 2016. 1039 [RED-FEC] Lin, C., Shieh, C., Chilamkurti, N., Ke, C., and H. Hwang, 1040 "A RED-FEC Mechanism for Video Transmission Over WLANs", 1041 IEEE Transactions on Broadcasting, vol. 54, no. 3, pp. 1042 517-524 DOI 10.1109/TBC.2008.2001713, September 2008. 1044 [Tetrys] Lacan, J. and E. Lochin, "Rethinking reliability for long- 1045 delay networks", International Workshop on Satellite and 1046 Space Communications 2008 (IWSSC08), October 2008. 1048 [Tetrys-RT] 1049 Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 1050 V. Roca, "On-the-fly erasure coding for real-time video 1051 applications", IEEE Transactions on Multimedia, Vol 13, 1052 Issue 4, August 2011 (TMM.2011), August 2011. 1054 [THAI] Tran-Thai, T., Lacan, J., and E. Lochin, "Joint on-the-fly 1055 network coding/video quality adaptation for real-time 1056 delivery", Signal Processing: Image Communication, vol. 29 1057 (no. 4), pp. 449-461 ISSN 0923-5965, 2014. 1059 Authors' Addresses 1061 Jonathan Detchart 1062 ISAE-SUPAERO 1063 10, avenue Edouard Belin 1064 BP 54032 1065 Toulouse CEDEX 4 31055 1066 France 1068 Email: jonathan.detchart@isae-supaero.fr 1070 Emmanuel Lochin 1071 ENAC 1072 7, avenue Edouard Belin 1073 Toulouse 31400 1074 France 1076 Email: emmanuel.lochin@enac.fr 1078 Jerome Lacan 1079 ISAE-SUPAERO 1080 10, avenue Edouard Belin 1081 BP 54032 1082 Toulouse CEDEX 4 31055 1083 France 1085 Email: jerome.lacan@isae-supaero.fr 1087 Vincent Roca 1088 INRIA 1089 655, avenue de l'Europe 1090 Inovallee; Montbonnot 1091 ST ISMIER cedex 38334 1092 France 1094 Email: vincent.roca@inria.fr