RFC 6681
Raptor Forward Error Correction (FEC) Schemes for FECFRAME
RFC 6681: Raptor Forward Error Correction (FEC) Schemes for FECFRAME 🎀
- Series: Internet Engineering Task Force (IETF) 🌸
- Authors: M. Watson (Netflix), T. Stockhammer (Nomor Research), M. Luby (Qualcomm Incorporated) 💅
- Category: Standards Track ⭐
- ISSN: 2070-1721
- Date: August 2012 🦋
- Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates 🫶
Abstract 💖
okay so this doc defines Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes, and shows how to use them to reliably deliver media streams inside the FEC Framework 🧚 these are systematic codes, which means a bunch of repair symbols get made from a set of source symbols, then sent in one or more repair flows alongside the source symbols that go out to the receiver(s) in a source flow ✨ they give you close to optimal protection against arbitrary packet losses without eating up a ton of computing power 🔥 six FEC Schemes are defined: two for arbitrary packet flows, two that are optimized for small source blocks, and two for protecting a single flow that already has a sequence number 👑 repair data can go over any datagram transport (like UDP) or over RTP 🌈
Status of This Memo ✨
this is an Internet Standards Track document 💅
it's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶 if you want more on Internet Standards, check out Section 2 of RFC 5741 📚
info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6681 🔗
Copyright Notice 🧚
Copyright (c) 2012 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain 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 this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, 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, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents 📚
1. Introduction ....................................................4
2. Document Outline ................................................5
3. Requirements Notation ...........................................5
4. Definitions and Abbreviations ...................................5
4.1. Definitions ................................................6
4.2. Abbreviations ..............................................6
5. General Procedures for Raptor FEC Schemes .......................6
6. Raptor FEC Schemes for Arbitrary Packet Flows ...................8
6.1. Introduction ...............................................8
6.2. Formats and Codes ..........................................8
6.2.1. FEC Framework Configuration Information .............8
6.2.2. Source FEC Payload ID ...............................9
6.2.3. Repair FEC Payload ID ..............................10
6.3. Procedures ................................................11
6.3.1. Source Symbol Construction .........................11
6.3.2. Repair Packet Construction .........................12
6.4. FEC Code Specification ....................................12
7. Optimized Raptor FEC Scheme for Arbitrary Packet Flows .........12
7.1. Introduction ..............................................12
7.2. Formats and Codes .........................................13
7.2.1. FEC Framework Configuration Information ............13
7.2.2. Source FEC Payload ID ..............................13
7.2.3. Repair FEC Payload ID ..............................13
7.3. Procedures ................................................13
7.3.1. Source Symbol Construction .........................13
7.3.2. Repair Packet Construction .........................14
7.4. FEC Code Specification ....................................14
8. Raptor FEC Scheme for a Single Sequenced Flow ..................15
8.1. Formats and Codes .........................................15
8.1.1. FEC Framework Configuration Information ............15
8.1.2. Source FEC Payload ID ..............................15
8.1.3. Repair FEC Payload ID ..............................15
8.2. Procedures ................................................16
8.2.1. Source Symbol Construction .........................16
8.2.2. Derivation of Source FEC Packet
Identification Information .........................17
8.2.3. Repair Packet Construction .........................18
8.2.4. Procedures for RTP Source Flows ....................18
8.3. FEC Code Specification ....................................18
9. Security Considerations ........................................18
10. Session Description Protocol (SDP) Signaling ..................19
11. Congestion Control Considerations .............................19
12. IANA Considerations ...........................................19
12.1. Registration of FEC Scheme IDs ...........................19
13. Acknowledgements ..............................................20
14. References ....................................................211. Introduction 🦋
bestie, so the "Forward Error Correction (FEC) Framework" doc [RFC6363] is the general framework for using Forward Error Correction with arbitrary packet flows 💜 it's modeled after the FEC Building Block that the IETF Reliable Multicast Transport working group made [RFC5052], and the FEC Framework defines FEC Schemes, which are the specific FEC setups 🧚 this doc describes six FEC Schemes that use the Raptor and RaptorQ FEC codes defined in [RFC5053] and [RFC6330] ✨
the protection doesn't care what kind of source data you have. it can be any sequence of packets, like audio or video 🎀 generally, it works like this:
- The sender picks a set of source packets (a source block) to protect together, based on the FEC Framework Configuration Information. 💅
- The sender arranges those source packets into a set of source symbols, all of the same size. 🌸
- The sender runs the Raptor/RaptorQ protection operation on the source symbols to make the number of repair symbols it needs. 🔥
- The sender packetizes the repair symbols, then sends the repair packet(s) and the source packets to the receiver(s). Per the FEC Framework requirements, the sender MUST transmit the source and repair packets in different source and repair flows, or in the case Real-time Transport Protocol (RTP) transport is used for repair packets, in different RTP streams. 🫶
- On the receiver side, if every source packet arrives safely, there's no need for FEC recovery and the repair packets get tossed 🗑️ but if some source packets are missing, the repair packets can be used to recover the missing info 👑
so the FEC mechanism needs the receiver to figure out how received source packets and repair packets relate to each other, especially which source packets went missing 🧚 often the source packets already carry data that can refer to them and show which ones are missing 💖 in that case, we assume a "sequence number" can be derived from the source packets, directly or indirectly, and used within the FEC Scheme ✨ this is called a "single sequenced flow" 🌈 in that case, the FEC Source Payload ID defined in [RFC6363] is empty, and the source packets aren't modified by applying FEC, which is a huge backwards compatibility win 🙈
otherwise, you have to add data to the source packets for FEC purposes, in the form of a non-empty FEC Source Payload ID 🦋 this is the "arbitrary packet flow" case. this document defines six FEC Schemes: two for a single sequenced flow and four for arbitrary packet flows ⭐
2. Document Outline 🌸
this doc is organized like this:
- Section 5 defines general procedures that apply to using the Raptor and RaptorQ codes in the context of the FEC Framework. 💅
- Section 6 defines a FEC Scheme for arbitrary source flows, following the format defined for FEC Schemes in [RFC6363]. When used with Raptor codes, this scheme is equivalent to the one defined in 3GPP TS 26.346, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs" [MBMSTS]. 🧚
- Section 7 defines a FEC Scheme similar to the one in Section 6, but with optimizations for when only limited source block sizes are needed. When used with Raptor codes, this scheme is equivalent to the one defined in ETSI TS 102.034, "Digital Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services over IP Based Networks" [DVBTS] for arbitrary packet flows. 🔥
- Section 8 defines a FEC Scheme for a single flow that already comes with a source packet sequence number. When used with Raptor codes, this scheme is equivalent to the one defined in [DVBTS] for the case of a single sequenced flow. 👑
3. Requirements Notation 🔥
okay this part is the important one 🫶 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] 💅
4. Definitions and Abbreviations 👑
the definitions, notations, and abbreviations commonly used in this document are summarized in this section ✨
4.1. Definitions 📖✨
The FEC-specific terminology used in this doc is defined in [RFC6363] 💅. In this document, as in [RFC6363], the first letter of each FEC-specific term is capitalized, along with the new terms defined here:
- Symbol: A unit of data. Its size, in octets, is called the symbol size. 🧩
- FEC Framework Configuration Information: Information that controls how the FEC Framework operates. Each FEC Framework instance has its own configuration information. 🎀
4.2. Abbreviations 🌸
This document uses abbreviations that apply to the FEC Framework in general, as defined in [RFC6363]. On top of those, it uses the following abbreviations:
- FSSI: FEC-Scheme-Specific Information.
- ADU: Application Data Unit
- ADUI: Application Data Unit Information.
- SPI: Source Packet Information.
- MSBL: Maximum Source Block Length
5. General Procedures for Raptor FEC Schemes 🦋
This section lays out the general procedures that apply to all Raptor and RaptorQ FEC Schemes. Specifically, it covers how source symbols get built from a set of source transport payloads. It's giving foundation 🫶
For any field defined in this document, the octets are ordered in network byte order. Bestie, this one is important 💜
As described in [RFC6363], for each Application Data Unit (ADU) in a source block, the FEC Scheme is provided with:
- A description of the source data flow the ADU is associated with, plus an integer identifier for that flow.
- The ADU itself.
- The length of the ADU.
For each ADU, we define the Application Data Unit Information (ADUI) like this. Let:
nbe the number of ADUs in the source block.Tbe the source symbol size in octets. Note: this information is provided by the FEC Scheme, as defined below.ibe the index to the (i+1)-th ADU to be added to the source block, where 0 <= i < n.f[i]denote the integer identifier associated with the source data flow the i-th ADU was taken from.F[i]denote a single octet representing the value off[i].l[i]be a length indication associated with the i-th ADU. The nature of the length indication is defined by the FEC Scheme.L[i]denote two octets representing the value ofl[i]for the i-th ADU, in network byte order (high order octet first).R[i]denote the number of octets in the (i+1)-th ADU.s[i]be the smallest integer such thats[i]*T >= (l[i]+3). Note:s[i]is the length ofSPI[i]in units of symbols of sizeToctets.P[i]denotes[i]*T-(l[i]+3)zero octets. Note:P[i]are padding octets that align the start of each UDP packet with the start of a symbol. 🌈ADUI[i]be the concatenation ofF[i],L[i],R[i], andP[i].
Then, a source data block gets built by concatenating ADUI[i] for i = 0, 1, 2, ... n-1. The source data block size, S, is then given by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer encoding symbol IDs (ESI), starting from zero and going up consecutively within the source block. Each ADU is associated with the ESI of the first symbol containing the SPI for that packet. So the encoding symbol ID value for the j-th source packet, ESI[j], is:
ESI[j] = 0, for j=0
ESI[j] = sum{s[i], i=0,...,(j-1)}, for 0 < j < nSource blocks are identified by integer Source Block Numbers. This specification does not say how Source Block Numbers get allocated to the source blocks. The Source FEC Packet Identification Information consists of the identity of the source block and the encoding symbol ID associated with the packet. 🔥
6. Raptor FEC Schemes for Arbitrary Packet Flows 👑
6.1. Introduction 🧚
This section specifies a FEC Scheme for applying the Raptor and RaptorQ codes to arbitrary packet flows. This scheme is recommended in scenarios where maximal generality is required. 💖
When used with the Raptor codes specified in [RFC5053], this scheme is equivalent to the one specified in [MBMSTS]. ✨
6.2. Formats and Codes 🍓
6.2.1. FEC Framework Configuration Information 🎀
6.2.1.1. FEC Scheme ID
The value of the FEC Scheme ID for the Fully-Specified FEC scheme defined in this section is 1 when [RFC5053] is used, and 2 when [RFC6330] is used, as assigned by IANA. 🫶
6.2.1.2. Scheme-Specific Elements
The scheme-specific elements of the FEC Framework Configuration information for this scheme are as follows:
- MSBL: The maximum source block length. This is a non-negative integer less than 8192 for FEC Scheme 1, and less than 56403 for FEC Scheme 2, in units of symbols. The field type is unsigned integer.
- T: The encoding symbol size. This is a non-negative integer less than 65536, in units of octets. The field type is unsigned integer.
- P: The payload ID format indicator. The P bit shall be set to zero to indicate payload ID format A, or to one to indicate payload ID format B. The field type is unsigned integer.
An encoding format for the encoding symbol size, MSBL, and payload ID format indicator is defined below. 🦋
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Symbol Size (T) | MSBL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+
Figure 1: FEC-Scheme-Specific InformationThe P bit shall be set to zero to indicate Payload ID format A, or to one to indicate Payload ID format B. The last octet of FEC-Scheme-Specific Information SHOULD be omitted, indicating that Payload ID format A is in use. The payload ID format indicator defines which of the Source FEC Payload ID and Repair FEC Payload ID formats defined below shall be used. Payload ID format B SHALL NOT be used for FEC Scheme 1. The two formats enable different use cases: format A is appropriate when the stream has many typically smaller source blocks, and format B is applicable when the stream has fewer large source blocks, each with many encoding symbols. 🌸
6.2.2. Source FEC Payload ID 💅
This scheme makes use of an Explicit Source FEC Payload ID, which is appended to the end of the source packets. Two formats are defined for the Source FEC Payload ID, format A and format B. The format in use is signaled as part of the FEC Framework Configuration Information. 🔥
The Source FEC Payload ID for format A is shown in Figure 2.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Source FEC Payload ID - Format A- Source Block Number (SBN), (16 bits): Identifier for the source block that the source data within the packet relates to. The field type is unsigned integer.
- Encoding Symbol ID (ESI), (16 bits): The starting symbol index of the source packet in the source block. The field type is unsigned integer.
The Source FEC Payload ID for format B is shown in Figure 3.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBN | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Source FEC Payload ID - Format B- Source Block Number (SBN), (8 bits): Identifier for the source block that the source data within the packet relates to. The field type is unsigned integer.
- Encoding Symbol ID (ESI), (24 bits): The starting symbol index of the source packet in the source block. The field type is unsigned integer.
6.2.3. Repair FEC Payload ID 🌈
Two formats for the Repair FEC Payload ID, format A and format B, are defined below.
The Repair FEC Payload ID for format A is shown in Figure 4.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (SBL) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Repair FEC Payload ID - Format A- Source Block Number (SBN), (16 bits): Identifier for the source block that the repair symbols within the packet relate to. For format A, it is 16 bits in size. The field type is unsigned integer.
- Encoding Symbol ID (ESI), (16 bits): Identifier for the encoding symbols within the packet. The field type is unsigned integer.
- Source Block Length (SBL), (16 bits): The number of source symbols in the source block. The field type is unsigned integer.
The Repair FEC Payload ID for format B is shown in Figure 5.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBN | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (SBL) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Repair FEC Payload ID - Format B- Source Block Number (SBN), (8 bits): Identifier for the source block that the repair symbols within the packet relate to. For format B, it is 8 bits in size. The field type is unsigned integer.
- Encoding Symbol ID (ESI), (24 bits): Identifier for the encoding symbols within the packet. The field type is unsigned integer.
- Source Block Length (SBL), (16 bits): The number of source symbols in the source block. The field type is unsigned integer.
The interpretation of the Source Block Number, encoding symbol ID, and Source Block Length is defined by the FEC Code Specification in [RFC5053] for FEC Scheme 1, and in [RFC6330] for FEC Scheme 2. 🫶
6.3. Procedures 🧠
6.3.1. Source Symbol Construction 🛠️
FEC Scheme 1 and FEC Scheme 2 use the procedures defined in Section 5 to construct a set of source symbols that the FEC Code can be applied to. The sender MUST allocate Source Block Numbers to source blocks sequentially, wrapping around to zero after Source Block Number 65535 (format A) or 255 (format B). 🔥
During the construction of the source block:
- the length indication,
l[i], included in the Source Packet Information for each packet shall be the transport payload length, i.e., the length of the ADU. - the value of
s[i]in the construction of the Source Packet Information for each packet shall be the smallest integer such thats[i]*T >= (l[i]+3).
6.3.2. Repair Packet Construction 💜
For FEC Scheme 1 [RFC5053], the ESI value placed into a repair packet is calculated as specified in Section 5.3.2 of [RFC5053].
For FEC Scheme 2 [RFC6330], the ESI value placed into a repair packet is calculated as specified in Section 4.4.2 of [RFC6330].
In both cases, K is identical to SBL. ✨
6.4. FEC Code Specification 💅
Okay bestie, the encoder rules are strict 🫶 For FEC Scheme 1, the FEC encoder defined in [RFC5053] SHALL be used, and for FEC Scheme 2, the FEC encoder defined in [RFC6330] SHALL be used. For both schemes, the source symbols passed to the encoder SHALL consist of the source symbols constructed according to Section 6.3.1. So the value of K (which is the Source Block Length) may vary between blocks in the stream, but it SHALL NOT exceed the Maximum Source Block Length signaled in the FEC-Scheme-Specific Information. The symbol size T, used for source block construction and repair symbol construction, is the encoding symbol size signaled in the FEC-Scheme-Specific Information. 🎀
7. Optimized Raptor FEC Scheme for Arbitrary Packet Flows ✨
7.1. Introduction 🌸
Okay so this section is a slightly glow-up version of the scheme from Section 6 🦋 It's for situations where only relatively small block sizes get used. These tweaks make things way more optimized for both senders and receivers, which is literally iconic.
Here's the tea on the changes:
- All source blocks within a stream are encoded using the same source block size. Code shortening handles blocks of different sizes by padding every block to the required size with zero symbols before encoding. Those zero symbols get thrown away after decoding. The source block size for a stream is signaled in the Maximum Source Block Length (MSBL) field of the scheme-specific information. The extended source block gets zero or more padding symbols added so the total number of symbols, MSBL, is one of the values listed in Section 7.4. Each padding symbol is T octets long, and every octet is zero. MSBL MUST be selected as the smallest value from the possible values in Section 7.4 that is greater than or equal to K. 💖
- The possible choices of MSBL for a stream are restricted to a small, specified set. This lets explicit operation sequences for encoding and decoding those restricted source block lengths be pre-calculated and embedded in software or hardware. 🧚
When used with the Raptor codes specified in [RFC5053], this scheme is equivalent to the one specified in [DVBTS] for arbitrary packet flows. 👑
7.2. Formats and Codes 💜
7.2.1. FEC Framework Configuration Information 🎀
7.2.1.1. FEC Scheme ID
The FEC Scheme ID for the Fully-Specified FEC scheme in this section is 3 when [RFC5053] is used and 4 when [RFC6330] is used, as assigned by IANA. 🦋
7.2.1.2. FEC-Scheme-Specific Information
The elements for FEC Scheme 3 are the same as the ones for FEC Scheme 1, and the elements for FEC Scheme 4 are the same as the ones for FEC 2 in Section 6.2.1.2. The only difference is that the MSBL value is defined in Section 7.4. 🌈
7.2.2. Source FEC Payload ID
The elements for FEC Scheme 3 match FEC Scheme 1, and the elements for FEC Scheme 4 match FEC 2, as specified in Section 6.2.2. ✨
7.2.3. Repair FEC Payload ID
The elements for FEC Scheme 3 match FEC Scheme 1, and the elements for FEC Scheme 4 match FEC 2, as specified in Section 6.2.3. 💅
7.3. Procedures 🌸
7.3.1. Source Symbol Construction
Just see Section 6.3.1, it's the same thing 🙈
7.3.2. Repair Packet Construction
The number of repair symbols inside a repair packet is computed from the packet length. The ESI value placed into a repair packet is calculated as X + MSBL - SBL. Here, X is what the ESI of the repair packet would be if the ESI were calculated as specified in Section 5.3.2 of [RFC5053] for FEC Scheme 3, and as specified in Section 4.4.2 of [RFC6330] for FEC Scheme 4, where K=SBL. The value of SBL SHALL be, at most, the value of MSBL. 🔥
7.4. FEC Code Specification 🦋
The FEC encoder defined in [RFC5053] SHALL be used for FEC Scheme 3, and the FEC encoder defined in [RFC6330] SHALL be used for FEC Scheme 4. The source symbols passed to the encoder SHALL consist of the source symbols constructed according to Section 6.3.1, extended with zero or more padding symbols. That extension SHALL be such that the total number of symbols in the source block is equal to the MSBL signaled in the FEC-Scheme-Specific Information. So the value of K used by the FEC encoder equals the MSBL for every block in the stream. Padding symbols shall consist entirely of octets set to zero. The symbol size T, used for source block construction and repair symbol construction, is the encoding symbol size signaled in the FEC-Scheme-Specific Information. 🫶
For FEC Scheme 3, T SHALL be set so the number of source symbols in any source block is, at most, 8192. The MSBL parameter, and therefore the number of symbols used in the FEC Encoding and Decoding operations, SHALL be set to one of these values:
101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031,
1139, 1281For FEC Scheme 4, T SHALL be set so the number of source symbols in any source block is less than 56403. The MSBL parameter SHALL be set to one of the supported values for K' defined in Section 5.6 of [RFC6330]. ✨
8. Raptor FEC Scheme for a Single Sequenced Flow 👑
8.1. Formats and Codes 💖
8.1.1. FEC Framework Configuration Information 🎀
8.1.1.1. FEC Scheme ID
For this Fully-Specified FEC scheme, the FEC Scheme ID is 5 when [RFC5053] is used and 6 when [RFC6330] is used, as assigned by IANA. 🧚
8.1.1.2. Scheme-Specific Elements
The elements for FEC Scheme 5 are the same as the ones for FEC Scheme 1, and the elements for FEC Scheme 6 are the same as the ones for FEC 2, as specified in Section 6.2.1.2. 🌸
8.1.2. Source FEC Payload ID
The Source FEC Payload ID field isn't used by this FEC Scheme. Source packets aren't modified by this FEC Scheme either 🙈
8.1.3. Repair FEC Payload ID
Two formats for the Repair FEC Payload ID are defined: format A and format B. 🦋
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Repair FEC Payload ID - Format AFormat A breaks down like this:
- Initial Sequence Number (Flow i ISN), (16 bits): This is the lowest 16 bits of the sequence number of the first packet included in this sub-block. If the sequence numbers are shorter than 16 bits, the received Sequence Number SHALL be logically padded with zero bits to become 16 bits in length. The field type is unsigned integer. 💅
- Source Block Length (SBL), (16 bits): This specifies the length of the source block in symbols. The field type is unsigned integer. 🌈
- Encoding Symbol ID (ESI), (16 bits): This indicates which repair symbols are contained within this repair packet. The ESI given is the ESI of the first repair symbol in the packet. The field type is unsigned integer. 💜
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Repair FEC Payload ID - Format BFormat B works the same way, with a few differences. 🍓
- Initial Sequence Number (Flow i ISN), (16 bits): This is the lowest 16 bits of the sequence number in the first packet included in this sub-block. If the sequence numbers are shorter than 16 bits, the received Sequence Number SHALL be logically padded with zero bits to become 16 bits in length. The field type is unsigned integer. 🫶
- Source Block Length (SBL), (16 bits): This specifies the length of the source block in symbols. The field type is unsigned integer. ⭐
- Encoding Symbol ID (ESI); (24 bits): This indicates which repair symbols are contained within this repair packet. The ESI given is the ESI of the first repair symbol in the packet. The field type is unsigned integer. 🔥
8.2. Procedures 🌈
8.2.1. Source Symbol Construction
FEC Scheme 5 and FEC Scheme 6 use the procedures defined in Section 5 to construct a set of source symbols that the FEC code can be applied to. 🦋
During the construction of the source block:
- The length indication, l[i], included in the Source Packet Information for each packet shall be dependent on the protocol carried within the transport payload. Rules for RTP are specified below. 💖
- The value of s[i] in the construction of the Source Packet Information for each packet shall be the smallest integer such that
s[i]*T >= (l[i]+3). 🧚
8.2.2. Derivation of Source FEC Packet Identification Information ✨
okay so the Source FEC Packet Identification Information for a source packet comes from two places: the packet's own sequence number, and whatever info shows up in any repair FEC packet that belongs to the same source block 🧩. Source blocks get their name from the sequence number of their first source packet, and that info gets signaled in the Initial Sequence Number field of all the repair FEC packets for that block 💖
The length of the Source Packet Information (in octets) for source packets in a block is the same as the length of the payload holding the encoding symbols of the repair packets (so not counting the Repair FEC Payload ID) for that block. This length MUST be the same for all repair packets 🎀 The Application Data Unit Information Length (ADUIL) in symbols is that length divided by the encoding symbol size, which gets signaled in the FEC Framework Configuration Information. Then the set of source packets in the block gets decided by the Initial Sequence Number (ISN) and the Source Block Length (SBL), like this:
Let's name the pieces:
Iis the Initial Sequence Number of the source blockLPis the Source Packet Information Length in symbolsLBis the Source Block Length in symbols
So source packets with sequence numbers from I to I +(LB/LP)-1 inclusive are in the source block 🦋 The Source Block Length, LB, MUST be chosen such that it is at least as large as the largest Source Packet Information Length LP. Big-brain move, no cap 🧠
Note that if no FEC repair packets are received, then no FEC decoding is possible, so it's totally unnecessary for the receiver to figure out the Source FEC Packet Identification Information for the source packets 🙈
The encoding symbol ID for a packet comes from this info:
- The sequence number,
Ns, of the packet - The Source Packet Information Length for the source block,
LP - The Initial Sequence Number of the source block,
I
And then the encoding symbol ID for the packet with sequence number Ns is given by this formula:
ESI = ( Ns - I ) * LPNote that all repair packets associated to a given source block MUST contain the same Source Block Length and Initial Sequence Number. They gotta match, bestie 👯
Also, the source packet flow processed by the FEC encoder MUST have consecutive sequence numbers 🌸 If the incoming source packet flow has a gap in the sequence numbers, then implementors SHOULD insert an ADU in the source block that complies to the format of the source packet flow, but is ignored at the application with high probability. For additional guidelines, refer to [RFC6363], Section 10.2, paragraph 5 📖
8.2.3. Repair Packet Construction 🧁
See Section 7.3.2 💅
8.2.4. Procedures for RTP Source Flows 🎞️
Okay, the specific case of RTP source packet flows is its own little thing 💜 For these, the RTP Sequence Number field SHALL be used as the sequence number in the procedures described above. The length indication included in the Application Data Unit Information SHALL be the RTP payload length plus the length of the contributing sources (CSRCs), if any, the RTP Header Extension, if present, and the RTP padding octets, if any. Note that this length is always equal to the UDP payload length of the packet minus 12 🌈
8.3. FEC Code Specification 🧩
The elements for FEC Scheme 5 are the same as specified for FEC Scheme 3, and the elements specified for FEC 6 are the same as specified for FEC 4, as specified in Section 7.4. It's giving copy-paste energy, and honestly that's the point ✨
9. Security Considerations 💀
For the general security considerations related to the use of FEC, refer to [RFC6363]. Also consider relevant security considerations in [RFC5053] and [RFC6330]. No security vulnerabilities specific to this document have been identified. Okay, that's the official word, but please, please keep the security stuff in mind while you build 🙏💀
10. Session Description Protocol (SDP) Signaling 🎀
This section provides an SDP [RFC4566] example. The syntax follows the definition in [RFC6364]. Picture this: we've got one source video stream (mid:S1) and one FEC repair stream (mid:R1). We bundle them into one FEC group with the "a=group:FEC-FR S1 R1" line. The source and repair streams are sent to the same port on different multicast groups, and the repair window is set to 200 ms ⏱️
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor FEC Example
t=0 0
a=group:FEC-FR S1 R1
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.2/127
a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A
a=repair-window:200ms
a=mid:R111. Congestion Control Considerations 🌊
For the general congestion control considerations related to the use of FEC, refer to [RFC6363]. Go read that one, it's the main character here 🎬
12. IANA Considerations 📋
12.1. Registration of FEC Scheme IDs 🔢
The value of FEC Scheme IDs is subject to IANA registration. For general guidelines on IANA considerations as they apply to this document, refer to [RFC6363] 🫧
This document registers six values in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry (http://www.iana.org/assignments/ rmt-fec-parameters/) as provided in Table 1. Each value refers to a Fully-Specified FEC scheme ✨ Here's the table:
+----------+---------------------+----------------------------------+
| FEC | FEC Scheme | Reference |
| Encoding | Description | |
| ID | | |
+----------+---------------------+----------------------------------+
| 1 | Raptor FEC Scheme | Section 6 in this document using |
| | for Arbitrary | [RFC5053] |
| | Packet Flows | |
+----------+---------------------+----------------------------------+
| 2 | RaptorQ FEC Scheme | Section 6 in this document using |
| | for Arbitrary | [RFC6330]. |
| | Packet Flows | |
+----------+---------------------+----------------------------------+
| 3 | Raptor FEC Scheme | Section 7 in this document using |
| | Optimized for | Raptor [RFC5053]. |
| | Arbitrary Packet | |
| | Flows | |
+----------+---------------------+----------------------------------+
| 4 | RaptorQ FEC Scheme | Section 7 in this document |
| | Optimized for | using RaptorQ [RFC6330]. |
| | Arbitrary Packet | |
| | Flows | |
+----------+---------------------+----------------------------------+
| 5 | Raptor FEC Scheme | Section 8 in this document using |
| | for a Single | Raptor [RFC5053]. |
| | Sequence Flow | |
+----------+---------------------+----------------------------------+
| 6 | RaptorQ FEC Scheme | Section 8 in this document using |
| | for a Single | RaptorQ [RFC6330]. |
| | Sequence Flow | |
+----------+---------------------+----------------------------------+
Table 1: FEC Framework (FECFRAME) FEC Encoding IDs13. Acknowledgements 🫶
Thanks are due to Ali C. Begen and David Harrington for thorough review of earlier draft versions of this document. Iconic reviewers, honestly 👑
14. References 📚
14.1. Normative References
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, October 2011.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme for Object
Delivery", RFC 5053, October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,
and L. Minder, "RaptorQ Forward Error Correction Scheme
for Object Delivery", RFC 6330, August 2011.14.2. Informative References
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC6364] Begen, A., "Session Description Protocol Elements for the
Forward Error Correction (FEC) Framework", RFC 6364,
October 2011.
[DVBTS] ETSI, "Digital Video Broadcasting (DVB); Transport of
MPEG-2 Based DVB Services over IP Based Networks", ETSI TS
102 034, March 2009.
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346, April 2005.Authors' Addresses 💌
Mark Watson
Netflix
100 Winchester Circle
Los Gatos, CA 95032
United States
EMail: watsonm@netflix.com
Thomas Stockhammer
Nomor Research
Brecherspitzstrasse 8
Munich 81541
Germany
EMail: stockhammer@nomor.de
Michael Luby
Qualcomm Research Berkeley
2030 Addison Street
Berkeley, CA 94704
United States
EMail: luby@qualcomm.com📦 where this page comes from
- ietf: rfc6681 2012-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms