Internet-Draft MoQ FEC Block Codes November 2026
Ramadan Expires 6 May 2027 [Page]
Workgroup:
moq
Internet-Draft:
draft-ramadan-moq-fec-block-codes-00
Published:
Intended Status:
Standards Track
Expires:
Author:
O. Ramadan
Blockcast

Block FEC Schemes for Media over QUIC: Reed-Solomon and RaptorQ

Abstract

This document specifies two block Forward Error Correction (FEC) schemes for the FEC mechanism of Media over QUIC (MoQ): the systematic Reed-Solomon erasure code over GF(2^8) of ISO/IEC 23008-10, which is mandatory to implement, and RaptorQ (RFC 6330), which is optional. For each scheme it gives the registered identifier, the derivation of the decoder's parameters from the instance's configuration and the Repair FEC Payload ID with no in-session signaling, the bounds on block size and symbol size, the decoding overhead, and how the scheme supports repair layers. It restates the Reed-Solomon code and gives test vectors for it.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 May 2027.

▲

Table of Contents

1. Introduction

[MOQ-FEC-CORE] specifies how FEC repair data is carried alongside source media in MoQ without naming an FEC code. Its Section 4.2 states the properties that a block FEC scheme must have to be used with that mechanism, and the information that a scheme's specification must give. This document specifies two such schemes: the systematic Reed-Solomon erasure code over GF(2^8) of [ISO.23008-10], which is mandatory to implement, and RaptorQ [RFC6330], which is optional. For each it gives the scheme identifier (Section 3), the derivation of the decoder's parameters (Section 5, Section 6), the bounds the scheme imposes on a configuration and on a repair object (Section 7), how its repair symbols are numbered and generated (Section 9) and how it supports repair layers (Section 8). For Reed-Solomon it also restates the code (Section 5.1), because [ISO.23008-10] is not freely available, and gives test vectors (Appendix A).

1.1. Relation to Other Documents

This document is one of a set. [MOQ-FEC-CORE] defines the mechanism: source symbols, blocks, repair tracks and layers, the repair object format, recovery, and the configuration data model whose scheme parameter carries an identifier of this document. [MOQ-FEC-CATALOG] encodes that data model in the MSF and CMSF catalogs. [MOQ-MMT] defines the "iso-ssbg1-v1" block profile for tracks packaged as MMTP packets and maps the identifiers of this document to the FEC code points that its AL-FEC message carries. [MOQ-FEC-MULTICAST] covers multicast delivery of protected tracks. The text of this document is taken from [I-D.ramadan-moq-fec]; Appendix C lists what moved here and what changed.

2. Conventions and Definitions

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.

This document uses the terms of [MOQ-FEC-CORE] Section 2. The ones it relies on are restated here; the others are as that section defines them.

FEC Instance: One independent FEC encoding over a sequence of source symbols, with its own source symbol bound K, symbol size T, SS_ID space, block partition, repair symbols and repair tracks. A source track has one or more FEC instances ([MOQ-FEC-CORE] Section 5.1).

Source Symbol: A T-byte unit of source data that an FEC instance encodes. Source symbols are formed from source objects by the instance's block profile ([MOQ-FEC-CORE] Section 5.2).

Repair Symbol: A T-byte unit generated by the FEC scheme from the source symbols of one block.

SS_ID: The 32-bit sequence number of a source symbol within its FEC instance. It wraps modulo 2^32 ([MOQ-FEC-CORE] Section 7.6).

Source Block: A run of SSB_length consecutive source symbols, 1 <= SSB_length <= K, over which a block FEC scheme encodes. A block is the SS_ID range [SS_Start, SS_Start + SSB_length) and is identified by its SS_Start.

SS_Start and SSB_length: The first SS_ID of a source block and the block's source symbol count, carried in the Repair FEC Payload ID of every repair object of the block ([MOQ-FEC-CORE] Section 7.5).

FEC Block: The combination of SSB_length source symbols and P repair symbols; the ISO encoding symbol block ([ISO.23008-1] 3.1.5).

Encoding Symbol ID (ESI): The index of a symbol within its block: a source symbol's serial distance from SS_Start, and SSB_length + RS_ID for a repair symbol.

RS_ID: The zero-based index of a repair symbol among the repair symbols of its block.

RSB_length: The number of repair symbols generated for a block, the instance's total repair count P when the block's repair symbols are generated, carried in the Repair FEC Payload ID of every repair object of the block ([MOQ-FEC-CORE] Section 7.5).

Repair Layer: One of possibly several repair tracks of one FEC instance, each carrying a disjoint range of RS_IDs for every block ([MOQ-FEC-CORE] Section 7.3). Layer 0 is the base layer.

RS_ID Offset: The first Repair Symbol ID a layer may use; O_i for layer i ([MOQ-FEC-CORE] Section 7.3.1).

Object Transmission Information (OTI): Parameters required to configure a RaptorQ decoder, as defined in [RFC6330].

Block Profile: The rules that fix how source symbols are formed from source objects and how blocks are delimited and identified ([MOQ-FEC-CORE] Section 5.2).

