Skip to main content

Sliding Window Selective Linear Code (SLC) Forward Error Correction (FEC) Scheme for FECFRAME
draft-wang-tsvwg-sw-slc-fec-scheme-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Ray Wang , Liang Si , Bifeng He
Last updated 2022-06-14 (Latest revision 2021-12-13)
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wang-tsvwg-sw-slc-fec-scheme-02
TSVWG                                                            R. Wang
Internet-Draft                                                     L. Si
Intended status: Standards Track                                   B. He
Expires: 16 December 2022                                      Agora Lab
                                                            14 June 2022

  Sliding Window Selective Linear Code (SLC) Forward Error Correction
                       (FEC) Scheme for FECFRAME
                 draft-wang-tsvwg-sw-slc-fec-scheme-02

Abstract

   RFC8680 describes a framework for using Sliding Window Forward Error
   Correction(FEC) codes to protection against packet loss, the
   framework significantly improves FEC efficiency and reduces FEC-
   related added latency compared to block FEC codes defined in RFC
   6363.  RFC8681 further describes two fully specified FEC schemes for
   Sliding Window Random Linear Codes(RLC), the schemes rely on an
   encoding window that slides over a continuous set of source symbols,
   generating new repair symbols whenever needed.  This document
   describes a fully specified FEC scheme for Sliding Window Selective
   Linear Code(SLC) over the Galois Field GF (2^^8) , compared to
   RFC8681, this framework use a discrete encoding window which can
   protect arbitrary media streams selectively, and has better recovery
   performance in scenarios such as layered video coding or mixed
   streams for video streaming applications.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 16 December 2022.

Wang, et al.            Expires 16 December 2022                [Page 1]
Internet-Draft               SLC FEC Scheme                    June 2022

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Definitions Notations and Abbreviations . . . . . . . . . . .   5
     3.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Notations . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Formats and Codes . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  FEC Framework Configuration Information . . . . . . . . .   7
       4.1.1.  Mandatory . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.2.  FEC Scheme-Specific Information . . . . . . . . . . .   7
     4.2.  FEC Payload IDs . . . . . . . . . . . . . . . . . . . . .   8
       4.2.1.  Explicit Source FEC Payload ID  . . . . . . . . . . .   8
       4.2.2.  Repair FEC Payload ID . . . . . . . . . . . . . . . .   9
   5.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Restrictions  . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  ADU, ADUI, and Source Symbols Mappings  . . . . . . . . .  10
     5.  Encoding Window Management  . . . . . . . . . . . . . . . .  11
     5.4.  Coding Matrix Generation  . . . . . . . . . . . . . . . .  12
     5.5.  Linear Operation on encoding side and decoding side . . .  13
       5.5.1.  Encoding Side . . . . . . . . . . . . . . . . . . . .  13
       5.5.2.  Decoding Side . . . . . . . . . . . . . . . . . . . .  13
   6.  FEC Code Specification  . . . . . . . . . . . . . . . . . . .  14
     6.1.  Encoding Side . . . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Decoding Side . . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     7.1.  Attacks Against the Data Flow . . . . . . . . . . . . . .  15
       7.1.1.  Access to Confidential Content  . . . . . . . . . . .  15
       7.1.2.  Content Corruption  . . . . . . . . . . . . . . . . .  16
     7.2.  Attacks Against the FEC Parameters  . . . . . . . . . . .  16
     7.3.  When Several Source Flows Are to Be Protected Together  .  17
     7.4.  Baseline Secure FECFRAME Operation  . . . . . . . . . . .  17
   8.  Operations and Management Considerations  . . . . . . . . . .  17

Wang, et al.            Expires 16 December 2022                [Page 2]
Internet-Draft               SLC FEC Scheme                    June 2022

     8.1.  Operational Recommendations: gc_max . . . . . . . . . . .  17
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     11.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   The use of Application-Level Forward Erasure Correction (AL-FEC)
   codes is a widely-used error control method used to improve the
   reliability of unicast, multicast, and broadcast transmissions.

   The [RFC5052] document describes a general framework to use FEC in
   Content Delivery Protocols (CDPs), and it is suitable for FEC schemes
   based on building blocks.  Based on this framework, the [RFC5170]
   describes two fully-specified FEC Schemes, Low-Density Parity Check
   (LDPC) Staircase and LDPC Triangle, and the [RFC5510] describes one
   Fully-Specified FEC Scheme for the special case of Reed-Solomon (RS)
   over GF (2^^8).

   The [RFC6363] document describes a general framework used to protect
   arbitrary media streams along the lines defined by FECFRAME.  The FEC
   scheme defined by the framework does not limit the type of input
   data, but only processes the data.

   Similar to [RFC5052], [RFC6363] only considers block FEC schemes,
   which requires that the input stream be divided into a series of
   blocks according to the block partitioning algorithm defined in
   [RFC5052].  The [RFC6681], [RFC6816], and [RFC6865] are FEC schemes
   based on this framework.  The value for the block size affects the
   packet loss resistance and the encoding and decoding delay of the FEC
   scheme.  At the same code rate, the FEC scheme with larger size
   blocks have higher robustness (e.g., in case of long packet erasure
   bursts), but it has higher decoding delay which is unacceptable for
   real-time video streaming application.

   The framework described in [RFC8680] provides support for FEC codes
   based on a sliding coding window.  The FEC scheme in this framework
   [RFC8681] is advantageous for real-time flows because of its high
   robustness and low additional delay.

   In general video coding, all frames in a GOP follow the rule of the
   frame by frame reference, that is, the reconstruction of the current
   video frame relies on the preceding frame.  In that case, all frames
   in the encoding window are beneficial to the decoding of the current
   frame.  However, for layered video coding, video frames may not

Wang, et al.            Expires 16 December 2022                [Page 3]
Internet-Draft               SLC FEC Scheme                    June 2022

   reference the preceding frames, but the upper layer frames.  When
   non-reference frames are encoded, the recovered packets will not help
   the decoding of the current frame, and even have a negative effect on
   the FEC error correction ability in extreme cases [Hel2011],
   [Wan2022].

   This document introduces one fully specified FEC scheme, it is
   capable to protect streams selectively by adding a filter into the
   FEC coding window management.  The Sliding Window SLC FEC scheme
   described in this document belongs to the broad class of Sliding
   Window AL-FEC Codes (a.k.a., convolutional codes) [RFC8406].  The
   encoding process is based on an encoding window, and the source
   symbols are encoded by sliding the encoding window.  However, the
   encoding window does not slide directly over the set of the source
   symbols.  Instead, it filters the source symbols according to the
   rule defined by application (e.g., video frame dependency, or stream
   type) and then slide over the set of these filtered source symbols
   [Wan2022].  Repair symbols are generated on-the-fly, by the
   computation of a linear combination of source symbols present in the
   current encoding window and passed to the transport layer.

   When the loss of source symbol is detected at the receiver, the SLC
   decoder will recover the lost source symbol according to the linear
   combination of the source symbols and each received repair symbol
   (when the rank of the equations involved is solvable).

   This fully-specified FEC scheme follows the structure required by
   [RFC6363], Section 5.6 ("FEC Scheme Requirements"), namely:

   *  Formats and Codes: This section defines the FEC Framework
      Configuration Information (FFCI) carrying signaling, including
      mandatory elements and Scheme-Specific elements.  It also defines
      the Source FEC Payload ID and Repair FEC Payload ID formats,
      carrying the signaling information associated with each source or
      repair symbol, including ESI, indexes of source symbols
      participating in encoding, and coding coefficients.

   *  Procedures: This section describes procedures specific to this FEC
      scheme, including encoding window management, coding matrix
      generation, a linear combination of source symbol computation in
      Finite Field, and the mapping between ADU, ADUI, and Source
      Symbols.

   *  FEC Code Specification: This section provides a high-level
      description of the Sliding Window SLC encoder and decoder.

Wang, et al.            Expires 16 December 2022                [Page 4]
Internet-Draft               SLC FEC Scheme                    June 2022

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] [RFC8174].

3.  Definitions Notations and Abbreviations

3.1.  Definitions

   This document uses the following terms and definitions.  Some of
   these terms and definitions are FEC scheme-specific and are in line
   with [RFC5052] [RFC6363]:

   Source symbol:  unit of data used during the encoding process.

   Encoding symbol:  unit of data generated by the encoding process.

   Repair symbol:  an encoding symbol that is not a source symbol.

   Packet erasure channel:  a communication path where packets are
      either dropped (e.g., by a congested router, or because the number
      of transmission errors exceeds the correction capabilities of the
      physical layer codes) or received.  When a packet is received, it
      is assumed that this packet is not corrupted.

   Application Data Unit (ADU):  unit of source data provided as payload
      to the transport layer.  Depending on the use case, an ADU may use
      an RTP encapsulation.

   ADU Information (ADUI):  unit of data constituted by the ADU and the
      associated Flow ID, Length and Padding fields.

   FEC Framework Configuration Information (FFCI):  information that
      controls the operation of FECFRAME.  Each FEC Framework instance
      has its own configuration information.  And the FFCI enables the
      synchronization of the FECFRAME sender and receiver instances.

   FEC Source Packet:  at a sender (respectively, at a receiver) a
      payload submitted to (respectively, received from) the transport
      protocol containing an ADU along with an Explicit Source FEC
      Payload ID.

   FEC Repair Packet:  at a sender (respectively, at a receiver) a
      payload submitted to (respectively, received from) the transport
      protocol containing one repair symbol along with a Repair FEC
      Payload ID and possibly an RTP header.

