RFC 8680

Forward Error Correction (FEC) Framework Extension to Sliding Window Codes

📅 published January 2020, from ietf

RFC 8680: Forward Error Correction (FEC) Framework Extension to Sliding Window Codes 🎀

Okay bestie, the vibe check first 💅. This is RFC 8680, published in January 2020 by the IETF. The authors are V. Roca (from INRIA) and A. Begen (from Networked Media). It's a Standards Track doc, which means it's an official Internet Standard 👑. Its ISSN is 2070-1721. It updates RFC 6363 and doesn't list anything it obsoletes. That's the whole CV 😭✨

Abstract

So, [RFC6363] lays out a framework for using Forward Error Correction (FEC) codes to protect against packet loss 🛡️. It works for arbitrary packet flows over unreliable transport, and it's mainly built for real-time or streaming media 📺. The catch is that FECFRAME under [RFC6363] only works with block FEC codes. This document updates RFC 6363 so it also supports FEC codes based on a sliding encoding window, alongside the block codes, in a backward-compatible way 🤝. When you're doing multicast or broadcast real-time delivery, sliding window codes are so good: they hold up way better in harsh environments, send less repair traffic, and add less FEC-related latency 🔥💜.

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 got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚.

For the latest status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8680 🔗.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved 💅.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please actually read these, bestie, because they explain 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 with no warranty, as described in the Simplified BSD License ⚠️.

Table of Contents

   1.  Introduction
   2.  Terminology
     2.1.  Definitions and Abbreviations
     2.2.  Requirements Language
   3.  Summary of Architecture Overview
   4.  Procedural Overview
     4.1.  General
     4.2.  Sender Operation with Sliding Window FEC Codes
     4.3.  Receiver Operation with Sliding Window FEC Codes
   5.  Protocol Specification
     5.1.  General
     5.2.  FEC Framework Configuration Information
     5.3.  FEC Scheme Requirements
   6.  Feedback
   7.  Transport Protocols
   8.  Congestion Control
   9.  Security Considerations
   10. Operations and Management Considerations
   11. IANA Considerations
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Appendix A.  About Sliding Encoding Window Management
           (Informational)
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

Lots of apps need to push a continuous stream of packetized data from a source (the sender) to one or more destinations (the receivers) 🌊. The problem is that the networks in between don't promise to deliver every packet 😬. This document is all about packet loss, and we're assuming transmitted packets either get lost (say, a congested router, a poor signal-to-noise ratio on a wireless network, or bit errors that go past what the physical-layer error-correcting code can fix) or arrive at the transport protocol without any corruption (any bit errors were already fixed by the physical-layer error-correcting code, so the upper layers never see them) 🫠.

For these use cases, Forward Error Correction (FEC) applied at the transport or application layer is a super efficient way to make packet transmission more robust against packet losses (or "erasures") 🦋. You don't have to go through retransmissions, which add delay that clashes with real-time constraints ⏱️. The FEC Building Block defined in [RFC5052] gives you a framework for defining Content Delivery Protocols (CDPs) that use separately defined FEC schemes 🧩. Any CDP that follows the requirements of the FEC Building Block can easily be paired with any FEC scheme that also follows them 💕.

Next up, FECFRAME [RFC6363] is a framework for defining CDPs that add FEC protection to arbitrary packet flows over an unreliable datagram service transport, such as UDP 🚀. It's mainly for real-time or streaming media apps using broadcast, multicast, or on-demand delivery 📡. Part of FECFRAME is already in the 3GPP Evolved Multimedia Broadcast/Multicast Service (eMBMS) standard [MBMSTS] 📱.