K, P and T denote an instance's sourceSymbols, its total repair count over all its repair layers, and its symbolSize ([MOQ-FEC-CORE] Section 10.1); P_i is the repair count of layer i.

3. Scheme Identifiers

FEC scheme identifiers are registered in the "MoQ FEC Schemes" registry ([MOQ-FEC-CORE] Section 15.2); the scheme parameter of an FEC instance ([MOQ-FEC-CORE] Section 10.1) carries the string identifier, and the catalog binding encodes it ([MOQ-FEC-CATALOG] Section 3.1). This document defines two:

"raptorq": RaptorQ fountain code per [RFC6330]. Can recover from loss of any symbols as long as SSB_length symbols (source or repair), plus a small decoding overhead (Section 8), are received. It is OPTIONAL (Section 10).

"reed-solomon": The systematic Reed-Solomon erasure code over GF(2^8) of [ISO.23008-10] Clause 6, restated in Section 5.1. It recovers a block from any SSB_length of its distinct source and repair symbols. An FEC instance under it holds at most 255 source and repair symbols per block (Section 7). It is the mandatory-to-implement scheme (Section 10).

Both codes are systematic: the source symbols of a block are among its encoding symbols, so a receiver uses the source symbols it receives as they arrive. The two identifiers correspond to the FEC code points 3 (the "6330 code") and 1 (the RS code) of [ISO.23008-10] Table 1, which an AL-FEC message carries in fec_code_id_for_repair_flow ([MOQ-MMT] Section 8.3).

4. Requirements of the Core Met by These Schemes

[MOQ-FEC-CORE] Section 4.2 lists eight properties that a block scheme must have and that its specification must establish. This section states, for each, where this document establishes it for "reed-solomon" and for "raptorq".

  1. Erasure code. "reed-solomon" recovers a block from any SSB_length of its distinct source and repair symbols (Section 5.1). "raptorq" can recover from loss of any symbols as long as SSB_length symbols (source or repair), plus a small decoding overhead, are received ([RFC6330]; Section 8).

  2. Systematic. Both codes are systematic: the source symbols of a block are among its encoding symbols, so a receiver uses the source symbols it receives as they arrive (Section 3). Under "reed-solomon" the source symbols themselves are sent unchanged (Section 5.1); under "raptorq" they occupy ESIs 0 to SSB_length - 1 of the [RFC6330] source block (Section 9).

  3. Fixed symbol size. Under both schemes every source and repair symbol is exactly T bytes. "raptorq" requires T to be a multiple of 8, the Symbol Alignment of its derived OTI (Section 6.1); "reed-solomon" imposes no alignment (Section 5.2).

  4. Index-fixed repair. Under either scheme, a repair symbol is fixed by its block and its RS_ID alone, whichever layer carries it: RaptorQ through its open Encoding Symbol ID space, and the Reed-Solomon code of this document through a Cauchy generator matrix whose column j depends on RS_ID j alone (Section 8).

  5. Parameters from configuration and the wire. Under both schemes the decoder of each block is configured from the instance's configuration and the block's Repair FEC Payload ID, and no other signaling is defined: Section 6.1 derives the RaptorQ OTI, and Section 5.2 the Reed-Solomon parameters.

  6. Stated bounds. Section 7 states, for each scheme, the largest K, the largest SSB_length + RSB_length and the largest RS_ID, and the constraint on T.

  7. Stated recovery condition. The decoding overhead e is 0 under "reed-solomon", which is maximum distance separable, and under "raptorq" a small number of symbols with the residual failure probabilities of [RFC6330] (Section 8).

  8. Deterministic and verifiable. Both codes are deterministic: Section 5.1 fixes the field, the generator matrix and the order of symbols, and [RFC6330] fixes every table and index of RaptorQ. Appendix A gives test vectors that tell the Reed-Solomon construction of this document apart from other systematic Reed-Solomon constructions over GF(2^8). Appendix B gives RaptorQ test vectors that fix, for a block of this document, the OTI that Section 6.1 derives and the Encoding Symbol ID that Section 9 gives each RS_ID.

Both schemes support repair layers (Section 8), which [MOQ-FEC-CORE] Section 4.2 asks a scheme specification to state. "reed-solomon" is maximum distance separable; "raptorq" is not, but is close to it at every block size of Section 7. Section 11 states the decoding cost of "reed-solomon" and, for "raptorq", points at the decoder of [RFC6330].

5. Reed-Solomon

5.1. The Code

The "reed-solomon" scheme is the systematic Reed-Solomon erasure code over GF(2^8) of [ISO.23008-10] Clause 6, to which that document assigns FEC code point 1 (its Table 1). This section restates the code, because [ISO.23008-10] is not freely available. If this restatement and [ISO.23008-10] Clause 6 differ, [ISO.23008-10] governs. Appendix A gives test vectors.

