Many applications need to transport a continuous stream of packetized data from a source (sender) to one or more destinations (receivers) over networks that do not provide guaranteed packet delivery. In particular, packets may be lost, which is strictly the focus of this document: we assume that transmitted packets are either lost (e.g., because of a congested router, a poor signal-to-noise ratio in a wireless network, or because the number of bit errors exceeds the correction capabilities of the physical-layer error-correcting code) or were received by the transport protocol without any corruption (i.e., the bit errors, if any, have been fixed by the physical-layer error-correcting code and therefore are hidden to the upper layers).
For these use cases, Forward Error Correction (FEC) applied within the transport or application layer is an efficient technique to improve packet transmission robustness in the presence of packet losses (or "erasures") without going through packet retransmissions that create a delay often incompatible with real-time constraints. The FEC Building Block defined in [RFC 5052
] provides a framework for the definition of Content Delivery Protocols (CDPs) that make use of separately defined FEC schemes. Any CDP defined according to the requirements of the FEC Building Block can then easily be used with any FEC scheme that is also defined according to the requirements of the FEC Building Block.
Then, FECFRAME [RFC 6363
] provides a framework to define Content Delivery Protocols (CDPs) that provide FEC protection for arbitrary packet flows over an unreliable datagram service transport, such as UDP. It is primarily intended for real-time or streaming media applications that are using broadcast, multicast, or on-demand delivery. A subset of FECFRAME is currently part of the 3GPP Evolved Multimedia Broadcast/Multicast Service (eMBMS) standard [MBMSTS
However, [RFC 6363
] only considers block FEC schemes defined in accordance with the FEC Building Block [RFC 5052
] (e.g., [RFC 6681
], [RFC 6816
], or [RFC 6865
]). These codes require the input flow(s) to be segmented into a sequence of blocks. Then, FEC encoding (at a sender or an encoding middlebox) and decoding (at a receiver or a decoding middlebox) are both performed on a per-block basis. For instance, if the current block encompasses the 100's to 119's source symbols (i.e., a block of size 20 symbols) of an input flow, encoding (and decoding) will be performed on this block independently of other blocks. This approach has major impacts on FEC encoding and decoding delays. The data packets of continuous media flow(s) may be passed to the transport layer immediately, without delay. But the block creation time, which depends on the number of source symbols in this block, impacts both the FEC encoding delay (since encoding requires that all source symbols be known) and, mechanically, the packet loss recovery delay at a receiver (since no repair symbol for the current block can be generated and therefore received before that time). Therefore, a good value for the block size is necessarily a balance between the maximum FEC decoding latency at the receivers (which must be in line with the most stringent real-time requirement of the protected flow(s), hence an incentive to reduce the block size) and the desired robustness against long loss bursts (which increases with the block size, hence an incentive to increase this size).
This document updates [RFC 6363
] in order to also support FEC codes based on a sliding encoding window (a.k.a., convolutional codes) [RFC 8406
]. This encoding window, either fixed or variable size, slides over the set of source symbols. FEC encoding is launched whenever needed from the set of source symbols present in the sliding encoding window at that time. This approach significantly reduces FEC-related latency, since repair symbols can be generated and passed to the transport layer on the fly at any time and can be regularly received by receivers to quickly recover packet losses. Using sliding window FEC codes is therefore highly beneficial to real-time flows, one of the primary targets of FECFRAME. [RFC 8681
] provides an example of such a FEC scheme for FECFRAME, which is built upon the simple sliding window Random Linear Code (RLC).
This document is fully backward compatible with [RFC 6363
This FECFRAME update does not prevent or compromise in any way the support of block FEC codes. Both types of codes can nicely coexist, just like different block FEC schemes can coexist.
Each sliding window FEC scheme is associated with a specific FEC Encoding ID subject to IANA registration, just like block FEC schemes.
Any receiver -- for instance, a legacy receiver that only supports block FEC schemes -- can easily identify the FEC scheme used in a FECFRAME session. Indeed, the FEC Encoding ID that identifies the FEC scheme is carried in FEC Framework Configuration Information (see Section 5.5 of RFC 6363). For instance, when the Session Description Protocol (SDP) is used to carry the FEC Framework Configuration Information, the FEC Encoding ID can be communicated in the "encoding-id=" parameter of a "fec-repair-flow" attribute [RFC 6364]. This mechanism is the basic approach for a FECFRAME receiver to determine whether or not it supports the FEC scheme used in a given FECFRAME session.
This document leverages on [RFC 6363
] and reuses its structure. It proposes new sections specific to sliding window FEC codes whenever required. The only exception is Section 3
, which provides a quick summary of FECFRAME in order to facilitate the understanding of this document to readers not familiar with the concepts and terminology.