BUT, and this is the important part, [RFC6363] only considers block FEC schemes that follow the FEC Building Block [RFC5052] (for example [RFC6681], [RFC6816], or [RFC6865]) 🙈. Block codes need the input flow(s) to be chopped into a sequence of blocks. Then FEC encoding (at a sender or an encoding middlebox) and decoding (at a receiver or a decoding middlebox) both happen on a per-block basis 🧱. For example, if the current block covers source symbols 100 to 119 of an input flow (so a block of size 20 symbols), encoding and decoding happen on that block independently of the other blocks 🔢. This choice has huge effects on FEC encoding and decoding delays 😵‍💫. The data packets of continuous media flows can be passed to the transport layer right away, no delay at all 🏃‍♀️. But the block creation time, which depends on how many source symbols are in the block, hits both the FEC encoding delay (because encoding needs every source symbol to be known) and the packet loss recovery delay at a receiver (because no repair symbol for the current block can be generated and received before that time) ⏳. So picking a block size is a real balancing act 🎭. On one side, the maximum FEC decoding latency at the receivers has to match the strictest real-time requirement of the protected flow(s), which is a reason to shrink the block size 📉. On the other side, you want solid robustness against long loss bursts, and that gets better as the block size grows, which is a reason to make it bigger 📈.

This document updates [RFC6363] so it can also support FEC codes based on a sliding encoding window (a.k.a. convolutional codes) [RFC8406] 🌀. This encoding window, either fixed or variable in size, slides over the set of source symbols 🪟. FEC encoding gets launched whenever it's needed, using whatever source symbols are in the sliding encoding window at that moment 🎯. This approach seriously cuts FEC-related latency, because repair symbols can be generated and handed to the transport layer on the fly at any time, and receivers can regularly get them to quickly recover from packet losses 🌈. So sliding window FEC codes are hugely beneficial for real-time flows, which are one of FECFRAME's main targets 💖. [RFC8681] gives an example of this kind of FEC scheme for FECFRAME, built on the simple sliding window Random Linear Code (RLC) 🧠.

This document is fully backward compatible with [RFC6363] 🫶. Here's the tea:

  • This FECFRAME update doesn't prevent or compromise, in any way, the support of block FEC codes 🙌. Both types of codes can coexist nicely, just like different block FEC schemes can coexist 🤝.
  • Each sliding window FEC scheme is tied to a specific FEC Encoding ID that's subject to IANA registration, just like block FEC schemes 📝.
  • Any receiver (for instance, a legacy receiver that only supports block FEC schemes) can easily figure out which FEC scheme is used in a FECFRAME session 🕵️‍♀️. The reason is that the FEC Encoding ID identifying the FEC scheme is carried in FEC Framework Configuration Information (see Section 5.5 of [RFC6363]) 💁‍♀️. For example, when the Session Description Protocol (SDP) carries the FEC Framework Configuration Information, the FEC Encoding ID can be communicated in the encoding-id= parameter of a fec-repair-flow attribute [RFC6364] 🎀. This is the basic approach a FECFRAME receiver uses to decide whether or not it supports the FEC scheme in a given FECFRAME session ✅.

This document builds on [RFC6363] and reuses its structure 🏗️. It adds new sections specific to sliding window FEC codes wherever they're needed 🧁. The only exception is Section 3, which gives a quick summary of FECFRAME so that readers new to the concepts and terminology can follow along 📖.

2. Terminology 🦋

2.1. Definitions and Abbreviations 💖

okay so bestie, this part is basically the glossary for the whole FEC party 🎀✨ the list below is copied from [RFC6363], and the only things I added are the Block FEC Code, Sliding Window FEC Code, and Encoding/Decoding Window definitions. I tagged those with "ADDED" so you can spot them instantly 🦋

Application Data Unit (ADU): The unit of source data handed to the transport layer as a payload. For example, it can be a payload holding the RTP packetization of a compressed video frame 🎬

ADU Flow: A sequence of ADUs tied to a 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 that sets up and manages 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 use FEC schemes to get FEC capabilities ✨

FEC Code: An algorithm that encodes data so the encoded data flow survives data loss. In general FEC codes can also make a flow resilient to corruption, but this document doesn't cover that 🛡️