Wang, et al.            Expires 16 December 2022                [Page 5]
Internet-Draft               SLC FEC Scheme                    June 2022

3.2.  Notations

   This document uses the following notations and some of them are FEC
   scheme-specific:

   m:  defines the length of the elements in the finite field, in bits.
      In this document, m is such that m=8.

   GF(q):  denotes a finite field (also known as the Galois Field) with
      q elements.  We assume that q = 2^^m in this document.

   a^^b:  denotes a raised to the power b.

   E:  denotes the size of an encoding symbol length in bytes.

   cw_size:  denotes coding window size (in symbols).

   cw_size_max:  denotes coding window maximum size (in symbols).

   gc:  denotes the count of symbol groups participating in encoding (if
      there is a gap in the serial number, it is considered a new group)
      when a repair symbol is generated.

   gc_max:  denotes the maximum count of symbol groups involved in
      encoding when generating maintenance symbols.

   cm:  denotes coding matrix.

   cm_r:  denotes row in the coding matrix.

   cm_c:  denotes col in the coding matrix.

   ESI:  denotes the first source symbol of the ADUI corresponding to
      this FEC Source Packet.

   Start_ESI:  denotes the first ADUI's ESI of the first group.

   Residual_ESI_:  denotes the residual value of the starting ESI of the
      current group relative to the previous group.

   Group_Size_:  denotes the number of ADUIs contained in each group.

3.3.  Abbreviations

   This document uses the following abbreviations, and some of them are
   FEC scheme-specific:

   FEC:  stands for Forward Error (or Erasure) Correction codes.

Wang, et al.            Expires 16 December 2022                [Page 6]
Internet-Draft               SLC FEC Scheme                    June 2022

   ADU:  stands for Application Data Unit.

   ADUI:  stands for Application Data Unit Information.

   ESI:  stands for Encoding Symbol ID.

   FFCI:  stands for FEC Framework Configuration Information.

   FSSI:  stands for FEC Scheme-Specific Information.

4.  Formats and Codes

   This section describes the format of FEC Framework Configuration
   Information (or FFCI) and FEC Payload IDs, which are carried in "big-
   endian" or "network order" format.

4.1.  FEC Framework Configuration Information

   The FFCI needs to be shared between FECFRAME sender and receiver
   instances to ensure the synchronization of information.  It includes
   mandatory elements (e.g., FEC Encoding ID) and scheme-specific
   elements (e.g., Encoding Symbol size).

4.1.1.  Mandatory

   FEC Encoding ID:  the value assigned to this Fully-Specified FEC
      scheme MUST be XXX, as assigned by IANA(Section 9).

4.1.2.  FEC Scheme-Specific Information

   The FEC scheme-specific information (FSSI) of this scheme is as
   follows:

   Encoding Symbol size (E):  a non-negative integer that indicates the
      size of each encoding symbol in bytes;

   The maximum coding window size (cw_size_max):  a non-negative integer
      that indicates the maximum size of the coding window allowed (in
      symbols);

   The maximum number of gc (gc_max):  a non-negative integer that
      indicates the maximum count of groups protected by each repair
      packet.

   These elements are required both by the encoder and decoder.

Wang, et al.            Expires 16 December 2022                [Page 7]
Internet-Draft               SLC FEC Scheme                    June 2022

   When SDP is used to communicate the FFCI, this FEC Scheme-Specific
   Information MUST be carried in the 'fssi' parameter in textual
   representation specified in [RFC6364].  For instance:

                 fssi=E:1500,cw_size_max:128,gc_max:4

   If another mechanism requires the FSSI to be carried as an opaque
   octet string (for instance after a Base64 encoding), the encoding
   format consists of the following four octets:

   Encoding symbol length (E):  16-bit field;

   Maximum coding window size (cw_size_max):  8-bit field;

   Maximum size of gc (gc_max):  8-bit field.

   The encoding format consists of the following 4 octets of Figure 1:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Encoding Symbol Length (E)  |  cw_size_max  |     gc_max    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: FSSI Encoding Format

4.2.  FEC Payload IDs

