Forward Error Correction (FEC) Framework Extension to Sliding Window Codes
updates
- rfc-6363 — Forward Error Correction (FEC) Framework
Extracted elements (17)
An encoding window composed of a non-sequential set of source symbols requires complex signaling to inform receivers of window composition; a sequential encoding window simplifies signaling to just the identity of the first source symbol plus count, creating fixed, small transmission overhead. This tradeoff between flexibility and overhead is a key consideration for FEC scheme designers.
Block size in block FEC codes is an inherent tradeoff: smaller blocks reduce maximum FEC decoding latency (better for real-time constraints) but reduce robustness against long loss bursts, while larger blocks improve robustness but increase recovery delay. Sliding window codes avoid this tradeoff entirely.
Sliding window FEC codes (convolutional codes) are used instead of block codes to significantly reduce FEC-related latency for real-time flows. With block codes, no repair symbol can be generated before the entire block is collected, creating a delay proportional to block size; sliding window codes generate repair symbols on the fly at any time, enabling receivers to quickly recover losses.
The encoding window management is intentionally left to the FEC scheme rather than specified in the FEC Framework. Source symbols are removed from the window either after a real-time timeout (old ADUs expire) or once the window reaches its maximum size (oldest symbol evicted on each new addition), with the specific policy being FEC-scheme-dependent.
RFC 8680 is fully backward compatible with RFC 6363. Block FEC codes and sliding window FEC codes can coexist; each sliding window FEC scheme has its own IANA-registered FEC Encoding ID carried in FEC Framework Configuration Information, allowing legacy receivers to detect unsupported schemes and reject sessions they cannot handle.
The global formats of FEC source data packets and repair data packets from RFC 6363 (Figures 6, 7, and 8) remain unchanged for sliding window FEC codes; only the contents and interpretation of the FEC Payload IDs differ, keeping the wire format compatible with existing FECFRAME infrastructure.
A FEC scheme associated with a Sliding Window FEC code MUST define the management of the decoding window, which usually consists of managing a system of linear equations for a linear FEC code.
A full sliding window FEC scheme specification (item 4-bis) MUST precisely define the valid FEC-Scheme-Specific Information values, the valid FEC Payload ID values, and the valid packet payload sizes (space within a packet dedicated to carrying encoding symbols).
Given valid FEC-Scheme-Specific Information, a valid Repair FEC Payload ID, a valid packet payload size, and a valid encoding window, the FEC scheme specification MUST uniquely define the values of the encoding symbol(s) to be included in the repair packet payload with that Repair FEC Payload ID.
The ADU-to-source-symbol mapping and encoding window management details are both the responsibility of the FEC scheme and MUST be detailed in the FEC scheme specification. The FEC Framework itself does not specify these details.
With a Sliding Window FEC code, the FEC Repair Packets MUST contain information identifying the relationship between the contained repair payloads and the original source symbols used during encoding, known as the Repair FEC Payload ID.
A Sliding Window FEC Code is a FEC code that generates repair symbols on the fly, at any time, from the set of source symbols present in the sliding encoding window at that time. These codes are also known as convolutional codes, in contrast to Block FEC Codes that operate independently on per-block segments.
Receiver operation with sliding window FEC codes differs from block codes in steps 4 and 5: the FEC scheme inserts source and repair packets into the decoding window using received FEC Payload IDs, attempts decoding when at least one source packet is missing and at least one repair packet is available, then returns received and decoded ADUs along with indications of unrecoverable losses.
Sender operation with sliding window FEC codes follows a 10-step procedure: the application provides ADUs; the FEC Framework passes them to the FEC scheme; the encoding window is updated; Source FEC Payload ID is determined; FEC Source Packets are constructed and sent; when needed, repair packets are generated from the current encoding window and sent on their configured port(s) and multicast group(s).
The Encoding Window is the set of source symbols available at the sender or coding node used to generate a repair symbol with a Sliding Window FEC code. The Decoding Window is the set of received or decoded source and repair symbols available at a receiver used to decode lost source symbols.
This document has no new IANA actions but references the existing 'FEC Framework (FECFRAME) FEC Encoding IDs' registry defined in RFC 6363. Each sliding window FEC scheme for use with this framework must register its own FEC Encoding ID in that registry under all the rules of RFC 6363 Section 11.
This FECFRAME extension introduces no new security considerations beyond those in RFC 6363 Section 9. One additional threat noted is that attacks can attempt to corrupt source flows in order to modify receiver application behavior, as opposed to merely denying service.