Block FEC Code: (ADDED) A FEC code that works on blocks. The input flow MUST be split into a sequence of blocks, and encoding and decoding happen independently for each block 🧱

Sliding Window FEC Code: (ADDED) A FEC code that can generate repair symbols on the fly, at any time, from the source symbols sitting in the sliding encoding window at that moment. These are also called convolutional codes 🌀

FEC Framework: A protocol framework for defining Content Delivery Protocols that use FEC, like the framework defined in this document 🍓

FEC Framework Configuration Information: Information that controls how the FEC Framework operates ⚙️

FEC Payload ID: Information that identifies the contents of a packet and gives its position with respect to the FEC scheme 📍

FEC Repair Packet: On the sender side, a payload handed to the transport protocol (on the receiver side, a payload received from it). It contains one or more repair symbols, a Repair FEC Payload ID, and possibly an RTP header 🔧

FEC Scheme: A specification that defines the extra protocol details needed to use a particular FEC code with the FEC Framework 📜

FEC Source Packet: On the sender side, a payload handed to the transport protocol (on the receiver side, a payload received from it). It contains an ADU and an optional Explicit Source FEC Payload ID 🎁

Repair Flow: The packet flow carrying FEC data 💜

Repair FEC Payload ID: A FEC Payload ID used specifically with repair packets 🩷

Source Flow: The packet flow that FEC protection is applied to. A source flow consists of ADUs 🌈

Source FEC Payload ID: A FEC Payload ID used specifically with 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. It needs to provide an unreliable datagram service, the way UDP does ([RFC6363], Section 7) 🚀

Encoding Window: (ADDED) The set of source symbols available at the sender/coding node that a Sliding Window FEC code uses to generate a repair symbol 🪟

Decoding Window: (ADDED) The set of received or decoded source and repair symbols available at a receiver that a Sliding Window FEC code uses to decode lost source symbols 🔓

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 encoding 📈

Encoding Symbol: A unit of data generated by the encoding process. With systematic codes, the source symbols are part of the encoding symbols 🧩

Packet Erasure Channel: A communication path where packets are either lost (for example, because a congested router dropped them, or because the number of transmission errors exceeded what the physical-layer code can correct) or received. When a packet is received, it is assumed not to be corrupted, meaning any bit errors are fixed by the physical-layer code and hidden from the upper layers 🌊

Repair Symbol: An encoding symbol that is not a source symbol 🫶

Source Block: A group of ADUs that are protected together as a single block. This notion is restricted to Block FEC codes 🧁

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 👑

2.2. Requirements Language 🎀

okay so this bit is the official "how to read the capital letters" section 🤓 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅 so if you see them in ALL CAPS, they're the real deal, and lowercase versions are just regular words 🌸

3. Summary of Architecture Overview ✨

okay so bestie, Section 3 of [RFC6363] is the architecture part, and it applies to this FECFRAME extension exactly as written, so we're not repeating it here 💅 BUT 🫶 this section gives you a quick summary so you're not lost if you're new to all this. let's go!

            +----------------------+
            |     Application      |
            +----------------------+
                       |
                       | (1) Application Data Units (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 Protocol  |
            +----------------------+

                Figure 1: FECFRAME Architecture at a Sender

The FECFRAME architecture is shown in Figure 1 for a block FEC scheme, from the sender's point of view 👀 An application is generating an ADU flow (other flows from other apps can totally coexist in there too 🌈). These ADUs come in variable sizes, and they must somehow get mapped to source symbols of a fixed size. This fixed size is a requirement of all FEC schemes, because it comes from how the math operations work on the symbols' content 🧮 That's the job of an ADU-to-symbols mapping process, and it's FEC scheme specific (more on that below ⬇️).

Once the source block is built, the FEC scheme's constraints (like the max source block size) and the application's flow constraints (like real-time stuff) both get taken into account 🎀. Then the source symbols get handed to the FEC scheme, which makes an appropriate number of repair symbols. FEC Source Packets (holding ADUs) and FEC Repair Packets (each holding one or more repair symbols) get generated and sent over an appropriate transport protocol. To be precise, Section 7 of [RFC6363] requires a transport protocol that gives an unreliable datagram service, like UDP 🦋 Also, FEC Source Packets can be passed down to the transport layer as soon as they're ready, without waiting for FEC encoding to happen. When that's the case, FECFRAME has to keep a copy of the associated source symbols around for future FEC encoding ✨

On the receiver side (not pictured, sorry bestie 🙈), FECFRAME works in a similar way, taking in the incoming FEC Source and Repair Packets. If some FEC Source Packets get lost, FEC decoding of the block might recover all of the missing source symbols (if decoding works), or only a subset of them, which could even be empty (if decoding fails) 😭 After source-symbol-to-ADU mapping, the recovered lost ADUs get assigned to their own flow (see below). ADUs are then returned to the application(s) in one of two ways, depending on what the application needs 💅. Either they come back in their original transmission order (in which case every ADU received after a lost one gets delayed until FEC decoding has happened), or they don't (in which case each ADU is returned the moment it's received or recovered) ⏩