4.2.1.  Explicit Source FEC Payload ID

   A FEC Source Packet MUST contain an Explicit Source FEC Payload ID
   that is appended to the end of the packet as illustrated in Figure 2.

   +---------------------------------+
   |            IP Header            |
   +---------------------------------+
   |         Transport Header        |
   +---------------------------------+
   |               ADUI              |
   +---------------------------------+
   | Explicit Source FEC Payload ID  |
   +---------------------------------+

       Figure 2: Structure of an FEC Source Packet with the Explicit
                           Source FEC Payload ID

   More precisely, the Explicit Source FEC Payload ID is composed of the
   following field:

Wang, et al.            Expires 16 December 2022                [Page 8]
Internet-Draft               SLC FEC Scheme                    June 2022

   Encoding Symbol ID (ESI) (32-bit field):  this unsigned integer
      identifies the first source symbol of the ADUI corresponding to
      this FEC Source Packet.  The ESI is incremented for each new
      source symbol, and after reaching the maximum value (2^^32-1),
      wrapping to zero occurs.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Encoding Symbol ID (ESI)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: Source FEC Payload ID Encoding Format

4.2.2.  Repair FEC Payload ID

   A FEC repair packet MUST contain a Repair FEC Payload ID prepended to
   the repair symbol as illustrated in Figure 4.  There MUST be a single
   repair symbol per FEC repair packet.

   +---------------------------------+
   |            IP Header            |
   +---------------------------------+
   |         Transport Header        |
   +---------------------------------+
   |       Repair FEC Payload ID     |
   +---------------------------------+
   |          Repair Symbol          |
   +---------------------------------+

      Figure 4: Structure of an FEC Repair Packet with the Repair FEC
                                 Payload ID

   More precisely, the SLC decoder scheme require the following
   information from the Repair FEC Payload ID:

   Start_ESI (32-bit field):  this unsigned integer indicates the ESI of
      the first source symbol of the first group in the encoding window
      when this repair symbol was generated.

   gc (8-bit field):  this unsigned integer indicates the number of
      symbol groups in the encoding window when this repair symbol is
      generated (if there is a gap in the serial number, it is
      considered a new group).

   cm_r (8-bit field):  this unsigned integer is used as a parameter to
      generate the desired encoding matrix.  This cm_r MUST NOT be
      greater than cw_size_max.

Wang, et al.            Expires 16 December 2022                [Page 9]
Internet-Draft               SLC FEC Scheme                    June 2022

   Residual_ESI_ (8-bit field):  this unsigned integer represents the
      residual value of the starting ESI of the current group relative
      to the previous group.

   Group_Size_ (8-bit field):  this unsigned integer is the number of
      the source symbols contained in each group.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Start_ESI                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       gc      |     cm_r      | Residual_ESI_2|      ...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Residual_ESI_gc|  Group_Size_1 |      ...      | Group_Size_gc |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 5: Repair FEC Payload ID Encoding Format

   The length of the Repair FEC Payload ID depends on the gc parameter.

5.  Procedures

5.1.  Restrictions

   This specification has the following restrictions:

   1.  There MUST be exactly one source symbol per ADUI, and therefore
      per ADI;

   2.  There MUST be exactly one repair symbol per FEC Repair Packet.

5.2.  ADU, ADUI, and Source Symbols Mappings

   Before FEC coding, the mapping from ADU to AUDI needs to be
   established.  When multiple source flows (e.g., media streams) are
   mapped onto the same FECFRAME instance, each flow is assigned its
   Flow ID value.  The Flow ID needs to be included in the ADUI.  Then,
   the recovered ADU can be allocated to the corresponding source flow
   by its Flow ID.

   Because the length of each ADU may be inconsistent, to ensure that
   the decoder can extract ADU from ADUI, the original ADU length also
   needs to be added to ADUI.

   For each incoming ADU, an ADUI MUST be created as follows.  First of
   all, 3 bytes are prepended (Figure 6):

Wang, et al.            Expires 16 December 2022               [Page 10]
Internet-Draft               SLC FEC Scheme                    June 2022

   Flow ID (F) (8-bit field):  this unsigned byte contains the integer
      identifier associated with the source ADU flow to which this ADU
      belongs.

   Length (L) (16-bit field):  this unsigned integer contains the length
      of this ADU in network byte order (i.e., big endian).  This length
      is for the ADU itself and does not include the F, or Pad fields.

   Then, zero padding is added to the ADU if needed:

   Padding (Pad) (variable size field):  this field is used for
      alignment purposes up to a size of exactly E bytes.

   The data unit resulting from the ADU and the F, L, and Pad fields is
   called ADUI.  An ADUI always contributes to an integral number of
   source symbols.

                   Encoding Symbol Length (E)
   +-------+-------------+------------------------+---------+
   |   F   |      L      |          ADU           |   Pad   |
   +-------+-------------+------------------------+---------+
   \___________________________ ____________________________/
                               v

                        SLC FEC encoding
   +--------------------------------------------------------+
   |                         Repair                         |
   +--------------------------------------------------------+

                      Figure 6: ADUI Creation Example

