]> INRIA

Univ. Grenoble Alpes France vincent.roca@inria.fr

Networked Media

Konya Turkey ali.begen@networked.media

TSVWG 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.

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, of 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 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 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 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 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, using broadcast, multicast, or on-demand delivery. However, only considers block FEC schemes defined in accordance with the FEC Building Block (e.g., , or ). 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, that 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 in order to also support FEC codes based on a sliding encoding window (A.K.A. convolutional codes) . This encoding window, either of 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. provides an example of such FEC Scheme for FECFRAME, built upon the simple sliding window Random Linear Codes (RLC). This document is fully backward compatible with . Indeed: this FECFRAME update does not prevent nor compromise in any way the support of block FEC codes. Both types of codes can nicely co-exist, just like different block FEC schemes can co-exist; each sliding window FEC Scheme is associated to 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 the FEC Framework Configuration Information (see section 5.5 of ). 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 . 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 and re-uses its structure. It proposes new sections specific to sliding window FEC codes whenever required. The only exception is that 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 , adding only the Block/sliding window FEC Code and Encoding/Decoding Window definitions (tagged with "ADDED"): The unit of source data provided as payload to the transport layer. For instance, it can be a payload containing the result of the RTP packetization of a compressed video frame. A sequence of ADUs associated with a transport-layer flow identifier (such as the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}). Application-layer Forward Error Correction. Control protocol used to establish and control the source flow being protected, e.g., the Real-Time Streaming Protocol (RTSP). A complete application protocol specification that, through the use of the framework defined in this document, is able to make use of FEC schemes to provide FEC capabilities. An algorithm for encoding data such that the encoded data flow is resilient to data loss. Note that, in general, FEC codes may also be used to make a data flow resilient to corruption, but that is not considered in this document. An FEC Code that operates on blocks, i.e., for which the input flow MUST be segmented into a sequence of blocks, FEC encoding and decoding being performed independently on a per-block basis. An FEC Code that can generate 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. A protocol framework for the definition of Content Delivery Protocols using FEC, such as the framework defined in this document. Information that controls the operation of the FEC Framework. Information that identifies the contents and provides positional information of a packet with respect to the FEC Scheme. At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing one or more repair symbols along with a Repair FEC Payload ID and possibly an RTP header. A specification that defines the additional protocol aspects required to use a particular FEC code with the FEC Framework. At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing an ADU along with an optional Explicit Source FEC Payload ID. The packet flow carrying FEC data. A FEC Payload ID specifically for use with repair packets. The packet flow to which FEC protection is to be applied. A source flow consists of ADUs. A FEC Payload ID specifically for use with source packets. A protocol used for the source flow being protected, e.g., RTP. The protocol used for the transport of the source and repair flows, using an unreliable datagram service such as UDP. Set of Source Symbols available at the sender/coding node that are used to generate a repair symbol, with a Sliding Window FEC Code. Set of received or decoded source and repair symbols available at a receiver that are used to decode erased source symbols, with a Sliding Window FEC Code. The ratio between the number of source symbols and the number of encoding symbols. By definition, the code rate is such that 0 < code rate <= 1. A code rate close to 1 indicates that a small number of repair symbols have been produced during the encoding process. Unit of data generated by the encoding process. With systematic codes, source symbols are part of the encoding symbols. A communication path where packets are either lost (e.g., in our case, by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical-layer code) or received. When a packet is received, it is assumed that this packet is not corrupted (i.e., in our case, the bit-errors, if any, are fixed by the physical-layer code and therefore hidden to the upper layers). Encoding symbol that is not a source symbol. Group of ADUs that are to be FEC protected as a single block. This notion is restricted to Block FEC Codes. Unit of data used during the encoding process. FEC code in which the source symbols are part of the encoding symbols. 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 when, and only when, they appear in all capitals, as shown here.

The architecture of , Section 3, equally applies to this FECFRAME extension and is not repeated here. However, we provide hereafter a quick summary to facilitate the understanding of this document to readers not familiar with the concepts and terminology.

| FEC Scheme | |(2) Construct source |(3) Source Block | | | blocks | |(4) FEC Encoding| |(6) Construct FEC |<--------------------------| | | Source and Repair | | | | Packets |(5) Explicit Source FEC | | +----------------------+ Payload IDs +----------------+ | Repair FEC Payload IDs | Repair symbols | |(7) FEC Source and Repair Packets v +----------------------+ | Transport Protocol | +----------------------+ ]]>