FECFRAME has two subtle mechanisms, and the details of both depend on the FEC scheme 🧠

  • ADUs-to-source-symbols mapping: to handle variable size ADUs, FECFRAME and FEC schemes can use small, fixed-size symbols and create a mapping between ADUs and symbols. The details of the mapping depend on the FEC scheme, and they must be defined in the associated document. For example, with certain FEC schemes, this mechanism prepends a length field (plus a flow identifier, see below) to each ADU, and then pads the result up to a multiple of the symbol size. A small ADU might map to a single source symbol, while a big one might map to multiple symbols 📦
  • Assignment of decoded ADUs to flows in multi-flow configurations: when multiple flows are multiplexed over the same FECFRAME instance, the tricky part is assigning a decoded ADU to the right flow 🚦 (UDP port numbers and IP addresses, which are traditionally used to map incoming ADUs to flows, are not recovered during FEC decoding, so no cheating there 🙅). The details of this mapping depend on the FEC scheme too, and they must be defined in the associated document. For example, with certain FEC schemes, each ADU gets a flow identifier (1 byte) prepended at the FECFRAME sending instance, during the ADU-to-source-symbols mapping. The flow identifiers are also shared across all FECFRAME instances as part of the FEC Framework Configuration Information. The ADU Information (ADUI), which includes the flow identifier, length, application payload, and padding, then gets FEC protected 🛡️ So a decoded ADUI has enough info to assign the ADU to the right flow. Also, a FEC scheme may be restricted to a single flow over a FECFRAME instance, and in that case this mechanism would be pointless 🤷‍♀️

A few things are NOT covered by FECFRAME, babe 🙃

  • Section 8 of [RFC6363] doesn't detail any congestion control mechanisms, and it only gives high-level normative requirements 🚧
  • Feedback from receiver(s) is considered out of scope, even though such a mechanism might exist within the application (for example, through RTP Control Protocol (RTCP) messages) 📨
  • Flow adaptation at a FECFRAME sender (like how to set the FEC code rate based on transmission conditions) isn't detailed, but it needs to comply with the congestion control normative requirements (see above) 🌸

4. Procedural Overview 🎀

4.1. General 💖

The general considerations of Section 4.1 of [RFC6363] that are specific to block FEC codes aren't repeated here, so we're skipping them 🙌

With a Sliding Window FEC code, the FEC Source Packet MUST contain information that identifies the position the ADU occupies within the source flow, in terms specific to the FEC scheme. This information is called 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 repair payloads they carry and the original source symbols that were used during encoding. This information is called the Repair FEC Payload ID, and the FEC scheme is responsible for defining and interpreting it too 🧩

The sender operation (Section 4.2 of [RFC6363]) and receiver operation (Section 4.3 of [RFC6363]) are both specific to block FEC codes, so they're omitted below. The following two sections walk through similar operations for Sliding Window FEC codes 🦋

