idnits 2.17.1 draft-wang-tsvwg-sw-slc-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 -- The document date (21 June 2021) is 1033 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 (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG R. Wang 3 Internet-Draft L. Si 4 Intended status: Standards Track B. He 5 Expires: 23 December 2021 Agora Lab 6 21 June 2021 8 Sliding Window Selective Linear Code (SLC) Forward Error Correction 9 (FEC) Scheme for FECFRAME 10 draft-wang-tsvwg-sw-slc-fec-scheme-00 12 Abstract 14 This document describes a fully-specified Forward Error Correction 15 (FEC) scheme for Sliding Window Selective Linear Code (SLC) over the 16 Galois Field GF (2^^8). It can be used to selectively protect 17 arbitrary media streams along the lines defined by FECFRAME. It is 18 necessary to protect the media streams selectively (e.g., the 19 reference frames are not continuous under the SVC mode in real-time 20 video streaming transmission). Compared with the traditional Sliding 21 Window FEC Codes, the Sliding Window Selective FEC Code supports that 22 the source symbols in the encoding window are discrete. Therefore, 23 it can be ensured that only source symbols with correlation (whether 24 continuous or not) are included in the encoding window. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 23 December 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Definitions Notations and Abbreviations . . . . . . . . . . . 5 62 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Formats and Codes . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. FEC Framework Configuration Information . . . . . . . . . 7 67 4.1.1. Mandatory . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1.2. FEC Scheme-Specific Information . . . . . . . . . . . 7 69 4.2. FEC Payload IDs . . . . . . . . . . . . . . . . . . . . . 8 70 4.2.1. Explicit Source FEC Payload ID . . . . . . . . . . . 8 71 4.2.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . 9 72 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 10 74 5.2. ADU, ADUI, and Source Symbols Mappings . . . . . . . . . 10 75 5.3. Encoding Window Management . . . . . . . . . . . . . . . 12 76 5.4. Coding Matrix Generation . . . . . . . . . . . . . . . . 13 77 5.5. Linear Operation on encoding side and decoding side . . . 13 78 5.5.1. Encoding Side . . . . . . . . . . . . . . . . . . . . 13 79 5.5.2. Decoding Side . . . . . . . . . . . . . . . . . . . . 14 80 6. FEC Code Specification . . . . . . . . . . . . . . . . . . . 14 81 6.1. Encoding Side . . . . . . . . . . . . . . . . . . . . . . 14 82 6.2. Decoding Side . . . . . . . . . . . . . . . . . . . . . . 15 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 7.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 15 85 7.1.1. Access to Confidential Content . . . . . . . . . . . 16 86 7.1.2. Content Corruption . . . . . . . . . . . . . . . . . 16 87 7.2. Attacks Against the FEC Parameters . . . . . . . . . . . 16 88 7.3. When Several Source Flows Are to Be Protected Together . 17 89 7.4. Baseline Secure FECFRAME Operation . . . . . . . . . . . 17 90 8. Operations and Management Considerations . . . . . . . . . . 17 91 8.1. Operational Recommendations: gc_max . . . . . . . . . . . 18 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 96 11.2. Informative References . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 The use of Application-Level Forward Erasure Correction (AL-FEC) 102 codes is a widely-used error control method used to improve the 103 reliability of unicast, multicast, and broadcast transmissions. 105 The [RFC5052] document describes a general framework to use FEC in 106 Content Delivery Protocols (CDPs), and it is suitable for FEC schemes 107 based on building blocks. Based on this framework, the [RFC5170] 108 describes two fully-specified FEC Schemes, Low-Density Parity Check 109 (LDPC) Staircase and LDPC Triangle, and the [RFC5510] describes one 110 Fully-Specified FEC Scheme for the special case of Reed-Solomon (RS) 111 over GF (2^^8). 113 The [RFC6363] document describes a general framework used to protect 114 arbitrary media streams along the lines defined by FECFRAME. The FEC 115 scheme defined by the framework does not limit the type of input 116 data, but only processes the data. 118 Similar to [RFC5052], [RFC6363] only considers block FEC schemes, 119 which requires that the input stream be divided into a series of 120 blocks according to the block partitioning algorithm defined in 121 [RFC5052]. The [RFC6681], [RFC6816], and [RFC6865] are FEC schemes 122 based on this framework. The value for the block size affects the 123 packet loss resistance and the encoding and decoding delay of the FEC 124 scheme. At the same code rate, the FEC scheme with larger size 125 blocks have higher robustness (e.g., in case of long packet erasure 126 bursts), but it has higher decoding delay which is unacceptable for 127 real-time video streaming application. 129 The framework described in [RFC8680] provides support for FEC codes 130 based on a sliding coding window. The FEC scheme in this framework 131 [RFC8681] is advantageous for real-time flows because of its high 132 robustness and low additional delay. 134 In real-time video streaming transmission, Scalable Video Coding 135 (SVC) is widely used. In normal real-time video coding, all frames 136 in a GOP follow the rule of the frame by frame reference, that is, 137 all frames except the last one are reference frames. In the encoding 138 window, all frames participating in the encoding are beneficial to 139 the decoding of the current frame. However, in the SVC mode, the 140 coding dependency between frames changes, some frames will become 141 non-reference frames. When non-reference frames are encoded, the 142 recovered packets will not help the decoding of the current frame, 143 and even have a negative effect on the FEC error correction ability 144 in extreme cases. 146 This document introduces one fully specified FEC scheme for the 147 situation that the sliding encoding window is discontinous in media 148 streaming. The Sliding Window SLC FEC scheme described in this 149 document belongs to the broad class of Sliding Window AL-FEC Codes 150 (a.k.a., convolutional codes) [RFC8406]. The encoding process is 151 based on an encoding window, and the source symbols are encoded by 152 sliding the encoding window. However, the encoding window does not 153 slide directly over the set of the source symbols. Instead, we find 154 the source symbols according to the rule defined by application 155 (e.g., coding dependency between frames) and then slide over the set 156 of these source symbols. Repair symbols are generated on-the-fly, by 157 the computation of a linear combination of source symbols present in 158 the current encoding window and passed to the transport layer. 160 When the loss of source symbol is detected at the receiver, the SLC 161 decoder will recover the lost source symbol according to the linear 162 combination of the source symbols and each received repair symbol 163 (when the rank of the equations involved is solvable). 165 This fully-specified FEC scheme follows the structure required by 166 [RFC6363], Section 5.6 ("FEC Scheme Requirements"), namely: 168 * Formats and Codes: This section defines the FEC Framework 169 Configuration Information (FFCI) carrying signaling, including 170 mandatory elements and Scheme-Specific elements. It also defines 171 the Source FEC Payload ID and Repair FEC Payload ID formats, 172 carrying the signaling information associated with each source or 173 repair symbol, including ESI, indexes of source symbols 174 participating in encoding, and coding coefficients. 176 * Procedures: This section describes procedures specific to this FEC 177 scheme, including encoding window management, coding matrix 178 generation, a linear combination of source symbol computation in 179 Finite Field, and the mapping between ADU, ADUI, and Source 180 Symbols. 182 * FEC Code Specification: This section provides a high-level 183 description of the Sliding Window SLC encoder and decoder. 185 2. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in 190 [RFC2119] [RFC8174]. 192 3. Definitions Notations and Abbreviations 194 3.1. Definitions 196 This document uses the following terms and definitions. Some of 197 these terms and definitions are FEC scheme-specific and are in line 198 with [RFC5052] [RFC6363]: 200 Source symbol: unit of data used during the encoding process. 202 Encoding symbol: unit of data generated by the encoding process. 204 Repair symbol: an encoding symbol that is not a source symbol. 206 Packet erasure channel: a communication path where packets are 207 either dropped (e.g., by a congested router, or because the number 208 of transmission errors exceeds the correction capabilities of the 209 physical layer codes) or received. When a packet is received, it 210 is assumed that this packet is not corrupted. 212 Application Data Unit (ADU): unit of source data provided as payload 213 to the transport layer. Depending on the use case, an ADU may use 214 an RTP encapsulation. 216 ADU Information (ADUI): unit of data constituted by the ADU and the 217 associated Flow ID, Length and Padding fields. 219 FEC Framework Configuration Information (FFCI): information that 220 controls the operation of FECFRAME. Each FEC Framework instance 221 has its own configuration information. And the FFCI enables the 222 synchronization of the FECFRAME sender and receiver instances. 224 FEC Source Packet: at a sender (respectively, at a receiver) a 225 payload submitted to (respectively, received from) the transport 226 protocol containing an ADU along with an Explicit Source FEC 227 Payload ID. 229 FEC Repair Packet: at a sender (respectively, at a receiver) a 230 payload submitted to (respectively, received from) the transport 231 protocol containing one repair symbol along with a Repair FEC 232 Payload ID and possibly an RTP header. 234 3.2. Notations 236 This document uses the following notations and some of them are FEC 237 scheme-specific: 239 m: defines the length of the elements in the finite field, in bits. 240 In this document, m is such that m=8. 242 GF(q): denotes a finite field (also known as the Galois Field) with 243 q elements. We assume that q = 2^^m in this document. 245 a^^b: denotes a raised to the power b. 247 E: denotes the size of an encoding symbol length in bytes. 249 cw_size: denotes coding window size (in symbols). 251 cw_size_max: denotes coding window maximum size (in symbols). 253 gc: denotes the count of symbol groups participating in encoding (if 254 there is a gap in the serial number, it is considered a new group) 255 when a repair symbol is generated. 257 gc_max: denotes the maximum count of symbol groups involved in 258 encoding when generating maintenance symbols. 260 cm: denotes coding matrix. 262 cm_r: denotes row in the coding matrix. 264 cm_c: denotes col in the coding matrix. 266 ESI: denotes the first source symbol of the ADUI corresponding to 267 this FEC Source Packet. 269 Start_ESI: denotes the first ADUI's ESI of the first group. 271 Residual_ESI_: denotes the residual value of the starting ESI of the 272 current group relative to the previous group. 274 Group_Size_: denotes the number of ADUIs contained in each group. 276 3.3. Abbreviations 278 This document uses the following abbreviations, and some of them are 279 FEC scheme-specific: 281 FEC: stands for Forward Error (or Erasure) Correction codes. 283 ADU: stands for Application Data Unit. 285 ADUI: stands for Application Data Unit Information. 287 ESI: stands for Encoding Symbol ID. 289 FFCI: stands for FEC Framework Configuration Information. 291 FSSI: stands for FEC Scheme-Specific Information. 293 4. Formats and Codes 295 This section describes the format of FEC Framework Configuration 296 Information (or FFCI) and FEC Payload IDs, which are carried in "big- 297 endian" or "network order" format. 299 4.1. FEC Framework Configuration Information 301 The FFCI needs to be shared between FECFRAME sender and receiver 302 instances to ensure the synchronization of information. It includes 303 mandatory elements (e.g., FEC Encoding ID) and scheme-specific 304 elements (e.g., Encoding Symbol size). 306 4.1.1. Mandatory 308 FEC Encoding ID: the value assigned to this Fully-Specified FEC 309 scheme MUST be XXX, as assigned by IANA(Section 9). 311 4.1.2. FEC Scheme-Specific Information 313 The FEC scheme-specific information (FSSI) of this scheme is as 314 follows: 316 Encoding Symbol size (E): a non-negative integer that indicates the 317 size of each encoding symbol in bytes; 319 The maximum coding window size (cw_size_max): a non-negative integer 320 that indicates the maximum size of the coding window allowed (in 321 symbols); 323 The maximum number of gc (gc_max): a non-negative integer that 324 indicates the maximum count of groups protected by each repair 325 packet. 327 These elements are required both by the encoder and decoder. 329 When SDP is used to communicate the FFCI, this FEC Scheme-Specific 330 Information MUST be carried in the 'fssi' parameter in textual 331 representation specified in [RFC6364]. For instance: 333 fssi=E:1500,cw_size_max:128,gc_max:4 335 If another mechanism requires the FSSI to be carried as an opaque 336 octet string (for instance after a Base64 encoding), the encoding 337 format consists of the following four octets: 339 Encoding symbol length (E): 16-bit field; 341 Maximum coding window size (cw_size_max): 8-bit field; 343 Maximum size of gc (gc_max): 8-bit field. 345 The encoding format consists of the following 4 octets of Figure 1: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Encoding Symbol Length (E) | cw_size_max | gc_max | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 1: FSSI Encoding Format 355 4.2. FEC Payload IDs 357 4.2.1. Explicit Source FEC Payload ID 359 A FEC Source Packet MUST contain an Explicit Source FEC Payload ID 360 that is appended to the end of the packet as illustrated in Figure 2. 362 +---------------------------------+ 363 | IP Header | 364 +---------------------------------+ 365 | Transport Header | 366 +---------------------------------+ 367 | ADUI | 368 +---------------------------------+ 369 | Explicit Source FEC Payload ID | 370 +---------------------------------+ 371 Figure 2: Structure of an FEC Source Packet with the Explicit 372 Source FEC Payload ID 374 More precisely, the Explicit Source FEC Payload ID is composed of the 375 following field: 377 Encoding Symbol ID (ESI) (32-bit field): this unsigned integer 378 identifies the first source symbol of the ADUI corresponding to 379 this FEC Source Packet. The ESI is incremented for each new 380 source symbol, and after reaching the maximum value (2^^32-1), 381 wrapping to zero occurs. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Encoding Symbol ID (ESI) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 3: Source FEC Payload ID Encoding Format 391 4.2.2. Repair FEC Payload ID 393 A FEC repair packet MUST contain a Repair FEC Payload ID prepended to 394 the repair symbol as illustrated in Figure 4. There MUST be a single 395 repair symbol per FEC repair packet. 397 +---------------------------------+ 398 | IP Header | 399 +---------------------------------+ 400 | Transport Header | 401 +---------------------------------+ 402 | Repair FEC Payload ID | 403 +---------------------------------+ 404 | Repair Symbol | 405 +---------------------------------+ 407 Figure 4: Structure of an FEC Repair Packet with the Repair FEC 408 Payload ID 410 More precisely, the SLC decoder scheme require the following 411 information from the Repair FEC Payload ID: 413 Start_ESI (32-bit field): this unsigned integer indicates the ESI of 414 the first source symbol of the first group in the encoding window 415 when this repair symbol was generated. 417 gc (8-bit field): this unsigned integer indicates the number of 418 symbol groups in the encoding window when this repair symbol is 419 generated (if there is a gap in the serial number, it is 420 considered a new group). 422 cm_r (8-bit field): this unsigned integer is used as a parameter to 423 generate the desired encoding matrix. This cm_r MUST NOT be 424 greater than cw_size_max. 426 Residual_ESI_ (8-bit field): this unsigned integer represents the 427 residual value of the starting ESI of the current group relative 428 to the previous group. 430 Group_Size_ (8-bit field): this unsigned integer is the number of 431 the source symbols contained in each group. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Start_ESI | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | gc | cm_r | Residual_ESI_2| ... | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |Residual_ESI_gc| Group_Size_1 | ... | Group_Size_gc | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 5: Repair FEC Payload ID Encoding Format 445 The length of the Repair FEC Payload ID depends on the gc parameter. 447 5. Procedures 449 5.1. Restrictions 451 This specification has the following restrictions: 453 1. There MUST be exactly one source symbol per ADUI, and therefore 454 per ADI; 456 2. There MUST be exactly one repair symbol per FEC Repair Packet. 458 5.2. ADU, ADUI, and Source Symbols Mappings 460 Before FEC coding, the mapping from ADU to AUDI needs to be 461 established. When multiple source flows (e.g., media streams) are 462 mapped onto the same FECFRAME instance, each flow is assigned its 463 Flow ID value. The Flow ID needs to be included in the ADUI. Then, 464 the recovered ADU can be allocated to the corresponding source flow 465 by its Flow ID. 467 Because the length of each ADU may be inconsistent, to ensure that 468 the decoder can extract ADU from ADUI, the original ADU length also 469 needs to be added to ADUI. 471 For each incoming ADU, an ADUI MUST be created as follows. First of 472 all, 3 bytes are prepended (Figure 6): 474 Flow ID (F) (8-bit field): this unsigned byte contains the integer 475 identifier associated with the source ADU flow to which this ADU 476 belongs. 478 Length (L) (16-bit field): this unsigned integer contains the length 479 of this ADU in network byte order (i.e., big endian). This length 480 is for the ADU itself and does not include the F, or Pad fields. 482 Then, zero padding is added to the ADU if needed: 484 Padding (Pad) (variable size field): this field is used for 485 alignment purposes up to a size of exactly E bytes. 487 The data unit resulting from the ADU and the F, L, and Pad fields is 488 called ADUI. An ADUI always contributes to an integral number of 489 source symbols. 491 Encoding Symbol Length (E) 492 +-------+-------------+------------------------+---------+ 493 | F | L | ADU | Pad | 494 +-------+-------------+------------------------+---------+ 495 \___________________________ ____________________________/ 496 v 498 SLC FEC encoding 499 +--------------------------------------------------------+ 500 | Repair | 501 +--------------------------------------------------------+ 503 Figure 6: ADUI Creation Example 505 Note that all the initial 3 bytes are considered during FEC encoding, 506 and a receiver that lost a certain FEC Source Packet will be able to 507 recover the ADUI if FEC decoding succeeds. Thanks to the initial 3 508 bytes, this receiver can determine the flow of ADU and verify the 509 recovered Source Packet. 511 5.3. Encoding Window Management 513 Whenever an ADU arrives, ADU-to-source symbols mapping will be 514 performed. Then, the source symbols will be added to the array 515 source_symbol_history. Whenever a repair symbol needs to be 516 generated, the SLC FEC encoder will search backward in the 517 source_symbol_history, and the source symbols that conforms the rules 518 defined by the application will be put into the encoding window. 519 When the encoding window cw_size is equal to its maximum value 520 cw_size_max or the symbol group count gc is equal to its maximum 521 value gc_max, the search is stopped and the FEC coding will be 522 performed on the source symbols in the encoding window. 524 Taking Figure 7 as an example, the coding dependency between frames 525 is used as the rule of source symbol selection, and frame I is the 526 reference frame of frame P1, so I and P1 are placed in the encoding 527 window when generating Repair2. However, P1 is not the reference 528 frame of P2 under the SVC mode, so P1 is skipped, I and P2 are put 529 into the encoding window to generate Repair3. The same process is 530 performed to produce Rapair4 and Repair5. 532 | +---+ FEC coding +-------+ 533 | | I |------------->|Repair1| 534 | +---+ +-------+ 535 | 536 | +---+ +----+ FEC coding +-------+ 537 | | I |--->| P1 |------------->|Repair2| 538 | +---+ +----+ +-------+ 539 | +-------------+ 540 | | | 541 | +---+ +----+ | +----+ FEC coding +-------+ 542 | | I | | | +-->| P2 |------------->|Repair3| 543 | +---+ +----+ +----+ +-------+ 544 | +-------------+ 545 | | | 546 | +---+ +----+ | +----+ +----+ FEC coding +-------+ 547 | | I | | | +-->| P2 |--->| P3 |------------->|Repair4| 548 | +---+ +----+ +----+ +----+ +-------+ 549 | +-------------+ +-------------+ 550 | | | | | 551 | +---+ +----+ | +----+ +----+ | +----+ FEC coding +-------+ 552 | | I | | | +-->| P2 | | | +-->| P4 |------------->|Repair5| 553 | +---+ +----+ +----+ +----+ +----+ +-------+ 554 | 555 | time 557 Figure 7: Example of Encoding Window Management 559 Note that each time the encoding window slides, cm_r will update. 560 The update rules are as follows: 562 if (++cm_r>=cw_size_max) cm_r=0; 564 5.4. Coding Matrix Generation 566 Compared with the RLC FEC encoder, which depends on a pseudorandom 567 number generator to compute the coding coefficients, the SLC FEC 568 encoder uses a fixed coding matrix to reduce overhead. The elements 569 of the coding matrix used during the encoding process are generated 570 at the SLC FEC encoder each time a new repair symbol needs to be 571 produced. The cm_r and cm_c parameters control these elements. The 572 values of cm_c between 0 (the minimum value) and cw_size_max-1 (the 573 maximum value). And the values of cm_r between 0 and 574 255-cw_size_max. 576 G (cm_r, cm_c) = y_c / (x_r + y_c) = (cm_c + cw_size_max) / (cm_r 577 + cm_c + cw_size_max) 579 where cm_r represents the row number in the matrix, cm_c represents 580 the col number in the matrix, cw_size_max represents the maximum 581 value of the encoding window, x_r = cm_r, y_c = cw_size_max+cm_c. 582 The basic operations of the above equations are carried out in the GF 583 (2^^8). 585 5.5. Linear Operation on encoding side and decoding side 587 5.5.1. Encoding Side 589 In Section 5.4, the elements of coding matrix G(cm_r, cm_c) are 590 obtained. Then, a repair symbol is generated by the computation of a 591 linear combination of source symbols. 593 A linear combination of the cw_size source symbols present in the 594 encoding window, say src_0 to src_cw_size_1, is computed as follows. 595 For each byte of position i in each source and the repair symbol, 596 where i belongs to [0; E-1]. 598 repair[i] = G(cm_r, 0) * src_0[i] + G(cm_r, 1) * src_1[i] + ... + 599 G(cm_r, cw_size-1) * src_cw_size_1[i] 601 where * is the multiplication over GF (2^^8), + is the addition over 602 GF (2^^8). In this document, the following irreducible polynomial is 603 used for GF(2^^8). 605 x^^8 + x^^4 + x^^3 + x^^2 + 1 607 5.5.2. Decoding Side 609 For decoding side, it is assumed that the repair symbol protects 610 cw_size source symbols, among which j source symbols are lost, then, 612 remove_src[i] = repair[i] - G(cm_r, 0) * src_0[i] - ... - G(cm_r, 613 k) * src_k[i] - G(cm_r, k + j + 1) * src_k_j_1[i] - ... - G(cm_r, 614 cw_size-1) * src_cw_size_1[i] 616 It is assumed that in the linear system maintained by the decoding 617 side, there is a symbol sequence S = {lost_src_1, lost_src_2, ... , 618 lost_src_N} consisting of N lost source symbols, a symbol sequence R 619 = {repair_1, repair_2, ... , repair_N} consisting of N repair symbols 621 There is a matrix A whose row represents the position of the repair 622 symbol in R and whose column represents the position of the lost 623 source symbol in S. A[row][col] represents the matrix element of 624 lost_src_row corresponding to repair_col (if it does not exist, then 625 A[row][col] = 0). 627 A[row][col] = G(cm_r,cm_c) 629 where cm_r can be extracted from the Repair FEC Payload ID, cm_c 630 represents the position of the lost source symbol in the encoding 631 window. 633 Therefore, there is a linear system of equation as follows: 635 A * Transpose(lost_src_1, lost_src_2, ... , lost_src_N) = 636 Transpose(remove_src_1, remove_src_2, ... , remove_src_N) 638 The inverse matrix of A can be obtained by Gauss elimination method, 639 and finally S can be recovered: 641 Transpose(lost_src_1, lost_src_2, ... , lost_src_N) = A^^-1 * 642 Transpose(remove_src_1, remove_src_2, ... , remove_src_N) 644 6. FEC Code Specification 646 6.1. Encoding Side 648 1. Whenever a new repair symbol needs to be produced, the source 649 symbols are put into the sliding encoding window according to the 650 rule defined by application (e.g., coding dependency between frames). 652 2. The SLC FEC encoder gathers the cw_size source symbols currently 653 in the sliding encoding window. 655 3. The elements of the coding matrix are determined according to the 656 parameters cm_r and cm_c (Section 5.4). 658 4. The SLC FEC encoder computes the repair symbol by a linear 659 combination of the cw_size source symbols present in the encoding 660 window using the coding matrix (Section 5.5.1). 662 When encoding, the execution object is ADUI composed of Flow ID, 663 Length, ADU, Padding. 665 6.2. Decoding Side 667 1. A linear system composed of source symbols, elements of the 668 coding matrix, and repair symbols MUST to be maintained to recover 669 the lost source packets. 671 2. When a repair symbol is received, it detects whether there is 672 loss in the protected source symbols. If at least one of the 673 corresponding source symbols has been lost, an equation composed of 674 the repair symbol, the corresponding source symbols, and the elements 675 of the coding matrix will be added to the linear system (the elements 676 of the coding matrix are generated by the method provided in 677 Section 5.4). 679 3. When the linear system covering one or more lost source symbols 680 is full, decoding is performed in order to recover lost source 681 symbols (Section 5.5.2). 683 4. Each time an ADUI can be totally recovered, padding is removed 684 (thanks to the Length field, L, of the ADUI), and the ADU will be 685 assigned to the corresponding flow. 687 Note that the recovered source symbols can be directly passed to the 688 application through the callback function, or passed to the 689 application after receiving a certain number of source symbols, which 690 depends on the operation decision of the application. 692 7. Security Considerations 694 The FEC Framework document [RFC6363] provides a comprehensive 695 analysis of security considerations applicable to FEC schemes. 696 Therefore, the present section follows the security considerations 697 section of [RFC6363] and only discusses specific topics. 699 7.1. Attacks Against the Data Flow 700 7.1.1. Access to Confidential Content 702 The Sliding Window SLC FEC scheme specified in this document does not 703 change the recommendations of [RFC6363]. To summarize, if 704 confidentiality is a concern, it is RECOMMENDED that one of the 705 solutions mentioned in [RFC6363] is used with special considerations 706 to the way this solution is applied (e.g., is encryption applied 707 before or after FEC protection, within the end system or in a 708 middlebox), to the operational constrains (e.g., performing FEC 709 decoding in a protected environment may be complicated or even 710 impossible) and to the threat model. 712 7.1.2. Content Corruption 714 The Sliding Window SLC FEC scheme specified in this document does not 715 change the recommendations of [RFC6363]. To summarize, it is 716 RECOMMENDED that one of the solutions mentioned in [RFC6363] is used 717 on both the FEC Source and Repair Packets. 719 7.2. Attacks Against the FEC Parameters 721 The Sliding Window SLC FEC scheme specified in this document defines 722 parameters that can be the basis of attacks. More specifically, the 723 following parameters of the FEC Framework Configuration Information 724 may be modified by an attacker (Section 4.1): 726 FEC Encoding ID: changing this parameter leads the receiver to 727 consider a different FEC Scheme. It will lead to severe 728 consequences that the format of the AUDI, the Explicit Source FEC 729 Payload ID, and Repair FEC Payload ID of received packets will 730 probably differ. The FEC decoder can't get the correct decoding 731 information, resulting in decoding failure or decoding error. 733 Encoding symbol length (E): setting this E parameter to a different 734 value will enable an attacker to create a DoS since the repair 735 symbols and certain source symbols will be larger or smaller than 736 E, incoherency for the receiver. 738 Therefore, it is RECOMMENDED that security measures be taken to 739 guarantee the FFCI integrity, as specified in [RFC6363]. How to 740 achieve this depends on how the FFCI is communicated from the sender 741 to the receiver, which is not specified in this document. 743 Similarly, attacks are possible against the Explicit Source FEC 744 Payload ID and Repair FEC Payload ID. More specifically, in the case 745 of an FEC Source Packet, the following value can be modified by an 746 attacker who targets receivers: 748 Encoding Symbol ID (ESI): changing the ESI leads a receiver to 749 consider a wrong ADU, resulting in severe consequences, including 750 corrupted content passed to the receiving application. And in the 751 case of an FEC Repair Packet. 753 Start_ESI: changing this value causes the FEC decoder to add the 754 wrong source symbol in the linear system, and therefore any source 755 symbol recovered by the linear system may be wrong. 757 gc: changing this value causes the FEC decoder to add an incorrect 758 number of source symbols in the linear system. Therefore any 759 source symbol recovered by the linear system may be wrong. 761 cm_r: changing this value leads a receiver to generate a wrong 762 coding coefficient, and therefore any source symbol decoded using 763 the repair symbol contained in this packet will be corrupted. 765 Residual_ESI_: changing this value causes the FEC decoder to add the 766 wrong source symbol in the linear system, and therefore any source 767 symbol recovered by the linear system may be wrong. 769 Group_Size_: changing this value causes the FEC decoder to add an 770 incorrect number of source symbols in the linear system. 771 Therefore any source symbol recovered by the linear system may be 772 wrong. 774 Therefore, it is RECOMMENDED that security measures are taken to 775 guarantee the FEC Source and Repair Packets as stated in [RFC6363]. 777 7.3. When Several Source Flows Are to Be Protected Together 779 The Sliding Window SLC FEC scheme specified in this document does not 780 change the recommendations of [RFC6363]. 782 7.4. Baseline Secure FECFRAME Operation 784 The Sliding Window SLC FEC scheme specified in this document does not 785 change the recommendations of [RFC6363] concerning the use of the 786 IPsec/Encapsulating Security Payload (ESP) security protocol as a 787 mandatory-to-implement (but not mandatory-to-use) security scheme. 788 This is well suited to situations where the only insecure domain is 789 the one over which the FEC Framework operates. 791 8. Operations and Management Considerations 793 The FECFRAME document [RFC6363] provides a comprehensive analysis of 794 operations and management considerations applicable to FEC schemes. 795 Therefore, the present section only discusses specific topics. 797 8.1. Operational Recommendations: gc_max 799 The Sliding Window SLC FEC scheme specified in this document defines 800 the maximum number of groups participating in encoding, called 801 gc_max, reflecting the maximum number of source symbols that the 802 coding window can hold. Gc_max is directly proportional to the 803 computational complexity of FEC encoding. If gc_max is too large, 804 the time complexity of FEC encoding will be too high, and the CPU 805 overhead will be too large. Generally, it is appropriate to 806 associate gc_max with cw_size_max. 808 For example, in real-time video streaming transmission, the frame 809 rate (FR) and bit rate (BR) is determined by transmitting the 810 transmitted video. The possible number of packets per frame can be 811 calculated according to FR and BR, and they can calculate the maximum 812 number of symbols in the coding window. 814 BR kbps / 8 / FR fps / MTU * gc_max <= cw_size_max 816 Where MTU denotes Maximum Transmission Unit. 818 9. IANA Considerations 820 This document registers one values in the "FEC Framework (FECFRAME) 821 FEC Encoding IDs" sub-registry as follows: 823 XXX refers to the Sliding Window Selective Linear Code (SLC) Forward 824 Error Correction (FEC) Scheme for Arbitrary Packet Flows. 826 10. Acknowledgments 828 The authors would like to thank the FEC Framework Design Team for 829 providing a great FEC Framework. The authors would also like to 830 thank Shie Qian for reviewing the earlier draft versions of this 831 document. 833 11. References 835 11.1. Normative References 837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 838 Requirement Levels", BCP 14, RFC 2119, 839 DOI 10.17487/RFC2119, March 1997, 840 . 842 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 843 Correction (FEC) Building Block", RFC 5052, 844 DOI 10.17487/RFC5052, August 2007, 845 . 847 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 848 Correction (FEC) Framework", RFC 6363, 849 DOI 10.17487/RFC6363, October 2011, 850 . 852 [RFC6364] Begen, A., "Session Description Protocol Elements for the 853 Forward Error Correction (FEC) Framework", RFC 6364, 854 DOI 10.17487/RFC6364, October 2011, 855 . 857 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 858 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 859 May 2017, . 861 [RFC8680] Roca, V. and A. Begen, "Forward Error Correction (FEC) 862 Framework Extension to Sliding Window Codes", RFC 8680, 863 DOI 10.17487/RFC8680, January 2020, 864 . 866 11.2. Informative References 868 [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity 869 Check (LDPC) Staircase and Triangle Forward Error 870 Correction (FEC) Schemes", RFC 5170, DOI 10.17487/RFC5170, 871 June 2008, . 873 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 874 "Reed-Solomon Forward Error Correction (FEC) Schemes", 875 RFC 5510, DOI 10.17487/RFC5510, April 2009, 876 . 878 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 879 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 880 DOI 10.17487/RFC6681, August 2012, 881 . 883 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 884 Parity Check (LDPC) Staircase Forward Error Correction 885 (FEC) Scheme for FECFRAME", RFC 6816, 886 DOI 10.17487/RFC6816, December 2012, 887 . 889 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 890 Matsuzono, "Simple Reed- Solomon Forward Error Correction 891 (FEC) Scheme for FECFRAME", RFC 6865, 892 DOI 10.17487/RFC6865, February 2013, 893 . 895 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 896 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 897 Pedersen, M., Peralta, G., Roca, V., Saxena, P., and S. 898 Sivakumar, "Taxonomy of Coding Techniques for Efficient 899 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 900 June 2018, . 902 [RFC8681] Roca, V. and B. Teibi, "Sliding Window Random Linear Code 903 (RLC) Forward Erasure Correction (FEC) Schemes for 904 FECFRAME", RFC 8681, DOI 10.17487/RFC8681, February 2020, 905 . 907 Authors' Addresses 909 Ray Wang 910 Agora Lab 911 China 913 Email: wangrui@agora.io 915 Liang Si 916 Agora Lab 917 China 919 Email: siliang@agora.io 921 Bifeng He 922 Agora Lab 923 China 925 Email: hebifeng@agora.io