Field. The code works in GF(2^8) defined by the primitive polynomial x^8 + x^4 + x^3 + x^2 + 1 (0x11D), the polynomial that [RFC5510] Section 8.1 gives for m = 8. alpha is a root of that polynomial and is represented by the byte 0x02. A byte with bits b_7 (the most significant) down to b_0 represents the element b_7 alpha^7 + b_6 alpha^6 + ... + b_1 alpha + b_0. Addition is the bitwise exclusive OR of bytes, and multiplication is the product of polynomials modulo 0x11D, so alpha^8 is 0x1D. This document defines the code over GF(2^8) only.

Generator matrix. The code is generated by G = [I | A], where I is an identity matrix and A is a Cauchy matrix ([ISO.23008-10] Clause 6.2 writes G = [I; A]). Row i of A belongs to the source symbol at ESI i, and column j to the repair symbol whose RS_ID is j. The entries of A are:

A_{i,j} = 1 / (x_i + y_j)
x_i     = alpha^(254 - i)
y_j     = alpha^j

A block that holds SSB_length source symbols and RSB_length repair symbols uses rows 0 to SSB_length - 1 and columns 0 to RSB_length - 1 of A. x_i and y_j differ whenever i + j < 254, so every entry the block uses is defined when SSB_length + RSB_length is at most 255, the bound of [ISO.23008-10] Clause 6.2. An entry depends on i and j alone: not on K, not on SSB_length and not on P.

Encoding. Every symbol of a block is T bytes long. Let s_i be the source symbol at ESI i ([MOQ-FEC-CORE] Section 5.5), for i from 0 to SSB_length - 1. The repair symbol r_j whose RS_ID is j is computed one byte position at a time, as [RFC5510] Section 8.4 applies its code to symbols: for each byte position u from 0 to T - 1,

r_j[u] = sum over i < SSB_length of A_{i,j} * s_i[u]

where the sum and the products are computed in GF(2^8). The source symbols themselves are sent unchanged.

Short blocks. A block whose SSB_length is less than K uses only the first SSB_length rows of A. Its repair symbols equal those of a block of K source symbols whose symbols at ESIs SSB_length to K - 1 are all zero, because a zero symbol adds nothing to any sum. No zero symbol is sent or counted in SSB_length ([MOQ-FEC-CORE] Section 5.4).

Decoding. Every square submatrix of a Cauchy matrix is invertible ([ISO.23008-10] Clause 6.2), so the code is maximum distance separable: a receiver that holds any SSB_length distinct symbols of a block, source and repair in any mix, recovers every source symbol of the block. Let M be the set of ESIs of the source symbols it lacks, and R a set of |M| RS_IDs of repair symbols that it holds. For each byte position u and each j in R:

sum over i in M of A_{i,j} * s_i[u]
    = r_j[u] + sum over i < SSB_length, i not in M,
               of A_{i,j} * s_i[u]

The square matrix of the entries A_{i,j} with i in M and j in R is a submatrix of A and is therefore invertible. The receiver inverts it once per block and applies the result at every byte position. Any decoding method that yields the same source symbols is acceptable.

The field is that of [RFC5510], but the generator matrix is not the Vandermonde-derived matrix of [RFC5510] Section 8.2, and this document uses neither the FEC Payload IDs nor the source block partitioning of [RFC5510]. Several systematic Reed-Solomon constructions over GF(2^8) are in use, and they produce different repair symbols from the same source symbols. Appendix A gives test vectors that tell this construction apart from the others.

5.2. Parameters

As for RaptorQ (Section 6.1), no decoder configuration is carried on the wire, and the code has no OTI to carry. When an instance's scheme is "reed-solomon", receivers MUST configure the decoder of each FEC block from the instance's configuration ([MOQ-FEC-CORE] Section 10.1) and the block's Repair FEC Payload ID ([MOQ-FEC-CORE] Section 7.5), under the source symbol construction of the instance's block profile ([MOQ-FEC-CORE] Section 5.2), as follows:

  • Symbol size: T = symbolSize. Every source and repair symbol is exactly T bytes. The RaptorQ rule that T is a multiple of 8 (Section 6.1) does not apply.
  • Rows: SSB_length, the block's source symbol count. The source symbol whose SS_ID is x is row (x - SS_Start) mod 2^32 of A, which is its ESI ([MOQ-FEC-CORE] Section 5.5).
  • Columns: the repair symbol whose RS_ID is j is column j of A. Its ESI, SSB_length + RS_ID (Section 9), still identifies it within its block, but the column depends on RS_ID alone.
  • Column count: RSB_length, the instance's total repair count P ([MOQ-FEC-CORE] Section 7.5).

This derivation is normative and complete: a receiver that has an instance's configuration requires no additional signaling to configure its decoder ([MOQ-FEC-CORE] Section 4.2, requirement 5). As under RaptorQ, its per-block inputs travel in the Repair FEC Payload ID of every repair object of the block.

