RFC 8680 | FEC Framework Extension | January 2020 |
Roca & Begen | Standards Track | [Page] |
RFC 6363 describes a framework for using Forward Error Correction (FEC) codes to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However, FECFRAME as per RFC 6363 is restricted to block FEC codes. This document updates RFC 6363 to support FEC codes based on a sliding encoding window, in addition to block FEC codes, in a backward-compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8680.¶
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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 [RFC5052] 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 [RFC6363] 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, [RFC6363] only considers block FEC schemes defined in accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], [RFC6816], or [RFC6865]). 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 [RFC6363] in order to also support FEC codes based on a sliding encoding window (a.k.a., convolutional codes) [RFC8406]. 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. [RFC8681] 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 [RFC6363]. Indeed:¶
This document leverages on [RFC6363] 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.¶
The following list of definitions and abbreviations is copied from [RFC6363], adding only the Block FEC Code, Sliding Window FEC Code, and Encoding/Decoding Window definitions (tagged with "ADDED"):¶
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The architecture of Section 3 of [RFC6363] equally applies to this FECFRAME extension and is not repeated here. However, this section includes a quick summary to facilitate the understanding of this document to readers not familiar with the concepts and terminology.¶
The FECFRAME architecture is illustrated in Figure 1 for a block FEC scheme from the sender's point of view. It shows an application generating an ADU flow (other flows from other applications may coexist). These ADUs of variable size must be somehow mapped to source symbols of a fixed size (this fixed size is a requirement of all FEC schemes, which comes from the way mathematical operations are applied to the symbols' content). This is the goal of an ADU-to-symbols mapping process that is FEC scheme specific (see below). Once the source block is built, taking into account both the FEC scheme constraints (e.g., in terms of maximum source block size) and the application's flow constraints (e.g., in terms of real-time constraints), the associated source symbols are handed to the FEC scheme in order to produce an appropriate number of repair symbols. FEC Source Packets (containing ADUs) and FEC Repair Packets (containing one or more repair symbols each) are then generated and sent using an appropriate transport protocol (more precisely, Section 7 of [RFC6363] requires a transport protocol providing an unreliable datagram service, such as UDP). In practice, FEC Source Packets may be passed to the transport layer as soon as available without having to wait for FEC encoding to take place. In that case, a copy of the associated source symbols needs to be kept within FECFRAME for future FEC encoding purposes.¶
At a receiver (not shown), FECFRAME processing operates in a similar way, taking as input the incoming FEC Source and Repair Packets received. In case of FEC Source Packet losses, the FEC decoding of the associated block may recover all (in case of successful decoding) or a subset that is potentially empty (if decoding fails) of the missing source symbols. After source-symbol-to-ADU mapping, when lost ADUs are recovered, they are then assigned to their respective flow (see below). ADUs are returned to the application(s), either in their initial transmission order (in which case all ADUs received after a lost ADU will be delayed until FEC decoding has taken place) or not (in which case each ADU is returned as soon as it is received or recovered), depending on the application requirements.¶
FECFRAME features two subtle mechanisms whose details are FEC scheme dependent:¶
A few aspects are not covered by FECFRAME, namely:¶
The general considerations of Section 4.1 of [RFC6363] that are specific to block FEC codes are not repeated here.¶
With a Sliding Window FEC code, the FEC Source Packet MUST contain information to identify the position occupied by the ADU within the source flow in terms specific to the FEC scheme. This information is known as the Source FEC Payload ID, and the FEC scheme is responsible for defining and interpreting it.¶
With a Sliding Window FEC code, the FEC Repair Packets MUST contain information that identifies the relationship between the contained repair payloads and the original source symbols used during encoding. This information is known as the Repair FEC Payload ID, and the FEC scheme is responsible for defining and interpreting it.¶
The sender operation ([RFC6363], Section 4.2) and receiver operation ([RFC6363], Section 4.3) are both specific to block FEC codes and are therefore omitted below. The following two sections detail similar operations for Sliding Window FEC codes.¶
With a Sliding Window FEC scheme, the following operations, illustrated in Figure 2 for the generic case (non-RTP repair flows) and in Figure 3 for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows:¶
With a Sliding Window FEC scheme, the following operations are illustrated in Figure 4 for the generic case (non-RTP repair flows) and in Figure 5 for the case of RTP repair flows. The only differences with respect to block FEC codes lie in steps (4) and (5). Therefore, this section does not repeat the other steps of Section 4.3 of [RFC6363] ("Receiver Operation"). The new steps (4) and (5) are:¶
This section discusses the protocol elements for the FEC Framework specific to Sliding Window FEC schemes. The global formats of source data packets (i.e., [RFC6363], Figure 6) and repair data packets (i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding Window FEC codes. They are not repeated here.¶
The FEC Framework Configuration Information considerations of Section 5.5 of [RFC6363] equally apply to this FECFRAME extension and are not repeated here.¶
The FEC scheme requirements of Section 5.6 of [RFC6363] mostly apply to this FECFRAME extension and are not repeated here. An exception, though, is the "full specification of the FEC code", item (4), which is specific to block FEC codes. In case of a Sliding Window FEC scheme, then the following item (4-bis) applies:¶
A full specification of the Sliding Window FEC code.¶
This specification MUST precisely define the valid FEC-Scheme-Specific Information values, the valid FEC Payload ID values, and the valid packet payload sizes (where "packet payload" refers to the space within a packet dedicated to carrying encoding symbols).¶
Furthermore, given valid values of the FEC-Scheme-Specific Information, a valid Repair FEC Payload ID value, a valid packet payload size, and a valid encoding window (i.e., a set of source symbols), the specification MUST uniquely define the values of the encoding symbol (or symbols) to be included in the repair packet payload with the given Repair FEC Payload ID value.¶
Additionally, the FEC scheme associated with a Sliding Window FEC code:¶
The discussion in Section 6 of [RFC6363] equally applies to this FECFRAME extension and is not repeated here.¶
The discussion in Section 7 of [RFC6363] equally applies to this FECFRAME extension and is not repeated here.¶
The discussion in Section 8 of [RFC6363] equally applies to this FECFRAME extension and is not repeated here.¶
This FECFRAME extension does not add any new security considerations. All the considerations of Section 9 of [RFC6363] apply to this document as well. However, for the sake of completeness, the following goal can be added to the list provided in Section 9.1 of [RFC6363] ("Problem Statement"):¶
This FECFRAME extension does not add any new Operations and Management Considerations. All the considerations of Section 10 of [RFC6363] apply to this document as well.¶
This document has no IANA actions.¶
A FEC scheme for use with this FEC Framework is identified via its FEC Encoding ID. It is subject to IANA registration in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of Section 11 of [RFC6363] apply and are not repeated here.¶
The FEC Framework does not specify the management of the sliding encoding window, which is the responsibility of the FEC scheme. This annex only provides a few informational hints.¶
Source symbols are added to the sliding encoding window each time a new ADU is available at the sender after the ADU-to-source-symbol mapping specific to the FEC scheme has been done.¶
Source symbols are removed from the sliding encoding window. For instance:¶
Several considerations can impact the management of this sliding encoding window:¶
The authors would like to thank Christer Holmberg, David Black, Gorry Fairhurst, Emmanuel Lochin, Spencer Dawkins, Ben Campbell, Benjamin Kaduk, Eric Rescorla, Adam Roach, and Greg Skinner for their valuable feedback on this document. This document being an extension of [RFC6363], the authors would also like to thank Mark Watson as the main author of that RFC.¶