5.  Encoding Window Management

   Whenever an ADU arrives, ADU-to-source symbols mapping will be
   performed.  Then, the source symbols will be added to the array
   source_symbol_history.  Whenever a repair symbol needs to be
   generated, the SLC FEC encoder will search backward in the
   source_symbol_history, and the source symbols that conforms the rules
   defined by the application will be put into the encoding window.
   When the encoding window cw_size is equal to its maximum value
   cw_size_max or the symbol group count gc is equal to its maximum
   value gc_max, the search is stopped and the FEC coding will be
   performed on the source symbols in the encoding window.

   Taking Figure 7 as an example, the coding dependency between frames
   is used as the rule of source symbol selection, and frame I is the
   reference frame of frame P1, so I and P1 are placed in the encoding
   window when generating Repair2.  However, P1 is not the reference

Wang, et al.            Expires 16 December 2022               [Page 11]
Internet-Draft               SLC FEC Scheme                    June 2022

   frame of P2 under the SVC mode, so P1 is skipped, I and P2 are put
   into the encoding window to generate Repair3.  The same process is
   performed to produce Rapair4 and Repair5.

| +---+  FEC coding  +-------+
| | I |------------->|Repair1|
| +---+              +-------+
|
| +---+    +----+  FEC coding  +-------+
| | I |--->| P1 |------------->|Repair2|
| +---+    +----+              +-------+
|   +-------------+
|   |             |
| +---+    +----+ |   +----+  FEC coding  +-------+
| | I |    |    | +-->| P2 |------------->|Repair3|
| +---+    +----+     +----+              +-------+
|   +-------------+
|   |             |
| +---+    +----+ |   +----+    +----+  FEC coding  +-------+
| | I |    |    | +-->| P2 |--->| P3 |------------->|Repair4|
| +---+    +----+     +----+    +----+              +-------+
|   +-------------+      +-------------+
|   |             |      |             |
| +---+    +----+ |   +----+    +----+ |   +----+  FEC coding  +-------+
| | I |    |    | +-->| P2 |    |    | +-->| P4 |------------->|Repair5|
| +---+    +----+     +----+    +----+     +----+              +-------+
|
| time

           Figure 7: Example of Encoding Window Management

   Note that each time a repair symbol is generated, cm_r will be
   updated.  The update rules are as follows:

      if (++cm_r>=cw_size_max) cm_r=0;

5.4.  Coding Matrix Generation

   Compared with the RLC FEC encoder, which depends on a pseudorandom
   number generator to compute the coding coefficients, the SLC FEC
   encoder uses a fixed coding matrix to reduce overhead.  The elements
   of the coding matrix calculated by a contant formula with parameters
   cm_r and cm_c at both the SLC FEC encoder and the decoder.  The cm_r
   and cm_c parameters control these elements.  The values of cm_c
   between 0 (the minimum value) and cw_size_max-1 (the maximum value).
   And the values of cm_r between 0 and 255-cw_size_max.

Wang, et al.            Expires 16 December 2022               [Page 12]
Internet-Draft               SLC FEC Scheme                    June 2022

      G (cm_r, cm_c) = y_c / (x_r + y_c) = (cm_c + cw_size_max) / (cm_r
      + cm_c + cw_size_max)

   where cm_r represents the row number in the matrix, cm_c represents
   the col number in the matrix, cw_size_max represents the maximum
   value of the encoding window, x_r = cm_r, y_c = cw_size_max+cm_c.
   The basic operations of the above equations are carried out in the GF
   (2^^8).

5.5.  Linear Operation on encoding side and decoding side

5.5.1.  Encoding Side

   In Section 5.4, the elements of coding matrix G(cm_r, cm_c) are
   obtained.  Then, a repair symbol is generated by the computation of a
   linear combination of source symbols.

   A linear combination of the cw_size source symbols present in the
   encoding window, say src_0 to src_cw_size_1, is computed as follows.
   For each byte of position i in each source and the repair symbol,
   where i belongs to [0; E-1].

      repair[i] = G(cm_r, 0) * src_0[i] + G(cm_r, 1) * src_1[i] + ... +
      G(cm_r, cw_size-1) * src_cw_size_1[i]

   where * is the multiplication over GF (2^^8), + is the addition over
   GF (2^^8).  In this document, the following irreducible polynomial is
   used for GF(2^^8).

      x^^8 + x^^4 + x^^3 + x^^2 + 1