The configuration keeps every FEC instance under "reed-solomon" within the bound of Section 5.1: K + P is at most 255, where K is the instance's sourceSymbols and P its total repair count over all its repair layers (Section 7). SSB_length + RSB_length is then at most 255 in every block. In addition to the checks of [MOQ-FEC-CORE] Section 5.4, a receiver MUST discard a repair object of such an instance whose SSB_length + RSB_length exceeds 255, or whose RS_ID is not less than RSB_length, leaving the state of every block unchanged. Neither object carries a symbol of a code that Section 5.1 defines. A repair object whose RSB_length is less than O_i + P_i for a layer i that the receiver holds goes to one of two rules. When the object is on that layer's own track, i above 0, or belongs to a block to which the check of [MOQ-FEC-CORE] Section 7.3.2 applies, that check handles it: it fails closed and stops FEC for the instance. Otherwise this rule applies, and the receiver discards the object only if it breaks one of the two conditions above. Such an object is one of a block generated before an append, carrying no symbol of layer i, or one of layer 0's track generated under a previous total ([MOQ-FEC-CORE] Section 7.3.2).

Repair layers ([MOQ-FEC-CORE] Section 7.3) carry disjoint ranges of columns: layer i carries columns O_i to O_i + P_i - 1 ([MOQ-FEC-CORE] Section 7.3.1). A column depends on its RS_ID alone, so a repair symbol is the same whichever layer carries it and whatever other layers exist, and symbols from any subset of layers combine in one decode. Each FEC instance of a source track, including an instance that overlaps another ([MOQ-FEC-CORE] Section 8.4), has its own rows, numbered from its own SS_IDs, its own columns and its own bound: K + P is at most 255 in each instance, whatever another instance of the track uses.

For example, this configuration, shown in the shape of the catalog binding ([MOQ-FEC-CATALOG]), protects a LOC video track under "reed-solomon":

{
  "version": 1,
  "tracks": [
    {
      "name": "video",
      "packaging": "loc",
      "isLive": true,
      "codec": "avc1.64001f",
      "width": 1280,
      "height": 720,
      "framerate": 30,
      "bitrate": 2500000,
      "fec": [
        {
          "instanceId": 0,
          "scheme": "reed-solomon",
          "blockProfile": "moq-object-v1",
          "sourceSymbols": 32,
          "repairSymbols": 8,
          "symbolSize": 1320,
          "interleaveDepthMs": 200,
          "reorderToleranceMs": 40,
          "repairTrack": "video/repair"
        }
      ]
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "isLive": true,
      "source": "video",
      "instanceId": 0,
      "repairLayer": 0,
      "repairSymbols": 8,
      "priority": 240
    }
  ]
}

K + P is 32 + 8 = 40, within the bound. A full block uses rows 0 to 31 and columns 0 to 7 of A, and its repair objects carry SSB_length 32 and RSB_length 8. A short block of 20 source symbols uses rows 0 to 19 and the same columns, and its repair objects carry SSB_length 20. The repair symbol with RS_ID 3 is column 3 in both blocks, at ESI 35 in the first and ESI 23 in the second. The full block recovers once the receiver holds any 32 of its 40 symbols, and the short block once it holds any 20 of its 28. The bound of Section 7 leaves room for repair layers ([MOQ-FEC-CORE] Section 7.3.2) of at most 215 more repair symbols in all, since 32 + 8 + 215 = 255, and [MOQ-FEC-CORE] Section 14.4 recommends far fewer.

6. RaptorQ

6.1. Object Transmission Information

An RFC 6330 decoder is configured by the Object Transmission Information (OTI): the 8-byte Common FEC OTI (Section 3.3.2 of [RFC6330]) and the 4-byte Scheme-Specific FEC OTI (Section 3.3.3 of [RFC6330]), totaling 12 bytes:

RaptorQ OTI {
  Transfer Length (40),
  Reserved (8),
  Symbol Size (16),
  Number of Source Blocks (8),
  Number of Sub-Blocks (16),
  Symbol Alignment (8),
}

This specification does not carry the OTI on the wire. When an instance's scheme is "raptorq", receivers MUST construct the OTI of each FEC block from the instance's configuration ([MOQ-FEC-CORE] Section 10.1) and the block's SSB_length, which every repair object of the block carries ([MOQ-FEC-CORE] Section 7.5), under the source symbol construction of the instance's block profile ([MOQ-FEC-CORE] Section 5.2), as follows:

  • Transfer Length: F = SSB_length x T, where SSB_length is the block's source symbol count and T is symbolSize, exact because every source symbol of a block profile is exactly T bytes. It is never computed from the cumulative size of source objects, which a receiver that has lost objects could not know, and never from sourceSymbols, which bounds SSB_length but is not the size of any particular block ([MOQ-FEC-CORE] Section 5.4). From this F an [RFC6330] decoder derives that document's K as SSB_length, and from K its own K' ([RFC6330] Section 5.3.1).
  • Symbol Size: T = symbolSize.
  • Number of Source Blocks: Z = 1. Each FEC block is decoded as an independent RFC 6330 object containing a single source block. Blocks are identified by the SS_Start of the Repair FEC Payload ID of repair objects, and source symbols are placed in them by SS_ID ([MOQ-FEC-CORE] Section 5.5) -- not by the RFC 6330 Z partitioning.
  • Number of Sub-Blocks: N = 1. Sub-blocking is not used; the MMTP block profile states the same for its sub-block mode ([MOQ-MMT] Section 7.1).
  • Symbol Alignment: Al = 8. symbolSize MUST be a multiple of 8 (Section 7).