4.2. Sender Operation with Sliding Window FEC Codes 💖

okay so with a Sliding Window FEC scheme, there's a possible way to generate compliant source and repair flows 🦋 Figure 2 shows the generic case (non-RTP repair flows) and Figure 3 shows the RTP repair flows case, and the steps go like this:

  1. The application gives us a new ADU ✨
  2. The FEC Framework passes that ADU along to the FEC scheme.
  3. The FEC scheme updates the sliding encoding window. The ADU-to-source-symbol mapping and all the encoding window management details are the FEC scheme's responsibility, and they MUST be detailed there. Appendix A has non-normative hints about what FEC scheme designers need to think about 🧠
  4. The FEC scheme decides the Source FEC Payload ID of the source packet. If the FEC scheme needs it, the Source FEC Payload ID gets encoded into the Explicit Source FEC Payload ID field and handed back to the FEC Framework.
  5. The FEC Framework builds the FEC Source Packet following Figure 6 in [RFC6363], using the Explicit Source FEC Payload ID from the FEC scheme if that applies.
  6. The FEC Source Packet goes out using normal transport-layer procedures. It uses the same ADU flow identification info the original source packet would have used if the FEC Framework weren't there. So the source and destination addresses and UDP port numbers on the IP datagram carrying the source packet stay the same whether or not the FEC Framework is applied 🙈
  7. When the FEC Framework needs to send one or several FEC Repair Packets (for example, to hit the target code rate), it asks the FEC scheme to make one or several repair packet payloads from the current sliding encoding window, along with their Repair FEC Payload ID.
  8. The FEC scheme hands the Repair FEC Payload IDs and repair packet payloads back to the FEC Framework.
  9. The FEC Framework builds the FEC Repair Packets following Figure 7 in [RFC6363], using the FEC Payload IDs and repair packet payloads from the FEC scheme.
  10. The FEC Repair Packets get sent using normal transport-layer procedures. The port(s) and multicast group(s) for FEC Repair Packets are defined in the FEC Framework Configuration Information 🎀
+----------------------+
|     Application      |
+----------------------+
           |
           | (1) New Application Data Unit (ADU)
           v