The FECFRAME architecture is illustrated in from the sender's point of view, in case of a block FEC Scheme. It shows an application generating an ADU flow (other flows, from other applications, may co-exist). These ADUs, of variable size, must be somehow mapped to source symbols of fixed size (this fixed size is a requirement of all FEC Schemes that comes from the way mathematical operations are applied to 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, 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 potentially empty (otherwise) 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 that case ADUs received after an erased one will be delayed until FEC decoding has taken place) or not (in that case each ADU is returned as soon as it is received or recovered), depending on the application requirements. FECFRAME features two subtle mechanisms: ADUs-to-source-symbols mapping: in order to manage variable size ADUs, FECFRAME and FEC Schemes can use small, fixed size symbols and create a mapping between ADUs and symbols. To each ADU this mechanism prepends a length field (plus a flow identifier, see below) and pads the result to a multiple of the symbol size. A small ADU may be mapped to a single source symbol while a large one may be mapped to multiple symbols. The mapping details are FEC-Scheme-dependent and must be defined in the associated document; Assignment of decoded ADUs to flows in multi-flow configurations: when multiple flows are multiplexed over the same FECFRAME instance, a problem is to assign a decoded ADU to the right flow (UDP port numbers and IP addresses traditionally used to map incoming ADUs to flows are not recovered during FEC decoding). To make it possible, at the FECFRAME sending instance, each ADU is prepended with a flow identifier (1 byte) during the ADU-to-source-symbols mapping (see above). The flow identifiers are also shared between all FECFRAME instances as part of the FEC Framework Configuration Information. This (flow identifier + length + application payload + padding), called ADUI, is then FEC protected. Therefore a decoded ADUI contains enough information to assign the ADU to the right flow. A few aspects are not covered by FECFRAME, namely: section 8 does not detail any congestion control mechanism, but only provides high level normative requirements; the possibility of having feedbacks from receiver(s) is considered out of scope, although such a mechanism may exist within the application (e.g., through RTCP control messages); flow adaptation at a FECFRAME sender (e.g., how to set the FEC code rate based on transmission conditions) is not detailed, but it needs to comply with the congestion control normative requirements (see above).

The general considerations of , Section 4.1, 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 (, Section 4.2.) and Receiver Operation (, Section 4.3) are both specific to block FEC codes and 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 for the generic case (non-RTP repair flows), and in Figure for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows: A new ADU is provided by the application. The FEC Framework communicates this ADU to the FEC Scheme. The sliding encoding window is updated by the FEC Scheme. The ADU-to-source-symbols mapping as well as the encoding window management details are both the responsibility of the FEC Scheme and MUST be detailed there. provides non-normative hints about what FEC Scheme designers need to consider; The Source FEC Payload ID information of the source packet is determined by the FEC Scheme. If required by the FEC Scheme, the Source FEC Payload ID is encoded into the Explicit Source FEC Payload ID field and returned to the FEC Framework. The FEC Framework constructs the FEC Source Packet according to Figure 6, using the Explicit Source FEC Payload ID provided by the FEC Scheme if applicable. The FEC Source Packet is sent using normal transport-layer procedures. This packet is sent using the same ADU flow identification information as would have been used for the original source packet if the FEC Framework were not present (e.g., the source and destination addresses and UDP port numbers on the IP datagram carrying the source packet will be the same whether or not the FEC Framework is applied). When the FEC Framework needs to send one or several FEC Repair Packets (e.g., according to the target Code Rate), it asks the FEC Scheme to create one or several repair packet payloads from the current sliding encoding window along with their Repair FEC Payload ID. The Repair FEC Payload IDs and repair packet payloads are provided back by the FEC Scheme to the FEC Framework. The FEC Framework constructs FEC Repair Packets according to Figure 7, using the FEC Payload IDs and repair packet payloads provided by the FEC Scheme. The FEC Repair Packets are sent using normal transport-layer procedures. The port(s) and multicast group(s) to be used for FEC Repair Packets are defined in the FEC Framework Configuration Information.

| | | | (2) New ADU |(3) Update of | | | | encoding | | |<--------------------------| window | |(5) Construct FEC | (4) Explicit Source | | | Source Packet | FEC Payload ID(s) |(7) FEC | | |<--------------------------| encoding | |(9) Construct FEC | (8) Repair FEC Payload ID | | | Repair Packet(s) | + Repair symbol(s) +----------------+ +---------------------+ | | (6) FEC Source Packet | (10) FEC Repair Packets v +----------------------+ | Transport Protocol | +----------------------+ ]]>

| | | | (2) New ADU |(3) Update of | | | | encoding | | |<--------------------------| window | |(5) Construct FEC | (4) Explicit Source | | | Source Packet | FEC Payload ID(s) |(7) FEC | | |<--------------------------| encoding | |(9) Construct FEC | (8) Repair FEC Payload ID | | | Repair Packet(s) | + Repair symbol(s) +----------------+ +---------------------+ | | |(6) Source |(10) Repair payloads | packets | | + -- -- -- -- -+ | | RTP | | +-- -- -- -- --+ v v +----------------------+ | Transport Protocol | +----------------------+ ]]>