5.5.2.  Decoding Side

   For decoding side, it is assumed that the repair symbol protects
   cw_size source symbols, among which j source symbols are lost, then,

      remove_src[i] = repair[i] - G(cm_r, 0) * src_0[i] - ... - G(cm_r,
      k) * src_k[i] - G(cm_r, k + j + 1) * src_k_j_1[i] - ... - G(cm_r,
      cw_size-1) * src_cw_size_1[i]

   It is assumed that in the linear system maintained by the decoding
   side, there is a symbol sequence S = {lost_src_1, lost_src_2, ... ,
   lost_src_N} consisting of N lost source symbols, a symbol sequence R
   = {repair_1, repair_2, ... , repair_N} consisting of N repair symbols

Wang, et al.            Expires 16 December 2022               [Page 13]
Internet-Draft               SLC FEC Scheme                    June 2022

   There is a matrix A whose row represents the position of the repair
   symbol in R and whose column represents the position of the lost
   source symbol in S.  A[row][col] represents the matrix element of
   lost_src_row corresponding to repair_col (if it does not exist, then
   A[row][col] = 0).

      A[row][col] = G(cm_r,cm_c)

   where cm_r can be extracted from the Repair FEC Payload ID, cm_c
   represents the position of the lost source symbol in the encoding
   window.

   Therefore, there is a linear system of equation as follows:

      A * Transpose(lost_src_1, lost_src_2, ... , lost_src_N) =
      Transpose(remove_src_1, remove_src_2, ... , remove_src_N)

   The inverse matrix of A can be obtained by Gauss elimination method,
   and finally S can be recovered:

      Transpose(lost_src_1, lost_src_2, ... , lost_src_N) = A^^-1 *
      Transpose(remove_src_1, remove_src_2, ... , remove_src_N)

6.  FEC Code Specification

6.1.  Encoding Side

   1.  Whenever a new repair symbol needs to be produced, the source
   symbols are put into the sliding encoding window according to the
   rule defined by application (e.g., coding dependency between frames).

   2.  The SLC FEC encoder gathers the cw_size source symbols currently
   in the sliding encoding window.

   3.  The elements of the coding matrix are determined according to the
   parameters cm_r and cm_c (Section 5.4).

   4.  The SLC FEC encoder computes the repair symbol by a linear
   combination of the cw_size source symbols present in the encoding
   window using the coding matrix (Section 5.5.1).

   When encoding, the execution object is ADUI composed of Flow ID,
   Length, ADU, Padding.

Wang, et al.            Expires 16 December 2022               [Page 14]
Internet-Draft               SLC FEC Scheme                    June 2022

6.2.  Decoding Side

   1.  A linear system composed of source symbols, elements of the
   coding matrix, and repair symbols MUST to be maintained to recover
   the lost source packets.

   2.  When a repair symbol is received, it detects whether there is
   loss in the protected source symbols.  If at least one of the
   corresponding source symbols has been lost, an equation composed of
   the repair symbol, the corresponding source symbols, and the elements
   of the coding matrix will be added to the linear system (the elements
   of the coding matrix are generated by the method provided in
   Section 5.4).

   3.  When the linear system covering one or more lost source symbols
   is full, decoding is performed in order to recover lost source
   symbols (Section 5.5.2).

   4.  Each time an ADUI can be totally recovered, padding is removed
   (thanks to the Length field, L, of the ADUI), and the ADU will be
   assigned to the corresponding flow.

   Note that the recovered source symbols can be directly passed to the
   application through the callback function, or passed to the
   application after receiving a certain number of source symbols, which
   depends on the operation decision of the application.

7.  Security Considerations

   The FEC Framework document [RFC6363] provides a comprehensive
   analysis of security considerations applicable to FEC schemes.
   Therefore, the present section follows the security considerations
   section of [RFC6363] and only discusses specific topics.

7.1.  Attacks Against the Data Flow

7.1.1.  Access to Confidential Content

   The Sliding Window SLC FEC scheme specified in this document does not
   change the recommendations of [RFC6363].  To summarize, if
   confidentiality is a concern, it is RECOMMENDED that one of the
   solutions mentioned in [RFC6363] is used with special considerations
   to the way this solution is applied (e.g., is encryption applied
   before or after FEC protection, within the end system or in a
   middlebox), to the operational constrains (e.g., performing FEC
   decoding in a protected environment may be complicated or even
   impossible) and to the threat model.

Wang, et al.            Expires 16 December 2022               [Page 15]
Internet-Draft               SLC FEC Scheme                    June 2022

