Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME
Extracted elements (28)
Each FEC Repair Packet uses a fixed 64-bit Repair FEC Payload ID regardless of encoding window size, because the encoding window contents and coding coefficients are described implicitly via FSS_ESI, NSS, Repair_Key, and DT rather than by enumerating all source symbols and coefficients individually.
RLC over GF(2^8) is expected to be the primary choice due to superior loss protection. RLC over GF(2) is an alternative for large encoding windows where throughput is critical, since its operations reduce to XOR, enabling much higher encoding/decoding speeds, but at significantly reduced loss protection.
Sliding Window RLC codes reduce FEC-related latency for real-time flows compared to block codes: an isolated lost source packet is recovered with the next repair packet, whereas block codes require waiting until the end of an entire block. Under constant bitrate conditions, sliding window codes can also achieve target quality with fewer repair packets (higher code rate).
The Density Threshold (DT) lets senders trade code density against computational cost: DT=15 guarantees all-nonzero coefficients (maximum protection) and is appropriate for small encoding windows, while smaller DT values reduce overhead for large windows. DT=15 with GF(2) degenerates to a plain XOR code producing only a single distinct repair symbol per window.
The parameter derivation techniques in Appendix C are informational: using a different derivation does not prevent encoder-decoder interoperability since a decoder can still recover erased symbols. However, inappropriate parameters may cause recovered ADUs to arrive after their real-time validity deadline, making them useless to the application.
A FEC Repair Packet MUST contain a Repair FEC Payload ID prepended to the repair symbol(s). When a packet contains multiple repair symbols, they MUST all have been generated from the same encoding window.
A FEC Source Packet MUST contain an Explicit Source FEC Payload ID appended to the end of the packet, carrying the 32-bit ESI of the first source symbol of the ADUI corresponding to this packet.
Any implementation of the TinyMT32 PRNG MUST produce the same output as the reference implementation of RFC 8682. Compliance is verified via three criteria: one from RFC 8682 for the 32-bit generator, and two in Appendix A for the 4-bit and 8-bit mapping functions.
For each incoming ADU, an ADUI MUST be created by prepending a 1-byte Flow ID and a 2-byte Length field, then padding with zeros to a multiple of E bytes.
For the GF(2) FEC scheme when DT=15, the sender MUST set the Repair_Key field to zero and receivers MUST ignore it, because all coefficients are necessarily 1 and the coefficient generation function does not invoke the PRNG.
The encoding symbol size E MUST be fixed by the FECFRAME sender and MUST be communicated to receivers as part of the FEC Scheme-Specific Information.
The ESI of source symbols MUST start at 0 for the first source symbol and MUST be managed sequentially, wrapping to 0 after reaching the maximum value (2^32 - 1 for FEC schemes 9 and 10).
The FEC Encoding ID for the Sliding Window RLC over GF(2) scheme MUST be 9, as assigned by IANA.
The linear system maximum size ls_max_size at a receiver SHOULD NOT be smaller than dw_max_size, as a smaller value could prevent recovery of lost ADUs even when sufficient repair packets are received.
When multiple repair symbols are packed into a single FEC Repair Packet, the repair key for each successive symbol MUST be the Repair_Key value in the Repair FEC Payload ID incremented by 1, looping from 65535 back to 0.
When the sliding encoding window reaches its maximum size ew_max_size, the oldest symbol MUST be removed before adding a new symbol, maintaining the invariant ew_size <= ew_max_size.
For GF(2^8), the irreducible polynomial x^8 + x^4 + x^3 + x^2 + 1 is used for multiplication. For GF(2), multiplication is a logical AND and addition is XOR, as specified in RFC 5510 Section 8.1.
The ADUI (Application Data Unit Information) is an intermediate format prepending a 1-byte Flow ID (F) and a 2-byte Length (L) to each ADU, followed by zero padding to align the total to a multiple of E bytes. This enables flow identification and padding removal after FEC decoding without transmitting the F, L, or Pad fields over the network.
The generate_coding_coefficients() function produces coding coefficients for each repair symbol, parameterized by repair_key (PRNG seed), cc_nb (encoding window size), DT (density threshold 0–15), and m (Galois Field parameter: 1 for GF(2), 8 for GF(2^8)). When DT=15, all coefficients are guaranteed nonzero; otherwise the average fraction of nonzero coefficients is (DT+1)/16.
The TinyMT32 PRNG is used to generate coding coefficients, initialized with the Repair_Key as a 32-bit seed. Two mapping functions are defined: tinymt32_rand16() returns the lower 4 bits (value in [0..15]) and tinymt32_rand256() returns the lower 8 bits (value in [0..255]) of the 32-bit PRNG output.
This document registers two values in the IETF 'FEC Framework (FECFRAME) FEC Encoding IDs' registry: value 9 for Sliding Window RLC over GF(2) for Arbitrary Packet Flows (Section 5) and value 10 for Sliding Window RLC over GF(2^8) for Arbitrary Packet Flows (Section 4).
Attackers can corrupt the FFCI parameters (FEC Encoding ID or E), causing receivers to misinterpret FEC packet formats or compute incorrect symbol sizes, resulting in DoS or corrupted decoded content. It is RECOMMENDED that integrity protection measures from RFC 6363 be applied to the FFCI.
For content confidentiality, it is RECOMMENDED to use solutions from RFC 6363, with attention to whether encryption is applied before or after FEC protection, operational constraints on decoding in protected environments, and the applicable threat model. IPsec/ESP is the mandatory-to-implement (but not mandatory-to-use) baseline security scheme.
Numerical overflows in parameter derivation formulae (e.g., Appendix C.1) and malicious corruption of RTP timestamp fields used in parameter derivation may cause hazardous behavior. It is RECOMMENDED to check that all computed parameter values remain within reasonable bounds.
Repair FEC Payload ID fields (Repair_Key, DT, NSS, FSS_ESI) and the Source FEC Payload ID ESI field are all attack surfaces: modifying any of them causes receivers to reconstruct incorrect encoding windows or coefficient sequences, yielding corrupted decoded symbols or increased processing overhead. Integrity protection of source and repair packets per RFC 6363 is RECOMMENDED.
The Explicit Source FEC Payload ID is a 32-bit unsigned integer (ESI) in network byte order, appended to each FEC Source Packet. The ESI identifies the first source symbol of the corresponding ADUI and wraps to 0 after reaching 2^32-1.
The FEC Scheme-Specific Information (FSSI) opaque encoding is 3 octets in network byte order: a 16-bit Encoding Symbol Length (E) followed by an 8-bit Window Size Ratio Parameter (WSR). In SDP, these are expressed as 'fssi=E:<value>,WSR:<value>'.
The Repair FEC Payload ID is a fixed 64-bit header in network byte order: 16-bit Repair_Key (PRNG seed for the first repair symbol), 4-bit DT (density threshold), 12-bit NSS (number of source symbols in encoding window), and 32-bit FSS_ESI (ESI of the first source symbol in the encoding window).