idnits 2.17.1 draft-wang-tsvwg-sw-slc-fec-scheme-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 December 2021) is 863 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: 16 June 2022 Agora Lab 6 13 December 2021 8 Sliding Window Selective Linear Code (SLC) Forward Error Correction 9 (FEC) Scheme for FECFRAME 10 draft-wang-tsvwg-sw-slc-fec-scheme-01 12 Abstract 14 RFC8680 describes a framework for using Sliding Window Forward Error 15 Correction(FEC) codes to protection against packet loss, the 16 framework significantly improves FEC efficiency and reduces FEC- 17 related added latency compared to block FEC codes defined in RFC 18 6363. RFC8681 further describes two fully specified FEC schemes for 19 Sliding Window Random Linear Codes(RLC), the schemes rely on an 20 encoding window that slides over a continuous set of source symbols, 21 generating new repair symbols whenever needed. This document 22 describes a fully specified FEC scheme for Sliding Window Selective 23 Linear Code(SLC) over the Galois Field GF (2^^8) , compared to 24 RFC8681, this framework use a discrete encoding window which can 25 protect arbitrary media streams selectively, and has better recovery 26 performance in scenarios such as layered video coding or mixed 27 streams for video streaming applications. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 16 June 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Definitions Notations and Abbreviations . . . . . . . . . . . 5 65 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Formats and Codes . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. FEC Framework Configuration Information . . . . . . . . . 7 70 4.1.1. Mandatory . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1.2. FEC Scheme-Specific Information . . . . . . . . . . . 7 72 4.2. FEC Payload IDs . . . . . . . . . . . . . . . . . . . . . 8 73 4.2.1. Explicit Source FEC Payload ID . . . . . . . . . . . 8 74 4.2.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . 9 75 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 10 77 5.2. ADU, ADUI, and Source Symbols Mappings . . . . . . . . . 10 78 5. Encoding Window Management . . . . . . . . . . . . . . . . 11 79 5.4. Coding Matrix Generation . . . . . . . . . . . . . . . . 12 80 5.5. Linear Operation on encoding side and decoding side . . . 13 81 5.5.1. Encoding Side . . . . . . . . . . . . . . . . . . . . 13 82 5.5.2. Decoding Side . . . . . . . . . . . . . . . . . . . . 13 83 6. FEC Code Specification . . . . . . . . . . . . . . . . . . . 14 84 6.1. Encoding Side . . . . . . . . . . . . . . . . . . . . . . 14 85 6.2. Decoding Side . . . . . . . . . . . . . . . . . . . . . . 15 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 7.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 15 88 7.1.1. Access to Confidential Content . . . . . . . . . . . 15 89 7.1.2. Content Corruption . . . . . . . . . . . . . . . . . 16 90 7.2. Attacks Against the FEC Parameters . . . . . . . . . . . 16 91 7.3. When Several Source Flows Are to Be Protected Together . 17 92 7.4. Baseline Secure FECFRAME Operation . . . . . . . . . . . 17 93 8. Operations and Management Considerations . . . . . . . . . . 17 94 8.1. Operational Recommendations: gc_max . . . . . . . . . . . 17 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 99 11.2. Informative References . . . . . . . . . . . . . . . . . 19 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 102 1. Introduction 104 The use of Application-Level Forward Erasure Correction (AL-FEC) 105 codes is a widely-used error control method used to improve the 106 reliability of unicast, multicast, and broadcast transmissions. 108 The [RFC5052] document describes a general framework to use FEC in 109 Content Delivery Protocols (CDPs), and it is suitable for FEC schemes 110 based on building blocks. Based on this framework, the [RFC5170] 111 describes two fully-specified FEC Schemes, Low-Density Parity Check 112 (LDPC) Staircase and LDPC Triangle, and the [RFC5510] describes one 113 Fully-Specified FEC Scheme for the special case of Reed-Solomon (RS) 114 over GF (2^^8). 116 The [RFC6363] document describes a general framework used to protect 117 arbitrary media streams along the lines defined by FECFRAME. The FEC 118 scheme defined by the framework does not limit the type of input 119 data, but only processes the data. 121 Similar to [RFC5052], [RFC6363] only considers block FEC schemes, 122 which requires that the input stream be divided into a series of 123 blocks according to the block partitioning algorithm defined in 124 [RFC5052]. The [RFC6681], [RFC6816], and [RFC6865] are FEC schemes 125 based on this framework. The value for the block size affects the 126 packet loss resistance and the encoding and decoding delay of the FEC 127 scheme. At the same code rate, the FEC scheme with larger size 128 blocks have higher robustness (e.g., in case of long packet erasure 129 bursts), but it has higher decoding delay which is unacceptable for 130 real-time video streaming application. 132 The framework described in [RFC8680] provides support for FEC codes 133 based on a sliding coding window. The FEC scheme in this framework 134 [RFC8681] is advantageous for real-time flows because of its high 135 robustness and low additional delay. 137 In general video coding, all frames in a GOP follow the rule of the 138 frame by frame reference, that is, the reconstruction of the current 139 video frame relies on the preceding frame. In that case, all frames 140 in the encoding window are beneficial to the decoding of the current 141 frame. However, for layered video coding, video frames may not 142 reference the preceding frames, but the upper layer frames. When 143 non-reference frames are encoded, the recovered packets will not help 144 the decoding of the current frame, and even have a negative effect on 145 the FEC error correction ability in extreme cases. 147 This document introduces one fully specified FEC scheme, it is 148 capable to protect streams selectively by adding a filter into the 149 FEC coding window management. The Sliding Window SLC FEC scheme 150 described in this document belongs to the broad class of Sliding 151 Window AL-FEC Codes (a.k.a., convolutional codes) [RFC8406]. The 152 encoding process is based on an encoding window, and the source 153 symbols are encoded by sliding the encoding window. However, the 154 encoding window does not slide directly over the set of the source 155 symbols. Instead, it filters the source symbols according to the 156 rule defined by application (e.g., video frame dependency, or stream 157 type) and then slide over the set of these filtered source symbols. 158 Repair symbols are generated on-the-fly, by the computation of a 159 linear combination of source symbols present in the current encoding 160 window and passed to the transport layer. 162 When the loss of source symbol is detected at the receiver, the SLC 163 decoder will recover the lost source symbol according to the linear 164 combination of the source symbols and each received repair symbol 165 (when the rank of the equations involved is solvable). 167 This fully-specified FEC scheme follows the structure required by 168 [RFC6363], Section 5.6 ("FEC Scheme Requirements"), namely: 170 * Formats and Codes: This section defines the FEC Framework 171 Configuration Information (FFCI) carrying signaling, including 172 mandatory elements and Scheme-Specific elements. It also defines 173 the Source FEC Payload ID and Repair FEC Payload ID formats, 174 carrying the signaling information associated with each source or 175 repair symbol, including ESI, indexes of source symbols 176 participating in encoding, and coding coefficients. 178 * Procedures: This section describes procedures specific to this FEC 179 scheme, including encoding window management, coding matrix 180 generation, a linear combination of source symbol computation in 181 Finite Field, and the mapping between ADU, ADUI, and Source 182 Symbols. 184 * FEC Code Specification: This section provides a high-level 185 description of the Sliding Window SLC encoder and decoder. 187 2. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in 192 [RFC2119] [RFC8174]. 194 3. Definitions Notations and Abbreviations 196 3.1. Definitions 198 This document uses the following terms and definitions. Some of 199 these terms and definitions are FEC scheme-specific and are in line 200 with [RFC5052] [RFC6363]: 202 Source symbol: unit of data used during the encoding process. 204 Encoding symbol: unit of data generated by the encoding process. 206 Repair symbol: an encoding symbol that is not a source symbol. 208 Packet erasure channel: a communication path where packets are 209 either dropped (e.g., by a congested router, or because the number 210 of transmission errors exceeds the correction capabilities of the 211 physical layer codes) or received. When a packet is received, it 212 is assumed that this packet is not corrupted. 214 Application Data Unit (ADU): unit of source data provided as payload 215 to the transport layer. Depending on the use case, an ADU may use 216 an RTP encapsulation. 218 ADU Information (ADUI): unit of data constituted by the ADU and the 219 associated Flow ID, Length and Padding fields. 221 FEC Framework Configuration Information (FFCI): information that 222 controls the operation of FECFRAME. Each FEC Framework instance 223 has its own configuration information. And the FFCI enables the 224 synchronization of the FECFRAME sender and receiver instances. 226 FEC Source Packet: at a sender (respectively, at a receiver) a 227 payload submitted to (respectively, received from) the transport 228 protocol containing an ADU along with an Explicit Source FEC 229 Payload ID. 231 FEC Repair Packet: at a sender (respectively, at a receiver) a 232 payload submitted to (respectively, received from) the transport 233 protocol containing one repair symbol along with a Repair FEC 234 Payload ID and possibly an RTP header. 236 3.2. Notations 238 This document uses the following notations and some of them are FEC 239 scheme-specific: 241 m: defines the length of the elements in the finite field, in bits. 242 In this document, m is such that m=8. 244 GF(q): denotes a finite field (also known as the Galois Field) with 245 q elements. We assume that q = 2^^m in this document. 247 a^^b: denotes a raised to the power b. 249 E: denotes the size of an encoding symbol length in bytes. 251 cw_size: denotes coding window size (in symbols). 253 cw_size_max: denotes coding window maximum size (in symbols). 255 gc: denotes the count of symbol groups participating in encoding (if 256 there is a gap in the serial number, it is considered a new group) 257 when a repair symbol is generated. 259 gc_max: denotes the maximum count of symbol groups involved in 260 encoding when generating maintenance symbols. 262 cm: denotes coding matrix. 264 cm_r: denotes row in the coding matrix. 266 cm_c: denotes col in the coding matrix. 268 ESI: denotes the first source symbol of the ADUI corresponding to 269 this FEC Source Packet. 271 Start_ESI: denotes the first ADUI's ESI of the first group. 273 Residual_ESI_: denotes the residual value of the starting ESI of the 274 current group relative to the previous group. 276 Group_Size_: denotes the number of ADUIs contained in each group. 278 3.3. Abbreviations 280 This document uses the following abbreviations, and some of them are 281 FEC scheme-specific: 283 FEC: stands for Forward Error (or Erasure) Correction codes. 285 ADU: stands for Application Data Unit. 287 ADUI: stands for Application Data Unit Information. 289 ESI: stands for Encoding Symbol ID. 291 FFCI: stands for FEC Framework Configuration Information. 293 FSSI: stands for FEC Scheme-Specific Information. 295 4. Formats and Codes 297 This section describes the format of FEC Framework Configuration 298 Information (or FFCI) and FEC Payload IDs, which are carried in "big- 299 endian" or "network order" format. 301 4.1. FEC Framework Configuration Information 303 The FFCI needs to be shared between FECFRAME sender and receiver 304 instances to ensure the synchronization of information. It includes 305 mandatory elements (e.g., FEC Encoding ID) and scheme-specific 306 elements (e.g., Encoding Symbol size). 308 4.1.1. Mandatory 310 FEC Encoding ID: the value assigned to this Fully-Specified FEC 311 scheme MUST be XXX, as assigned by IANA(Section 9). 313 4.1.2. FEC Scheme-Specific Information 315 The FEC scheme-specific information (FSSI) of this scheme is as 316 follows: 318 Encoding Symbol size (E): a non-negative integer that indicates the 319 size of each encoding symbol in bytes; 321 The maximum coding window size (cw_size_max): a non-negative integer 322 that indicates the maximum size of the coding window allowed (in 323 symbols); 325 The maximum number of gc (gc_max): a non-negative integer that 326 indicates the maximum count of groups protected by each repair 327 packet. 329 These elements are required both by the encoder and decoder. 331 When SDP is used to communicate the FFCI, this FEC Scheme-Specific 332 Information MUST be carried in the 'fssi' parameter in textual 333 representation specified in [RFC6364]. For instance: 335 fssi=E:1500,cw_size_max:128,gc_max:4 337 If another mechanism requires the FSSI to be carried as an opaque 338 octet string (for instance after a Base64 encoding), the encoding 339 format consists of the following four octets: 341 Encoding symbol length (E): 16-bit field; 343 Maximum coding window size (cw_size_max): 8-bit field; 345 Maximum size of gc (gc_max): 8-bit field. 347 The encoding format consists of the following 4 octets of Figure 1: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Encoding Symbol Length (E) | cw_size_max | gc_max | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 1: FSSI Encoding Format 357 4.2. FEC Payload IDs 359 4.2.1. Explicit Source FEC Payload ID 361 A FEC Source Packet MUST contain an Explicit Source FEC Payload ID 362 that is appended to the end of the packet as illustrated in Figure 2. 364 +---------------------------------+ 365 | IP Header | 366 +---------------------------------+ 367 | Transport Header | 368 +---------------------------------+ 369 | ADUI | 370 +---------------------------------+ 371 | Explicit Source FEC Payload ID | 372 +---------------------------------+ 374 Figure 2: Structure of an FEC Source Packet with the Explicit 375 Source FEC Payload ID 377 More precisely, the Explicit Source FEC Payload ID is composed of the 378 following field: 380 Encoding Symbol ID (ESI) (32-bit field): this unsigned integer 381 identifies the first source symbol of the ADUI corresponding to 382 this FEC Source Packet. The ESI is incremented for each new 383 source symbol, and after reaching the maximum value (2^^32-1), 384 wrapping to zero occurs. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Encoding Symbol ID (ESI) | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 3: Source FEC Payload ID Encoding Format 394 4.2.2. Repair FEC Payload ID 396 A FEC repair packet MUST contain a Repair FEC Payload ID prepended to 397 the repair symbol as illustrated in Figure 4. There MUST be a single 398 repair symbol per FEC repair packet. 400 +---------------------------------+ 401 | IP Header | 402 +---------------------------------+ 403 | Transport Header | 404 +---------------------------------+ 405 | Repair FEC Payload ID | 406 +---------------------------------+ 407 | Repair Symbol | 408 +---------------------------------+ 410 Figure 4: Structure of an FEC Repair Packet with the Repair FEC 411 Payload ID 413 More precisely, the SLC decoder scheme require the following 414 information from the Repair FEC Payload ID: 416 Start_ESI (32-bit field): this unsigned integer indicates the ESI of 417 the first source symbol of the first group in the encoding window 418 when this repair symbol was generated. 420 gc (8-bit field): this unsigned integer indicates the number of 421 symbol groups in the encoding window when this repair symbol is 422 generated (if there is a gap in the serial number, it is 423 considered a new group). 425 cm_r (8-bit field): this unsigned integer is used as a parameter to 426 generate the desired encoding matrix. This cm_r MUST NOT be 427 greater than cw_size_max. 429 Residual_ESI_ (8-bit field): this unsigned integer represents the 430 residual value of the starting ESI of the current group relative 431 to the previous group. 433 Group_Size_ (8-bit field): this unsigned integer is the number of 434 the source symbols contained in each group. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Start_ESI | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | gc | cm_r | Residual_ESI_2| ... | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |Residual_ESI_gc| Group_Size_1 | ... | Group_Size_gc | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 5: Repair FEC Payload ID Encoding Format 448 The length of the Repair FEC Payload ID depends on the gc parameter. 450 5. Procedures 452 5.1. Restrictions 454 This specification has the following restrictions: 456 1. There MUST be exactly one source symbol per ADUI, and therefore 457 per ADI; 459 2. There MUST be exactly one repair symbol per FEC Repair Packet. 461 5.2. ADU, ADUI, and Source Symbols Mappings 463 Before FEC coding, the mapping from ADU to AUDI needs to be 464 established. When multiple source flows (e.g., media streams) are 465 mapped onto the same FECFRAME instance, each flow is assigned its 466 Flow ID value. The Flow ID needs to be included in the ADUI. Then, 467 the recovered ADU can be allocated to the corresponding source flow 468 by its Flow ID. 470 Because the length of each ADU may be inconsistent, to ensure that 471 the decoder can extract ADU from ADUI, the original ADU length also 472 needs to be added to ADUI. 474 For each incoming ADU, an ADUI MUST be created as follows. First of 475 all, 3 bytes are prepended (Figure 6): 477 Flow ID (F) (8-bit field): this unsigned byte contains the integer 478 identifier associated with the source ADU flow to which this ADU 479 belongs. 481 Length (L) (16-bit field): this unsigned integer contains the length 482 of this ADU in network byte order (i.e., big endian). This length 483 is for the ADU itself and does not include the F, or Pad fields. 485 Then, zero padding is added to the ADU if needed: 487 Padding (Pad) (variable size field): this field is used for 488 alignment purposes up to a size of exactly E bytes. 490 The data unit resulting from the ADU and the F, L, and Pad fields is 491 called ADUI. An ADUI always contributes to an integral number of 492 source symbols. 494 Encoding Symbol Length (E) 495 +-------+-------------+------------------------+---------+ 496 | F | L | ADU | Pad | 497 +-------+-------------+------------------------+---------+ 498 \___________________________ ____________________________/ 499 v 501 SLC FEC encoding 502 +--------------------------------------------------------+ 503 | Repair | 504 +--------------------------------------------------------+ 506 Figure 6: ADUI Creation Example 508 5. Encoding Window Management 510 Whenever an ADU arrives, ADU-to-source symbols mapping will be 511 performed. Then, the source symbols will be added to the array 512 source_symbol_history. Whenever a repair symbol needs to be 513 generated, the SLC FEC encoder will search backward in the 514 source_symbol_history, and the source symbols that conforms the rules 515 defined by the application will be put into the encoding window. 516 When the encoding window cw_size is equal to its maximum value 517 cw_size_max or the symbol group count gc is equal to its maximum 518 value gc_max, the search is stopped and the FEC coding will be 519 performed on the source symbols in the encoding window. 521 Taking Figure 7 as an example, the coding dependency between frames 522 is used as the rule of source symbol selection, and frame I is the 523 reference frame of frame P1, so I and P1 are placed in the encoding 524 window when generating Repair2. However, P1 is not the reference 525 frame of P2 under the SVC mode, so P1 is skipped, I and P2 are put 526 into the encoding window to generate Repair3. The same process is 527 performed to produce Rapair4 and Repair5. 529 | +---+ FEC coding +-------+ 530 | | I |------------->|Repair1| 531 | +---+ +-------+ 532 | 533 | +---+ +----+ FEC coding +-------+ 534 | | I |--->| P1 |------------->|Repair2| 535 | +---+ +----+ +-------+ 536 | +-------------+ 537 | | | 538 | +---+ +----+ | +----+ FEC coding +-------+ 539 | | I | | | +-->| P2 |------------->|Repair3| 540 | +---+ +----+ +----+ +-------+ 541 | +-------------+ 542 | | | 543 | +---+ +----+ | +----+ +----+ FEC coding +-------+ 544 | | I | | | +-->| P2 |--->| P3 |------------->|Repair4| 545 | +---+ +----+ +----+ +----+ +-------+ 546 | +-------------+ +-------------+ 547 | | | | | 548 | +---+ +----+ | +----+ +----+ | +----+ FEC coding +-------+ 549 | | I | | | +-->| P2 | | | +-->| P4 |------------->|Repair5| 550 | +---+ +----+ +----+ +----+ +----+ +-------+ 551 | 552 | time 554 Figure 7: Example of Encoding Window Management 556 Note that each time the encoding window slides, cm_r will update. 557 The update rules are as follows: 559 if (++cm_r>=cw_size_max) cm_r=0; 561 5.4. Coding Matrix Generation 563 Compared with the RLC FEC encoder, which depends on a pseudorandom 564 number generator to compute the coding coefficients, the SLC FEC 565 encoder uses a fixed coding matrix to reduce overhead. The elements 566 of the coding matrix used during the encoding process are generated 567 at the SLC FEC encoder each time a new repair symbol needs to be 568 produced. The cm_r and cm_c parameters control these elements. The 569 values of cm_c between 0 (the minimum value) and cw_size_max-1 (the 570 maximum value). And the values of cm_r between 0 and 571 255-cw_size_max. 573 G (cm_r, cm_c) = y_c / (x_r + y_c) = (cm_c + cw_size_max) / (cm_r 574 + cm_c + cw_size_max) 576 where cm_r represents the row number in the matrix, cm_c represents 577 the col number in the matrix, cw_size_max represents the maximum 578 value of the encoding window, x_r = cm_r, y_c = cw_size_max+cm_c. 579 The basic operations of the above equations are carried out in the GF 580 (2^^8). 582 5.5. Linear Operation on encoding side and decoding side 584 5.5.1. Encoding Side 586 In Section 5.4, the elements of coding matrix G(cm_r, cm_c) are 587 obtained. Then, a repair symbol is generated by the computation of a 588 linear combination of source symbols. 590 A linear combination of the cw_size source symbols present in the 591 encoding window, say src_0 to src_cw_size_1, is computed as follows. 592 For each byte of position i in each source and the repair symbol, 593 where i belongs to [0; E-1]. 595 repair[i] = G(cm_r, 0) * src_0[i] + G(cm_r, 1) * src_1[i] + ... + 596 G(cm_r, cw_size-1) * src_cw_size_1[i] 598 where * is the multiplication over GF (2^^8), + is the addition over 599 GF (2^^8). In this document, the following irreducible polynomial is 600 used for GF(2^^8). 602 x^^8 + x^^4 + x^^3 + x^^2 + 1 604 5.5.2. Decoding Side 606 For decoding side, it is assumed that the repair symbol protects 607 cw_size source symbols, among which j source symbols are lost, then, 609 remove_src[i] = repair[i] - G(cm_r, 0) * src_0[i] - ... - G(cm_r, 610 k) * src_k[i] - G(cm_r, k + j + 1) * src_k_j_1[i] - ... - G(cm_r, 611 cw_size-1) * src_cw_size_1[i] 613 It is assumed that in the linear system maintained by the decoding 614 side, there is a symbol sequence S = {lost_src_1, lost_src_2, ... , 615 lost_src_N} consisting of N lost source symbols, a symbol sequence R 616 = {repair_1, repair_2, ... , repair_N} consisting of N repair symbols 617 There is a matrix A whose row represents the position of the repair 618 symbol in R and whose column represents the position of the lost 619 source symbol in S. A[row][col] represents the matrix element of 620 lost_src_row corresponding to repair_col (if it does not exist, then 621 A[row][col] = 0). 623 A[row][col] = G(cm_r,cm_c) 625 where cm_r can be extracted from the Repair FEC Payload ID, cm_c 626 represents the position of the lost source symbol in the encoding 627 window. 629 Therefore, there is a linear system of equation as follows: 631 A * Transpose(lost_src_1, lost_src_2, ... , lost_src_N) = 632 Transpose(remove_src_1, remove_src_2, ... , remove_src_N) 634 The inverse matrix of A can be obtained by Gauss elimination method, 635 and finally S can be recovered: 637 Transpose(lost_src_1, lost_src_2, ... , lost_src_N) = A^^-1 * 638 Transpose(remove_src_1, remove_src_2, ... , remove_src_N) 640 6. FEC Code Specification 642 6.1. Encoding Side 644 1. Whenever a new repair symbol needs to be produced, the source 645 symbols are put into the sliding encoding window according to the 646 rule defined by application (e.g., coding dependency between frames). 648 2. The SLC FEC encoder gathers the cw_size source symbols currently 649 in the sliding encoding window. 651 3. The elements of the coding matrix are determined according to the 652 parameters cm_r and cm_c (Section 5.4). 654 4. The SLC FEC encoder computes the repair symbol by a linear 655 combination of the cw_size source symbols present in the encoding 656 window using the coding matrix (Section 5.5.1). 658 When encoding, the execution object is ADUI composed of Flow ID, 659 Length, ADU, Padding. 661 6.2. Decoding Side 663 1. A linear system composed of source symbols, elements of the 664 coding matrix, and repair symbols MUST to be maintained to recover 665 the lost source packets. 667 2. When a repair symbol is received, it detects whether there is 668 loss in the protected source symbols. If at least one of the 669 corresponding source symbols has been lost, an equation composed of 670 the repair symbol, the corresponding source symbols, and the elements 671 of the coding matrix will be added to the linear system (the elements 672 of the coding matrix are generated by the method provided in 673 Section 5.4). 675 3. When the linear system covering one or more lost source symbols 676 is full, decoding is performed in order to recover lost source 677 symbols (Section 5.5.2). 679 4. Each time an ADUI can be totally recovered, padding is removed 680 (thanks to the Length field, L, of the ADUI), and the ADU will be 681 assigned to the corresponding flow. 683 Note that the recovered source symbols can be directly passed to the 684 application through the callback function, or passed to the 685 application after receiving a certain number of source symbols, which 686 depends on the operation decision of the application. 688 7. Security Considerations 690 The FEC Framework document [RFC6363] provides a comprehensive 691 analysis of security considerations applicable to FEC schemes. 692 Therefore, the present section follows the security considerations 693 section of [RFC6363] and only discusses specific topics. 695 7.1. Attacks Against the Data Flow 697 7.1.1. Access to Confidential Content 699 The Sliding Window SLC FEC scheme specified in this document does not 700 change the recommendations of [RFC6363]. To summarize, if 701 confidentiality is a concern, it is RECOMMENDED that one of the 702 solutions mentioned in [RFC6363] is used with special considerations 703 to the way this solution is applied (e.g., is encryption applied 704 before or after FEC protection, within the end system or in a 705 middlebox), to the operational constrains (e.g., performing FEC 706 decoding in a protected environment may be complicated or even 707 impossible) and to the threat model. 709 7.1.2. Content Corruption 711 The Sliding Window SLC FEC scheme specified in this document does not 712 change the recommendations of [RFC6363]. To summarize, it is 713 RECOMMENDED that one of the solutions mentioned in [RFC6363] is used 714 on both the FEC Source and Repair Packets. 716 7.2. Attacks Against the FEC Parameters 718 The Sliding Window SLC FEC scheme specified in this document defines 719 parameters that can be the basis of attacks. More specifically, the 720 following parameters of the FEC Framework Configuration Information 721 may be modified by an attacker (Section 4.1): 723 FEC Encoding ID: changing this parameter leads the receiver to 724 consider a different FEC Scheme. It will lead to severe 725 consequences that the format of the AUDI, the Explicit Source FEC 726 Payload ID, and Repair FEC Payload ID of received packets will 727 probably differ. The FEC decoder can't get the correct decoding 728 information, resulting in decoding failure or decoding error. 730 Encoding symbol length (E): setting this E parameter to a different 731 value will enable an attacker to create a DoS since the repair 732 symbols and certain source symbols will be larger or smaller than 733 E, incoherency for the receiver. 735 Therefore, it is RECOMMENDED that security measures be taken to 736 guarantee the FFCI integrity, as specified in [RFC6363]. How to 737 achieve this depends on how the FFCI is communicated from the sender 738 to the receiver, which is not specified in this document. 740 Similarly, attacks are possible against the Explicit Source FEC 741 Payload ID and Repair FEC Payload ID. More specifically, in the case 742 of an FEC Source Packet, the following value can be modified by an 743 attacker who targets receivers: 745 Encoding Symbol ID (ESI): changing the ESI leads a receiver to 746 consider a wrong ADU, resulting in severe consequences, including 747 corrupted content passed to the receiving application. And in the 748 case of an FEC Repair Packet. 750 Start_ESI: changing this value causes the FEC decoder to add the 751 wrong source symbol in the linear system, and therefore any source 752 symbol recovered by the linear system may be wrong. 754 gc: changing this value causes the FEC decoder to add an incorrect 755 number of source symbols in the linear system. Therefore any 756 source symbol recovered by the linear system may be wrong. 758 cm_r: changing this value leads a receiver to generate a wrong 759 coding coefficient, and therefore any source symbol decoded using 760 the repair symbol contained in this packet will be corrupted. 762 Residual_ESI_: changing this value causes the FEC decoder to add the 763 wrong source symbol in the linear system, and therefore any source 764 symbol recovered by the linear system may be wrong. 766 Group_Size_: changing this value causes the FEC decoder to add an 767 incorrect number of source symbols in the linear system. 768 Therefore any source symbol recovered by the linear system may be 769 wrong. 771 Therefore, it is RECOMMENDED that security measures are taken to 772 guarantee the FEC Source and Repair Packets as stated in [RFC6363]. 774 7.3. When Several Source Flows Are to Be Protected Together 776 The Sliding Window SLC FEC scheme specified in this document does not 777 change the recommendations of [RFC6363]. 779 7.4. Baseline Secure FECFRAME Operation 781 The Sliding Window SLC FEC scheme specified in this document does not 782 change the recommendations of [RFC6363] concerning the use of the 783 IPsec/Encapsulating Security Payload (ESP) security protocol as a 784 mandatory-to-implement (but not mandatory-to-use) security scheme. 785 This is well suited to situations where the only insecure domain is 786 the one over which the FEC Framework operates. 788 8. Operations and Management Considerations 790 The FECFRAME document [RFC6363] provides a comprehensive analysis of 791 operations and management considerations applicable to FEC schemes. 792 Therefore, the present section only discusses specific topics. 794 8.1. Operational Recommendations: gc_max 796 The Sliding Window SLC FEC scheme specified in this document defines 797 the maximum number of groups participating in encoding, called 798 gc_max, reflecting the maximum number of source symbols that the 799 coding window can hold. Gc_max is directly proportional to the 800 computational complexity of FEC encoding. If gc_max is too large, 801 the time complexity of FEC encoding will be too high, and the CPU 802 overhead will be too large. Generally, it is appropriate to 803 associate gc_max with cw_size_max. 805 For example, in real-time video streaming applications, the frame 806 rate (FR) and bit rate (BR) is determined by transmitting the video 807 frames. The possible number of packets per frame can be calculated 808 according to FR and BR, and they can calculate the maximum number of 809 symbols in the coding window. 811 BR kbps / 8 / FR fps / MTU * gc_max <= cw_size_max 813 Where MTU denotes Maximum Transmission Unit. 815 9. IANA Considerations 817 This document registers one values in the "FEC Framework (FECFRAME) 818 FEC Encoding IDs" sub-registry as follows: 820 XXX refers to the Sliding Window Selective Linear Code (SLC) Forward 821 Error Correction (FEC) Scheme for Arbitrary Packet Flows. 823 10. Acknowledgments 825 The authors would like to thank the FEC Framework Design Team for 826 providing a great FEC Framework. The authors would also like to 827 thank Shie Qian for reviewing the earlier draft versions of this 828 document. 830 11. References 832 11.1. Normative References 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14, RFC 2119, 836 DOI 10.17487/RFC2119, March 1997, 837 . 839 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 840 Correction (FEC) Building Block", RFC 5052, 841 DOI 10.17487/RFC5052, August 2007, 842 . 844 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 845 Correction (FEC) Framework", RFC 6363, 846 DOI 10.17487/RFC6363, October 2011, 847 . 849 [RFC6364] Begen, A., "Session Description Protocol Elements for the 850 Forward Error Correction (FEC) Framework", RFC 6364, 851 DOI 10.17487/RFC6364, October 2011, 852 . 854 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 855 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 856 May 2017, . 858 [RFC8680] Roca, V. and A. Begen, "Forward Error Correction (FEC) 859 Framework Extension to Sliding Window Codes", RFC 8680, 860 DOI 10.17487/RFC8680, January 2020, 861 . 863 11.2. Informative References 865 [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity 866 Check (LDPC) Staircase and Triangle Forward Error 867 Correction (FEC) Schemes", RFC 5170, DOI 10.17487/RFC5170, 868 June 2008, . 870 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 871 "Reed-Solomon Forward Error Correction (FEC) Schemes", 872 RFC 5510, DOI 10.17487/RFC5510, April 2009, 873 . 875 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 876 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 877 DOI 10.17487/RFC6681, August 2012, 878 . 880 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 881 Parity Check (LDPC) Staircase Forward Error Correction 882 (FEC) Scheme for FECFRAME", RFC 6816, 883 DOI 10.17487/RFC6816, December 2012, 884 . 886 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 887 Matsuzono, "Simple Reed- Solomon Forward Error Correction 888 (FEC) Scheme for FECFRAME", RFC 6865, 889 DOI 10.17487/RFC6865, February 2013, 890 . 892 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 893 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 894 Pedersen, M., Peralta, G., Roca, V., Saxena, P., and S. 895 Sivakumar, "Taxonomy of Coding Techniques for Efficient 896 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 897 June 2018, . 899 [RFC8681] Roca, V. and B. Teibi, "Sliding Window Random Linear Code 900 (RLC) Forward Erasure Correction (FEC) Schemes for 901 FECFRAME", RFC 8681, DOI 10.17487/RFC8681, February 2020, 902 . 904 Authors' Addresses 906 Ray Wang 907 Agora Lab 908 China 910 Email: wangrui@agora.io 912 Liang Si 913 Agora Lab 914 China 916 Email: siliang@agora.io 918 Bifeng He 919 Agora Lab 920 China 922 Email: hebifeng@agora.io