Blockcast

omar@blockcast.net

wit moq FEC MoQ Reed-Solomon RaptorQ erasure code 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.

Introduction 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 , which is mandatory to implement, and RaptorQ , which is optional. For each it gives the scheme identifier (), the derivation of the decoder's parameters (, ), the bounds the scheme imposes on a configuration and on a repair object (), how its repair symbols are numbered and generated () and how it supports repair layers (). For Reed-Solomon it also restates the code (), because is not freely available, and gives test vectors ().

Relation to Other Documents This document is one of a set. 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. encodes that data model in the MSF and CMSF catalogs. 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. covers multicast delivery of protected tracks. The text of this document is taken from ; lists what moved here and what changed.

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 when, and only when, they appear in all capitals, as shown here. This document uses the terms of 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 ( 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 ( 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 ( 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 ( Section 7.5). FEC Block: The combination of SSB_length source symbols and P repair symbols; the ISO encoding symbol block ( 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 ( 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 ( 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 ( Section 7.3.1). Object Transmission Information (OTI): Parameters required to configure a RaptorQ decoder, as defined in . Block Profile: The rules that fix how source symbols are formed from source objects and how blocks are delimited and identified ( Section 5.2). K, P and T denote an instance's sourceSymbols, its total repair count over all its repair layers, and its symbolSize ( Section 10.1); P_i is the repair count of layer i.

Scheme Identifiers FEC scheme identifiers are registered in the "MoQ FEC Schemes" registry ( Section 15.2); the scheme parameter of an FEC instance ( Section 10.1) carries the string identifier, and the catalog binding encodes it ( Section 3.1). This document defines two: "raptorq": RaptorQ fountain code per . Can recover from loss of any symbols as long as SSB_length symbols (source or repair), plus a small decoding overhead (), are received. It is OPTIONAL (). "reed-solomon": The systematic Reed-Solomon erasure code over GF(2^8) of Clause 6, restated in . 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 (). It is the mandatory-to-implement scheme (). 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 Table 1, which an AL-FEC message carries in fec_code_id_for_repair_flow ( Section 8.3).

Requirements of the Core Met by These Schemes 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 (). "raptorq" can recover from loss of any symbols as long as SSB_length symbols (source or repair), plus a small decoding overhead, are received (; ).
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 (). Under "reed-solomon" the source symbols themselves are sent unchanged (); under "raptorq" they occupy ESIs 0 to SSB_length - 1 of the source block ().
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 (); "reed-solomon" imposes no alignment ().
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 ().
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: derives the RaptorQ OTI, and the Reed-Solomon parameters.
6. Stated bounds. 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 ().
8. Deterministic and verifiable. Both codes are deterministic: fixes the field, the generator matrix and the order of symbols, and fixes every table and index of RaptorQ. gives test vectors that tell the Reed-Solomon construction of this document apart from other systematic Reed-Solomon constructions over GF(2^8). gives RaptorQ test vectors that fix, for a block of this document, the OTI that derives and the Encoding Symbol ID that gives each RS_ID.

Both schemes support repair layers (), which 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 . states the decoding cost of "reed-solomon" and, for "raptorq", points at the decoder of .

Reed-Solomon

The Code The "reed-solomon" scheme is the systematic Reed-Solomon erasure code over GF(2^8) of Clause 6, to which that document assigns FEC code point 1 (its Table 1). This section restates the code, because is not freely available. If this restatement and Clause 6 differ, governs. 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 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 ( 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 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 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 ( 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 Section 8.4 applies its code to symbols: for each byte position u from 0 to T - 1, 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 ( Section 5.4). Decoding. Every square submatrix of a Cauchy matrix is invertible ( 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: 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 , but the generator matrix is not the Vandermonde-derived matrix of Section 8.2, and this document uses neither the FEC Payload IDs nor the source block partitioning of . Several systematic Reed-Solomon constructions over GF(2^8) are in use, and they produce different repair symbols from the same source symbols. gives test vectors that tell this construction apart from the others.

Parameters As for RaptorQ (), 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 ( Section 10.1) and the block's Repair FEC Payload ID ( Section 7.5), under the source symbol construction of the instance's block profile ( 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 () 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 ( Section 5.5).
• Columns: the repair symbol whose RS_ID is j is column j of A. Its ESI, SSB_length + RS_ID (), 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 ( 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 ( 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 : K + P is at most 255, where K is the instance's sourceSymbols and P its total repair count over all its repair layers (). SSB_length + RSB_length is then at most 255 in every block. In addition to the checks of 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 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 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 ( Section 7.3.2). Repair layers ( Section 7.3) carry disjoint ranges of columns: layer i carries columns O_i to O_i + P_i - 1 ( 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 ( 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 (), protects a LOC video track under "reed-solomon": 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 leaves room for repair layers ( Section 7.3.2) of at most 215 more repair symbols in all, since 32 + 8 + 215 = 255, and Section 14.4 recommends far fewer.

RaptorQ

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 ) and the 4-byte Scheme-Specific FEC OTI (Section 3.3.3 of ), totaling 12 bytes: 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 ( Section 10.1) and the block's SSB_length, which every repair object of the block carries ( Section 7.5), under the source symbol construction of the instance's block profile ( 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 ( Section 5.4). From this F an decoder derives that document's K as SSB_length, and from K its own K' ( 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 ( 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 ( Section 7.1).
• Symbol Alignment: Al = 8. symbolSize MUST be a multiple of 8 ().

This derivation is normative and complete: a receiver that has an instance's configuration requires no additional signaling to configure its decoder ( 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 source block whose K, in the notation of , is SSB_length; the K of is the configured bound instead. The extension of that source block to K' symbols by padding ( 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 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 (), 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.

Scheme Bounds 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 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 ( Sections 10.3 and 7.5). Under "reed-solomon":

• K + P is at most 255 for each FEC instance: its sourceSymbols plus the repairSymbols of all its repair layers. Every entry of A that a block of the instance uses is then defined (). SSB_length + RSB_length is therefore at most 255 in every block, and the largest RS_ID, RSB_length - 1, is at most 253.
• A publisher that appends a repair layer MUST keep the instance within this bound with the new total ( Section 7.3.2).
• T is at least 1, and no alignment applies ().

Under "raptorq":

• K is at most 56403 for each FEC instance. extends a source block of K source symbols to K' symbols, the smallest value at least K in its Table 2 ( Section 5.3.1), and 56403 is the largest such value, K'_max ( Section 5.1.2), so a RaptorQ source block holds at most 56403 source symbols.
• symbolSize is a multiple of 8, the fixed Symbol Alignment of the derived OTI (), so the least T this scheme admits is 8. A block profile can place a larger floor on T, as the MMTP block profile does ( Section 7.1); that floor is the profile's rule, not a bound of this scheme, and under it the least T is the smallest multiple of 8 at or above the floor. A RaptorQ symbol size off the Symbol Alignment fits no derived OTI.
• The largest Encoding Symbol ID of is 2^24 - 1 (its Section 3.2), the bound that Section 10.3 already places on K + P - 1 for every scheme, so "raptorq" adds no bound of its own on SSB_length + RSB_length or on RS_ID.

Repair Layers Both schemes support repair layers ( 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 (). The property is not particular to fountain codes. A systematic Reed-Solomon code whose generator matrix is Vandermonde-derived ( 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. 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 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 construction, and at most 2^m for a Cauchy construction in general. The construction of , 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 meets the conditions of 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 (); and 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 source block (), and 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 (), 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 ).

Repair Symbols For RaptorQ, repair symbols are generated per 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 ( Section 5.3.1): ESI = SSB_length + RS_ID, both fields taken from the Repair FEC Payload ID ( Section 7.5). The Internal Symbol IDs of , 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 . 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 (). Under "raptorq" the block is a RaptorQ source block of SSB_length source symbols, whose decoder is configured with F = SSB_length x T (); under "reed-solomon" SSB_length is the number of rows of A that the block uses (). A short source block ( 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 (), and under "reed-solomon" the first SSB_length rows of A (). 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 ( 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 , which is zero under "reed-solomon".

Mandatory-to-Implement Scheme Reed-Solomon is the mandatory-to-implement FEC scheme: an implementation that performs FEC decoding under MUST support "reed-solomon", which fully specifies. "raptorq" is OPTIONAL. The MMT AL-FEC framework on which the MMTP block profile of rests ( Annex C) requires no FEC code: it carries whichever code the AL-FEC message names by its code point, and ATSC 3.0, which applies AL-FEC to an MMTP session through that framework, requires none either ( Section 8.1.2.5; 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 ( 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 (), 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 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 Section 4.5 specifies; an instance under "raptorq" is therefore protected only for the receivers that implement it.

Security Considerations The security considerations of apply. 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 decoder for a source block of SSB_length symbols of T bytes (), which 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 (), 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 (). One open block holds at most 255 x T bytes of symbols. The code provides no integrity protection, as RaptorQ provides none ( 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 ( Section 9.2 for "moq-object-v1", and 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.

IANA Considerations This document requests the registration of two entries in the "MoQ FEC Schemes" registry that Section 15.2 creates:

Identifier	Class	Layers	Reference
"reed-solomon"	block	yes	Clause 6; this document,
"raptorq"	block	yes	; this document,

The Identifier is the string that the scheme parameter of an FEC instance carries ( 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 ( Section 4.2), and that it states whether the scheme admits repair layers ( Section 7.3).

References Normative References ISO/IEC Blockcast Rutgers University Informative References ATSC ISO/IEC Blockcast Blockcast Blockcast

Reed-Solomon Test Vectors This appendix is informative. It gives values of the reed-solomon code of , 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 computed these values. They have not been checked against an implementation of . The field. The powers of alpha fix the polynomial (alpha^8 = 1d) and the representation of elements as bytes (alpha^7 = 80): 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. A block of four one-byte source symbols, and its repair symbols at RS_IDs 0 to 2: 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: 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:

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 can check the OTI that derives from the instance's configuration and the block's SSB_length, and the Encoding Symbol ID that gives each RS_ID. Bytes are in hexadecimal, and a symbol is written as its T bytes in order. 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 ), 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 ( Section 5.3.1 and Table 2); the repair symbol at RS_ID j has ESI = SSB_length + j on the wire and, inside , ISI = ESI + K' - K: A short block ( 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 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:

Changes from draft-ramadan-moq-fec-01 This appendix is informative. It lists what this document takes from (the "-01" below), and every sentence that is new or changed rather than moved. What moved here, by -01 section:

• -01 Section 2: the "Object Transmission Information (OTI)", "FEC Block" and "RS_ID Offset" definitions (), and the RaptorQ K' text of the "Source Block" definition ().
• -01 Section 4.1 (FEC Algorithms) is . The one-byte Value column of the -01 registry is gone, as it is in the core's registry, so the parenthetical values 0x01 and 0x02 are dropped.
• -01 Section 4.2 (RaptorQ Object Transmission Information) is , with the OTI numbers of -01 Appendix A.1 as its example.
• -01 Section 4.3 (Algorithm Requirements), lines on the mandatory-to-implement designation and the reasons for the two codes, is . The sentence closing the list of ISO/IEC 23008-10 codes to the two of -01, and the sentence on registered values other than "none", "raptorq" and "reed-solomon", are not carried: the core's scheme registration model replaces them. The paragraph on receivers that do not implement a scheme is in the core (Section 4.5); keeps one sentence that cites it.
• -01 Section 4.4 (Reed-Solomon Code) is .
• -01 Section 4.5 (Reed-Solomon Parameters) is .
• -01 Section 5.1, the clause that T is a multiple of 8 under "raptorq", the fixed Symbol Alignment of the derived OTI, and the least T it implies under each block profile, is in .
• -01 Section 6.3.2, the decoding-overhead numbers, and -01 Section 6.3.3, the scheme part (the index-fixed property as RaptorQ and the Cauchy construction have it, and the statement that "reed-solomon" meets the conditions for layers), are . The -01 conditions (a) to (d) are the core's (Section 4.2).
• -01 Section 6.3.4, rule 6 (K at most 56403 under "raptorq"), rule 12 (K + P at most 255 under "reed-solomon") and the scheme parts of rule 13 (T a multiple of 8 under "raptorq"), and -01 Section 6.3.9's clause that an append keeps a "reed-solomon" instance within rule 12, are .
• -01 Section 7.1, the RaptorQ and Reed-Solomon clauses of the SSB_length field definition, -01 Section 7.2 (Repair Symbols) and the RaptorQ and Reed-Solomon clauses of -01 Section 7.4 (Short Source Blocks) are ; the RaptorQ and Reed-Solomon clauses of the -01 Section 7.1 RS_ID field definition are not carried separately, since the two paragraphs from -01 Section 7.2 state the same.
• -01 Section 14.7 (Reed-Solomon Considerations) is .
• -01 Section 15.2, the "raptorq" and "reed-solomon" registry entries and the designated-expert guidance, is . The core creates the registry; this document registers the two schemes.
• -01 Appendix C (Reed-Solomon Test Vectors) is , unchanged.

Changes to carried text:

• Citations of -01 sections are re-pointed at the core, the catalog binding and the MMT draft. "Algorithm" is "scheme", "repair packet" is "repair object", and "the catalog fec object" and "catalog fields" are "the instance's configuration", following the core's data model. The scheme is named per FEC instance rather than per track.
• is an informative reference: this document cites it only to name the ISO encoding symbol block in the "FEC Block" definition, where -01 Section 2 wrote "(3.1.5)" alone, and for the AL-FEC framework in . -01 cited it normatively for its MMTP profile, which is now .
• The Reed-Solomon discard rule of -01 Section 4.5 is restated against the fail-closed check of the core (Section 7.3.2) in place of -01 Section 6.3.9, and its reference to "the checks of Section 7.4" at the core's short-block rules; the sentence that routes a repair object whose RSB_length is below O_i + P_i is written as two cases, one per rule.
• The 300 ms sentence of -01 Section 4.3, carried in , "such a block spans at most about 300 ms of media", now reads "255 symbols are about 300 ms, and a Reed-Solomon block's 255 - P source symbols span less than that", since 255 is the source-plus-repair ceiling.
• The keyframe-overlay sentence of -01 Section 4.5 is generalized to any FEC instance of a track, including an overlapping instance: "Each FEC instance of a source track, including an instance that overlaps another, 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."
• The -01 Section 4.5 example catalog, an MMTP track under "iso-ssbg1-v1", is re-rendered as a LOC track under "moq-object-v1" in the shape of the catalog binding, with the same K, P and T; the arithmetic that follows it is unchanged.
• In , "Catalog-signaled sessions do not use sub-blocking (Section 7.3)" is "Sub-blocking is not used; the MMTP block profile states the same for its sub-block mode", and "every source symbol of either block profile" is "every source symbol of a block profile".
• The "Subsets need not be prefixes" example of -01 Section 6.3.2, written against the -01 worked catalog, is not carried; the core states the rule.
• The -01 Section 6.3.3 sentence restricting repair layers and the overlay to the two codes is not carried; the core's validation rule replaces it.
• The -01 Section 7.2 sentence that repair symbol generation for other registered algorithms is not specified, and the -01 Section 6.3.3 sentence that a specification of another algorithm can admit repair layers and the overlay on the same terms, are not carried: the core's scheme registration model and validation rule replace them.
• In the designated-expert sentence of -01 Section 15.2 carried in , "(Section 4.3)" and "(Section 6.3.3)" are re-pointed at the core, and "and the keyframe overlay" is not carried: the keyframe overlay is the MMTP profile's ( Section 7.4).
• The "raptorq" clause of the symbolSize definition of -01 Section 5.1, which gave the least T as 8 under "moq-object-v1" and 16 under "iso-ssbg1-v1", is carried into reduced to this scheme's own bound, a least T of 8. The floor of 14 that "iso-ssbg1-v1" places on T, and the 16 that follows from it under "raptorq", are the MMTP block profile's rule and are stated by Section 7.1.

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

• The Abstract and the Introduction, including "Relation to Other Documents".
• In : the lead-in sentence on the core's terms, the "RSB_length" definition, and the sentence defining K, P, T and P_i.
• , entirely: it restates where each requirement of the core is established.
• , entirely: RaptorQ test vectors for a full block and a short block. -01 Appendix C gave test vectors for Reed-Solomon only; the core's requirement 8 asks for them of every registered scheme.
• In : the paragraph that the Symbol Alignment does not affect the symbols, so an implementation that fixes Al at another value conforms.
• In : the opening paragraph; "the largest RS_ID, RSB_length - 1, is at most 253"; "T is at least 1, and no alignment applies"; and the RaptorQ item on the 24-bit Encoding Symbol ID.
• In : the opening sentence, and the sentence mapping a "raptorq" layer's RS_ID range to Encoding Symbol IDs.
• In : the lead-in "A short source block ... is encoded as" that frames the carried short-block clauses.
• In : the sentence citing the core for unimplemented schemes.
• In : the opening paragraph.
• In : the request sentence and the Identifier sentence.

Acknowledgements The split of 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 . Portions of this document were drafted with the assistance of AI tools. The author reviewed, edited and takes responsibility for all of its content.