With a Sliding Window FEC Scheme, the following operations, illustrated in Figure for the generic case (non-RTP repair flows), and in Figure 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, "Receiver Operation". The new steps (4) and (5) are: The FEC Scheme uses the received FEC Payload IDs (and derived FEC Source Payload IDs when the Explicit Source FEC Payload ID field is not used) to insert source and repair packets into the decoding window in the right way. If at least one source packet is missing and at least one repair packet has been received, then FEC decoding is attempted to recover missing source payloads. The FEC Scheme determines whether source packets have been lost and whether enough repair packets have been received to decode any or all of the missing source payloads. The FEC Scheme returns the received and decoded ADUs to the FEC Framework, along with indications of any ADUs that were missing and could not be decoded.

| | | payloads to FEC |(3) Explicit Source FEC +----------------+ | scheme | Payload IDs +----------------------+ Repair FEC Payload IDs ^ Source payloads | Repair payloads |(1) FEC Source | and Repair Packets +----------------------+ | Transport Protocol | +----------------------+ ]]>

| | | payloads to FEC |(3) Explicit Source FEC +----------------+ | scheme | Payload IDs +----------------------+ Repair FEC Payload IDs ^ ^ Source payloads | | Repair payloads |Source pkts |Repair payloads | | +-- |- -- -- -- -- -- -+ |RTP| | RTP Processing | | | +-- -- -- --|-- -+ | +-- -- -- -- -- |--+ | | | RTP Demux | | +-- -- -- -- -- -- -- -+ ^ |(1) FEC Source and Repair Packets | +----------------------+ | Transport Protocol | +----------------------+ ]]>

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., , Figure 6) and repair data packets (i.e., , 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, equally applies to this FECFRAME extension and is not repeated here.

The FEC Scheme requirements of , Section 5.6, mostly apply to this FECFRAME extension and are not repeated here. An exception though is the "full specification of the FEC code", item (4), that is specific to block FEC codes. The following item (4-bis) applies in case of Sliding Window FEC schemes: 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 to a Sliding Window FEC Code: MUST define the relationships between ADUs and the associated source symbols (mapping); MUST define the management of the encoding window that slides over the set of ADUs. provides non normative hints about what FEC Scheme designers need to consider; MUST define the management of the decoding window. This usually consists in managing a system of linear equations (in case of a linear FEC code);

The discussion of , Section 6, equally applies to this FECFRAME extension and is not repeated here.

The discussion of , Section 7, equally applies to this FECFRAME extension and is not repeated here.

The discussion of , Section 8, equally applies to this FECFRAME extension and is not repeated here.

Editor's notes: RFC Editor, please remove this section motivated by RFC 7942 before publishing the RFC. Thanks! An implementation of FECFRAME extended to Sliding Window codes exists: Organisation: Inria Description: This is an implementation of FECFRAME extended to Sliding Window codes and supporting the RLC FEC Scheme . It is based on: (1) a proprietary implementation of FECFRAME, made by Inria and Expway for which interoperability tests have been conducted; and (2) a proprietary implementation of RLC Sliding Window FEC Codes. Maturity: the basic FECFRAME maturity is "production", the FECFRAME extension maturity is "under progress". Coverage: the software implements a subset of , as specialized by the 3GPP eMBMS standard . This software also covers the additional features of FECFRAME extended to Sliding Window codes, in particular the RLC FEC Scheme. Licensing: proprietary. Implementation experience: maximum. Information update date: March 2018. Contact: vincent.roca@inria.fr

This FECFRAME extension does not add any new security consideration. All the considerations of , Section 9, 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 "Problem Statement" of : Attacks can try to corrupt source flows in order to modify the receiver application's behavior (as opposed to just denying service).

This FECFRAME extension does not add any new Operations and Management Consideration. All the considerations of , Section 10, apply to this document as well.

No IANA actions are required for this document. 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, apply and are not repeated here.

The authors would like to thank Christer Holmberg, David Black, Gorry Fairhurst, and 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 to , the authors would also like to thank Mark Watson as the main author of that RFC.

&rfc2119; &rfc8174; &rfc6363; &rfc5052; &rfc6364; &rfc6681; &rfc6816; &rfc6865; &rfc8406; 3GPP

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. Source symbols are removed from the sliding encoding window, for instance: after a certain delay, when an "old" ADU of a real-time flow times out. The source symbol retention delay in the sliding encoding window should therefore be initialized according to the real-time features of incoming flow(s) when applicable; once the sliding encoding window has reached its maximum size (there is usually an upper limit to the sliding encoding window size). In that case the oldest symbol is removed each time a new source symbol is added. Several considerations can impact the management of this sliding encoding window: at the source flows level: real-time constraints can limit the total time source symbols can remain in the encoding window; at the FEC code level: theoretical or practical limitations (e.g., because of computational complexity) can limit the number of source symbols in the encoding window; at the FEC Scheme level: signaling and window management are intrinsically related. For instance, an encoding window composed of a non-sequential set of source symbols requires an appropriate signaling to inform a receiver of the composition of the encoding window, and the associated transmission overhead can limit the maximum encoding window size. On the opposite, an encoding window always composed of a sequential set of source symbols simplifies signaling: providing the identity of the first source symbol plus their number is sufficient, which creates a fixed and relatively small transmission overhead.