This derivation is normative and complete: a receiver that has an instance's configuration requires no additional signaling to configure its decoder ([MOQ-FEC-CORE] Section 4.2, requirement 5). Its one per-block input, SSB_length, travels in the Repair FEC Payload ID of every repair object of the block, so a receiver holding any repair symbol of a block holds the block's SSB_length.

Under "raptorq", a block of SSB_length source symbols is an [RFC6330] source block whose K, in the notation of [RFC6330], is SSB_length; the K of [MOQ-FEC-CORE] is the configured bound instead. The extension of that source block to K' symbols by padding ([RFC6330] Section 5.3.1) happens inside the encoder and the decoder and is not visible on the wire, and this document defines no K' of its own.

The Symbol Alignment does not affect the symbols. In [RFC6330] Al governs only the division of a symbol into sub-symbols across the N sub-blocks (its Section 4.4.1.2), and with N = 1 every symbol is one contiguous run of T bytes whatever Al is. A library that fixes Al at another value, such as 1, therefore produces the same source and repair symbols for the same F, T and K, and conforms to this document; the Al = 8 of the derived OTI records that symbolSize is a multiple of 8 (Section 7), and nothing else depends on it.

For example, for an instance with K = 32 and T = 1312, a full block (SSB_length = K = 32) has Transfer Length F = SSB_length x T = 32 x 1312 = 41,984 bytes, Symbol Size T = 1312, Z = 1, N = 1, Al = 8. No in-session message is required.

7. Scheme Bounds

[MOQ-FEC-CORE] Section 4.2, requirement 6, asks a scheme to state the largest K, the largest SSB_length + RSB_length and the largest RS_ID that its construction supports, and [MOQ-FEC-CORE] Section 10.3 applies those bounds to a configuration before FEC starts. This section is the one place that states them for the two schemes of this document. A receiver rejects a configuration, and discards a repair object, outside them ([MOQ-FEC-CORE] Sections 10.3 and 7.5).

Under "reed-solomon":

Under "raptorq":

8. Repair Layers

Both schemes support repair layers ([MOQ-FEC-CORE] Section 7.3). Layering needs a code whose repair symbols are identified by ESI alone and whose repair symbol for a given ESI does not depend on how many repair symbols the block generates in total. Only then do repair symbols from disjoint ESI ranges on separate tracks remain symbols of one code, and only then can a receiver add a layer without the publisher re-encoding. RaptorQ has this property by construction, through its open Encoding Symbol ID space ([RFC6330]). The property is not particular to fountain codes. A systematic Reed-Solomon code whose generator matrix is Vandermonde-derived ([RFC5510] Section 8.2.1) or Cauchy-derived has it too, provided the field element that defines each repair column is fixed by the symbol's index in the code and never by P. [RFC5510] fixes it as alpha^j for the Encoding Symbol ID j, so a repair column is fixed by SSB_length and RS_ID together, through ESI = SSB_length + RS_ID. The Cauchy construction of Section 5.1 fixes y_j as alpha^j for RS_ID j, so a repair column is fixed by RS_ID alone. Each repair symbol is then one fixed column of that matrix, independent of the code length n = K + P, and the field size is the only bound: K + P is at most 2^m - 1 over GF(2^m) for the [RFC5510] construction, and at most 2^m for a Cauchy construction in general. The construction of Section 5.1, whose x_i and y_j are nonzero powers of alpha, allows 2^m - 1, that is 255. A Reed-Solomon code in generator-polynomial form lacks the property: its parity is the remainder modulo a polynomial of degree n - K, so its symbols for one P are not valid for another.

The "reed-solomon" code of Section 5.1 meets the conditions of [MOQ-FEC-CORE] Section 4.2 for a scheme that supports layers: column j of A depends on RS_ID j alone, through y_j = alpha^j, and not on P or on SSB_length; layer i carries columns O_i to O_i + P_i - 1 (Section 5.2); and Section 7 bounds K + P by 255 for each FEC instance. Under "raptorq", layer i carries, for every block, the repair symbols whose Encoding Symbol IDs are SSB_length + O_i to SSB_length + O_i + P_i - 1 of the block's [RFC6330] source block (Section 9), and Section 7 bounds K.

A receiver that has subscribed a set of layers recovers a block whenever the number of lost symbols, source and repair together, does not exceed C - e, where C is the total P over the layers it holds and e is the decoding overhead of the instance's scheme: 0 under "reed-solomon", which is maximum distance separable (Section 5.1), and under "raptorq" a small number of symbols (roughly 1e-2, 1e-4, and 1e-6 residual failure at 0, 1, and 2 symbols of overhead per [RFC6330]).

9. Repair Symbols

