idnits 2.17.1 draft-roca-tsvwg-rlc-fec-scheme-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 == Line 459 has weird spacing: '...air_key key...' -- The document date (February 7, 2017) is 2635 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG V. Roca 3 Internet-Draft INRIA 4 Intended status: Standards Track February 7, 2017 5 Expires: August 11, 2017 7 Random Linear Codes (RLC) Forward Error Correction (FEC) Scheme for 8 FECFRAME 9 draft-roca-tsvwg-rlc-fec-scheme-00 11 Abstract 13 This document describes a fully-specified FEC scheme for the 14 convolutional Random Linear Codes (RLC) over GF(2^^m), where m equals 15 1 (binary case), 4 or 8, that can be used to protect arbitrary media 16 streams along the lines defined by FECFRAME extended to convolutional 17 codes. These convolutional FEC codes rely on an encoding window that 18 slides over the source symbols, generating new repair symbols 19 whenever needed. Compared to block FEC codes, these convolutional 20 FEC codes offer key advantages in terms of reduced FEC-related 21 latency while often providing improved erasure recovery capabilities. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 11, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Limits of Block Codes with Real-Time Flows . . . . . . . 3 59 1.2. Lower Latency and Better Protection with RLC 60 Convolutional Codes . . . . . . . . . . . . . . . . . . . 3 61 1.3. Small Transmission Overheads with the RLC FEC Scheme . . 4 62 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 63 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5 64 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. RLC parameters derivation . . . . . . . . . . . . . . . . 6 66 3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 7 67 3.3. Encoding Window Management . . . . . . . . . . . . . . . 8 68 3.4. Pseudo-Random Number Generator . . . . . . . . . . . . . 9 69 3.5. Coding Coefficients Generation Function . . . . . . . . . 10 70 4. RLC FEC Scheme for Arbitrary ADU Flows . . . . . . . . . . . 12 71 4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12 72 4.1.1. FEC Framework Configuration Information . . . . . . . 12 73 4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 13 74 4.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13 75 4.1.4. Additional Procedures . . . . . . . . . . . . . . . . 14 76 5. FEC Code Specification . . . . . . . . . . . . . . . . . . . 15 77 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 8. Operations and Management Considerations . . . . . . . . . . 16 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 84 11.2. Informative References . . . . . . . . . . . . . . . . . 16 85 Appendix A. Decoding Beyond Maximum Latency Optimization . . . . 18 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 Application-Level Forward Erasure Correction (AL-FEC) codes are a key 91 element of telecommunication systems. They are used to recover from 92 packet erasures during content delivery sessions to a large number of 93 receivers (multicast/broadcast transmissions). This is the case with 94 the FLUTE/ALC protocol [RFC6726] in case of reliable file transfers 95 over lossy networks, and the FECFRAME protocol for reliable 96 continuous media transfers over lossy networks. 98 The present document focusses only on the FECFRAME protocol, used in 99 multicast/broadcast delivery mode, with contents that feature 100 stringent real-time constraints: each source packet has a maximum 101 validity period after which it will not be considered by the 102 destination application. 104 1.1. Limits of Block Codes with Real-Time Flows 106 With FECFRAME, there is a single FEC encoding point (either a end- 107 host/server (source) or a middlebox) and a single FEC decoding point 108 (either a end-host (receiver) or middlebox). In this context, 109 currently standardized AL-FEC codes for FECFRAME like Reed-Solomon 110 [RFC6865], LDPC-Staircase [RFC6816], or Raptor/RaptorQ, are all 111 linear block codes: they require the data flow to be segmented into 112 blocks of a predefined maximum size. The block size is a balance 113 between robustness (in particular in front of long erasure bursts for 114 which there is an incentive to increase the block size) and maximum 115 decoding latency (for which there is an incentive to decrease the 116 block size). Therefore, with a multicast/broadcast session, the 117 block code is dimensioned by considering the worst communication 118 channel one wants to support, and this choice impacts all receivers, 119 no matter their individual channel quality. 121 1.2. Lower Latency and Better Protection with RLC Convolutional Codes 123 This document introduces a fully-specified FEC scheme that follows a 124 totally different approach: the Random Linear Codes (RLC) over 125 GF(2^^m), where m equals 1, 4 or 8. This FEC scheme is used to 126 protect arbitrary media streams along the lines defined by FECFRAME 127 extended to convolutional codes [fecframe-ext]. This FEC scheme is 128 extremmely efficient in case of media with real-time constraints, 129 sent within a multicast/broadcast session. 131 The RLC codes belong to the broad class of convolutional AL-FEC 132 codes. The encoding process is based on an encoding window that 133 slides over the set of source packets (in fact source symbols as we 134 will see in Section 3.2), and which is either of fixed or variable 135 size (elastic window). Repair packets (symbols) are generated and 136 sent on-the-fly, after computing a random linear combination of the 137 source symbols present in the current encoding window. 139 At the receiver, a linear system is managed from the set of received 140 source and repair packets. New variables (representing source 141 symbols) and equations (representing the linear combination of each 142 repair symbol received) are added upon receiving new packets. 143 Variables are removed when they are too old with respect to their 144 validity period (real-time constraints), as well as the associated 145 equations they are involved in (Appendix A introduces an optimisation 146 that extends the time a variable is considered in the system). 147 Erased source symbols are then recovered thanks this linear system 148 whenever its rank permits it. 150 With RLC (more generally with convolutional codes), the protection of 151 a multicast/broadcast session also needs to be dimensioned by 152 considering the worst communication channel one wants to support. 153 However the receivers experiencing a good to medium channel quality 154 observe a FEC-related latency close to zero [Roca16] since an 155 isolated erased source packet is quickly recovered by the following 156 repair packet. On the opposite, with a block code, recovering an 157 isolated erased source packet always requires waiting the end of the 158 block for the first repair packet to arrive. Additionally, under 159 certain situations (e.g., with a limited FEC-related latency budget 160 and with constant bit rate transmissions after FECFRAME encoding), 161 convolutional codes achieve more easily a target transmission quality 162 (e.g., measured by the residual loss after FEC decoding) by sending 163 fewer repair packets (i.e., higher code rate) than block codes. 165 1.3. Small Transmission Overheads with the RLC FEC Scheme 167 The RLC FEC scheme is designed so as to reduce the transmission 168 overhead. The main requirement is that each repair packet header 169 must enable a receiver to reconstruct the list of source symbols and 170 the associated random coefficients used during the encoding process. 171 In order to minimize packet overhead, the set of symbols in the 172 encoding window as well as the set of coefficients over GF(2^^m) used 173 in the linear combination are not individually listed in the repair 174 packet header. Instead, each FEC repair packet header contains: 176 o the Encoding Symbol Identifier (ESI) of the first source symbol in 177 the encoding window as well as the number of symbols (since this 178 number may vary with a variable size, elastic window). These two 179 pieces of information enable each receiver to easily reconstruct 180 the set of source symbols considered during encoding, the only 181 constraint being that there cannot be any gap; 182 o the seed used by a coding coefficients generation function 183 (Section 3.5). This information enables each receiver to generate 184 the same set of coding coefficients over GF(2^^m) as the sender; 186 Therefore, no matter the number of source symbols present in the 187 encoding window, each FEC repair packet features a fixed 64-bit long 188 header, also called Repair FEC Payload ID (Figure 7). Similarly, 189 each FEC source packet features a fixed 32-bit lon trailer, also 190 called Explicit Source FEC Payload ID (Figure 5), that contains the 191 ESI of the first source symbol (see the ADUI and source symbol 192 mapping, Section 3.2). 194 1.4. Document Organization 196 This fully-specified FEC scheme follows the structure required by 197 [RFC6363], section 5.6. "FEC Scheme Requirements", namely: 199 3. Procedures: This section describes procedures specific to this 200 FEC scheme, namely: RLC parameters derivation, ADUI and source 201 symbols mapping, pseudo-random number generator, and coding 202 coefficients generation function; 203 4. Formats and Codes: This section defines the Source FEC Payload 204 ID and Repair FEC Payload ID formats, carrying the signaling 205 information associated to each source or repair symbol. It also 206 defines the FEC Framework Configuration Information (FFCI) 207 carrying signaling information for the session; 208 5. FEC Code Specification: Finally this section provides the code 209 specification. 211 2. Definitions and Abbreviations 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 This document uses the following definitions and abbreviations: 219 ADU: Application Data Unit 220 E: encoding symbol size (i.e., source or repair symbol), assumed 221 fixed (in bytes) 222 bw_out: transmission bandwidth at the output of the FECFRAME sender, 223 assumed fixed (in bits/s) 224 max_lat: maximum FEC-related latency within FECFRAME (in seconds) 225 cr: AL-FEC coding rate 226 plr: packet loss rate on the erasure channel 227 ew_size: encoding window current size at a sender (in symbols) 228 ew_max_size: encoding window maximum size at a sender (in symbols) 229 dw_size: decoding window current size at a receiver (in symbols). 230 dw_max_size: decoding window maximum size at a receiver (in symbols) 231 ls_max_size: linear system maximum size (or width) at a receiver (in 232 symbols) 233 ls_size: linear system current size (or width) at a receiver (in 234 symbols) 235 PRNG: pseudo-random number generator 236 pmms_rand(maxv): PRNG defined in Section 3.4 and used in this 237 specification, that returns a new random integer in [0; maxv-1] 239 3. Procedures 241 This section introduces the procedures that are used by this FEC 242 scheme. 244 3.1. RLC parameters derivation 246 The RLC FEC Scheme relies on several key internal parameters: 248 Maximum FEC-related latency budget, max_lat (in seconds) A source 249 ADU flow can have real-time constraints, and therefore any 250 FECFRAME related operation must take place within the validity 251 period of each ADU. When there are multiple flows with different 252 real-time constraints, we consider the most stringent constraints 253 (see [RFC6363], Section 10.2, item 6, for recommendations when 254 several flows are globally protected). This maximum FEC-related 255 latency accounts for all sources of latency added by FEC encoding 256 (sender) and FEC decoding (receiver). Any other source of latency 257 (e.g., added by network communications) is not considered in this 258 latency budget; It can be regarded as the latency budget permitted 259 for all FEC-related operations. This is also an input parameter 260 that enables to derive other internal parameters; 261 Encoding window current (resp. maximum) size, ew_size (resp. 262 ew_max_size) (in symbols): 263 these parameters are used by a sender during FEC encoding. More 264 precisely, each repair symbol is a linear combination of the 265 ew_size source symbols present in the encoding window when RLC 266 encoding took place. In all situations, we MUST have ew_size <= 267 ew_max_size; 268 Decoding window current (resp. maximum) size, dw_size (resp. 269 dw_max_size) (in symbols): 270 these parameters are used by a receiver when managing the linear 271 system used for decoding. dw_size is the current size of the 272 decoding window, i.e., the set of received or erased source 273 symbols that are currently part of the linear system. In all 274 situations, we MUST have dw_size <= dw_max_size; 276 In order to comply with the maximum FEC-related latency budget, 277 assuming a constant transmission bandwidth at the output of the 278 FECFRAME sender (bw_out), encoding symbol size (E), and code rate 279 (cr), we have: 281 dw_max_size = (max_lat * bw_out * cr) / (8 * E) 283 This dw_max_size defines the maximum delay after which an old source 284 symbol may be recovered: after this delay, this old source symbol 285 symbol will be removed from the decoding window. 287 It is often good practice to choose: 289 ew_max_size = dw_max_size / 2 291 However any value ew_max_size < dw_max_size can be used without 292 impact on the FEC-related latency budget. Finding the optimal value 293 can depend on the erasure channel one wants to support and should be 294 determined after simulations or field trials. 296 Note that the decoding beyond maximum latency optimisation 297 (Appendix A) enables an old source symbol to be kept in the linear 298 system beyond the FEC-related latency budget, but not delivered to 299 the receiving application. Here we have: ls_size >= dw_max_size 301 3.2. ADU, ADUI and Source Symbols Mappings 303 An ADU, coming from the application, cannot be mapped to source 304 symbols directly. Indeed, an erased ADU recovered at a receiver must 305 contain enough information to be assigned to the right application 306 flow (UDP port numbers and IP addresses cannot be used to that 307 purpose as they are not protected by FEC encoding). This requires 308 adding the flow identifier to each ADU before doing FEC encoding. 310 Additionally, since ADUs are of variable size, padding is needed so 311 that each ADU (with its flow identifier) contribute to an integral 312 number of source symbols. This requires adding the original ADU 313 length to each ADU before doing FEC encoding. Because of these 314 requirements, an intermediate format, the ADUI, or ADU Information, 315 is considered [RFC6363]. 317 For each incoming ADU, an ADUI is created as follows. First of all, 318 3 bytes are prepended: (Figure 1): 320 Flow ID (F) (8-bit field): this unsigned byte contains the integer 321 identifier associated to the source ADU flow to which this ADU 322 belongs. It is assumed that a single byte is sufficient, which 323 implies that no more than 256 flows will be protected by a single 324 FECFRAME instance. 325 Length (L) (16-bit field): this unsigned integer contain the length 326 of this ADU, in network byte order (i.e., big endian). This 327 length is for the ADU itself and does not include the F, L, or Pad 328 fields. 330 Then, zero padding is added to ADU if needed: 332 Padding (Pad) (variable size field): this field contains zero 333 padding to align the F, L, ADU and padding up to a size that is 334 multiple of E bytes (i.e., the source and repair symbol length). 336 Each ADUI contributes to an integral number of source symbols. The 337 data unit resulting from the ADU and the F, L, and Pad fields is 338 called ADU Information (or ADUI). Since ADUs can be of different 339 size, this is also the case for ADUIs. 341 symbol length, E E E 342 < ------------------ >< ------------------ >< ------------------ > 343 +-+--+---------------------------------------------+-------------+ 344 |F| L| ADU | Pad | 345 +-+--+---------------------------------------------+-------------+ 347 Figure 1: ADUI Creation example (here 3 source symbols are created 348 for this ADUI). 350 Note that neither the initial 3 bytes nor the optional padding are 351 sent over the network. However, they are considered during FEC 352 encoding. It means that a receiver who lost a certain FEC source 353 packet (e.g., the UDP datagram containing this FEC source packet) 354 will be able to recover the ADUI if FEC decoding succeeds. Thanks to 355 the initial 3 bytes, this receiver will get rid of the padding (if 356 any) and identify the corresponding ADU flow. 358 3.3. Encoding Window Management 360 Source symbols and the corresponding ADUs are removed from the 361 encoding window: 363 o when the sliding encoding window has reached its maximum size, 364 ew_max_size. In that case the oldest symbol MUST be removed 365 before adding a new symbol, so that the current encoding window 366 size always remains inferior or equal to the maximum size: ew_size 367 <= ew_max_size; 368 o when an ADU has reached its maximum validity duration in case of a 369 realtime flow. When this happens, all source symbols 370 corresponding to the ADUI that expired SHOULD be removed from the 371 encoding window; 373 Source symbols are added to the sliding encoding window each time a 374 new ADU arrives, once the ADU to ADUI and then to source symbols 375 mapping has been performed (Section 3.2). The current size of the 376 encoding window, ew_size, is updated after adding new source symbols. 377 This process may require to remove old source symbols so that: 378 ew_size <= ew_max_size. 380 Note that a FEC codec may feature practical limits in the number of 381 source symbols in the encoding window (e.g., for computational 382 complexity reasons). This factor may further limit the ew_max_lat 383 value, in addition to the maximum FEC-related latency budget 384 (Section 3.1). 386 3.4. Pseudo-Random Number Generator 388 The RLC codes rely on the following Pseudo-Random Number Generator 389 (PRNG), identical to the PRNG used with LDPC-Staircase codes 390 ([RFC5170], section 5.7). 392 The Park-Miler "minimal standard" PRNG [PM88] MUST be used. It 393 defines a simple multiplicative congruential algorithm: Ij+1 = A * Ij 394 (modulo M), with the following choices: A = 7^^5 = 16807 and M = 395 2^^31 - 1 = 2147483647. A validation criteria of such a PRNG is the 396 following: if seed = 1, then the 10,000th value returned MUST be 397 equal to 1043618065. 399 Several implementations of this PRNG are known and discussed in the 400 literature. An optimized implementation of this algorithm, using 401 only 32-bit mathematics, and which does not require any division, can 402 be found in [rand31pmc]. It uses the Park and Miller algorithm 403 [PM88] with the optimization suggested by D. Carta in [CA90]. The 404 history behind this algorithm is detailed in [WI08]. Yet, any other 405 implementation of the PRNG algorithm that matches the above 406 validation criteria, like the ones detailed in [PM88], is 407 appropriate. 409 This PRNG produces, natively, a 31-bit value between 1 and 0x7FFFFFFE 410 (2^^31-2) inclusive. Since it is desired to scale the pseudo-random 411 number between 0 and maxv-1 inclusive, one must keep the most 412 significant bits of the value returned by the PRNG (the least 413 significant bits are known to be less random, and modulo-based 414 solutions should be avoided [PTVF92]). The following algorithm MUST 415 be used: 417 Input: 419 raw_value: random integer generated by the inner PRNG algorithm, 420 between 1 and 0x7FFFFFFE (2^^31-2) inclusive. 421 maxv: upper bound used during the scaling operation. 423 Output: 425 scaled_value: random integer between 0 and maxv-1 inclusive. 427 Algorithm: 429 scaled_value = (unsigned long) ((double)maxv * (double)raw_value / 430 (double)0x7FFFFFFF); 431 (NB: the above C type casting to unsigned long is equivalent to 432 using floor() with positive floating point values.) 434 In this document, pmms_rand(maxv) denotes the PRNG function that 435 implements the Park-Miller "minimal standard" algorithm, defined 436 above, and that scales the raw value between 0 and maxv-1 inclusive, 437 using the above scaling algorithm. 439 Additionally, the pmms_srand(seed) function must be provided to 440 enable the initialization of the PRNG with a seed before calling 441 pmms_rand(maxv) the first time. The seed is a 31-bit integer between 442 1 and 0x7FFFFFFE inclusive. In this specification, the seed is 443 restricted to a value between 1 and 0xFFFF inclusive, as this is the 444 Repair_Key 16-bit field value of the Repair FEC Payload ID 445 (Section 4.1.3). 447 3.5. Coding Coefficients Generation Function 449 The coding coefficients, used during the encoding process, are 450 generated at the RLC encoder by the following function each time a 451 new repair symbol needs to be produced: 453 454 /* 455 * Fills in the table of coding coefficients (of the right size) 456 * provided with the appropriate number of coding coefficients to 457 * use for the repair symbol key provided. 458 * 459 * (in) repair_key key associated to this repair symbol 460 * (in) cc_tab[] pointer to a table of the right size to store 461 * coding coefficients. All coefficients are 462 * stored as bytes, regardless of the m parameter, 463 * upon return of this function. 464 * (in) cc_nb[] number of entries in the table. This value is 465 * equal to the current encoding window size. 466 * (in) m Finite Field GF(2^^m) parameter. 467 * (out) returns an error code 468 */ 469 int generate_coding_coefficients (UINT16 repair_key, 470 UINT8 cc_tab[], 471 UINT16 cc_nb, 472 UINT8 m) 473 { 474 UINT32 i; 476 if (repair_key == 0) { 477 return SOMETHING_WENT_WRONG; 478 } 479 pmms_srand(repair_key); 480 if (m == 1) { 481 /* 0 is a valid coefficient value in binary GF */ 482 for (i = 0 ; i < cc_nb ; i ++) { 483 cc_tab[i] = (UINT8) pmms_rand(2); 484 } 485 } else { 486 /* coefficient 0 is avoided in non-binary GF to consider each 487 * source symbol */ 488 UINT32 maxv; 489 maxv = get_gf_size(); /* i.e., 16 if m=4 or 256 if m=8 */ 490 for (i = 0 ; i < cc_nb ; i ++) { 491 do { 492 cc_tab[i] = (UINT8) pmms_rand(maxv); 493 } while (cc_tab[i] == 0) 494 } 495 } 496 return EVERYTHING_IS_OKAY; 497 } 498 500 Figure 2: Coding Coefficients Generation Function pseudo-code 502 4. RLC FEC Scheme for Arbitrary ADU Flows 504 4.1. Formats and Codes 506 4.1.1. FEC Framework Configuration Information 508 The FEC Framework Configuration Information (or FFCI) includes 509 information that MUST be communicated between the sender and 510 receiver(s). More specifically, it enables the synchronization of 511 the FECFRAME sender and receiver instances. It includes both 512 mandatory elements and scheme-specific elements, as detailed below. 514 4.1.1.1. Mandatory Information 516 o FEC Encoding ID: the value assigned to this fully specified FEC 517 scheme MUST be XXXX, as assigned by IANA (Section 9). 519 When SDP is used to communicate the FFCI, this FEC Encoding ID is 520 carried in the 'encoding-id' parameter. 522 4.1.1.2. FEC Scheme-Specific Information 524 The FEC Scheme-Specific Information (FSSI) includes elements that are 525 specific to the present FEC scheme. More precisely: 527 Encoding symbol length (E): a non-negative integer that indicates 528 the length of each encoding symbol in bytes; 530 This element is required both by the sender (RLC encoder) and the 531 receiver(s) (RLC decoder). 533 When SDP is used to communicate the FFCI, this FEC scheme-specific 534 information is carried in the 'fssi' parameter in textual 535 representation as specified in [RFC6364]. For instance: 537 fssi=E:1400 539 If another mechanism requires the FSSI to be carried as an opaque 540 octet string (for instance, after a Base64 encoding), the encoding 541 format consists of the following 2 octets: 543 Encoding symbol length (E) field (16-bits): Length, in number of 544 bytes, of the source and repair symbols. 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Encoding Symbol Length (E) | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Figure 3: FSSI Encoding Format 554 4.1.2. Explicit Source FEC Payload ID 556 A FEC source packet MUST contain an Explicit Source FEC Payload ID 557 that is appended to the end of the packet as illustrated in Figure 4. 559 +--------------------------------+ 560 | IP Header | 561 +--------------------------------+ 562 | Transport Header | 563 +--------------------------------+ 564 | ADU | 565 +--------------------------------+ 566 | Explicit Source FEC Payload ID | 567 +--------------------------------+ 569 Figure 4: Structure of an FEC Source Packet with the Explicit Source 570 FEC Payload ID 572 More precisely, the Explicit Source FEC Payload ID is composed of the 573 following field (Figure 5): 575 Encoding Symbol ID (ESI) (32-bit field): this unsigned integer 576 identifies the first source symbol of the ADUI corresponding to 577 this FEC source packet. The ESI is incremented for each new 578 source symbol, and after reaching the maximum value (2^32-1), 579 wrapping to zero occurs. 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Encoding Symbol ID (ESI) | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Figure 5: Source FEC Payload ID Encoding Format 589 4.1.3. Repair FEC Payload ID 591 A FEC repair packet MUST contain a Repair FEC Payload ID that is 592 prepended to the repair symbol as illustrated in Figure 6. There 593 MUST be a single repair symbol per FEC repair packet. 595 +--------------------------------+ 596 | IP Header | 597 +--------------------------------+ 598 | Transport Header | 599 +--------------------------------+ 600 | Repair FEC Payload ID | 601 +--------------------------------+ 602 | Repair Symbol | 603 +--------------------------------+ 605 Figure 6: Structure of an FEC Repair Packet with the Repair FEC 606 Payload ID 608 More precisely, the Repair FEC Payload ID is composed of the 609 following fields (Figure 7): 611 Repair_Key (16-bit field): this unsigned integer is used as a seed 612 by the coefficient generation function Section 3.5, in order to 613 generate the desired number of coding coefficients. Value 0 MUST 614 NOT be used. 615 Number of Source Symbols in the Encoding Window, NSS (16-bit field): 617 this unsigned integer indicates the number of source symbols in 618 the encoding window when this repair symbol was generated. 619 ESI of first source symbol in encoding window, FSS_ESI (32-bit 620 field): 621 this unsigned integer indicates the ESI of the first source symbol 622 in the encoding window when this repair symbol was generated. 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Repair_Key | NSS (# source symbols in ew) | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | FSS_ESI | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Figure 7: Repair FEC Payload ID Encoding Format 634 4.1.4. Additional Procedures 636 The following procedure applies: 638 o The ESI of source symbols MUST start with value 0 for the first 639 source symbol and MUST be managed sequentially. Wrapping to zero 640 will happen after reaching the maximum 32-bit value. 642 5. FEC Code Specification 644 TBD... Describe a typical sender's operation, when using the RLC FEC 645 scheme. Describe a typical receiver operation, when using the RLC 646 FEC scheme. 648 (summary, to be detailed): The FECFRAME sender generates a linear 649 combination of source symbols, using the coding coefficients 650 generation function and sends it within an FEC repair packet. This 651 linear combination encompasses all the source symbols currently in 652 the encoding window. FEC repair packets are sent immediately after 653 having been created, inter-mixed with FEC source packets. 655 (summary, to be detailed): A FECFRAME receiver, upon receiving a FEC 656 repair packet, adds an equation to the linear system it maintains (or 657 no equation if this repair packet does not change the linear system 658 rank). Whenever possible, decoding is performed in order to recover 659 erased source symbols if any. 661 6. Implementation Status 663 Editor's notes: 665 o RFC Editor, please remove this section motivated by RFC 6982 666 before publishing the RFC. Thanks. 668 An implementation of the RLC convolutional FEC Scheme for FECFRAME 669 exists: 671 o Organisation: Inria 672 o Description: This is an implementation of the RLC Convolutional 673 FEC Scheme. It relies on a modified version of our OpenFEC 674 (http://openfec.org) FEC code library. It is integrated in our 675 FECFRAME software (see [fecframe-ext]). 676 o Maturity: prototype. 677 o Coverage: this software complies with the RLC FEC Scheme (limited 678 to m=8 as of end of January, 2017). 679 o Lincensing: proprietary. 680 o Contact: vincent.roca@inria.fr 682 7. Security Considerations 684 TBD 686 8. Operations and Management Considerations 688 9. IANA Considerations 690 This document registers one value in the "FEC Framework (FECFRAME) 691 FEC Encoding IDs" registry [RFC6363] as follows: 693 o XXX refers to the convolutional Random Linear Codes (RLC) FEC 694 Scheme for Arbitrary Packet Flows, as defined in Section XXX of 695 this document. 697 10. Acknowledgments 699 11. References 701 11.1. Normative References 703 [fecframe-ext] 704 Roca, V. and A. Begen, "Forward Error Correction (FEC) 705 Framework version 2", Transport Area Working Group 706 (TSVWG) draft-roca-tsvwg-fecframev2 (Work in Progress), 707 October 2016, . 710 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 711 Requirement Levels", BCP 14, RFC 2119, 712 DOI 10.17487/RFC2119, March 1997, 713 . 715 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 716 Correction (FEC) Framework", RFC 6363, 717 DOI 10.17487/RFC6363, October 2011, 718 . 720 [RFC6364] Begen, A., "Session Description Protocol Elements for the 721 Forward Error Correction (FEC) Framework", RFC 6364, 722 DOI 10.17487/RFC6364, October 2011, 723 . 725 11.2. Informative References 727 [CA90] Carta, D., "Two Fast Implementations of the Minimal 728 Standard Random Number Generator", Communications of the 729 ACM, Vol. 33, No. 1, pp.87-88, January 1990. 731 [PM88] Park, S. and K. Miller, "Random Number Generators: Good 732 Ones are Hard to Find", Communications of the ACM, Vol. 733 31, No. 10, pp.1192-1201, 1988. 735 [PTVF92] Press, W., Teukolsky, S., Vetterling, W., and B. Flannery, 736 "Numerical Recipies in C; Second Edition", Cambridge 737 University Press, ISBN: 0-521-43108-5, 1992. 739 [rand31pmc] 740 Whittle, R., "31 bit pseudo-random number generator", 741 September 2005, . 744 [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity 745 Check (LDPC) Staircase and Triangle Forward Error 746 Correction (FEC) Schemes", RFC 5170, DOI 10.17487/RFC5170, 747 June 2008, . 749 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 750 "FLUTE - File Delivery over Unidirectional Transport", 751 RFC 6726, DOI 10.17487/RFC6726, November 2012, 752 . 754 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 755 Parity Check (LDPC) Staircase Forward Error Correction 756 (FEC) Scheme for FECFRAME", RFC 6816, 757 DOI 10.17487/RFC6816, December 2012, 758 . 760 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 761 Matsuzono, "Simple Reed-Solomon Forward Error Correction 762 (FEC) Scheme for FECFRAME", RFC 6865, 763 DOI 10.17487/RFC6865, February 2013, 764 . 766 [Roca16] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C. 767 Thienot, "Block or Convolutional AL-FEC Codes? A 768 Performance Comparison for Robust Low-Latency 769 Communications", Submitted for publication 770 https://hal.inria.fr/hal-01395937/en/, November 2016, < 771 https://hal.inria.fr/hal-01395937/en/>. 773 [WI08] Whittle, R., "Park-Miller-Carta Pseudo-Random Number 774 Generator", http://www.firstpr.com.au/dsp/rand31/, 775 January 2008, . 777 Appendix A. Decoding Beyond Maximum Latency Optimization 779 This annex introduces non normative considerations. They are 780 provided as suggestions, without any impact on interoperability. For 781 more information see [Roca16]. 783 It is possible to improve the decoding performance of convolutional 784 codes without impacting maximum latency, at the cost of extra CPU 785 overhead. The optimization consists, for a receiver, to extend the 786 linear system beyond the decoding window: 788 ls_max_size > dw_max_size 790 Usually the following choice is a good trade-off between decoding 791 performance and extra CPU overhead: 793 ls_max_size = 2 * dw_max_size 795 ls_max_size 796 /---------------------------------^-------------------------------\ 798 late source symbols 799 (pot. decoded but not delivered) dw_max_size 800 /--------------^-----------------\ /--------------^---------------\ 801 src0 src1 src2 src3 src4 src5 src6 src7 src8 src9 src10 src11 src12 803 Figure 8: Relationship between parameters to decode beyond maximum 804 latency. 806 It means that source symbols (and therefore ADUs) may be decoded even 807 if their transport protocol added latency exceeds the maximum value 808 permitted by the application. It follows that these source symbols 809 SHOULD NOT be delivered to the application and SHOULD be dropped once 810 they are no longer needed. However, decoding these late symbols 811 significantly improves the global robustness in bad reception 812 conditions and is therefore recommended for receivers experiencing 813 bad channels[Roca16]. In any case whether or not to use this 814 facility and what exact value to use for the ls_max_size parameter 815 are decisions made by each receiver independantly, without any impact 816 on others, neither the other receivers nor the source. 818 Author's Address 819 Vincent Roca 820 INRIA 821 655, av. de l'Europe 822 Inovallee; Montbonnot 823 ST ISMIER cedex 38334 824 France 826 EMail: vincent.roca@inria.fr