+---------------------+                           +----------------+
|    FEC Framework    |                           |   FEC Scheme   |
|                     |-------------------------->|                |
|                     | (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  |
+----------------------+

      Figure 2: Sender Operation with Sliding Window FEC Codes
+----------------------+
|     Application      |
+----------------------+
           |
           | (1) New Application Data Unit (ADU)
           v
+---------------------+                           +----------------+
|    FEC Framework    |                           |   FEC Scheme   |
|                     |-------------------------->|                |
|                     | (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  |
+----------------------+

   Figure 3: Sender Operation with Sliding Window FEC Codes and RTP
                             Repair Flows

4.3. Receiver Operation with Sliding Window FEC Codes ✨

With a Sliding Window FEC scheme, the receiver steps are shown in Figure 4 for the generic case (non-RTP repair flows) and in Figure 5 for the RTP repair flows case. The only differences from block FEC codes are steps (4) and (5), so this section doesn't repeat the other steps of Section 4.3 of [RFC6363] ("Receiver Operation"). The new steps (4) and (5) are:

  1. The FEC scheme uses the received FEC Payload IDs (and derived FEC Source Payload IDs when the Explicit Source FEC Payload ID field isn't used) to slot source and repair packets into the decoding window the right way. If at least one source packet is missing and at least one repair packet has arrived, FEC decoding is attempted to recover the missing source payloads. The FEC scheme works out whether source packets were lost and whether enough repair packets came in to decode any or all of the missing source payloads.
  2. The FEC scheme returns the received and decoded ADUs to the FEC Framework, along with indications of any ADUs that were missing and couldn't be decoded 💅
+----------------------+
|     Application      |
+----------------------+
           ^
           |(6) ADUs
           |
+----------------------+                           +----------------+
|    FEC Framework     |                           |   FEC Scheme   |
|                      |<--------------------------|                |
|(2)Extract FEC Payload|(5) ADUs                   |(4) FEC Decoding|
|   IDs and pass IDs & |-------------------------->|                |
|   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  |
+----------------------+

      Figure 4: Receiver Operation with Sliding Window FEC Codes
+----------------------+
|     Application      |
+----------------------+
           ^
           |(6) ADUs
           |
+----------------------+                           +----------------+
|    FEC Framework     |                           |   FEC Scheme   |
|                      |<--------------------------|                |
|(2)Extract FEC Payload|(5) ADUs                   |(4) FEC Decoding|
|   IDs and pass IDs & |-------------------------->|                |
|   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  |
+----------------------+

    Figure 5: Receiver Operation with Sliding Window FEC Codes and
                           RTP Repair Flows

5. Protocol Specification 🎀

5.1. General 🌸

This section covers the protocol elements of the FEC Framework that are specific to Sliding Window FEC schemes. The global formats of source data packets (that's [RFC6363], Figure 6) and repair data packets ([RFC6363], Figures 7 and 8) stay the same with Sliding Window FEC codes. They aren't repeated here 💜

5.2. FEC Framework Configuration Information 🧚

The FEC Framework Configuration Information considerations of Section 5.5 of [RFC6363] apply equally to this FECFRAME extension and aren't repeated here.

5.3. FEC Scheme Requirements 👑

The FEC scheme requirements of Section 5.6 of [RFC6363] mostly apply to this FECFRAME extension and aren't repeated here. The exception is the "full specification of the FEC code", item (4), which is specific to block FEC codes. For a Sliding Window FEC scheme, the following item (4-bis) applies:

4-bis. A full specification of the Sliding Window FEC code.

This specification MUST precisely define the valid FEC-Scheme-Specific Information values, the valid FEC Payload ID values, and the valid packet payload sizes (where "packet payload" means the space within a packet dedicated to carrying encoding symbols).

Also, 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 (that is, a set of source symbols), the specification MUST uniquely define the value of the encoding symbol (or symbols) to be included in the repair packet payload with the given Repair FEC Payload ID value 🔥

On top of that, the FEC scheme tied 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. Appendix A has non-normative hints about what FEC scheme designers need to consider.
  • MUST define the management of the decoding window. This usually means managing a system of linear equations (for a linear FEC code).

6. Feedback 🦋

The discussion in Section 6 of [RFC6363] applies equally to this FECFRAME extension and isn't repeated here.

7. Transport Protocols 🌈

The discussion in Section 7 of [RFC6363] applies equally to this FECFRAME extension and isn't repeated here.

8. Congestion Control ⭐

The discussion in Section 8 of [RFC6363] applies equally to this FECFRAME extension and isn't repeated here.

9. Security Considerations 💀

This FECFRAME extension doesn't add any new security considerations. All the considerations of Section 9 of [RFC6363] apply to this document as well. However, for completeness, the following goal can be added to the list in Section 9.1 of [RFC6363] ("Problem Statement"):

  • Attacks can try to corrupt source flows in order to modify the receiver application's behavior (as opposed to just denying service). 😭

10. Operations and Management Considerations 💅

okay so this FECFRAME extension doesn't add any new Operations and Management Considerations 🫶 literally nothing new! BUT bestie, all the considerations in Section 10 of [RFC6363] still apply to this doc too, so go read those ✨

11. IANA Considerations 🎀

This document has no IANA actions 🌸

A FEC scheme for use with this FEC Framework is identified by its FEC Encoding ID 💜 That ID gets registered in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of Section 11 of [RFC6363] apply here too, and they aren't repeated in this doc, so no copy-paste drama 💅

12. References 📚

12.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
           Correction (FEC) Framework", RFC 6363,
           DOI 10.17487/RFC6363, October 2011,
           <https://www.rfc-editor.org/info/rfc6363>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

12.2. Informative References

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

[RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
           Correction (FEC) Building Block", RFC 5052,
           DOI 10.17487/RFC5052, August 2007,
           <https://www.rfc-editor.org/info/rfc5052>.

[RFC6364]  Begen, A., "Session Description Protocol Elements for the
           Forward Error Correction (FEC) Framework", RFC 6364,
           DOI 10.17487/RFC6364, October 2011,
           <https://www.rfc-editor.org/info/rfc6364>.

[RFC6681]  Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward
           Error Correction (FEC) Schemes for FECFRAME", RFC 6681,
           DOI 10.17487/RFC6681, August 2012,
           <https://www.rfc-editor.org/info/rfc6681>.

[RFC6816]  Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density
           Parity Check (LDPC) Staircase Forward Error Correction
           (FEC) Scheme for FECFRAME", RFC 6816,
           DOI 10.17487/RFC6816, December 2012,
           <https://www.rfc-editor.org/info/rfc6816>.

[RFC6865]  Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K.
           Matsuzono, "Simple Reed-Solomon Forward Error Correction
           (FEC) Scheme for FECFRAME", RFC 6865,
           DOI 10.17487/RFC6865, February 2013,
           <https://www.rfc-editor.org/info/rfc6865>.

[RFC8406]  Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
           F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J.,
           Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
           S. Sivakumar, "Taxonomy of Coding Techniques for Efficient
           Network Communications", RFC 8406, DOI 10.17487/RFC8406,
           June 2018, <https://www.rfc-editor.org/info/rfc8406>.

[RFC8681]  Roca, V. and B. Teibi, "Sliding Window Random Linear Code
           (RLC) Forward Erasure Correction (FEC) Schemes for
           FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020,
           <https://www.rfc-editor.org/info/rfc8681>.

Appendix A. About Sliding Encoding Window Management (Informational) 🦋

okay so the FEC Framework doesn't specify how the sliding encoding window gets managed 🙈 that's the FEC scheme's job! this annex just drops a few informational hints for you, so don't treat them as the whole story 💜

Source symbols get added to the sliding encoding window every time a new ADU is available at the sender, after the ADU-to-source-symbol mapping specific to the FEC scheme has been done ✨

Source symbols get removed from the window too. For instance:

  • After a certain delay, when an "old" ADU of a real-time flow times out. So the source symbol retention delay in the sliding encoding window should be initialized according to the real-time features of the incoming flow(s), when that applies 🕰️
  • Once the sliding encoding window has hit its maximum size (there's usually an upper limit to it). Then the oldest symbol gets removed each time a new source symbol is added 🍓

A few things can impact how this window gets managed:

  • At the source flows level: real-time constraints can limit the total time source symbols can stay in the encoding window ⏳
  • At the FEC code level: theoretical or practical limits (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, bestie 🫶 For instance, an encoding window made of a nonsequential set of source symbols needs appropriate signaling to tell a receiver what the window is made of, and that transmission overhead can limit the maximum encoding window size. On the flip side, an encoding window that's always a sequential set of source symbols makes signaling easier: giving the identity of the first source symbol plus its number is enough, which creates a fixed and relatively small transmission overhead 🌈

Acknowledgments 🫶

The authors would like to thank Christer Holmberg, David Black, Gorry Fairhurst, Emmanuel Lochin, Spencer Dawkins, Ben Campbell, Benjamin Kaduk, Eric Rescorla, Adam Roach, and Greg Skinner for their valuable feedback on this document 💖 This document is an extension of [RFC6363], so the authors would also like to thank Mark Watson, the main author of that RFC 👑

Authors' Addresses 🦋

Vincent Roca
INRIA
Univ. Grenoble Alpes
France

Email: vincent.roca@inria.fr


Ali Begen
Networked Media
Konya/
Turkey

Email: ali.begen@networked.media
📦 where this page comes from