For RaptorQ, repair symbols are generated per [RFC6330] Section 5.3. The source symbols of a block occupy ESIs 0 to SSB_length - 1 in SS_ID order, and the Encoding Symbol ID (ESI) of a repair symbol starts at SSB_length, the block's K in the notation of [RFC6330] ([RFC6330] Section 5.3.1): ESI = SSB_length + RS_ID, both fields taken from the Repair FEC Payload ID ([MOQ-FEC-CORE] Section 7.5). The Internal Symbol IDs of [RFC6330], which start the repair symbols at that document's K', are internal to its encoder and decoder and never appear on the wire.

For Reed-Solomon, repair symbols are generated per Section 5.1. Source and repair symbols carry the same ESIs as under RaptorQ, so ESI = SSB_length + RS_ID still identifies a repair symbol within its block, but the code takes the symbol's column of A from its RS_ID alone (Section 5.2).

Under "raptorq" the block is a RaptorQ source block of SSB_length source symbols, whose decoder is configured with F = SSB_length x T (Section 6.1); under "reed-solomon" SSB_length is the number of rows of A that the block uses (Section 5.2).

A short source block ([MOQ-FEC-CORE] Section 5.4) is encoded as a block of its SSB_length source symbols, at ESIs 0 to SSB_length - 1 in SS_ID order: under "raptorq" a RaptorQ source block with F = SSB_length x T (Section 6.1), and under "reed-solomon" the first SSB_length rows of A (Section 5.1). No padding symbol is transmitted, and none is counted in SSB_length or F. The padding of the block to K' symbols in the notation of [RFC6330] ([RFC6330] Section 5.3.1) is part of RaptorQ encoding and decoding, performed inside the encoder and the decoder. A short block is recoverable once the source and repair symbols the receiver holds together number at least SSB_length, plus the decoding overhead of Section 8, which is zero under "reed-solomon".

10. Mandatory-to-Implement Scheme

Reed-Solomon is the mandatory-to-implement FEC scheme: an implementation that performs FEC decoding under [MOQ-FEC-CORE] MUST support "reed-solomon", which Section 5 fully specifies. "raptorq" is OPTIONAL.

The MMT AL-FEC framework on which the MMTP block profile of [MOQ-MMT] rests ([ISO.23008-1] Annex C) requires no FEC code: it carries whichever code the AL-FEC message names by its [ISO.23008-10] code point, and ATSC 3.0, which applies AL-FEC to an MMTP session through that framework, requires none either ([ATSC-A331] Section 8.1.2.5; [MOQ-MMT] Section 10). This document therefore specifies the codes it uses. Reed-Solomon is the mandatory scheme because it is small to implement, recovers a block from exactly SSB_length of its symbols, and is a code of that framework ([ISO.23008-10] code point 1). RaptorQ stays specified, code point 3, for its block size: it serves every block size this document allows. A RaptorQ block holds up to 56403 source symbols (Section 7), while a Reed-Solomon block holds at most 255 source and repair symbols. At 8 Mb/s with symbols of 1200 bytes, 255 symbols are about 300 ms, and a Reed-Solomon block's 255 - P source symbols span less than that, so the multi-second interleave windows of [MOQ-FEC-CORE] Section 9.3 need RaptorQ at that rate.

A receiver that does not implement the scheme of an FEC instance forgoes FEC for that instance, as [MOQ-FEC-CORE] Section 4.5 specifies; an instance under "raptorq" is therefore protected only for the receivers that implement it.

11. Security Considerations

The security considerations of [MOQ-FEC-CORE] apply. [MOQ-FEC-CORE] Section 14.3 bounds a receiver's work per instance; this section gives the Reed-Solomon figures. Under "raptorq" the cost of decoding a block is that of an [RFC6330] decoder for a source block of SSB_length symbols of T bytes (Section 6.1), which [RFC6330] Section 5.4 describes; this document gives no closer figure.

The configuration bounds the cost of "reed-solomon" decoding. A block has at most 255 source and repair symbols (Section 7), so the number of source symbols a receiver recovers in it, E, is at most min(SSB_length, RSB_length), which is at most 127. The receiver inverts one E x E matrix per block and performs about E x SSB_length x T multiplications in GF(2^8) to form and apply the result (Section 5.1). One open block holds at most 255 x T bytes of symbols.

The code provides no integrity protection, as RaptorQ provides none ([MOQ-FEC-CORE] Section 14.2). A decoder that is given a corrupted or injected symbol yields wrong source symbols and reports no error, and when it decodes from exactly SSB_length symbols the code itself cannot reveal the error. The checks of the block profile ([MOQ-FEC-CORE] Section 9.2 for "moq-object-v1", and [MOQ-MMT] Section 7.1 for MMTP packets) reject some wrong results. A receiver that holds more than SSB_length symbols of a block can also re-encode the recovered block and compare the result with the symbols it did not use: a mismatch shows that some symbol it holds is not what the publisher encoded.

12. IANA Considerations

This document requests the registration of two entries in the "MoQ FEC Schemes" registry that [MOQ-FEC-CORE] Section 15.2 creates:

Table 1
Identifier Class Layers Reference
"reed-solomon" block yes [ISO.23008-10] Clause 6; this document, Section 5
"raptorq" block yes [RFC6330]; this document, Section 6