7.1.2.  Content Corruption

   The Sliding Window SLC FEC scheme specified in this document does not
   change the recommendations of [RFC6363].  To summarize, it is
   RECOMMENDED that one of the solutions mentioned in [RFC6363] is used
   on both the FEC Source and Repair Packets.

7.2.  Attacks Against the FEC Parameters

   The Sliding Window SLC FEC scheme specified in this document defines
   parameters that can be the basis of attacks.  More specifically, the
   following parameters of the FEC Framework Configuration Information
   may be modified by an attacker (Section 4.1):

   FEC Encoding ID:  changing this parameter leads the receiver to
      consider a different FEC Scheme.  It will lead to severe
      consequences that the format of the AUDI, the Explicit Source FEC
      Payload ID, and Repair FEC Payload ID of received packets will
      probably differ.  The FEC decoder can't get the correct decoding
      information, resulting in decoding failure or decoding error.

   Encoding symbol length (E):  setting this E parameter to a different
      value will enable an attacker to create a DoS since the repair
      symbols and certain source symbols will be larger or smaller than
      E, incoherency for the receiver.

   Therefore, it is RECOMMENDED that security measures be taken to
   guarantee the FFCI integrity, as specified in [RFC6363].  How to
   achieve this depends on how the FFCI is communicated from the sender
   to the receiver, which is not specified in this document.

   Similarly, attacks are possible against the Explicit Source FEC
   Payload ID and Repair FEC Payload ID.  More specifically, in the case
   of an FEC Source Packet, the following value can be modified by an
   attacker who targets receivers:

   Encoding Symbol ID (ESI):  changing the ESI leads a receiver to
      consider a wrong ADU, resulting in severe consequences, including
      corrupted content passed to the receiving application.  And in the
      case of an FEC Repair Packet.

   Start_ESI:  changing this value causes the FEC decoder to add the
      wrong source symbol in the linear system, and therefore any source
      symbol recovered by the linear system may be wrong.

   gc:  changing this value causes the FEC decoder to add an incorrect
      number of source symbols in the linear system.  Therefore any
      source symbol recovered by the linear system may be wrong.

Wang, et al.            Expires 16 December 2022               [Page 16]
Internet-Draft               SLC FEC Scheme                    June 2022

   cm_r:  changing this value leads a receiver to generate a wrong
      coding coefficient, and therefore any source symbol decoded using
      the repair symbol contained in this packet will be corrupted.

   Residual_ESI_:  changing this value causes the FEC decoder to add the
      wrong source symbol in the linear system, and therefore any source
      symbol recovered by the linear system may be wrong.

   Group_Size_:  changing this value causes the FEC decoder to add an
      incorrect number of source symbols in the linear system.
      Therefore any source symbol recovered by the linear system may be
      wrong.

   Therefore, it is RECOMMENDED that security measures are taken to
   guarantee the FEC Source and Repair Packets as stated in [RFC6363].

7.3.  When Several Source Flows Are to Be Protected Together

   The Sliding Window SLC FEC scheme specified in this document does not
   change the recommendations of [RFC6363].

7.4.  Baseline Secure FECFRAME Operation

   The Sliding Window SLC FEC scheme specified in this document does not
   change the recommendations of [RFC6363] concerning the use of the
   IPsec/Encapsulating Security Payload (ESP) security protocol as a
   mandatory-to-implement (but not mandatory-to-use) security scheme.
   This is well suited to situations where the only insecure domain is
   the one over which the FEC Framework operates.

8.  Operations and Management Considerations

   The FECFRAME document [RFC6363] provides a comprehensive analysis of
   operations and management considerations applicable to FEC schemes.
   Therefore, the present section only discusses specific topics.

8.1.  Operational Recommendations: gc_max

   The Sliding Window SLC FEC scheme specified in this document defines
   the maximum number of groups participating in encoding, called
   gc_max, reflecting the maximum number of source symbols that the
   coding window can hold.  Gc_max is directly proportional to the
   computational complexity of FEC encoding.  If gc_max is too large,
   the time complexity of FEC encoding will be too high, and the CPU
   overhead will be too large.  Generally, it is appropriate to
   associate gc_max with cw_size_max.

Wang, et al.            Expires 16 December 2022               [Page 17]
Internet-Draft               SLC FEC Scheme                    June 2022

   For example, in real-time video streaming applications, the frame
   rate (FR) and bit rate (BR) is determined by transmitting the video
   frames.  The possible number of packets per frame can be calculated
   according to FR and BR, and they can calculate the maximum number of
   symbols in the coding window.

      BR kbps / 8 / FR fps / MTU * gc_max <= cw_size_max

   Where MTU denotes Maximum Transmission Unit.

