idnits 2.17.1 draft-heide-nwcrg-rlnc-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2019) is 1897 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3453' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC5445' is defined on line 483, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NWCRG J. Heide 3 Internet-Draft Steinwurf Aps 4 Intended status: Experimental S. Shi 5 Expires: August 19, 2019 K. Fouli 6 M. Medard 7 Code On Network Coding LLC 8 V. Chook 9 Inmarsat PLC 10 February 15, 2019 12 Random Linear Network Coding (RLNC)-Based Symbol Representation 13 draft-heide-nwcrg-rlnc-01 15 Abstract 17 This document describes a symbol representation for Random Linear 18 Network Coding (RLNC) schemes used for reliable data transfer. 19 Specifically, the following features are discussed and incorporated: 20 both block RLNC and a sliding window RLNC, varying data frame sizes, 21 and one or multiple symbols associated with a single symbol 22 representation header. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 19, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Symbol Representation . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Representation Setup . . . . . . . . . . . . . . . . . . 4 67 2.2. Field Types and Formats . . . . . . . . . . . . . . . . . 4 68 2.3. Small Encoding Window . . . . . . . . . . . . . . . . . . 7 69 2.3.1. Examples . . . . . . . . . . . . . . . . . . . . . . 8 70 2.4. Large Encoding Window . . . . . . . . . . . . . . . . . . 9 71 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 5.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 Symbol representation specifies the format of the symbol-carrying 81 data unit that is to be used in network coding operations, including 82 header format and symbol concatenation. This document describes a 83 symbol representation format intended to be used for Network Coding 84 in general, and for Random Linear Network Coding (RLNC) in particular 85 [HK03]. 87 Owing to its dynamic structure, network coding has requirements that 88 are distinct from conventional point-to-point codes, leading to a 89 highly reconfigurable symbol set. Consequently, the design choices 90 related to symbol representation are particularly important in 91 network coding as they have a direct impact on the viability of 92 network protocols, topologies, and architecture [RLNC-Background]. 93 For example, recoding [RLNC-Background] requires the coefficients to 94 be accessible at the recoding nodes. Hence, architectures and 95 protocols requiring recoding must specify coefficient location in 96 their symbol representation. 98 In addition to providing background on RLNC, [RLNC-Background] argues 99 that careful design and specification of a symbol representation is a 100 requirement for any viable network coding protocol, architecture, or 101 topology. 103 2. Symbol Representation 105 This section provides a symbol representation design for implementing 106 RLNC-based erasure correction schemes. In the decribed symbol 107 representation design, multiple symbols are concatenated and 108 associated with a single symbol representation header. 110 The symbol representation design is provided for constructing a data 111 payload portion of a data packet for a protocol that utilizes a 112 generation-based or sliding-window RLNC, where recoding can be used 113 at intermediate nodes. A data packet data payload comprises one or 114 more symbol representations. Each symbol representation in turn 115 comprises one or more symbols that can be systematic, coded or 116 recoded. The use of this symbol representation design is not limited 117 by transmission schemes. It can be applied to unicast, multiple- 118 unicast, multicast, multi-path, and multi-source settings and the 119 like. 121 Coding coefficient vectors must be implicitly or explicitly 122 transmitted from the sender to the receiver, generally along with the 123 coded data for successful decoding of the original data. One option 124 is to attach each coding coefficient vector to the corresponding 125 coded symbol as a header, thus also enabling recoding at intermediate 126 nodes. Another option is to attach the current state of a pseudo- 127 random generator for generating the coding coefficient vector, to 128 reduce the size of the header. Adding a header to each symbol may 129 result in a high overhead when the symbol size is small or when 130 generation or sliding window size is large. Adding a joint header to 131 the beginning of each generation may also cause synchronization to be 132 re-initiated only at the beginning of each generation instead of 133 every symbol. In what follows, a symbol representation is provided 134 that allow for both of these options such that both a general 135 representation with coding coefficients and a compact representation 136 with a seed for generating the coding coefficients can be used, in 137 order to reduce the header overhead. 139 2.1. Representation Setup 141 This section specifies a symbol representation that enables both a 142 general form with coding vectors attached, and a compact form where a 143 seed is attached instead for the first symbol in the symbol 144 representation, and where subsequent coding vectors are deduced from 145 the first one. Different maximum generation and window size are 146 supported for RLNC encoding, recoding, and decoding. 148 To encode over a set of data symbols, a coding vector as described in 149 Section 1.1 is first generated, comprising a number of finite field 150 elements as specified by a generation/window size variable. In the 151 case of systematic codes, systematic symbols correspond to unit 152 coding vectors. 154 Figure 1 illustrates the general symbol representation design. Four 155 header fields precede the symbol data: TYPE flag (T), SYMBOLS, 156 ENCODER RANK, and SEED or CODING COEFFICIENTS. The TYPE Flag (T) 157 indicates if the symbol is systematic, coded, or recoded. SYMBOLS 158 indicates the number of symbols in the "Symbol(s) Data" field. 159 ENCODER RANK represents the current rank of the encoder, which is the 160 number of symbols being linearly combined. SEED is used to generate 161 the coding coefficient vector(s) using a pseudo-random number 162 generator, for a compact form of the symbol representation. The 163 CODING COEFFICIENTS field is a list of SYMBOLS number of coding 164 vectors used to generate the ensuing SYMBOL(S) DATA. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | T |SYMBOLS| ENCODER RANK | SEED or CODING COEFFICIENTS | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 | SYMBOL(S) DATA | 173 | ... | 174 | | 175 +---------------------------------------------------------------+ 177 Figure 1: A general symbol representation design. 179 2.2. Field Types and Formats 181 The TYPE Flag (T) indicates if the symbol is systematic, coded, or 182 recoded, and has the following properties: 184 o 2 bits long. 186 o If the TYPE flag is '1', all symbols included in this symbol 187 representation are systematic or uncoded, with symbol index 188 starting from ENCODER RANK. This option allows for efficient 189 representation of systematic symbols. 191 o If the TYPE is '2', all symbols included in this symbol 192 representation are coded, with coding vectors generated using the 193 included SEED and the ENCODER RANK. This option allows for 194 compact and efficient representation of coded symbols, which may 195 also subsequently be recoded. 197 o If the TYPE is '3', all symbols included in this symbol 198 representation are either coded or recoded, with the coding 199 coefficients included constituting ENCODER RANK coefficients each. 201 SYMBOLS indicates the number of symbols in the "Symbol(s) Data" 202 field, and has the following properties: 204 o 4 bits long. A maximum number of 15 symbols are concatenated 205 within each symbol representation. 207 o The special case of SYMBOLS = 0 indicates that zero symbols are 208 included, and consequently the size of 'Symbol(s) Data' is 0 209 bytes. This can, for example, be used to implement a flush 210 functionality or ensure that protocol operations do not stop in 211 certain case for purely event-driven protocols. 213 ENCODER RANK represents the current rank of the encoder, and has the 214 following properties: 216 o MUST be no larger than generation/window size. 218 o If TYPE flag is '1', ENCODER RANK is the symbol index of the first 219 data symbol in this symbol representation. 221 o If TYPE flag is '2' or '3', ENCODER RANK is the number of data 222 symbols over which coding was performed for all coded symbols in 223 this symbol representation. 225 o Coded symbols can be generated before a generation or window is 226 filled. ENCODER RANK describes the number of original symbols 227 included in the coded symbol(s). 229 SEED is used to generate the coding coefficient vector(s) using a 230 pseudo-random number generator, for a compact form of the symbol 231 representation, and has the following properties: 233 o The SEED field is only present when TYPE flag is '2'. If TYPE is 234 '1' or '3', this field is absent. 236 o The pseudo-random generator MUST be seeded with this value and all 237 coding coefficient vectors are produced by the same generator. 238 For example, if ENCODER RANK is 12, then coding vector for the 239 first symbol in this symbol representation is coefficients 0 240 through 11 generated by the pseudo-random generator seeded by 241 SEED, and coding vector for the second symbol in this symbol 242 representation is coefficients 12 through 23 generated by the 243 pseudo-random generator seeded by SEED. If generation/window size 244 is larger than ENCODER RANK, the remaining coefficients in the 245 coding vector are zero. 247 o To ensure that SEED can be interpreted correctly at the receiver, 248 the same pseudo-random number generator MUST be used by the sender 249 and a recoding or receiving node. Otherwise, more than one SEED 250 field would need to be used. 252 o 8 bits long. Thus, 256 different seed values can be served. One 253 SEED is used per symbol representation, each of which can contain 254 up to 15 symbols, all derived using the same SEED. For distinct 255 ENCODER RANKs, different coding vectors would be generated from 256 the same SEED, since only an ENCODER RANK number of coefficients 257 from the random generator is grouped as a coding coefficient 258 vector, before progressing to the next coding vector for the next 259 symbol in the symbol representation. Consequently, the maximal 260 number of coded symbols that can be generated for a generation 261 is |SEED| * |SYMBOLS| * |ENCODER RANK| which in the best case is 262 (2^8)*(2^4-1)*(2^10) ~ 2^22, which for all practical 263 considerations can be considered as an infinite number of coded 264 symbols. If all coded symbols that can be represented using a 265 SEED is exhausted, symbols where the coding vectors is included 266 can be sent instead. 268 o In the case where no random number generator is available, or 269 where its use is not desired, the coding coefficients can be 270 produced by other means, such as functions of the data, state of 271 the network, or the like, and transmitted explicitly by setting 272 the TYPE flag to '3'. 274 CODING COEFFICIENTS field is a list of SYMBOLS number of coding 275 vectors used to generate the ensuing SYMBOL(S) DATA, and has the 276 following properties: 278 o The CODING COEFFICIENT field is only present when TYPE flag is 279 '3'. If TYPE is '1' or '2', this field is absent. 281 o Each coding vector comprises ENCODER RANK number of coding 282 coefficients, each coding coefficient having a predetermined field 283 size. 285 2.3. Small Encoding Window 287 In a first small encoding window symbol representation, ENCODER RANK 288 is 10 bits long, and the maximum generation/window size is 2^10. 290 Figures 2 to 4 below illustrate systematic, coded, and recoded symbol 291 representations within an encoding window of size 2^10. Systematic 292 symbols are uncoded. Coded symbols are compact in form and comprise 293 a seed for coding coefficient generation. Recoded symbols are 294 general in form and comprise the coding coefficient vectors 295 explicitly. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | 1 |SYMBOLS| ENCODER RANK | SYMBOL(S) DATA | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 | SYMBOLS(S) DATA continued | 304 | ... | 305 | | 306 +---------------------------------------------------------------+ 308 Figure 2: A systematic symbol representation. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | 2 |SYMBOLS| ENCODER RANK | SEED |SYMBOL(S) DATA | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 | SYMBOL(S) DATA continued | 317 | ... | 318 | | 319 +---------------------------------------------------------------+ 321 Figure 3: A compact, coded symbol representation. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | 3 |SYMBOLS| ENCODER RANK | CODING COEFFICIENTS | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 | CODING COEFFICIENTS continued | 330 | ... | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | | 334 | SYMBOL(S) DATA | 335 | ... | 336 | | 337 +---------------------------------------------------------------+ 339 Figure 4: A recoded symbol representation. 341 2.3.1. Examples 343 The following examples show different symbol representations for an 344 illustrative case where the symbol size is 2 bytes, generation/window 345 size is 8, and field size is 2^8. 347 Example 1: Three systematic symbols with ID 0, 1 and 2. As the TYPE 348 flag is '1' , SEED/CODING COEFFICIENTS is absent, and ENCODER RANK is 349 the symbol index of the first data symbol with ID 0 in this compact 350 symbol representation. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | 1 | 3 | 0 | Systematic Symbol 0 Data | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Systematic Symbol 1 Data | Systematic Symbol 2 Data | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Figure 5: A symbol representation with 3 systematic, uncoded symbols. 362 Example 2: Two coded symbols using a compact representation. In this 363 example, TYPE is '2', the SEED to the pseudo-random number generator 364 shared by the sender and receiver is 4. The coding vector for Symbol 365 A is coefficients 0 to 7 generated by the pseudo-random number 366 generator, the coding vector for symbol B is coefficients 8 to 15 367 generated by the pseudo-random number generator. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | 2 | 2 | 8 | 4 | Coded Symbol A 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Data | Coded Symbol B Data | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 6: A symbol representation with 2 coded symbols. 379 Example 3: Two recoded symbols. Coefficients A0 to A7 constitute the 380 coding vector for Symbol A, coefficients B0 to B7 constitute the 381 coding vector for symbol B. In practical implementations, symbol 382 sizes are much larger than 2, leading to amortization of the coding 383 coefficient overheads. 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | 3 | 2 | 8 | A0 | A1 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | A2 | A3 | A4 | A5 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | A6 | A7 | B0 | B1 | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | B2 | B3 | B4 | B5 | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | B6 | B7 | Coded Symbol A Data | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Coded Symbol B Data | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Figure 7: A symbol representation with 2 recoded symbols having 402 coding coefficients attached. 404 2.4. Large Encoding Window 406 In a second large encoding window symbol representation, ENCODER RANK 407 is 18-bit long, and the maximum generation/window size is 2^18. 409 Figures 8 to 10 below illustrate systematic, coded, and recoded 410 symbol representations within an encoding window of size 2^18. 411 Systematic symbols are uncoded. Coded symbols are compact in form 412 and comprise a seed for coding coefficient generation. Recoded 413 symbols are general in form and comprise the coding coefficient 414 vectors explicitly (CODING COEFFICIENTS or CODING COEFFS). 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | 1 |SYMBOLS| ENCODER RANK |SYMBOL(S) DATA | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 | SYMBOL(S) DATA continued | 423 | ... | 424 | | 425 +---------------------------------------------------------------+ 427 Figure 8: A systematic symbol representation. 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | 2 |SYMBOLS| ENCODER RANK | SEED | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | | 435 | SYMBOL(S) DATA | 436 | ... | 437 | | 438 +---------------------------------------------------------------+ 440 Figure 9: A coded symbol representation. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | 3 |SYMBOLS| ENCODER RANK | CODING COEFFS | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | 448 | CODING COEFFICIENTS continued | 449 | ... | 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 | SYMBOL(S) DATA | 454 | ... | 455 | | 456 +---------------------------------------------------------------+ 458 Figure 10: A recoded symbol representation. 460 3. Security Considerations 462 This document does not present new security considerations. 464 4. IANA Considerations 466 This document has no actions for IANA. 468 5. References 470 5.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 478 M., and J. Crowcroft, "The Use of Forward Error Correction 479 (FEC) in Reliable Multicast", RFC 3453, 480 DOI 10.17487/RFC3453, December 2002, 481 . 483 [RFC5445] Watson, M., "Basic Forward Error Correction (FEC) 484 Schemes", RFC 5445, DOI 10.17487/RFC5445, March 2009, 485 . 487 [RLNC-Background] 488 Heide, J., Shi, S., Fouli, K., Medard, M., and V. Chook, 489 "Random Linear Network Coding (RLNC): Background and 490 Practical Considerations", February 2018, 491 . 494 5.2. Informative References 496 [HK03] Ho, T., Koetter, R., Medard, M., Karger, D., and M. 497 Effros, "The Benefits of Coding over Routing in a 498 Randomized Setting", July 2003, 499 . 501 Authors' Addresses 502 Janus Heide 503 Steinwurf Aps 504 Aalborg 505 Denmark 507 Email: janus@steinwurf.com 509 Shirley Shi 510 Code On Network Coding LLC 511 Cambridge 512 USA 514 Email: xshi@alum.mit.edu 516 Kerim Fouli 517 Code On Network Coding LLC 518 Cambridge 519 USA 521 Email: fouli@codeontechnologies.com 523 Muriel Medard 524 Code On Network Coding LLC 525 Cambridge 526 USA 528 Email: muriel.medard@codeontechnologies.com 530 Vince Chook 531 Inmarsat PLC 532 London 533 United Kingdom 535 Email: Vince.Chook@inmarsat.com