The Identifier is the string that the scheme parameter of an FEC instance carries ([MOQ-FEC-CORE] Section 10.1). When reviewing a registration in that registry, the designated expert checks that the specification gives the scheme's symbol construction, the derivation of its decoder parameters from the configuration and the Repair FEC Payload ID, and the semantics of its repair objects ([MOQ-FEC-CORE] Section 4.2), and that it states whether the scheme admits repair layers ([MOQ-FEC-CORE] Section 7.3).

13. References

13.1. Normative References

[ISO.23008-10]
ISO/IEC, "Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 10: MPEG media transport forward error correction (FEC) codes", ISO/IEC 23008-10:2015, .
[MOQ-FEC-CORE]
Ramadan, O. and M. E. Fiuczynski, "Forward Error Correction for Media over QUIC: Core Mechanism", Work in Progress, Internet-Draft, draft-ramadan-moq-fec-core-00, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-fec-core-00>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6330]
Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", RFC 6330, DOI 10.17487/RFC6330, , <https://www.rfc-editor.org/info/rfc6330>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

13.2. Informative References

[ATSC-A331]
ATSC, "Signaling, Delivery, Synchronization, and Error Protection", ATSC A/331:2026-02, , <https://www.atsc.org/atsc-documents/3312017-signaling-delivery-synchronization-error-protection/>.
[I-D.ramadan-moq-fec]
Ramadan, O., "Forward Error Correction for Media over QUIC", Work in Progress, Internet-Draft, draft-ramadan-moq-fec-01, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-fec-01>.
[ISO.23008-1]
ISO/IEC, "Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 1: MPEG media transport (MMT)", ISO/IEC 23008-1:2023, .
[MOQ-FEC-CATALOG]
Ramadan, O., "Catalog Binding for Forward Error Correction in Media over QUIC", Work in Progress, Internet-Draft, draft-ramadan-moq-fec-catalog-00, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-fec-catalog-00>.
[MOQ-FEC-MULTICAST]
Ramadan, O., "Forward Error Correction for Multicast Delivery of Media over QUIC", Work in Progress, Internet-Draft, draft-ramadan-moq-fec-multicast-00, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-fec-multicast-00>.
[MOQ-MMT]
Ramadan, O., "MPEG Media Transport (MMT) Packaging for Media over QUIC", Work in Progress, Internet-Draft, draft-ramadan-moq-mmt-02, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-mmt-02>.
[RFC5510]
Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, DOI 10.17487/RFC5510, , <https://www.rfc-editor.org/info/rfc5510>.

Appendix A. Reed-Solomon Test Vectors

This appendix is informative. It gives values of the reed-solomon code of Section 5.1, so that an implementation can check its field arithmetic, its matrix A and the order of its symbols. Bytes are in hexadecimal, and a symbol is written as its T bytes in order. Two separate implementations of Section 5.1 computed these values. They have not been checked against an implementation of [ISO.23008-10].

The field. The powers of alpha fix the polynomial (alpha^8 = 1d) and the representation of elements as bytes (alpha^7 = 80):

{
  "vector": "field",
  "polynomial": "11d",
  "alphaPowers": {"0": "01", "1": "02", "7": "80", "8": "1d",
                  "9": "3a", "254": "8e", "255": "01"},
  "inverses": {"02": "8e", "03": "f4", "1d": "83"}
}

Entries of A, with the x_i and y_j that define them. A_{253,0} and A_{0,253} lie at the edge of the bound: a block that uses either has SSB_length + RSB_length = 255.

{
  "vector": "matrix",
  "entries": [
    {"i": 0, "j": 0, "x": "8e", "y": "01", "A": "f5"},
    {"i": 0, "j": 1, "x": "8e", "y": "02", "A": "53"},
    {"i": 1, "j": 0, "x": "47", "y": "01", "A": "a6"},
    {"i": 1, "j": 1, "x": "47", "y": "02", "A": "4e"},
    {"i": 3, "j": 2, "x": "d8", "y": "04", "A": "99"},
    {"i": 31, "j": 7, "x": "09", "y": "80", "A": "31"},
    {"i": 253, "j": 0, "x": "02", "y": "01", "A": "f4"},
    {"i": 0, "j": 253, "x": "8e", "y": "47", "A": "f7"}
  ]
}

A block of four one-byte source symbols, and its repair symbols at RS_IDs 0 to 2:

{
  "vector": "encode",
  "T": 1,
  "SSB_length": 4,
  "source": ["01", "02", "03", "04"],
  "RS_ID": [0, 1, 2],
  "repair": ["cc", "ce", "83"]
}

A short block. K is 8, and the block holds three two-byte source symbols. Its repair symbols are also those of a full block of eight source symbols whose last five are zero. A receiver that holds the source symbol at ESI 0 and both repair symbols recovers the source symbols at ESIs 1 and 2:

{
  "vector": "short-block",
  "T": 2,
  "K": 8,
  "SSB_length": 3,
  "source": ["0102", "0304", "0506"],
  "RS_ID": [0, 1],
  "repair": ["d43a", "d016"],
  "received": {"ESI": [ 0 ], "RS_ID": [0, 1]},
  "recovered": ["0304", "0506"]
}