9.  IANA Considerations

   This document registers one values in the "FEC Framework (FECFRAME)
   FEC Encoding IDs" sub-registry as follows:

   XXX  refers to the Sliding Window Selective Linear Code (SLC) Forward
      Error Correction (FEC) Scheme for Arbitrary Packet Flows.

10.  Acknowledgments

   The authors would like to thank the FEC Framework Design Team for
   providing a great FEC Framework.  The authors would also like to
   thank Shie Qian for reviewing the earlier draft versions of this
   document.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
              Correction (FEC) Building Block", RFC 5052,
              DOI 10.17487/RFC5052, August 2007,
              <https://www.rfc-editor.org/info/rfc5052>.

   [RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
              Correction (FEC) Framework", RFC 6363,
              DOI 10.17487/RFC6363, October 2011,
              <https://www.rfc-editor.org/info/rfc6363>.

   [RFC6364]  Begen, A., "Session Description Protocol Elements for the
              Forward Error Correction (FEC) Framework", RFC 6364,
              DOI 10.17487/RFC6364, October 2011,
              <https://www.rfc-editor.org/info/rfc6364>.

Wang, et al.            Expires 16 December 2022               [Page 18]
Internet-Draft               SLC FEC Scheme                    June 2022

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8680]  Roca, V. and A. Begen, "Forward Error Correction (FEC)
              Framework Extension to Sliding Window Codes", RFC 8680,
              DOI 10.17487/RFC8680, January 2020,
              <https://www.rfc-editor.org/info/rfc8680>.

11.2.  Informative References

   [Hel2011]  Cornelius, H., Barquero, G., Schierl, D., and T. Wiegand,
              "Sliding-Window Forward Error Correction Based on
              Reference Order for Real-Time Video Streaming",
              DOI 10.1109/TMM.2011.2129499, June 2011,
              <https://ieeexplore.ieee.org/document/9741773/>.

   [RFC5170]  Roca, V., Neumann, C., and D. Furodet, "Low Density Parity
              Check (LDPC) Staircase and Triangle Forward Error
              Correction (FEC) Schemes", RFC 5170, DOI 10.17487/RFC5170,
              June 2008, <https://www.rfc-editor.org/info/rfc5170>.

   [RFC5510]  Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
              "Reed-Solomon Forward Error Correction (FEC) Schemes",
              RFC 5510, DOI 10.17487/RFC5510, April 2009,
              <https://www.rfc-editor.org/info/rfc5510>.

   [RFC6681]  Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward
              Error Correction (FEC) Schemes for FECFRAME", RFC 6681,
              DOI 10.17487/RFC6681, August 2012,
              <https://www.rfc-editor.org/info/rfc6681>.

   [RFC6816]  Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density
              Parity Check (LDPC) Staircase Forward Error Correction
              (FEC) Scheme for FECFRAME", RFC 6816,
              DOI 10.17487/RFC6816, December 2012,
              <https://www.rfc-editor.org/info/rfc6816>.

   [RFC6865]  Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K.
              Matsuzono, "Simple Reed- Solomon Forward Error Correction
              (FEC) Scheme for FECFRAME", RFC 6865,
              DOI 10.17487/RFC6865, February 2013,
              <https://www.rfc-editor.org/info/rfc6865>.

Wang, et al.            Expires 16 December 2022               [Page 19]
Internet-Draft               SLC FEC Scheme                    June 2022

   [RFC8406]  Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
              F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J.,
              Pedersen, M., Peralta, G., Roca, V., Saxena, P., and S.
              Sivakumar, "Taxonomy of Coding Techniques for Efficient
              Network Communications", RFC 8406, DOI 10.17487/RFC8406,
              June 2018, <https://www.rfc-editor.org/info/rfc8406>.

   [RFC8681]  Roca, V. and B. Teibi, "Sliding Window Random Linear Code
              (RLC) Forward Erasure Correction (FEC) Schemes for
              FECFRAME", RFC 8681, DOI 10.17487/RFC8681, February 2020,
              <https://www.rfc-editor.org/info/rfc8681>.

   [Wan2022]  Wang, R., Si, L., and B. He, "Sliding-Window Forward Error
              Correction Based on Reference Order for Real-Time Video
              Streaming", DOI 10.1109/ACCESS.2022.3162217, March 2022,
              <https://ieeexplore.ieee.org/document/9741773/>.

Authors' Addresses

   Ray Wang
   Agora Lab
   China
   Email: wangrui@agora.io

   Liang Si
   Agora Lab
   China
   Email: siliang@agora.io

   Bifeng He
   Agora Lab
   China
   Email: hebifeng@agora.io

Wang, et al.            Expires 16 December 2022               [Page 20]