idnits 2.17.1 draft-heide-nwcrg-rlnc-background-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 11, 2019) is 1898 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-heide-nwcrg-rlnc-00 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: Informational S. Shi 5 Expires: August 15, 2019 K. Fouli 6 M. Medard 7 Code On Network Coding LLC 8 V. Chook 9 Inmarsat PLC 10 February 11, 2019 12 Random Linear Network Coding (RLNC): Background and Practical 13 Considerations 14 draft-heide-nwcrg-rlnc-background-00 16 Abstract 18 This document describes the use of Random Linear Network Coding 19 (RLNC) schemes for reliable data transport. Both block and sliding 20 window RLNC code implementations are described. By providing erasure 21 correction using randomly generated repair symbols, such RLNC-based 22 schemes offer advantages in accommodating varying frame sizes and 23 dynamically changing connections, reducing the need for feedback, and 24 lowering the amount of state information needed at the sender and 25 receiver. The practical considerations' section identifies RLNC- 26 encoded symbol representation as a valuable target for 27 standardization. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 15, 2019. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Random Linear Network Coding (RLNC) Basics . . . . . . . 3 70 1.2. Generation-Based RLNC . . . . . . . . . . . . . . . . . . 5 71 1.3. Sliding Window RLNC . . . . . . . . . . . . . . . . . . . 7 72 1.4. Recoding . . . . . . . . . . . . . . . . . . . . . . . . 8 73 2. Practical Considerations . . . . . . . . . . . . . . . . . . 9 74 2.1. Symbol Representation . . . . . . . . . . . . . . . . . . 9 75 2.1.1. Symbol Representation as a Standardization Approach . 9 76 2.1.2. Coding Parameter Design Considerations . . . . . . . 12 77 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 5.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 Network Coding is a coding discipline that jointly improves network 87 reliability and efficiency. In general communication networks, 88 source coding is performed as a compression mechanism to reduce data 89 redundancy and to reduce resources necessary for data transportation 90 over the network. Channel coding, on the other hand, introduces 91 redundancy for data transmission reliability over lossy channels. 92 Network coding adds another layer of coding in-between these two. 93 Random Linear Network Coding (RLNC) is an efficient network coding 94 approach that enables network nodes to generate independently and 95 randomly linear mappings of input to output data symbols over a 96 finite field. 98 This document provides background on RLNC operation. The document 99 also includes an open section for practical considerations where 100 topics such as standardization and RLNC-encoded symbol 101 representations are addressed. 103 1.1. Random Linear Network Coding (RLNC) Basics 105 Unlike conventional communication systems based on the "store-and- 106 forward" principle, RLNC allows network nodes to independently and 107 randomly combine input source data into coded symbols over a finite 108 field [HK03]. Such an approach enables receivers to decode and 109 recover the original source data as long as enough linearly 110 independent coded symbols, with sufficient degrees of freedom, are 111 received. At the sender, RLNC can introduce redundancy into data 112 streams in a granular way. At the receiver, RLNC enables progressive 113 decoding and reduces feedback necessary for retransmission. 114 Collectively, RLNC provides network utilization and throughput 115 improvements, high degrees of robustness and decentralization, 116 reduces transmission latency, and simplifies feedback and state 117 management. 119 To encode using RLNC, original source data are divided into symbols 120 of a given size and linearly combined. Each symbol is multiplied 121 with a scalar coding coefficient drawn randomly from a finite field, 122 and the resulting coded symbol is of the same size as the original 123 data symbols. 125 Thus, each RLNC encoding operation can be viewed as creating a linear 126 equation in the data symbols, where the random scalar coding 127 coefficients can be grouped and viewed as a coding vector. 128 Similarly, the overall encoding process where multiple coded symbols 129 are generated can be viewed as a system of linear equations with 130 randomly generated coefficients. Any number of coded symbols can be 131 generated from a set of data symbols, similarly to expandable forward 132 error correction codes specified in [RFC5445] and [RFC3453]. Coding 133 vectors must be implicitly or explicitly transmitted from the sender 134 to the receiver for successful decoding of the original data. For 135 example, sending a seed for generating pseudo-random coding 136 coefficients can be considered as an implicit transmission of the 137 coding vectors. In addition, while coding vectors are often 138 transmitted together with coded data in the same data packet, it is 139 also possible to separate the transmission of coding coefficient 140 vectors from the coded data, if desired. 142 To reconstruct the original data from coded symbols, a network node 143 collects a finite but sufficient number of degrees of freedom for 144 solving the system of linear equations. This is beneficial over 145 conventional approaches as the network node is no longer required to 146 gather each individual data symbol. In general, the network node 147 needs to collect slightly more independent coded symbols than there 148 are original data symbols, where the slight overhead arises because 149 coding coefficients are drawn at random, with a non-zero probability 150 that a coding vector is linearly dependent on another coding vector, 151 and that one coded symbol is linearly dependent on another coded 152 symbol. This overhead can be made arbitrarily small, provided that 153 the finite field used is sufficiently large. 155 A unique advantage of RLNC is the ability to re-encode or "recode" 156 without first decoding. Recoding can be performed jointly on 157 existing coded symbols, partially decoded symbols, or uncoded 158 systematic data symbols. This feature allows intermediate network 159 nodes to re-encode and generate new linear combinations on the fly, 160 thus increasing the likelihood of innovative transmissions to the 161 receiver. Recoded symbols and recoded coefficient vectors have the 162 same size as before and are indistinguishable from the original coded 163 symbols and coefficient vectors. 165 In practical implementations of RLNC, the original source data are 166 often divided into multiple coding blocks or "generations" where 167 coding is performed over each individual generation to lower the 168 computational complexity of the encoding and decoding operations. 169 Alternatively, a convolutional approach can be used, where coding is 170 applied to overlapping spans of data symbols, possibly of different 171 spanning widths, viewed as a sliding coding window. In generation- 172 based RLNC, not all symbols within a single generation need to be 173 present for coding to start. Similarly, a sliding window can be 174 variable-sized, with more data symbols added to the coding window as 175 they arrive. Thus, innovative coded symbols can be generated as data 176 symbols arrive. This "on-the-fly" coding technique reduces coding 177 delays at transmit buffers, and together with rateless encoding 178 operations, enables the sender to start emitting coded packets as 179 soon as data is received from an upper layer in the protocol stack, 180 adapting to fluctuating incoming traffic flows. Injecting coded 181 symbols based on a dynamic transmission window also breaks the 182 decoding delay lower bound imposed by traditional block codes and is 183 well suited for delay-sensitive applications and streaming protocols. 185 When coded symbols are transmitted through a communication network, 186 erasures may occur, depending on channel conditions and interactions 187 with underlying transport protocols. RLNC can efficiently repair 188 such erasures, potentially improving protocol response to erasure 189 events to ensure reliability and throughput over the communication 190 network. For example, in a point-to-point connection, RLNC can 191 proactively compensate for packet erasures by generating Forward 192 Erasure Correcting (FEC) redundancy, especially when a packet erasure 193 probability can be estimated. As any number of coded symbols may be 194 generated from a set of data symbols, RLNC is naturally suited for 195 adapting to network conditions by adjusting redundancy dynamically to 196 fit the level of erasures, and by updating coding parameters during a 197 session. Alternatively, packet erasures may be repaired reactively 198 by using feedback requests from the receiver to the sender, or by a 199 combination of FEC and retransmission. RLNC simplifies state and 200 feedback management and coordination as only a desired number of 201 degrees of freedom needs to be communicated from the receiver to the 202 sender, instead of indications of the exact packets to be 203 retransmitted. The need to exchange packet arrival state information 204 is therefore greatly reduced in feedback operations. 206 The advantages of RLNC in state and feedback management are apparent 207 in a multicast setting. In this one-to-many setup, uncorrelated 208 losses may occur, and any retransmitted data symbol is likely to 209 benefit only a single receiver. By comparison, a transmitted RLNC 210 coded symbol is likely to carry a new degree of freedom that may 211 correct different errors at different receivers simultaneously. 212 Similarly, RLNC offers advantages in coordinating multiple paths, 213 multiple sources, mesh networking and cooperation, and peer-to-peer 214 operations. 216 A more detailed introduction to network coding including RLNC is 217 provided in the books [MS11] and [HL08]. 219 1.2. Generation-Based RLNC 221 This section describes a generation-based RLNC scheme. 223 In generation-based RLNC, input data as received from an upper layer 224 in the protocol stack is segmented into equal-sized blocks, denoted 225 as generations, and each generation is further segmented into equal- 226 sized data symbols for encoding, with paddings added when necessary. 227 Encoding and decoding are performed over each individual generation. 228 Figure 1 below provides an illustrative example where each generation 229 includes four data symbols, and a systematic RLNC code is generated 230 with rate 2/3. 232 Data Symbols: 233 Generation-1 Generation-2 234 +============================++============================+ 235 | +---+ +---+ +---+ +---+ || +---+ +---+ +---+ +---+ | 236 | | 1 | | 2 | | 3 | | 4 | || | 5 | | 6 | | 7 | | 8 | | ... 237 | +---+ +---+ +---+ +---+ || +---+ +---+ +---+ +---+ | 238 +============================++============================+ 239 | | 240 | | 241 Systematic | | 242 Symbols: V V 243 +---++---++---++---++---++---+ +---++---++---++---++---++---+ 244 | 1 || 2 || 3 || 4 || C1|| C2| | 5 || 6 || 7 || 8 || C3|| C4| ... 245 +---++---++---++---++---++---+ +---++---++---++---++---++---+ 247 Figure 1: Generation-based RLNC with rate 2/3, systematic encoding 248 performed on data symbols within each generation. 250 Symbols can be of any size, although symbol sizes typically depend on 251 application or system specifications. In scenarios with highly 252 varying input data frame sizes, a small symbol size may be desirable 253 for achieving flexibility and transmission efficiency, with one or 254 more symbols concatenated to form a coded data packet. In this 255 context, existing basic FEC schemes [RFC5445] do not support the use 256 of a single header for multiple coded symbols, whereas the symbol 257 representation design as described in [Symbol-Representation] 258 provides this option. 260 For any protocol that utilizes generation-based RLNC, a setup process 261 is necessary for establishing a connection and conveying coding 262 parameters from the sender to the receiver. Such coding parameters 263 can include one or more of field size, code specifications, index of 264 the current generation being encoded at the sender, generation size, 265 code rate, and desired feedback frequency or probability. Some 266 coding parameters are updated dynamically during the transmission 267 process, reflecting the coding operations over sequences of 268 generations, and adjusting to channel conditions and resource 269 availability. For example, an outer header can be added to the 270 symbol representation specified in [Symbol-Representation] to 271 indicate the current generation encoded within the symbol 272 representation. Such information is essential for proper recoding 273 and decoding operations, but the exact design of the outer header is 274 outside the scope of the current document. At the minimum, an outer 275 header should indicate the current generation, generation size, 276 symbol size, and field size. Section 2 provides a detailed 277 discussion of coding parameter considerations. 279 1.3. Sliding Window RLNC 281 This section describes a sliding-window RLNC scheme. Sliding window 282 RLNC was first described in [SS09]. 284 In sliding-window RLNC, input data as received from an upper layer in 285 the protocol stack is segmented into equal-sized data symbols for 286 encoding. In some implementations, the sliding encoding window can 287 expand in size as new data packets arrive, until it is closed off by 288 an explicit instruction, such as a feedback message that re-initiates 289 the encoding window. In some implementations, the size of the 290 sliding encoding window is upper bounded by some parameter, fixed or 291 dynamically determined by online behavior such as packet loss or 292 congestion estimation. Figure 3 below provides an example of a 293 systematic finite sliding window code with rate 2/3. 295 Data Symbols: 296 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 297 | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 | | 8 | ... 298 +--- +---+ +---+ +---+ +---+ +---+ +---+ +---+ 299 | C1 | | | | 300 +==========+ | | | 301 | C2 | | | 302 +========================+ | | 303 | C3 | | 304 +========================+ | 305 | C4 | 306 +========================+ ... 307 | 308 | 309 Systematically | 310 Coded Symbols: V 311 +---++---++---++---++---++---++---++---++---++---++---++---+ 312 | 1 || 2 || C1|| 3 || 4 || C2|| 5 || 6 || C3|| 7 || 8 || C4|... 313 +---++---++---++---++---++---++---++---++---++---++---++---+ 315 Figure 3: Finite sliding-window RLNC with code rate 2/3, systematic 316 encoding performed on data symbols within the sliding coding window. 318 For any protocol that utilizes sliding-window RLNC, a setup process 319 is necessary for establishing a connection and conveying coding 320 parameters from the sender to the receiver. Such coding parameters 321 can include one or more of field size, code specifications, symbol 322 ordering, encoding window position, encoding window size, code rate, 323 and desired feedback frequency or probability. Some coding 324 parameters can also be updated dynamically during the transmission 325 process in accordance to channel conditions and resource 326 availability. For example, an outer header can be added to the 327 symbol representation specified in [Symbol-Representation] to 328 indicate an encoding window position, as a starting index for current 329 data symbols being encoded within the symbol representation. Again, 330 such information is essential for proper recoding and decoding 331 operations, but the exact design of the outer header is outside the 332 scope of the current document. At the minimum, an outer header 333 should indicate the current encoding window position, encoding window 334 size, symbol size, and field size. Section 2 provides a detailed 335 discussion of coding parameter considerations. 337 Once a connection is established, RLNC coded packets comprising one 338 or more coded symbols are transmitted from the sender to the 339 receiver. The sender can transmit in either a systematic or coded 340 fashion, with or without receiver feedback. In progressive decoding 341 of RLNC coded symbols, the notion of "seen" packets can be utilized 342 to provide degree of freedom feedbacks. Seen packets are those 343 packet that have contributed to a received coded packet, where 344 generally the oldest such packet that has yet to be declared seen is 345 declared as seen [SS09]. 347 1.4. Recoding 349 Recoding is the process where coded or partially decoded symbols are 350 re-encoded without first being fully decoded. To recode, both coded 351 symbols and corresponding coding coefficient vectors are linearly 352 combined, respectively, with new randomly generated recoding 353 coefficients. Recoded symbols and recoded coefficient vectors 354 generally have the same size as before and are indistinguishable from 355 the original coded symbols and coding coefficient vectors. Recoding 356 is typically performed at intermediate network nodes, in either an 357 intra-session or an inter-session fashion. Intra-session coding 358 refers to coding between packets of the same flow or session, while 359 inter-session coding refers to combination of packets from different 360 flows or sessions in a network. 362 As recoding requires the same operations on the coding coefficient 363 vectors as applied to the coded symbols, coding coefficients must be 364 updated by recoding coefficients. This is generally achieved by 365 having the coding coefficients accessible at recoding nodes so that 366 they may be updated. Thus, either the original coding coefficients 367 or reversible representations of the coding coefficients need to be 368 communicated from upstream nodes to the recoding nodes. 370 2. Practical Considerations 372 This is an open section describing various practical considerations 373 such as standardization approaches and implementation-related topics. 375 2.1. Symbol Representation 377 This sub-section argues for the specification of symbol 378 representation as a starting point for network coding standardization 379 and provides relevant coding parameter design considerations. 381 2.1.1. Symbol Representation as a Standardization Approach 383 Symbol representation specifies the format of the symbol-carrying 384 data unit that is to be coded, recoded, and decoded. In other words, 385 symbol representation defines the format of the coding-layer data 386 unit, including header format and symbol concatenation. 388 Network Coding has fundamentally different requirements from 389 conventional point-to-point codes. Network coding owes its distinct 390 requirements to its dynamic structure, leading to a highly 391 reconfigurable symbol set. For example: 393 o Coefficient Location: RLNC's encoding, recoding, and decoding 394 process requires coefficients and payload to go through identical 395 coding operations. These operations are independent from the 396 location of the coefficients. As a consequence, coefficient 397 location is flexible. While some designs cluster coefficients 398 together, other designs may distribute them throughout the payload 399 in a manner that is specific to a given protocol. [SS09] 401 o Number of coefficients: RLNC is designed to allow coding and 402 recoding even when the number of input symbols is dynamic, leading 403 to varying code density. As a consequence, the number of 404 coefficients and source data symbols need not be fixed. 406 o Payload Size: Although an identical size of symbols is desirable 407 when performing coding operations, padding and fragmentation are 408 viable not only at the source but also throughout the network, as 409 illustrated in the example of Figure 5. This allows flexibility 410 in the payload size. 412 o Field: Although the finite field is typically a fixed system 413 variable, this is not necessarily the case. Network coding need 414 not specify a single field for all payload components, as 415 different symbols may belong to different fields (e.g., packet 416 concatenation). This feature does not necessarily complicate 417 coding, since finite field operations defined in a given field are 418 typically valid in multiple other fields. 420 Useful symbol representations should include provisions for the major 421 coding functions that are relevant to the application, such as 422 recoding, feedback, or inter-session network coding. For example, 423 recoding requires the coefficients to be accessible at the 424 intermediate recoding nodes. Hence, architectures and protocols 425 requiring recoding must specify coefficient location. 427 Furthermore, the example of Figure 4 illustrates how the knowledge of 428 coefficient location affects the way a coded payload is fragmented, 429 coded, and transported across the network. 431 (a) Code-aware fragmentation 432 +---+---------+ 433 | C | D1 | 434 +---+---------+---------+ +---+---------+ 435 | C | D1 | D2 | +----> 436 +---+---------+---------+ +---+---------+ 437 | C | D2 | 438 +---+---------+ 440 (b) Conventional fragmentation 441 +-----------+ 442 | D1 | 443 +-----------+-----------+ +-----------+ 444 | D1 | D2 | +----> 445 +-----------+-----------+ +-----------+ 446 | D2 | 447 +-----------+ 449 Figure 4: Network operations such as fragmentation may be affected by 450 symbol representation. For example, whether coefficient location is 451 (a) specified or (b) hidden may affect the way fragmentation is 452 carried out. 454 In Figure 4 (a), coefficient locations are known, allowing the 455 association of the coefficient set C to both fragments D1 and D2 of 456 original payload. The ability to manipulate the original 457 coefficients allows the newly formed packets to be recoded and 458 decoded at the same coding layer. Figure 4 (b) shows a case where 459 the coding coefficient location are unknown. This may occur when the 460 file is pre-coded by a higher layer such as the application layer, or 461 when coefficients are deliberately hidden for security reasons, 462 leading to typical fragmentation without coefficient replication. 464 The absence of information on coefficient location has important 465 implications. One such implication is that any additional coding 466 needs to be carried out within a new coding layer, potentially 467 leading to higher computational and transport overheads. 469 The elements discussed above demonstrate that the design choices 470 related to symbol representation have a direct impact on the 471 viability of protocols, topologies, and architecture. The importance 472 of symbol representation is illustrated in Figure 5, where the term 473 "architecture" includes coding architecture (e.g., generation or 474 sliding window), the layer placement of coding operations, and coding 475 objectives (e.g., erasure correction, multisourcing, etc.). 477 +---------------+ 478 |Architecture | 479 | | Symbol 480 | | Representation 481 | | 482 +-------------------+ | ^ 483 |Topology | | | | 484 | | +-------------------+ | 485 | | |----| | | | 486 | | |----| <----------------+ 487 | | |----| | | 488 | +---------------+ | 489 | | | | 490 +-------------------+ | 491 | | 492 | Protocol| 493 +-------------------+ 495 Figure 5: The specification of symbol representation has major 496 implications on system architecture, topology, and protocol. 498 Since symbol representation has implications on core design elements, 499 it is expected that coding implementations that share protocol, 500 architecture, and topology elements are likely to reuse the same 501 symbol representation. For example, implementations with security 502 requirements can reuse a common symbol representation that hides 503 coefficient locations. 505 Another example can be found in [Symbol-Representation], which 506 specifies symbol representation designs for generation-based and 507 sliding window RLNC implementations. These designs introduce highly 508 reusable formats that concatenate multiple symbols and associate them 509 with a single symbol representation header. 511 2.1.2. Coding Parameter Design Considerations 513 For any protocol that utilizes generation-based or sliding-window 514 RLNC, several coding parameters must be communicated from the sender 515 to the receiver as part of the protocol design. Without elaborating 516 on all such parameters, this section examines those essential for 517 symbol representation design, including field size, symbol size, 518 maximum number of symbols, and maximum generation or window size. 520 As RLNC is performed over a finite field, field size determines the 521 complexity of the required mathematical computations. Larger field 522 sizes translate to higher probability of successful decoding, as 523 randomly generated coding coefficient vectors are more likely to be 524 independent from each other. However, larger field sizes may also 525 result in higher computational complexity, leading to longer decoding 526 latency, higher energy usage, and other hardware requirements for 527 both the encoder and the decoder. A finite field size of 2 or the 528 binary Finite Field FF(2) should always be supported since addition, 529 multiplication, and division over FF(2) are equivalent to elementary 530 XOR, AND, and IDENTITY operations respectively. It is also desirable 531 to support a field size of 2^8, corresponding to a single byte, and 532 where operations are performed over the binary extension field 533 FF(2^8) with polynomial x^8+x^4+x^3+x^2+1. 535 The choice of symbol size typically depends on the application or 536 system specification. For example, a symbol size may be chosen based 537 on the size of a maximum transmission unit (MTU) so that datagrams 538 are not fragmented as they traverse a network, while also ensuring no 539 symbol bits are unnecessarily wasted. A symbol representation design 540 can be flexible and accommodate any symbol size in bytes. For 541 example, an IP packet is typically in the range between 500 and 1500 542 bytes, while a much smaller datagram having a size of 90 bytes may be 543 used by satellite communication networks. The symbol representation 544 in [Symbol-Representation] can be configured to support either or 545 both cases in different implementations. 547 The generation size or coding window size is a tradeoff between the 548 strength of the code and the computational complexity of performing 549 the coding operations. With a larger generation/window size, fewer 550 generations or coding windows are needed to enclose a data message of 551 a given size, thus reducing protocol overhead for coordinating 552 individual generations or coding windows. In addition, a larger 553 generation/window size increases the likelihood that a received coded 554 symbol is innovative with respect to previously received symbols, 555 thus amortizing retransmission or FEC overheads. Conversely, when 556 coding coefficients are attached, larger generation/window sizes also 557 lead to larger overheads per packet. The generation/window size to 558 be used can be signaled between the sender and receiver when the 559 connection is first established. 561 Lastly, to successfully decode RLNC coded symbols, sufficient degrees 562 of freedom are required at the decoder. The maximum number of 563 redundant symbols that can be transmitted is therefore limited by the 564 number of linearly independent coding coefficient vectors that can be 565 supported by the system. For example, if coding vectors are 566 constructed using a pseudo-random generator, the maximum number of 567 redundant symbols that can be transmitted is limited by the number of 568 available generator states.[RFC5445] 570 3. Security Considerations 572 This document does not present new security considerations. 574 4. IANA Considerations 576 This document has no actions for IANA. 578 5. References 580 5.1. Normative References 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, 584 DOI 10.17487/RFC2119, March 1997, 585 . 587 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 588 M., and J. Crowcroft, "The Use of Forward Error Correction 589 (FEC) in Reliable Multicast", RFC 3453, 590 DOI 10.17487/RFC3453, December 2002, 591 . 593 [RFC5445] Watson, M., "Basic Forward Error Correction (FEC) 594 Schemes", RFC 5445, DOI 10.17487/RFC5445, March 2009, 595 . 597 [Symbol-Representation] 598 Heide, J., Shi, S., Fouli, K., Medard, M., and V. Chook, 599 "Random Linear Network Coding (RLNC)-Based Symbol 600 Representation", February 2018, 601 . 604 5.2. Informative References 606 [HK03] Ho, T., Koetter, R., Medard, M., Karger, D., and M. 607 Effros, "The Benefits of Coding over Routing in a 608 Randomized Setting", July 2003, 609 . 611 [HL08] Ho, T. and D. Lun, "Network Coding: An Introduction", 612 April 2008. 614 [MS11] Medard, M. and A. Sprintson, "Network Coding: Fundamentals 615 and Applications", October 2011. 617 [SS09] Sundararajan, J., Shah, D., Medard, M., Mitzenmacher, M., 618 and J. Barros, "Network Coding Meets TCP", April 2009, 619 . 621 Authors' Addresses 623 Janus Heide 624 Steinwurf Aps 625 Aalborg 626 Denmark 628 Email: janus@steinwurf.com 630 Shirley Shi 631 Code On Network Coding LLC 632 Cambridge 633 USA 635 Email: xshi@alum.mit.edu 637 Kerim Fouli 638 Code On Network Coding LLC 639 Cambridge 640 USA 642 Email: fouli@codeontechnologies.com 643 Muriel Medard 644 Code On Network Coding LLC 645 Cambridge 646 USA 648 Email: muriel.medard@codeontechnologies.com 650 Vince Chook 651 Inmarsat PLC 652 London 653 United Kingdom 655 Email: Vince.Chook@inmarsat.com