Two repair layers over the block of the third vector, with K = 4. Layer 0 carries RS_IDs 0 and 1 (P_0 = 2, O_0 = 0), and layer 1 carries RS_IDs 2 and 3 (P_1 = 2, O_1 = 2), so RSB_length is 4. The symbols at RS_IDs 0 to 2 equal those of the third vector, whose block has a total repair count of 3: a column does not depend on P. A receiver that holds layer 1 alone, with the source symbols at ESIs 0 and 3, recovers the source symbols at ESIs 1 and 2:

{
  "vector": "layers",
  "T": 1,
  "K": 4,
  "SSB_length": 4,
  "RSB_length": 4,
  "source": ["01", "02", "03", "04"],
  "layers": [
    {"repairLayer": 0, "RS_ID": [0, 1], "repair": ["cc", "ce"]},
    {"repairLayer": 1, "RS_ID": [2, 3], "repair": ["83", "20"]}
  ],
  "received": {"ESI": [0, 3], "RS_ID": [2, 3]},
  "recovered": ["02", "03"]
}

Appendix B. RaptorQ Test Vectors

This appendix is informative. It gives values of the "raptorq" scheme for a full block and a short block of one instance, so that an implementation of [RFC6330] can check the OTI that Section 6.1 derives from the instance's configuration and the block's SSB_length, and the Encoding Symbol ID that Section 9 gives each RS_ID. Bytes are in hexadecimal, and a symbol is written as its T bytes in order. [RFC6330] fixes the symbols themselves, and independent implementations of it agree on these values.

A full block of four 8-byte source symbols (K = SSB_length = 4 and T = 8, the least symbol size of Section 7), and its repair symbols at RS_IDs 0 to 2. The derived OTI is F = 32, T = 8, Z = 1, N = 1, Al = 8. The encoder extends the block to K' = 10 symbols internally ([RFC6330] Section 5.3.1 and Table 2); the repair symbol at RS_ID j has ESI = SSB_length + j on the wire and, inside [RFC6330], ISI = ESI + K' - K:

{
  "vector": "raptorq-encode",
  "T": 8,
  "SSB_length": 4,
  "OTI": {"F": 32, "T": 8, "Z": 1, "N": 1, "Al": 8},
  "Kprime": 10,
  "source": ["0102030405060708", "090a0b0c0d0e0f10",
             "1112131415161718", "191a1b1c1d1e1f20"],
  "RS_ID": [0, 1, 2],
  "ESI": [4, 5, 6],
  "ISI": [10, 11, 12],
  "repair": ["b5f2cf7c41063b7d", "3f1e015c43627db5",
             "16ecba0553a9ff31"]
}

A short block ([MOQ-FEC-CORE] Section 5.4) of the same instance: K = 4 and T = 8 as above, but the block holds SSB_length = 3 source symbols, the first three of the full block above. The derived OTI is F = SSB_length x T = 24, T = 8, Z = 1, N = 1, Al = 8, so an [RFC6330] decoder derives K = 3 and, as above, K' = 10: the encoder pads the block to K' with seven zero symbols rather than six, and the repair symbols differ from those of the full block at the same ISIs. The repair symbol at RS_ID j has ESI = SSB_length + j = 3 + j on the wire and ISI = ESI + K' - K = 10 + j. A receiver that holds the source symbols at ESIs 0 and 2 and the repair symbol at RS_ID 0 recovers the source symbol at ESI 1:

{
  "vector": "raptorq-short-block",
  "T": 8,
  "K": 4,
  "SSB_length": 3,
  "OTI": {"F": 24, "T": 8, "Z": 1, "N": 1, "Al": 8},
  "Kprime": 10,
  "source": ["0102030405060708", "090a0b0c0d0e0f10",
             "1112131415161718"],
  "RS_ID": [0, 1, 2],
  "ESI": [3, 4, 5],
  "ISI": [10, 11, 12],
  "repair": ["8323437e1ebede12", "21635de7d99ba5e1",
             "7fc8a5bbd6610c02"],
  "received": {"ESI": [0, 2], "RS_ID": [0]},
  "recovered": ["090a0b0c0d0e0f10"]
}

Appendix C. Changes from draft-ramadan-moq-fec-01

This appendix is informative. It lists what this document takes from [I-D.ramadan-moq-fec] (the "-01" below), and every sentence that is new or changed rather than moved.

What moved here, by -01 section:

Changes to carried text:

New sentences (bridging text that a stand-alone document needs; none adds a requirement beyond those of -01 and the core):

Acknowledgements

The split of [I-D.ramadan-moq-fec] into a core mechanism and companion documents follows a proposal by Marc E. Fiuczynski. Two separate implementations of the Reed-Solomon code computed the test vectors of Appendix A.

Portions of this document were drafted with the assistance of AI tools. The author reviewed, edited and takes responsibility for all of its content.

Author's Address

Omar Ramadan
Blockcast