RFC 6363
Forward Error Correction (FEC) Framework
RFC 6363: Forward Error Correction (FEC) Framework 🎀
Okay bestie, let's go! 🦋 This is RFC 6363, and it's a Standards Track document (so it's official, not just vibes) from October 2011. ✨
Its authors are M. Watson from Netflix, Inc., A. Begen from Cisco, and V. Roca from INRIA. The ISSN is 2070-1721. It doesn't list any "Obsoletes" or "Updates" entries in its title block, so it isn't replacing or changing any other RFC. 💅
Abstract 🦋
So the big idea here is a framework for using Forward Error Correction (FEC) codes in public and private IP networks to protect against packet loss 🛡️. It works on arbitrary packet flows over unreliable transport and is mainly built for real-time, or streaming, media 🎬. You can use it to define Content Delivery Protocols that bring FEC to streaming media or other packet flows 📡.
The best part is that these protocols can support any FEC scheme (and its FEC codes) that follows the requirements in this document 🔥. So Content Delivery Protocols don't have to be tied to one specific FEC scheme, and FEC schemes don't have to be tied to one specific Content Delivery Protocol. It's giving mix-and-match energy 💖.
Status of This Memo 📜
This is an Internet Standards Track document. ✨
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more on Internet Standards, check Section 2 of RFC 5741 🌸.
Info about the current status of this document, any errata, and how to send feedback can be found at http://www.rfc-editor.org/info/rfc6363. 🧚
Copyright Notice 💜
Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️.
This document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process 😭. Unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🍓.
Table of Contents 🗂️
1. Introduction ....................................................3
2. Definitions and Abbreviations ...................................5
3. Architecture Overview ...........................................7
4. Procedural Overview ............................................11
4.1. General ...................................................11
4.2. Sender Operation ..........................................13
4.3. Receiver Operation ........................................15
5. Protocol Specification .........................................19
5.1. General ...................................................19
5.2. Structure of the Source Block .............................19
5.3. Packet Format for FEC Source Packets ......................19
5.3.1. Generic Explicit Source FEC Payload ID .............21
5.4. Packet Format for FEC Repair Packets ......................21
5.4.1. Packet Format for FEC Repair Packets over RTP ......22
5.5. FEC Framework Configuration Information ...................22
5.6. FEC Scheme Requirements ...................................24
6. Feedback .......................................................26
7. Transport Protocols ............................................27
8. Congestion Control .............................................27
8.1. Motivation ................................................27
8.2. Normative Requirements ....................................29
9. Security Considerations ........................................29
9.1. Problem Statement .........................................29
9.2. Attacks against the Data Flows ............................31
9.2.1. Access to Confidential Content .....................31
9.2.2. Content Corruption .................................32
9.3. Attacks against the FEC Parameters ........................33
9.4. When Several Source Flows Are to Be Protected Together ....33
9.5. Baseline Secure FEC Framework Operation ...................34
10. Operations and Management Considerations ......................35
10.1. What Are the Key Aspects to Consider? ....................35
10.2. Operational and Management Recommendations ...............36
11. IANA Considerations ...........................................39
12. Acknowledgments ...............................................39
13. References ....................................................40
13.1. Normative References .....................................40
13.2. Informative References ...................................401. Introduction 🎀
Okay, so tons of apps need to send a never-ending stream of packetized data from a source (the sender) to one or more destinations (the receivers) over networks that don't promise packets will arrive 😭. The big examples are real-time, or streaming, media apps like broadcast, multicast, or on-demand audio, video, and multimedia 📺.
Forward Error Correction (FEC) is a famous technique for making packet transmission more reliable over networks that don't guarantee delivery, especially in multicast and broadcast apps 🔥. The FEC Building Block, defined in [RFC5052], gives you a framework for defining Content Delivery Protocols (CDPs) for object delivery (mostly file delivery) that use separately defined FEC schemes 📦. Any CDP written to the FEC Building Block's requirements can easily be paired with any FEC scheme that's also written to those requirements 💅.
Quick side note: you'll sometimes see "Forward Erasure Correction." An erasure is an error where data gets lost and you can tell it's lost, instead of getting it in a corrupted form 🙈. This document is strictly about erasures, but "Forward Error Correction" is the more popular term, so that's what we're using 🌸.
This document defines a framework for CDPs that add FEC protection to arbitrary packet flows over unreliable transports, like UDP 🦋. So it's the sibling of the FEC Building Block in [RFC5052]: it gives arbitrary packet flows over unreliable transport the same kind of framework that document gives object delivery 💖. It doesn't define a complete CDP, though. It only covers the parts that are expected to be shared by all CDPs built on this framework 🧚.
Here's the thing: this framework doesn't decide how the flows to be protected are picked out, and it doesn't say how the details of the protected flows and the FEC streams protecting them get communicated from sender to receiver 🙃. A complete CDP spec that uses this framework is expected to handle that signaling ✨. What this document does specify is the info the FEC Framework needs at the sender and receiver, like the details of the flows to be FEC protected, the flow(s) that will carry the FEC protection data, and an opaque container for FEC-Scheme-Specific Information 🎁.
FEC schemes designed for this framework have to meet a bunch of requirements defined in this document 📋. These requirements are different from the ones in [RFC5052] for FEC schemes used for object delivery. But there's a LOT of overlap, and FEC schemes made for object delivery can be pretty easily adapted to work with this framework 👑.
Since RTP [RFC3550] is (often) sent over UDP, this framework works for RTP flows too 🎶. FEC repair packets can go straight over UDP or over RTP. RTP has a perk: RTP instrumentation based on the RTP Control Protocol (RTCP) can be used for the repair flow 📊. Plus, the post-repair RTCP extended reports [RFC5725] can be used to find out the loss rate after FEC recovery 🌈.
For each FEC scheme, the use of RTP for repair flows gets defined by writing an RTP payload format for that particular scheme. That can happen in the same document, too 💜.
2. Definitions and Abbreviations ✨
okay bestie, this is the glossary section and it's giving dictionary energy 📖💅 Every term here gets used all over the rest of the doc, so let's get them straight.
Application Data Unit (ADU): the chunk of source data handed down as the payload to the transport layer. 📦
ADU Flow: a sequence of ADUs tied to one transport-layer flow identifier, like the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}. 🦋
AL-FEC: Application-layer Forward Error Correction. 🧚
Application Protocol: the control protocol used to set up and manage the source flow being protected, e.g., the Real-Time Streaming Protocol (RTSP). 🎀
Content Delivery Protocol (CDP): a complete application protocol spec that, by using the framework defined in this document, can make use of FEC schemes to get FEC capabilities. 💖
FEC Code: an algorithm for encoding data so the encoded data flow stays resilient to data loss. Generally, FEC codes can also make a flow resilient to corruption, but this document doesn't cover that. 🌸
FEC Framework: a protocol framework for defining Content Delivery Protocols that use FEC, like the framework defined in this document. ✨
FEC Framework Configuration Information: the info that controls how the FEC Framework operates. ⭐
FEC Payload ID: the info that identifies a packet's contents with respect to the FEC scheme. 🫶
FEC Repair Packet: at a sender (or at a receiver), a payload handed to (or received from) the transport protocol that contains one or more repair symbols along with a Repair FEC Payload ID and possibly an RTP header. 🔥
FEC Scheme: a spec that defines the additional protocol aspects required to use a particular FEC code with the FEC Framework. 👑
FEC Source Packet: at a sender (or at a receiver), a payload handed to (or received from) the transport protocol that contains an ADU along with an optional Explicit Source FEC Payload ID. 💅
Protection Amount: the relative increase in data sent due to the use of FEC. 📈
Repair Flow: the packet flow carrying FEC data. 🌈
Repair FEC Payload ID: a FEC Payload ID made specifically for repair packets. 💜
Source Flow: the packet flow that FEC protection is to be applied to. A source flow consists of ADUs. 🍓
Source FEC Payload ID: a FEC Payload ID made specifically for source packets. 🧚
Source Protocol: a protocol used for the source flow being protected, e.g., RTP. 🌸
Transport Protocol: the protocol used to carry the source and repair flows, e.g., UDP and the Datagram Congestion Control Protocol (DCCP). 🦋
The following definitions are aligned with [RFC5052]: this part is giving textbook but make it cute 🎀
Code Rate: 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 means only a small number of repair symbols were produced during the encoding process. 💫
Encoding Symbol: a unit of data generated by the encoding process. With systematic codes, source symbols are part of the encoding symbols. 🌷
Packet Erasure Channel: a communication path where packets are either dropped (e.g., by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical-layer codes) or received. When a packet is received, it is assumed that the packet is not corrupted. 🌊
Repair Symbol: an encoding symbol that is not a source symbol. 🩹
Source Block: a group of ADUs that are to be FEC protected as a single block. 🧱
Source Symbol: a unit of data used during the encoding process. 🍒
Systematic Code: a 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the official words that carry the big requirement energy, so keep an eye out for them 👀✨
3. Architecture Overview ✨
okay so the FEC Framework is described as an extra layer sitting between the transport layer (like UDP or DCCP) and the protocols running on top of that transport 💅. That means the data path interface between the FEC Framework and the layers both below and above it can be thought of as being the same as the standard interface to the transport layer 🦋. The data being exchanged is datagram payloads, and each one is associated with a single ADU flow, identified by the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}. If RTP is used for the repair flows, the source and repair data can be multiplexed using RTP onto a single UDP flow, and then the receiver needs to demultiplex it 🧚. There are lots of ways to do that multiplexing (for example, the one described in [RFC4588]).
The whole point of the FEC Framework architecture is to hand out functional responsibilities to separately documented components, so that specific instances of those components can be mixed and matched in different ways to describe different protocols 🎀. It's giving modular, bestie 💖.
The FEC Framework uses a FEC scheme, in a similar sense to the one defined in [RFC5052], and it uses the terminology from that document 📚. The FEC scheme handles the FEC encoding and decoding, and it defines the protocol fields and procedures used to identify packet payload data in the context of the scheme ✨. The interface between the FEC Framework and a FEC scheme is described in this document, but it's a logical one that only exists for specification purposes, so don't go looking for it in the wild 🙈. On the encoder side, the FEC Framework passes ADUs to the FEC scheme for FEC encoding. The scheme hands back repair symbols with their associated Repair FEC Payload IDs and, depending on the scheme, Source FEC Payload IDs too 🌈. On the decoder side, the FEC Framework passes transport packet payloads (both source and repair) to the FEC scheme, and the scheme returns any additional recovered source packet payloads 🫶.
This document defines certain FEC Framework Configuration Information that MUST be available to both the sender and the receiver(s) 👑. This includes things like the specification of the ADU flows that are going to be FEC protected, the specification of the ADU flow(s) that will carry the FEC protection (repair) data, and the relationship between those source and repair flows (aka which source flows are protected by which repair flows) 💜. The Configuration Information also includes fields that are specific to the FEC scheme, and this info is analogous to the FEC Object Transmission Information defined in [RFC5052] ⭐.
The FEC Framework does not define how the FEC Framework Configuration Information for the stream gets communicated from sender to receiver. That has to be defined by any CDP specification, as covered in the following sections 🦋.
In this architecture we assume the interface to the transport layer supports the concepts of data units (called Application Data Units, or ADUs) to be transported, and identification of the ADU flows those data units travel on 🍓. Since this is an interface internal to the architecture, we don't specify it explicitly. What we DO require is that ADU flows that are distinct from the transport layer's point of view (for example, distinct UDP flows identified by their UDP source/destination addresses and ports) also stay distinct on the interface between the transport layer and the FEC Framework 💅.
As mentioned above, RTP flows are a specific example of ADU flows that might be protected by the FEC Framework. From the FEC Framework's point of view, RTP source flows are just ADU flows like any other, with the RTP header included inside the ADU 🌸.
Depending on the FEC scheme, RTP can also be used as a transport for repair packet flows. In that case, the FEC scheme has to define an RTP payload format for the repair data 🧚♀️.
The architecture is illustrated in Figure 1 below 👇. In this architecture, two (optional) RTP instances are shown, one for the source data and one for the repair data. That's because using RTP for the source data is separate from, and independent of, using RTP for the repair data 🫧. Two RTP instances make more sense once you realize that in many FEC codes, the repair payload contains repair data calculated across the RTP headers of the source packets. So a repair packet carried over RTP starts with an RTP header of its own, followed (after the Repair Payload ID) by repair data containing bytes that protect the source RTP headers, as well as repair data for the source RTP payloads 🤯.
+--------------------------------------------+
| Application |
+--------------------------------------------+
|
|
|
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ |
| Application Layer |
| +--------------------------------------------+ |
| |
| + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP (Optional) | |
| | | |- Configuration/
+- -- -- -- -- -- -- -- -- -- -- -+ | Coordination
| | | |
| ADU flows |
| | v |
+--------------------------------------------+ +------------+
| | FEC Framework (This document) |<--->| FEC Scheme |
+--------------------------------------------+ +------------+
| | | |
Source | Repair |
| | | |
+-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
| | RTP Layer | | RTP Processing | | |
| (Optional) | +-- -- -- |- -- -+ |
| | +-- -- -- -- -- -- -- |--+ | |
| | RTP (De)multiplexing | |
| +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
|
| +--------------------------------------------+ |
| Transport Layer (e.g., UDP) |
| +--------------------------------------------+ |
|
| +--------------------------------------------+ |
| IP |
| +--------------------------------------------+ |
| Content Delivery Protocol |
+ - - - - - - - - - - - - - - - - - - - - - - - +
Figure 1: FEC Framework ArchitectureThe content of the transport payload for repair packets is fully defined by the FEC scheme 🔥. For a specific FEC scheme, a means MAY be defined for repair data to be carried over RTP, in which case the repair packet payload format starts with the RTP header. That's basically the same thing as defining an RTP payload format for that specific FEC scheme 💖.
The use of RTP for repair packets is independent of the protocols used for source packets. If RTP is used for source packets, repair packets may or may not use RTP, and vice versa. (Although it's unlikely there are useful scenarios where non-RTP source flows get protected by RTP repair flows 🙃.) FEC schemes are expected to recover entire transport payloads for recovered source packets in all cases. For example, if RTP is used for source flows, the FEC scheme is expected to recover the entire UDP payload, including the RTP header 🎀.
4. Procedural Overview 🌸
4.1. General
Okay so the big vibe here is that this mechanism is super chill about which ADUs get protected together 💅. The only real rule is that the ADU has to ride over a supported transport protocol (see Section 7) ✨. The data can even come from multiple source flows that are protected jointly 🫶. The FEC Framework treats the flows as a sequence of source blocks, where each block is a bundle of ADUs, possibly from several source flows that are protected together 🎀. For example, each source block could be built from the ADUs tied to one particular segment in time of the flow 🧚.
At the sender, the FEC Framework hands the payloads for a given block over to the FEC scheme for FEC encoding 🔥. The FEC scheme does the encoding and gives back:
- Optionally, FEC Payload IDs for each of the source payloads (encoded according to a FEC-Scheme-Specific format).
- One or more FEC repair packet payloads.
- FEC Payload IDs for each of the repair packet payloads (encoded according to a FEC-Scheme-Specific format).
Then the FEC Framework does two things 💖. First, it appends the Source FEC Payload IDs (if provided) to each of the ADUs and sends the results, known as "FEC source packets", to the receiver. Second, it places the provided FEC repair packet payloads and their corresponding Repair FEC Payload IDs appropriately to build FEC repair packets, then sends those along too 🦋.
This document does not define how the sender decides which ADUs go into which source blocks, or the sending order and timing of FEC source and repair packets 🙈. A specific CDP MAY define this mapping, or it MAY be left as implementation dependent at the sender. However, a CDP specification MUST define how a receiver determines a minimum length of time that it needs to wait to receive FEC repair packets for any given source block 👑. FEC schemes MAY define limitations on this mapping, such as maximum size of source blocks, but they SHOULD NOT attempt to define specific mappings 💅. The sequence of operations at the sender is described in more detail in Section 4.2 🌈.
At the receiver, the FEC Framework recovers the original ADUs directly from any FEC source packets it receives, just by removing the Source FEC Payload ID if one is present ✨. The receiver also passes the contents of the received ADUs, plus their FEC Payload IDs, to the FEC scheme for possible decoding 🧚.
If any ADUs related to a given source block have been lost, the FEC scheme can perform FEC decoding to recover the missing ADUs (assuming sufficient FEC source and repair packets related to that source block have been received) 😭.
Note that the receiver might need to buffer received source packets so there's time for the FEC repair packets to arrive and FEC decoding to happen before some or all of the received or recovered packets get passed up to the application ⏳. If such a buffer is not provided, then the application has to be able to deal with the severe re-ordering of packets that can occur 💀. However, that buffering is CDP- and/or implementation-specific and is not specified here 🙈. The receiver operation is described in more detail in Section 4.3 💅.
The FEC source packets MUST contain information that identifies the source block and the position within the source block (in terms specific to the FEC scheme) occupied by the ADU. This information is known as the Source FEC Payload ID. The FEC scheme is responsible for defining and interpreting this information. This information MAY be encoded into a specific field within the FEC source packet format defined in this specification, called the Explicit Source FEC Payload ID field. The exact contents and format of the Explicit Source FEC Payload ID field are defined by the FEC schemes. Alternatively, the FEC scheme MAY define how the Source FEC Payload ID is derived from other fields within the source packets. This document defines the way that the Explicit Source FEC Payload ID field is appended to source packets to form FEC source packets 🎀.
The FEC repair packets MUST contain information that identifies the source block and the relationship between the contained repair payloads and the original source block. This is known as the Repair FEC Payload ID. This information MUST be encoded into a specific field, the Repair FEC Payload ID field, the contents and format of which are defined by the FEC schemes 🔥.
The FEC scheme MAY use different FEC Payload ID field formats for source and repair packets 💜.
4.2. Sender Operation
It is assumed that the sender has constructed or received original data packets for the session 🌸. These could be carrying any type of data. The following operations, illustrated in Figure 2 for the case of UDP repair flows and in Figure 3 for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows 🦋:
- ADUs are provided by the application.
- A source block is constructed as specified in Section 5.2.
- The source block is passed to the FEC scheme for FEC encoding. The Source FEC Payload ID information of each 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 IDfield. - The FEC scheme performs FEC encoding, generating repair packet payloads from a source block and a Repair FEC Payload ID field for each repair payload.
- The
Explicit Source FEC Payload IDs (if used), Repair FEC Payload IDs, and repair packet payloads are provided back from the FEC scheme to the FEC Framework. - The FEC Framework constructs FEC source packets according to Section 5.3, and FEC repair packets according to Section 5.4, using the FEC Payload IDs and repair packet payloads provided by the FEC scheme.
- The FEC source and 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. The FEC source packets are sent using the same ADU flow identification information as would have been used for the original source packets if the FEC Framework were not present (for example, in the UDP case, the UDP source and destination addresses and ports on the IP datagram carrying the source packet will be the same whether or not the FEC Framework is applied) ✨.
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| 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 Layer |
| (e.g., UDP) |
+----------------------+
Figure 2: Sender Operation +----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source packets and| | |
| repair payloads |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| | Repair FEC Payload IDs
| | Repair symbols
| |
|(7) Source |(7') Repair payloads
| packets |
| |
| + -- -- -- -- -+
| | RTP |
| +-- -- -- -- --+
v v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 3: Sender Operation with RTP Repair Flows4.3. Receiver Operation 📬
okay so here's the receiver's playbook 💅 Figure 4 shows the plain UDP version and Figure 5 shows RTP repair flows. This is what happens when a FEC source or repair packet shows up:
- FEC source packets and FEC repair packets get received and handed to the FEC Framework. The packet type (source or repair), plus the source flow it belongs to (for source packets), comes from the ADU flow information, which identifies the flow at the transport layer.
bestie, the special case 🎀: if RTP is used for repair packets and the source and repair packets are multiplexed onto the same UDP flow, then RTP demultiplexing is required to split source and repair flows apart. But RTP processing only happens to the repair packets at this stage. Source packets keep being handled as UDP payloads (i.e., including their RTP headers) 🧚
- The FEC Framework pulls the Explicit Source FEC Payload ID field (if present) out of the source packets, and the Repair FEC Payload ID out of the repair packets.
- The Explicit Source FEC Payload IDs (if present), the Repair FEC Payload IDs, and the FEC source and repair payloads all get passed to the FEC scheme.
- The FEC scheme uses the received FEC Payload IDs to group source and repair packets into source blocks. (If the Explicit Source FEC Payload ID field isn't used, it uses derived FEC Source Payload IDs instead.) If at least one source packet is missing from a source block, and at least one repair packet has arrived for that same source block, then FEC decoding can be performed to recover the missing source payloads. The FEC scheme figures out whether any source packets were lost, and whether enough data has come in to decode any or all of the missing source payloads in that block. Main character energy 👑
- The FEC scheme hands the ADUs back to the FEC Framework as source blocks. Those blocks contain the received and decoded ADUs, plus indications of any ADUs that were missing and couldn't be decoded.
- The FEC Framework passes the received and recovered ADUs up to the application. ✨
This description covers who is responsible for what, but it doesn't imply any specific timing relationships 🦋 Source packets that arrive correctly, and ones that get reconstructed, MAY be delivered to the application out of order, and in a different order from the order they arrived at the receiver. Or, if the application needs it, buffering and packet re-ordering MAY be applied to put received and reconstructed source packets back into the order they were placed in the source block.
Here's Figure 4 for the UDP version:
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ Repair FEC Payload IDs
| Source payloads
| Repair payloads
|
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+Figure 4: Receiver Operation
And here's Figure 5, the RTP repair flow version 🌈
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ ^ Repair FEC Payload IDs
| | Source payloads
| | Repair payloads
| |
|Source |Repair payloads
|packets |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux | |
+-- -- -- -- -- -- -- -+
^
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+Figure 5: Receiver Operation with RTP Repair Flows
heads up: running the procedure above might not recover every ADU. Not every ADU is guaranteed to come back, so keep that in mind 🙈
5. Protocol Specification 💖
5.1. General
okay so this section lays out the protocol elements for the FEC Framework 🧁 Three parts of the protocol are defined in this document, and each gets its own section below:
- Building a source block from ADUs. The FEC code gets applied to this source block to make the repair payloads.
- A format for packets that carry source data.
- A format for packets that carry repair data.
The FEC Framework's behaviour is controlled by some FEC Framework Configuration Information, which gets defined in this section. A complete protocol specification that uses this framework MUST specify how sender and receiver determine and communicate that information. No skipping this part, bestie 💅
5.2. Structure of the Source Block
The FEC Framework and the FEC scheme swap ADUs in the form of source blocks 🦋 The FEC Framework builds a source block out of an ordered sequence of ADUs. How ADUs get allocated to blocks depends on the application. Some ADUs might not end up in any block at all. Each source block handed to the FEC scheme is an ordered sequence of ADUs, and for each ADU, the following info is provided:
- A description of the source flow the ADU is associated with.
- The ADU itself.
- The length of the ADU.
5.3. Packet Format for FEC Source Packets
The packet format for FEC source packets MUST be used to carry the payload of an original source packet. As shown in Figure 6, it's the original packet, optionally followed by the Explicit Source FEC Payload ID field. The FEC scheme decides whether the Explicit Source FEC Payload ID field is required, and that decision is made per ADU flow 💜
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Application Data Unit |
+------------------------------------+
| Explicit Source FEC Payload ID |
+------------------------------------+Figure 6: Structure of the FEC Packet Format for FEC Source Packets
The FEC source packets MUST be sent using the same ADU flow the original source packets would have used if the FEC Framework weren't there. The transport payload of an FEC source packet MUST consist of the ADU followed by the Explicit Source FEC Payload ID field, if it's required.
The Explicit Source FEC Payload ID field holds the info needed to link the source packet to a source block and to run the FEC algorithm. The FEC scheme defines it, so the format of the Source FEC Payload ID field is up to the FEC scheme. If the FEC scheme or CDP has a way to derive the Source FEC Payload ID from other info already in the packet (for example, a sequence number the application protocol uses), then the Source FEC Payload ID field isn't included in the packet at all. In that case, the original source packet and the FEC source packet are identical 🙈
In applications where avoiding IP packet fragmentation is a goal, CDPs SHOULD consider the Explicit Source FEC Payload ID size when deciding how big the ADUs delivered through the FEC Framework should be. Why? Because adding the Explicit Source FEC Payload ID makes the packet longer 📏
The Explicit Source FEC Payload ID sits at the end of the packet, so if Robust Header Compression (ROHC) [RFC3095] or other header compression mechanisms are in use, ROHC can still be applied to FEC source packets. This also holds when a ROHC profile exists for the protocol carried in the transport payload (RTP, for example). Applications using this framework need to remember that FEC schemes can add this Explicit Source FEC Payload ID and make the packet bigger 🧚
In lots of applications, FEC support gets bolted onto an existing protocol. In that case, using the Explicit Source FEC Payload ID can break backward compatibility, because it changes the source packets 😭
5.3.1. Generic Explicit Source FEC Payload ID
Okay so, to protect a single source flow with multiple FEC schemes, all of those schemes have to use the same Explicit Source FEC Payload ID format 🫶 To make that work, it's RECOMMENDED that FEC schemes support the Generic Explicit Source FEC Payload ID format described below.
The Generic Explicit Source FEC Payload ID is two octets long and holds an unsigned packet sequence number in network-byte order. Assigning sequence numbers to packets doesn't depend on any FEC scheme or on how source blocks are built. The one catch is that using this sequence number puts a constraint on source block construction. Source packets within a given source block MUST have consecutive sequence numbers (where "consecutive" includes wrap-around from the maximum value that fits in two octets (65535) back to 0). Sequence numbers SHOULD NOT be reused until every value in the sequence number space has been used. 🔥
Note that if the original packets of the source flow already carry a packet sequence number that's at least two bytes long, there's no need to add the generic Explicit Source FEC Payload ID or modify the packets. Literally less work, iconic 🌸
5.4. Packet Format for FEC Repair Packets 🦋
okay so here's the layout for FEC repair packets 💅. The transport payload is a Repair FEC Payload ID field followed by the repair data that comes out of the FEC encoding process. Figure 7 shows the whole vibe:
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+Figure 7: Packet Format for FEC Repair Packets
The Repair FEC Payload ID field carries the info the FEC algorithm needs at the receiver 🧠. The FEC scheme decides what that info is, so the format of this field is defined by the FEC scheme too. ✨
5.4.1. Packet Format for FEC Repair Packets over RTP 🎀
For FEC schemes that specify the use of RTP for repair packets, the packet format for repair packets includes an RTP header, as shown in Figure 8. 🌈
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header (UDP) |
+------------------------------------+
| RTP Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+Figure 8: Packet Format for FEC Repair Packets over RTP
5.5. FEC Framework Configuration Information 🌸
The FEC Framework Configuration Information is the info the FEC Framework needs in order to protect the ADU flows 🫶. A complete CDP specification that uses the framework described here MUST include details of how this information is derived and communicated between sender and receiver. Lowkey the most important homework 📚.
The FEC Framework Configuration Information includes identification of the set of source flows. For example, with UDP, each source flow is uniquely identified by a tuple of {source IP address, source UDP port, destination IP address, destination UDP port}. Some applications let some of these fields be wildcards, so the flow is identified by a subset of the fields. In many applications, the limited tuple {destination IP address, destination UDP port} is enough, which is so relatable 🙈.
A single instance of the FEC Framework protects packets of the specified set of source flows, using one or more packet flows made of repair packets 🔥. For each instance of the FEC Framework, the FEC Framework Configuration Information includes:
- Identification of the repair flows.
- For each source flow protected by the repair flow(s):
A. Definition of the source flow.
B. An integer identifier for this flow definition (i.e., tuple). This identifier MUST be unique among all source flows that are protected by the same FEC repair flow. Integer identifiers can start at zero and go up by one for each flow. Any random allocation that is still unique is also possible 🎲. A source flow identifier does not need to be carried in source packets, since source packets are already tied to a flow by their packet headers 💖.
- The FEC Encoding ID, which identifies the FEC scheme.
- The length of the Explicit Source FEC Payload ID (in octets).
- Zero or more FEC-Scheme-Specific Information (FSSI) elements, each made of a name and a value. The valid element names and value ranges are defined by the FEC scheme 🧁.
Multiple instances of the FEC Framework, each with separate and independent FEC Framework Configuration Information, can exist at a sender or receiver 👑. A single instance of the FEC Framework protects the packets of the source flows identified in (2) above. In other words, all packets sent on those flows MUST be FEC source packets as defined in Section 5.3. A single source flow can be protected by multiple instances of the FEC Framework 🌟.
The integer flow identifier from (2B) above is a shorthand for identifying source flows between the FEC Framework and the FEC scheme 🧚. It is an integer, and it lives in the FEC Framework Configuration Information, so the FEC scheme at the sender and receiver can use it to figure out which source flow a recovered packet belongs to. That means the integer flow identifier can take the place of the complete flow description, like a UDP 4-tuple 🎀.
Whether and how this flow identifier is used is defined by the FEC scheme. Repair packets can protect multiple source flows, so repair packets either would not carry the identifier at all or can carry multiple identifiers. Either way, the flow identifier for a particular source packet can be recovered from the repair packets during a FEC decoding operation 🔍.
A single FEC repair flow provides repair packets for a single instance of the FEC Framework. Other packets MUST NOT be sent within this flow. In other words, all packets in the FEC repair flow MUST be FEC repair packets as defined in Section 5.4, and they MUST relate to the same FEC Framework instance 🚫.
If RTP is used for repair packets, the identification of the repair packet flow can also include the RTP payload type to be used for repair packets 🎶.
FSSI holds the info that is specific to the FEC scheme used by the CDP 💅. It carries information that cannot be represented adequately any other way, and it is essential for proper FEC encoding and decoding operations 🌷. The reason the SS-FSSI is split off from the rest of the FSSI is so the receiver, or third-party entities, can control the FEC operations at the sender. This split-off info is the Sender-Side FEC-Scheme-Specific Information (SS-FSSI) container, and it holds only what the sender alone needs. Any FSSI other than the info solely required by the sender MUST be communicated via the FSSI container 🫶.
The variable-length SS-FSSI and FSSI containers transmit their info in textual representation. Each contains zero or more distinct elements, and the fully specified FEC schemes describe those elements 📝.
For CDPs that choose the Session Description Protocol (SDP) [RFC4566] for their multimedia sessions, the ABNF [RFC5234] syntax for the SS-FSSI and FSSI containers is provided in Section 4.5 of [RFC6364] 🎬.
5.6. FEC Scheme Requirements 💜
To be used with this framework, a FEC scheme MUST be capable of processing data arranged into blocks of ADUs (source blocks) 🧩.
A specification for a new FEC scheme MUST include the following:
- The FEC Encoding ID value that uniquely identifies the FEC scheme. This value MUST be registered with IANA, as described in Section 11.
- The type, semantics, and encoding format of the Repair FEC Payload ID.
- The name, type, semantics, and text value encoding rules for zero or more FEC-Scheme-Specific Information elements.
- A full specification of the 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 a source block as defined in Section 5.2, valid values of the FEC-Scheme-Specific Information, a valid Repair FEC Payload ID value, and a valid packet payload size, the specification MUST uniquely define the values of the encoding symbols to be included in the repair packet payload of a packet with the given Repair FEC Payload ID value 🔐.
A common and simple way to specify the FEC code to the required level of detail is to provide a precise specification of an encoding algorithm. Given a source block, valid values of the FEC-Scheme-Specific Information, a valid Repair FEC Payload ID value, and a valid packet payload size as input, it produces the exact values of the encoding symbols as output 🧠.
- A description of practical encoding and decoding algorithms.
This description does not need to be as detailed as the encoding above. It does, however, have to be sufficient to demonstrate that encoding and decoding of the code are both possible and practical 🌈.
FEC scheme specifications MAY additionally define the following:
Type, semantics, and encoding format of an Explicit Source FEC Payload ID.
Whenever a FEC scheme specification defines an 'encoding format' for an element, that has to be defined as a sequence of bytes that can be embedded within a protocol 🧃. The length of the encoding format either MUST be fixed or it MUST be possible to derive the length from examining the encoded bytes themselves. For example, the initial bytes can include some kind of length indication 📏.
FEC scheme specifications SHOULD use the terminology defined in this document and SHOULD follow the format below 🍓:
1. Introduction <Describe the use cases addressed by this FEC
scheme>
2. Formats and Codes
2.1. Source FEC Payload ID(s) <Either define the type and
format of the Explicit Source FEC Payload ID or define how
Source FEC Payload ID information is derived from source
packets>
2.2. Repair FEC Payload ID <Define the type and format of the
Repair FEC Payload ID>
2.3. FEC Framework Configuration Information <Define the names,
types, and text value encoding formats of the FEC-Scheme-
Specific Information elements>
3. Procedures <Describe any procedures that are specific to this
FEC scheme, in particular derivation and interpretation of the
fields in the FEC Payload IDs and FEC-Scheme-Specific
Information>
4. FEC Code Specification <Provide a complete specification of the
FEC Code>Specifications can include additional sections, including examples 🌸.
Each FEC scheme MUST be specified independently of all other FEC schemes. For example, that can be a separate specification or a completely independent section of a larger specification. The exception is that a specification of one FEC scheme can include portions of another by reference 🔗. Where an RTP payload format is defined for repair data for a specific FEC scheme, the RTP payload format and the FEC scheme can be specified within the same document 🎀.
6. Feedback ✨
Okay so lots of apps need some kind of feedback on how the transport is doing 📊: how much data reached the receiver, at what rate, and when? 👀 Once you add FEC, that feedback might need a glow-up too, so it can report on how the FEC is doing, like how much of the lost data FEC actually got back 💅. For engineering stuff, remember FEC usually works on pretty small blocks (each one gets sent over a short stretch of time), so feedback averaged over longer periods probably won't tell you enough. ngl, more detailed feedback over shorter timescales might be the move 🎯. For apps using RTP transport, check out [RFC5725].
Apps that use feedback for congestion control MUST calculate that feedback based on packets received before FEC recovery is applied 🚨. If that clashes with other uses of the feedback, the app MUST be enhanced to support information calculated both pre- and post-FEC recovery 🫶. The whole point is making sure congestion control works off the congestion signals coming from the network, not post-FEC recovery info that would paint a wrong picture of congestion 😭.
New apps that need this kind of feedback SHOULD use RTP/RTCP [RFC3550] 🎀.
7. Transport Protocols 🦋
This framework is meant for defining CDPs that run over transport protocols with an unreliable datagram service, including the User Datagram Protocol (UDP) and the Datagram Congestion Control Protocol (DCCP) 🌊.
8. Congestion Control 🚦
This section starts with some informative background on the motivation behind the normative requirements for congestion control, which are spelled out in Section 8.2 📚.
8.1. Motivation 🌸
- Enforcing congestion control principles has gained a lot of momentum at the IETF over recent years 💜. Congestion control over the open Internet is unquestioned, and the goal of TCP friendliness is generally agreed upon for most (but not all) applications. Still, detecting and measuring congestion in heterogeneous networks is far from solved 🙈. Most congestion control algorithms detect and measure congestion by taking (primarily or exclusively) the packet loss rate into account, which seems inappropriate in environments where a big chunk of packet losses come from link-layer errors and have nothing to do with network load 💀.
- The authors are mainly interested in applications where the application's reliability requirements and the network's end-to-end reliability don't match, so the packet stream warrants higher-layer protection. This could be because of unreliable links in the end-to-end path, and where real-time, scalability, or other constraints rule out higher-layer (transport or application) feedback ✨. A classic example is multicast and broadcast streaming, or multimedia over heterogeneous networks 📺. In other cases, the application's reliability requirements can be so high that the required end-to-end reliability is hard to reach 🧗. Plus, the end-to-end network reliability isn't necessarily known in advance 🤷♀️.
- This FEC Framework is not defined as, nor is it meant to be, a quality-of-service (QoS) enhancement tool for fighting losses from highly congested networks. It should not be used for such purposes 🙅♀️.
- One way to prevent that misuse is to leave standardization to the bodies most concerned with the problem above. However, the IETF defines base standards used by several bodies, including the Digital Video Broadcasting (DVB) Project, the Third Generation Partnership Project (3GPP), and 3GPP2, and they all seem to share the same environment and problem 🤝.
- Another approach is to write a clear applicability statement. For example, you could restrict the use of this framework to networks with certain loss characteristics (like wireless links) 📶. But there can be applications where FEC is justified to combat congestion-induced packet losses, especially in lightly loaded networks, where congestion is the result of relatively rare random peaks in instantaneous traffic load. That means intentionally violating congestion control principles 😬. One possible example is a no-matter-what, brute-force FEC protection of traffic generated as an emergency signal 🚨.
- A third approach is to require, at a minimum, that using this framework with any given application, in any given environment, doesn't cause congestion issues the application alone wouldn't cause. In other words, using this framework must not make things worse 🫶.
- With all of the above in mind, Section 8.2 lays out a small set of constraints for FEC. These constraints are mandatory for all senders compliant with this FEC Framework 💅. Certain CDPs can impose further restrictions 🌈.
8.2. Normative Requirements 💖
- The bandwidth of FEC repair data MUST NOT exceed the bandwidth of the original source data being protected (without the possible addition of an Explicit Source FEC Payload ID) 🛑. This blocks the (static or dynamic) use of excessively strong FEC to fight high packet loss rates, which naively implemented dynamic FEC-strength selection mechanisms could otherwise pick 🙃. We do acknowledge that a few exotic applications, like IP traffic from space-based senders or senders in certain hardened military devices, could justify a higher FEC strength 🛰️. But in this specification, we're giving preference to the overall stability and network friendliness of average applications 🫶.
- Whenever the source data rate gets adapted because of congestion control mechanisms, the FEC repair data rate MUST be similarly adapted 🔄.
9. Security Considerations 🔐
First of all, it must be clear that applying FEC protection to a stream does not provide any kind of security 💀. On the contrary, the FEC Framework itself could be subject to attacks or could pose new security risks 🚨. The goals of this section are to state the problem, discuss the risks, and identify solutions when feasible. It also defines a mandatory-to-implement (but not mandatory-to-use) security scheme 🔒.
9.1. Problem Statement 🕵️♀️
A content delivery system is potentially subject to lots of attacks 😱. Attacks can target the content, the CDP, or the network itself, and the consequences can be totally different, especially in terms of how many nodes get impacted 💥.
Attacks can have several goals:
- They can try to get access to confidential content (for example, in the case of non-free content) 🔓.
- They can try to corrupt the source flows (for example, to stop a receiver from using them), which is a form of denial-of-service (DoS) attack 🙅♀️.
- They can try to compromise the receiver's behavior (for example, by making the decoding of an object computationally expensive), which is another form of DoS attack 🥵.
- They can try to compromise the network's behavior (for example, by causing congestion within the network), which can hit a large number of nodes 🌪️.
These attacks can be launched against the source and/or repair flows (for example, by sending fake FEC source and/or repair packets), or against the FEC parameters. Those parameters are sent either in-band (for example, in the Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or out-of-band (for example, in the FEC Framework Configuration Information) 👀.
Several dimensions of the problem need to be considered 🧩. The first one is how the FEC Framework is used. It can be used end-to-end, meaning it's included in the final end-device where the upper application runs. Or it can be used in middleboxes, for instance to globally protect several source flows exchanged between two or more distant sites 🏢.
A second dimension is the threat model. When the FEC Framework operates in the end-device (like a personal computer), that device might be subject to attacks. In this case, the attacker is either the end-user (who might want to access confidential content) or somebody else 🕶️. In all cases, the attacker has access to the end-device but doesn't necessarily fully control it, since a secure domain can exist 🛡️. Similarly, when the FEC Framework operates in a middlebox, that middlebox can be attacked, or the attacker can gain access to it 🫣. The threats can also target the end-to-end transport (for example, through the Internet). Here, examples include sending fake FEC source or repair packets, replaying valid packets, dropping, delaying, or misordering packets, and, of course, traffic eavesdropping 👂.
The third dimension is the desired security services. Among them, content integrity and sender authentication are probably the most important features 🥇. We can also mention DoS mitigation, anti-replay protection, or content confidentiality 💜.
Finally, the fourth dimension is the security tools available. This includes the various Digital Rights Management (DRM) systems, defined outside the context of the IETF, which can be proprietary solutions 🎫. Otherwise, the Secure Real-Time Transport Protocol (SRTP) [RFC3711] and IPsec/Encapsulating Security Payload (IPsec/ESP) [RFC4303] are two tools that can turn out to be useful in the context of the FEC Framework 🧰. Note that using SRTP requires that the application generate RTP source flows and, when applied below the FEC Framework, that both the FEC source and repair packets be regular RTP packets. So SRTP isn't a universal solution for every use case, sorry bestie 🥺.
In the following sections, we dig deeper into security aspects related to the use of the FEC Framework 🔍.
9.2. Attacks against the Data Flows 🌷
9.2.1. Access to Confidential Content
Okay so, keeping the source flow private is usually done with encryption 🔐✨ The content provider can handle it, the application can do it (like with SRTP [RFC3711]), or the network layer can encrypt per packet when IPsec/ESP is in use [RFC4303]. If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used. We're bringing these attacks up here, but FEC has nothing to do with them. It doesn't cause them and it doesn't make them easier 🙅♀️
Real talk: when encryption is applied, it MUST be applied either on the source data before the FEC protection, or, if it's done after the FEC protection, on both the FEC source packets and the repair packets. The repair packets MUST get an encryption at least as cryptographically secure as the one on the FEC source packets 🔒 If you only encrypted the FEC source packets after FEC encoding, an unauthorized receiver could recover the source data after decoding the repair packets, as long as enough of them were available. 😭 Not it.
Here's what to think about when picking where encryption goes (and where other security services go too). Once decryption happens, the source data is in plaintext 👀 The whole path from the output of the deciphering module to the final destination (say, the TV display for a video) MUST be secured so nobody unauthorized can get to the source data.
When the FEC Framework endpoint is the end-system (where the upper application runs) and the threat model includes an attacker who could have access to that end-system, the end-system architecture is everything 💅 To keep an attacker from grabbing the plaintext, all processing after deciphering MUST occur in a protected environment. If encryption is applied after FEC protection at the sending side (so below the FEC Framework), then FEC decoding MUST take place in the protected environment too. In some use cases, this MAY be complicated or even impossible. In those cases, applying encryption before FEC protection is preferred.
When the FEC Framework endpoint is a middlebox, the recovered source flow (after FEC decoding) SHOULD NOT be sent in plaintext to the final destination(s) if the threat model includes an attacker eavesdropping on the traffic. In that situation, it's preferable to encrypt before FEC protection 🫶
Sometimes encryption can go both before and after FEC protection. The considerations above still apply in that case 🌸
9.2.2. Content Corruption
Protecting against corruption (like forged FEC source or repair packets) is done with a content integrity verification and source authentication scheme 🛡️ This service is usually provided at the packet level. Once all the forged packets are removed, the source flow can sometimes be recovered. A few techniques can give you this content integrity and source authentication:
- At the application layer, SRTP [RFC3711] has several solutions to check the integrity and authenticate the source of RTP and RTCP messages, among other things. For example, paired with the Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4383], SRTP is a really solid pick. It's robust to losses, it provides a true authentication/integrity service, and it doesn't create a prohibitive processing load or transmission overhead ✨ The catch: with TESLA, checking a packet needs a small delay (a second or more) after it's received. Whether that extra delay, both for startup at the client and end-to-end, is okay depends on the use case. In some situations it might hurt the user experience, and in others it won't be an issue at all. Other building blocks can also be used within SRTP to provide integrity/authentication services.
- At the network layer, IPsec/ESP [RFC4303] offers (among other services) an integrity verification mechanism that can be used to provide authentication/content integrity services.
Picking the best solution is up to the developer and the person in charge of deployment, since they know the security requirements and features of the target application area 🧚 Still, it is RECOMMENDED that at least one of these techniques be used. 💖
Note that when integrity protection is applied, it is RECOMMENDED that it take place on both FEC source and repair packets. The point is to keep corrupted packets out of decoding, because those would often cause a decoding failure or a corrupted decoded source flow 😱
9.3. Attacks against the FEC Parameters
Attacks on these FEC parameters can stop the associated object from being decoded 😬 For example, modifying the finite field size of a Reed-Solomon FEC scheme (when applicable) will make a receiver consider a different FEC code.
So, it is RECOMMENDED that security measures be taken to guarantee the integrity of the FEC Framework Configuration Information. The FEC Framework doesn't define how the FEC Framework Configuration Information gets from sender to receiver, so we can't give further recommendations on guaranteeing its integrity. However, any complete CDP specification MUST give recommendations on how to achieve it. When the FEC Framework Configuration Information is sent out-of-band, e.g., in a session description, it SHOULD be protected, for instance by digitally signing it 🔏
Attacks are also possible against some FEC parameters included in the Explicit Source FEC Payload ID and Repair FEC Payload ID. For example, modifying the Source Block Number of a FEC source or repair packet will make a receiver assign that packet to a wrong block.
So, it is RECOMMENDED that security measures be taken to guarantee the integrity of the Explicit Source FEC Payload ID and Repair FEC Payload ID. For that purpose, one of the packet-level source authentication/content integrity techniques described in Section 9.2.2 can be used 🎀
9.4. When Several Source Flows Are to Be Protected Together
When several source flows with different security requirements need to be FEC protected jointly, within a single FEC Framework instance, then each flow MAY be processed appropriately before the protection. For example, source flows that require access control MAY be encrypted before they are FEC protected 🧁
There are also situations where the only insecure domain is the one over which the FEC Framework operates. In that case, this situation MAY be addressed at the network layer, using IPsec/ESP (see Section 9.5), even if only a subset of the source flows has strict security requirements.
Since the use of the FEC Framework shouldn't add any extra threat, it is RECOMMENDED that the FEC Framework aggregate flow be in line with the maximum security requirements of the individual source flows. For example, if denial-of-service (DoS) protection is required, an integrity protection SHOULD be provided below the FEC Framework, using, for instance, IPsec/ESP 🛡️
Generally speaking, whenever feasible, it is RECOMMENDED that FEC protecting flows with totally different security requirements be avoided. Otherwise, significant processing overhead would be added to protect source flows that don't need it 💀
9.5. Baseline Secure FEC Framework Operation
The FEC Framework was defined to be independent from the application that generates source flows 🦋 Some applications might use purely unidirectional flows, while others might also use unicast feedback from the receivers. For example, that's the case when you're looking at RTP/RTCP-based source flows.
This section describes a baseline mode of secure FEC Framework operation based on the application of the IPsec protocol. It's one possible solution for solving or mitigating the security threats introduced by the use of the FEC Framework.
Two related documents are of interest. First, Section 5.1 of [RFC5775] defines a baseline secure Asynchronous Layered Coding (ALC) operation for sender-to-group transmissions, assuming a single sender and a source-specific multicast (SSM) or SSM-like operation. The proposed solution, based on IPsec/ESP, can be used to provide a baseline FEC Framework secure operation for the downstream source flow.
Second, Section 7.1 of [RFC5740] defines a baseline secure NACK-Oriented Reliable Multicast (NORM) operation, for sender-to-group transmissions as well as unicast feedback from receivers. Here, a single sender is also assumed. The proposed solution is also based on IPsec/ESP. However, the difference with respect to [RFC5775] is in the management of IPsec Security Associations (SAs) and corresponding Security Policy Database (SPD) entries, since NORM requires a second set of SAs and SPD entries to be defined to protect unicast feedback from receivers 🌈
Note that the IPsec/ESP requirement profiles outlined in [RFC5775] and [RFC5740] are commonly available on many potential hosts. They can form the basis of a secure mode of operation. Configuration and operation of IPsec typically require privileged user authorization. Automated key management implementations are typically configured with the privileges necessary to allow the needed system IPsec configuration.
10. Operations and Management Considerations
Operating and managing the FEC Framework and the associated FEC scheme(s) is super important in practice ⭐ The goals of this section are to discuss aspects and recommendations related to specific deployments and solutions.
In particular, this section discusses the questions of interoperability across vendors/use cases, and whether defining mandatory-to-implement (but not mandatory-to-use) solutions is beneficial 👑
10.1. What Are the Key Aspects to Consider? 💖
Okay bestie, there are a bunch of things to think about here, because they totally change how the FEC Framework and its FEC schemes get operated and managed 🧚
- A Single Small Generic Component within a Larger (and Often Legacy) Solution ✨: The FEC Framework is just one piece of a bigger setup. That setup includes one or more upper-layer applications that generate one or more ADU flows, plus an underlying protocol stack. The big design idea is that the FEC Framework should be able to work without making any assumptions about the upper-layer application(s) or the underlying protocol stack, even though there are special cases where assumptions do get made 🫶
- One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to-Many without Feedback Scenarios 🦋: The FEC Framework can show up in use cases that are totally different from each other. Some are one-way (like broadcast networks), with a one-to-one, one-to-many, or many-to-many transmission model, and the receivers can't send any feedback back to the senders. Others are bidirectional one-to-one, one-to-many, or many-to-many setups, where the receivers can send feedback to the senders 💅
- Non-FEC Framework Capable Receivers 🙈: In one-to-many and many-to-many use cases, the receivers might not all have the same abilities when it comes to the FEC Framework itself and the FEC schemes it supports. Some receivers can't decode the repair packets for a particular FEC scheme, and some other receivers don't support the FEC Framework at all. Not everyone is on the same page, bestie 💀
- Internet vs. Non-Internet Networks 🌸: The FEC Framework can be super useful in lots of use cases that run over a transport network that isn't the public Internet, like IPTV or Mobile TV. In those networks, the operational and management stuff can be handled with an open or proprietary solution that gets specified outside of the IETF.
- Congestion Control Considerations ⭐: Check out Section 8 for the whole discussion on whether congestion control is needed, and how it connects to the FEC Framework.
- Within End-Systems vs. within Middleboxes 🍓: The FEC Framework can run inside end-systems, really close to the upper-layer application, or inside dedicated middleboxes. The middlebox option is handy when you want to protect one or several flows while they cross a lossy channel between two or more remote sites 🌈
- Protecting a Single Flow vs. Several Flows Globally 👑: The FEC Framework can protect a single flow, or it can protect several flows globally. Main character energy either way ✨
10.2. Operational and Management Recommendations 🎀
Okay so, from everything we just covered in Section 10.1, it's super clear that the CDPs and FEC schemes that work with the FEC Framework are wildly different in what they can do, where they get used, and how they get deployed. One common operation and management method or protocol that works well for all of them would be way too complicated to define 😭 So as a design choice, the FEC Framework doesn't force any particular technology or protocol for transporting FEC data, managing the hosts, signaling the configuration information, or encoding the configuration information. That flexibility is literally one of the main goals of the FEC Framework 💜 That said, this section does give some RECOMMENDED guidelines 🔥
- A Single Small Generic Component within a Larger (and Often Legacy) Solution 🌷: It's expected that the FEC Framework will often be used to protect one or several RTP streams. So implementations SHOULD make feedback information accessible via RTCP, so users can take advantage of the tools that use (or are used by) RTCP to operate and manage the FEC Framework instance along with the associated FEC schemes 🧁
- One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to-Many without Feedback Scenarios 🫧: With one-way use cases, the FEC Framework sender has no way to gather feedback from the receivers. With bidirectional use cases, the sender can collect detailed feedback in a one-to-one scenario, or at least occasional feedback in a multicast, one-to-many scenario. All of these applications have naturally different operational and management aspects, and they have different requirements or features (if any) for collecting feedback, processing it, and acting on it. The data structures for carrying the feedback vary too 🌈
Implementers SHOULD make feedback available using either an in-band or out-of-band asynchronous reporting mechanism. When an out-of-band solution is preferred, a standardized reporting mechanism, such as Syslog [RFC5424] or Simple Network Management Protocol (SNMP) notifications [RFC3411], is RECOMMENDED. When required, a mapping mechanism between the Syslog and SNMP reporting mechanisms could be used, as described in [RFC5675] and [RFC5676] 🎀
- Non-FEC Framework Capable Receivers 🦢: Section 5.3 gives recommendations on how to keep things backward compatible when receivers can't support the FEC scheme being used or the FEC Framework itself. The short version: using Explicit Source FEC Payload ID is banned. On top of that, a non-FEC Framework capable receiver MUST also have a way to avoid receiving the repair packets it can't decode in the first place, or a way to identify and discard them properly once they arrive. This SHOULD be achieved by sending repair packets on a different transport-layer flow. If source and repair packets are both going on the same transport-layer flow in the RTP transport case, this SHOULD be achieved by using an RTP framing for FEC repair packets with a different payload type. It's the sender's job to pick the right mechanism when it's needed 💅
- Within End-Systems vs. within Middleboxes 🌟: When the FEC Framework is used within middleboxes, it is RECOMMENDED that the paths between the hosts where the sending applications run and the middlebox doing the FEC encoding be as reliable as possible, meaning they're not prone to packet loss, packet reordering, or varying delays in delivering packets 🧚
Similarly, when the FEC Framework is used within middleboxes, it is RECOMMENDED that the paths between the middleboxes doing the FEC decoding and the end-systems where the receiving applications run be as reliable as possible 💖
- Management of Communication Issues before Reaching the Sending FECFRAME Instance 🙃: Let's say the FEC Framework is used within middleboxes. On the sending side, the general reliability recommendation for the path between the sending applications and the middlebox matters a lot, but it may not guarantee that a loss, reordering, or long delivery delay can't happen, for whatever reason. If one of these rare events does happen, it SHOULD NOT compromise the operation of the FECFRAME instances, on either the sending side or the receiving side. This is especially important with FEC schemes that don't modify the ADU for backward-compatibility purposes (that is, they don't use any Explicit Source FEC Payload ID) and instead rely on, for instance, the RTP sequence number field to identify FEC source packets within their source block. In that case, packet loss or reordering leads to a gap in the RTP sequence number space that the FECFRAME instance sees. Similarly, varying delay in delivering packets over this path can cause significant timing issues 😵💫
With FEC schemes that indicate, in the Repair FEC Payload ID for each source block, the base RTP sequence number and the number of consecutive RTP packets that belong to that source block, a missing ADU or an ADU delivered out of order could make the FECFRAME sender switch to a new source block. However, some FEC schemes and/or receivers might not handle varying source block sizes well. In that case, one option is to duplicate the last ADU received before the loss, or to insert zeroed ADU(s), depending on the nature of the ADU flow. Implementers SHOULD consider the consequences of these alternative approaches, based on their use cases 🧠
- Protecting a Single Flow vs. Several Flows Globally 👯: In the general case, the various ADU flows that get protected globally can have different features, and in particular different real-time requirements (for real-time flows). The process of globally protecting these flows SHOULD take into account the requirements of each individual flow. Specifically, it would be counterproductive to add repair traffic to a real-time flow where the FEC decoding delay at a receiver makes the decoded ADUs useless for that flow, because they don't meet the associated real-time constraints 🙅♀️ In practical terms, that means the source block creation process at the sending FEC Framework instance SHOULD consider the most stringent real-time requirements of the ADU flows being protected globally 🔥
- ADU Flow Bundle Definition and Flow Delivery 🔒: By design, a repair flow might let a receiver recover the ADU flow(s) it protects, even if none of the associated FEC source packets are received. So when defining the bundle of ADU flows that get protected globally, and when deciding which receiver gets which flow, the sender SHOULD make sure that the ADU flow(s) and repair flow(s) of that bundle are only received by receivers that are authorized to receive all the ADU flows in that bundle. See Section 9.4 for more recommendations for situations where strict access control for ADU flows is needed 🛡️
Also, when multiple ADU flows are protected globally, a receiver that wants to benefit from FECFRAME loss protection SHOULD receive all the ADU flows of the bundle. Otherwise, the missing FEC source packets would be treated as lost, which could seriously reduce the efficiency of the FEC scheme 💀
11. IANA Considerations ✨
FEC schemes for use with this framework are identified in protocols using FEC Encoding IDs, and those values are subject to IANA registration. For this purpose, this document creates a new registry called "FEC Framework (FECFRAME) FEC Encoding IDs" 🌸
The values that can be assigned in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry are numeric indexes in the range (0, 255). The values 0 and 255 are reserved. Assignment requests are granted on an IETF Review basis, as defined in [RFC5226]. Section 5.6 defines explicit requirements that documents defining new FEC Encoding IDs should meet 🎀
12. Acknowledgments ✨
okay so this doc is lowkey built on [FEC-SF] 💖, and the co-authors of that one deserve a whole parade: Mike Luby, Magnus Westerlund, and Stephan Wenger 👑. that doc was itself based on the FEC Streaming Protocol from 3GPP in [MBMSTS] 🧚, so the people in 3GPP SA Working Group 4 get major credit too 🫶. and the FECFRAME Working Group deserves a huge thank you for all their comments and reviews 🌸. literally couldn't have done it without you all 😭💅
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.13.2. Informative References
[FEC-SF] Watson, M., Luby, M., Westerlund, M., and S. Wenger,
"Forward Error Correction (FEC) Streaming Framework", Work
in Progress, July 2005.
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346, March 2009,
<http://ftp.3gpp.org/specs/html-info/26346.htm>.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383,
February 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network
Management Protocol (SNMP) Notifications to SYSLOG
Messages", RFC 5675, October 2009.
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar,
"Definitions of Managed Objects for Mapping SYSLOG
Messages to Simple Network Management Protocol (SNMP)
Notifications", RFC 5676, October 2009.
[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
Report Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", RFC 5725, February 2010.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, November 2009.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775,
April 2010.
[RFC6364] Begen, A., "Session Description Protocol Elements for FEC
Framework", RFC 6364, October 2011.Authors' Addresses
Mark Watson
Netflix, Inc.
100 Winchester Circle
Los Gatos, CA 95032
USA
EMail: watsonm@netflix.com
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com
Vincent Roca
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/that's a wrap on the whole doc, bestie 🦋💜
📦 where this page comes from
- ietf: rfc6363 2011-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms