Forward Error Correction for Media over QUIC

4.1. FEC Algorithms

FEC algorithm values are registered in the "MoQ FEC Algorithms" registry (Section 15.2); the catalog (Section 5.1) carries the corresponding string identifiers.¶

RaptorQ (0x01): RaptorQ fountain code per [RFC6330]. Can recover from loss of any symbols as long as K symbols (source or repair) are received. It is the mandatory-to-implement scheme (Section 4.3).¶

Reed-Solomon (0x02): Reed-Solomon erasure code over GF(2^8) per [RFC5510]; an extension point not specified by this document (Section 4.3).¶

4.2. 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 [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 a track's catalog fec.algorithm is "raptorq", receivers MUST construct the OTI of each FEC block from the catalog fields (Section 5.1) and the block's SSB_length, which every repair packet of the block carries (Section 7.1), under the source symbol construction of Section 7.3, as follows:¶

• Transfer Length: F = SSB_length x T, where SSB_length is the block's source symbol count (Section 7.1) and T is symbolSize, exact because every source symbol of the construction of Section 7.3 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 7.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 of this specification 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 (Section 7.1), and source symbols are placed in them by SS_ID (Section 8.3) -- not by the RFC 6330 Z partitioning.¶
• Number of Sub-Blocks: N = 1. Catalog-signaled sessions do not use sub-blocking (Section 7.3).¶
• Symbol Alignment: Al = 8. symbolSize MUST be a multiple of 8.¶

This derivation is normative and complete: a receiver that has a track's catalog fec object requires no additional signaling to configure its decoder (Section 5.2). Its one per-block input, SSB_length, travels in the Repair FEC Payload ID of every repair packet of the block, so a receiver holding any repair symbol of a block holds the block's SSB_length.¶

4.3. Other FEC Algorithms

RaptorQ is the mandatory-to-implement FEC scheme: an implementation that performs FEC decoding under this specification MUST support "raptorq". It is also the only algorithm this document fully specifies.¶

The algorithm registry (Section 15.2) provides an extension point for additional schemes. In particular, "reed-solomon" (0x02) is allocated for a Reed-Solomon erasure code over GF(2^8) [RFC5510], but its symbol construction, parameter derivation, and repair object semantics are not specified by this document; a future companion specification is required before it can be used interoperably.¶

A receiver that does not implement a track's signaled fec.algorithm simply forgoes FEC protection for that track: it consumes the source track normally and does not subscribe to the repair track. Repair-track subscription is optional (Section 6.2), so an unrecognized or unimplemented algorithm is not an error.¶

5.1. Catalog Fields

The catalog (Section 5.2) is an MSF catalog [I-D.ietf-moq-msf], extended by the documents of this suite as described in [MOQ-MMT] Section 12, and is delivered on the track named catalog ([I-D.ietf-moq-msf] Section 5). This document adds one track-level field -- the fec object defined below -- and one packaging value (fec-repair, below). The FEC configuration is carried at the track level:¶

{
  "tracks": [
    {
      "name": "video",
      "packaging": "mmtp",
      "mmtpMode": "mfu",
      "timescale": 90000,
      "presentationAnchorTicks": 0,
      "groupDurationMs": 1000,
      "codec": "avc1.64001f",
      "width": 1920,
      "height": 1080,
      "framerate": 30,
      "fec": {
        "algorithm": "raptorq",
        "blockProfile": "iso-ssbg1-v1",
        "sourceSymbols": 625,
        "repairSymbols": 125,
        "symbolSize": 1000,
        "interleaveDepthMs": 1000,
        "reorderToleranceMs": 40,
        "repairTrack": "video/repair"
      }
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "depends": ["video"],
      "repairSymbols": 125,
      "priority": 240
    }
  ]
}

(Appendix B works this parameter set through in full.)¶

Field definitions:¶

algorithm (string, REQUIRED if fec present): FEC scheme identifier.¶

• "none": No FEC¶
• "raptorq": RaptorQ per RFC 6330 (mandatory to implement, Section 4.3)¶
• "reed-solomon": Reserved extension point (Section 4.3); not specified by this document¶

blockProfile (string, REQUIRED when algorithm is not "none"): The block profile of the track's FEC: the rules that fix how a source symbol is formed from a source packet, how many source symbols a block holds, how a block and the source symbols in it are identified, and how those identifiers wrap. It applies to every FEC instance of the source track, its repair layers (Section 6.3) and any keyframe overlay (Section 6.4) included, and a repair track carries no blockProfile of its own (Section 6.3.4, rule 8). A publisher MUST NOT change a published track's blockProfile; a different profile is a different rendition. A fec object whose algorithm is "none" declares no FEC instance and need not carry blockProfile. This document defines exactly one value:¶

• "iso-ssbg1-v1": the ISO/IEC 23008-1 Annex C profile of this document, all of whose rules a receiver applies together. A source symbol is the ssbg_mode1 framing of one FEC source packet (Section 7.3). A block holds SSB_length source symbols, with sourceSymbols as the upper bound on SSB_length (Section 7.4). SS_IDs advance by one per FEC source packet, blocks are consecutive, and a source symbol is placed in its block by range membership (Section 8.3). SS_ID arithmetic is modulo 2^32, and a block's repair objects are grouped under its 62-bit extended SS_Start (Section 7.5). An in-band AL-FEC message that describes such a track carries the coding byte 0x14 (Section 7.3).¶

A receiver MUST NOT apply FEC to a track whose blockProfile is absent or names a profile the receiver does not implement. It treats FEC as unavailable for that track, as for an unimplemented algorithm (Section 4.3): it consumes the source track without FEC and does not subscribe to or join the track's repair tracks, and it MUST NOT fail the session, or FEC for any other track, on that account. There is no default profile, and a receiver MUST NOT infer one from the wire, whether from the fields of an in-band AL-FEC message, from the length of the source packets it receives, or from any other observation.¶

sourceSymbols (integer, REQUIRED): K, the largest number of source symbols an FEC block may hold. MUST be >= 1. It is an upper bound, not the size of each block: a block holds SSB_length source symbols, 1 <= SSB_length <= K (Section 7.4). It is the value an in-band AL-FEC message carries as maximum_k_for_repair_flow ([ISO.23008-1] Clause C.6.3), which is likewise a maximum.¶

repairSymbols (integer, REQUIRED): P value - repair symbols per FEC block. MUST be >= 1 when a repair track is published.¶

symbolSize (integer, REQUIRED): T value - bytes per symbol. All symbols in a block have the same size; the byte layout of each source symbol is fixed by the track's blockProfile -- for "iso-ssbg1-v1", the ssbg_mode1 construction of Section 7.3, under which a source packet of up to T - 2 bytes is protected -- and is not otherwise carried in the catalog. For "raptorq", T is a multiple of 8, the fixed Symbol Alignment of the derived OTI (Section 4.2).¶

interleaveDepthMs (integer, OPTIONAL): When present, its value MUST be a non-negative integer. A value greater than zero is the complete FEC source/repair packet send span in milliseconds. It is the catalog form of protection_window_time in [ISO.23008-1] Sections 11.2 and C.6.3: the actual elapsed time from sending the first source or repair packet of a block to sending the last source or repair packet of that block MUST NOT exceed this value. For a positive value it is a duration, never a count of frames, groups, samples, or symbols, and never a per-symbol interval.¶

This field does not select FEC block boundaries, the number of source symbols in a block, the number of blocks in a MoQ Group, or the number of groups a block spans. Those are determined by the consecutive source SS_ID values and the (SS_Start, SSB_length) carried by the block's repair packets (Sections 7.4 and 8.3). A block MAY contain part of a Group, one Group, or several Groups, and a Group MAY contain more than one block.¶

Thus interleaveDepthMs and groupDurationMs are not inputs to block assignment; Section 8.3 specifies the source-symbol range and repair packet fields that assign a source symbol to a block.¶

When present with a value greater than zero, a publisher chooses this value to cover the actual source/repair send span of every block. An absent field supplies no catalog-signaled span. A value of zero has the ISO meaning of using protection_window_size instead of a time window [ISO.23008-1] Clause C.6.3; this catalog profile carries no packet-count window. A catalog-only receiver therefore MUST NOT treat zero as a zero-duration span or use it to derive a block count, and has no elapsed-time FEC deadline from this field. If an applicable ISO packet-count window is accepted in-band, it governs separate count-based processing; it does not supply a millisecond deadline, and the receiver MUST NOT assume a media cadence to convert it. Without an elapsed-time deadline, open-block state is bounded only by the local policy of Section 9, and on a multicast or AMT leg the receiver performs no block classification or unicast repair (Section 11.4) and keeps its repair-layer selection fixed (Section 6.3.6).¶

Note: the iso-ssbg1-v1 token is unchanged from an earlier revision of this document that derived the number D of Groups per block from this field and read an absent or zero value as one group duration (D = 1), so receivers implementing that derivation must change in lockstep with producers.¶

reorderToleranceMs (number, OPTIONAL): A receiver-local allowance for packet reordering, network jitter, and local processing variance, in milliseconds. When present, the value MUST be finite and MUST be greater than or equal to zero; fractional values are permitted. An explicit value of zero means that no additional allowance is required. An omitted field means that the publisher did not signal an allowance; receivers MUST preserve that distinction from an explicit zero.¶

For a receiver that uses a positive interleaveDepthMs, the FEC block deadline is the receiver-local timestamp of the first accepted packet plus the complete block span. When reorderToleranceMs is present, its catalog allowance is then added:¶

base_deadline = firstAcceptedAtMs + interleaveDepthMs
deadline = base_deadline + reorderToleranceMs  // when present

The catalog allowance is added exactly once when present. Its absence is not equivalent to an explicitly signaled zero; a receiver that applies an explicit local policy MUST keep that policy separate from the catalog value. When interleaveDepthMs is absent or zero, this formula supplies no elapsed-time FEC deadline; an applicable ISO packet-count window, if accepted in-band, remains separate count-based processing and is not converted to milliseconds. A receiver whose FEC deadline API requires a signaled allowance MUST reject or disable FEC for a track that omits reorderToleranceMs.¶

repairTrack (string, REQUIRED): Track name for repair symbols, following the convention in Section 6.1.¶

Repair tracks themselves are identified in the catalog by the packaging value "fec-repair": a track with "packaging": "fec-repair" carries repair objects (Section 7) for the source track whose fec.repairTrack field names it, and carries no directly renderable media. The value extends the allowed packaging values of [I-D.ietf-moq-msf] Section 5.2.4 in the same manner as the cmaf value of [I-D.ietf-moq-cmsf]; see Section 15.3. Receivers that do not implement this specification do not recognize the value and ignore such tracks.¶

enhancementRepair: Not defined. Repair layers and keyframe overlays are declared on their own repair-track entries (Section 5.1.1), and a catalog carrying this member is rejected under the exceptions there.¶

{
  "tracks": [
    {
      "name": "video",
      "packaging": "mmtp",
      "mmtpMode": "mfu",
      "timescale": 90000,
      "presentationAnchorTicks": 0,
      "groupDurationMs": 1000,
      "codec": "avc1.64001f",
      "width": 1920,
      "height": 1080,
      "framerate": 30,
      "fec": {
        "algorithm": "raptorq",
        "blockProfile": "iso-ssbg1-v1",
        "sourceSymbols": 64,
        "repairSymbols": 8,
        "symbolSize": 1200,
        "interleaveDepthMs": 200,
        "repairTrack": "video/repair"
      }
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "depends": ["video"],
      "repairLayer": 0,
      "repairSymbols": 8,
      "priority": 240
    },
    {
      "name": "video/repair/1",
      "packaging": "fec-repair",
      "depends": ["video"],
      "repairLayer": 1,
      "repairSymbols": 16,
      "priority": 244
    },
    {
      "name": "video/repair/2",
      "packaging": "fec-repair",
      "depends": ["video"],
      "repairLayer": 2,
      "repairSymbols": 32,
      "priority": 248
    },
    {
      "name": "video/repair/kf",
      "packaging": "fec-repair",
      "depends": ["video"],
      "scope": "keyframe",
      "sourceSymbols": 256,
      "repairSymbols": 32,
      "priority": 242
    }
  ]
}

5.2. Signaling Model

The catalog fec object (Section 5.1) is the authoritative FEC signaling for MoQ receivers, that is for every receiver that obtains the track's catalog entry. Such a receiver has everything needed to discover and subscribe to the repair track (Section 6) and to configure its decoder via the derived OTI (Section 4.2); no in-session signaling is required.¶

A packaging profile MAY also define in-band FEC signaling carried with the media, which serves a receiver that consumes a flow without the catalog. For the mmtp packaging this is the AL-FEC message of [ISO.23008-1] Clause C.6 ([MOQ-MMT] Sections 8 and 8.3). In-band FEC signaling MUST NOT signal FEC parameters that contradict the track's catalog fec object. Where the two disagree the catalog governs for a MoQ receiver, and a MoQ receiver MUST NOT require in-band signaling in order to configure its decoder.¶

The catalog's authority holds uniformly across a MoQ receiver's delivery paths, its multicast and AMT legs included. MoQ control messages cannot reach multicast or sessionless receivers at all (Section 11), so no control-message mechanism could serve as the common signaling path; the catalog can, because it is delivered as track data or out of band.¶

5.3. FEC Source Info Object Property

A publisher that carries FEC source symbols as MoQ objects MUST tag each such object with a FEC Source Info Object Property, whose type is the odd value 0x11 (Section 15.1).¶

0x11 is the value this document requests, and the registration policy for the range it lies in is not reachable by an individual draft (Section 15.1). Until that request is resolved, 0x11 is to be read as provisional. If it is not obtainable, Section 15.1 names an odd value in the range 0x80 to 0x37FF as the fallback; that value is a 2-byte Delta Type, so adopting it changes the bytes on the wire and not only the constant in this paragraph.¶

[I-D.ietf-moq-transport] calls these Object Properties; drafts before draft-17 called them object extension headers, and the two terms name the same wire construct. It encodes a Property as a key-value pair whose type parity selects the value encoding: an even type carries a single variable-length integer, an odd type carries a length-prefixed sequence of bytes. FEC Source Info is byte-valued, so its type is odd, and a receiver or relay that knows nothing of this document still steps over the Property correctly by its length prefix.¶

Deployed implementations have used the even value 0x10 for this purpose. That value is not available: [I-D.ietf-moq-transport] already lists 0x10 as the TIMESTAMP Object Property of draft-ietf-moq-loc, in the same Property Type space and at the same Object scope. A 0x10-tagged FEC object is therefore not merely unparseable under the parity rule; it is a semantic collision with an unrelated Property. A receiver that implements TIMESTAMP parses the FEC Source Info value as a variable-length integer, yields a garbage timestamp, and then reads the next Property type out of the middle of the FEC Source Info bytes. The key-value sequence is desynchronized from that point on, so the exchange ends in a session closure rather than in a quietly wrong value. Which closure depends on where the desynchronized parse lands: a Delta Type read out of the FEC Source Info bytes that overflows 2^64-1, or a Length that exceeds 2^16-1, is a PROTOCOL_VIOLATION; a type that is understood but whose value does not match its serialization is a KEY_VALUE_FORMATTING_ERROR. This is why implementations that use 0x10 must special-case the type ahead of the parity rule to interoperate at all. An implementation of this document MUST NOT send 0x10. The defence is necessarily publisher-side: a receiver cannot detect a 0x10-tagged FEC object as such, because by construction it is indistinguishable from a well-formed TIMESTAMP until the following Delta Type fails. A receiver cannot reject a 0x10 Property and carry on, because the sequence is already desynchronized by the time the value has been mis-parsed; it MUST close the session as [I-D.ietf-moq-transport] requires.¶

The Property value is:¶

FEC Source Info {
  SS_ID (32),
}

SS_ID is an unsigned integer in network byte order. It is the sequence number of the source symbol the object carries (Section 2), the same value and the same definition that the Source FEC Payload ID trailer of a FEC source packet carries on the MMTP path (Section 8.5). This Property is that trailer's MoQ-layer carrier: one identifier, one definition, whichever path the symbol travels.¶

Where the packaging also delivers the trailer, both carry the same value and a publisher MUST make them identical. On the mmtp packaging of [MOQ-MMT] that is every source object, because the object payload is the whole FEC source packet, trailer included. The Property is wanted there as well: it places the symbol at the MoQ layer, reachable by a relay and by a receiver that does not parse MMTP, whereas the trailer is the field the FEC encoder emitted and the one Section 8.3 locates the symbol by. Where the two disagree the trailer prevails (Section 8.5). A packet the decoder recovers carries neither (Section 7.3): the Property is not recovered with the object, and the trailer is appended after FEC encoding, so a receiver that recovers a packet determines its SS_ID from the block coordinate that recovered it, within that FEC instance's SS_ID space (Section 6.4.1); an overlay coordinate does not yield a base SS_ID (Section 7.3).¶

Where a keyframe overlay applies (Section 6.4), an object carrying a Random Access Point fragment is a source symbol of two FEC instances, whose SS_ID spaces are disjoint (Section 6.4.1), so "the source symbol the object carries" names two SS_IDs rather than one. This Property carries the base instance's SS_ID -- the value the Source FEC Payload ID trailer carries on the MMTP path (Section 8.5.1) -- and a publisher MUST NOT place an overlay SS_ID in it. No second Property conveys the overlay SS_ID: it travels in the 0x8B01 MMTP header extension, which lies inside the MMTP packet header and is therefore part of the protected packet of both instances (Section 8.5.1), so it rides inside the object's payload on this path as on any other. A receiver takes an overlay SS_ID from that extension and from nothing else, and in particular MUST NOT infer one from this Property (Section 8.5.1).¶

A receiver places the symbol in a block by SS_ID (Section 8.3) and learns the block's extent from the (SS_Start, SSB_length) of a repair object (Section 7.1), exactly as on the MMTP path. The Property carries no block coordinate, and a receiver MUST NOT infer one from it: the constraints of Section 7.4 on delimiting a block apply unchanged to a MoQ receiver, so it MUST NOT infer a block boundary, or SSB_length, from a gap in SS_IDs, from a group or MPU boundary -- which for a MoQ receiver includes a Group boundary -- from elapsed time, or from sourceSymbols. Until it has accepted a repair object of the block it holds the symbol without placing it, as Section 8.3 describes.¶

An object that carries a source symbol but no FEC Source Info Property violates the publisher requirement that opens this section. A receiver that does not parse the FEC source packet has no SS_ID for it -- at the MoQ layer the Property is the only carrier -- so it MUST NOT feed such an object to the base decoder and MUST NOT count it in K or in any base block, and MAY still deliver it as media. Where the packaging delivers the trailer, a receiver that parses the packet MAY take the SS_ID from there instead (Section 8.3). An overlay SS_ID is unaffected either way: it travels in the 0x8B01 MMTP header extension (Section 8.5.1), which this Property does not carry, and Section 8.5.1 alone governs when the overlay decoder may be fed.¶

The value is exactly 4 bytes. A value of any other length does not match the serialization defined for this type, so a receiver that implements this document MUST close the session with KEY_VALUE_FORMATTING_ERROR, as [I-D.ietf-moq-transport] requires of any Property whose type is understood and whose value does not match.¶

SS_ID is a fixed 32-bit field rather than a variable-length integer for two reasons. First, [I-D.ietf-moq-transport] does not require its variable-length integers to be encoded in the minimum number of bytes, so one numeric value has several valid encodings that differ in length; a varint field inside the Property value would therefore vary the Property's own length without varying its meaning. Second, the encoding is a property of the session: [I-D.ietf-moq-transport] replaced it at draft-17 (transport issue 1016) with a leading-1-bits scheme that is not the QUIC variable-length integer encoding of earlier drafts and does not decode the same bytes to the same values, so a varint field following the session encoding would decode differently on two drafts. A fixed width removes both. A publisher and a receiver that negotiated different session versions, and a relay that re-encodes between them, decode this field identically.¶

This Property carries no object length. A receiver that recovers an object by FEC decoding receives no Properties with it, so a length carried here would be absent in exactly the case a recovered length is wanted. The recoverable length is the Length field inside the source symbol itself (Section 7.3), which is recovered with the symbol. Under the source symbol construction of Section 7.3 the padding that completes a symbol is applied by the encoder and decoder and is not transmitted, so there is no transmitted padding for a receiver to strip.¶

5.4. Relay Extensibility Requirements

Relays conforming to this specification are subject to the following requirements:¶

1. A relay MUST NOT terminate, reset, or otherwise fail a session in response to a control message whose type it does not recognize. Such messages MUST be ignored.¶

2. A relay MUST NOT terminate, reset, or otherwise fail a session in response to an Object Property whose type it does not recognize. Such Properties MUST be forwarded unmodified to downstream subscribers; a relay MUST NOT strip them.¶

6.1. Track Naming

For a source track with name components [namespace, track_name], the corresponding repair track MUST be named:¶

[namespace, track_name, "repair"]

Examples:¶

These name components are commonly rendered in slash-separated form for URIs and logging (e.g., "live/video" and "live/video/repair"); the normative form is the tuple.¶

The convention covers layer 0 only, and it is a convention rather than a resolution mechanism. Enhancement layers (Section 6.3) and a keyframe overlay (Section 6.4) have no required name: they are resolved from depends, repairLayer and scope on their own catalog entries (Section 5.1.1). A receiver MUST NOT infer that a track is a repair track, which source it repairs, or which layer it is, by parsing a track name or a name suffix, and a publisher MUST NOT rely on a receiver doing so. Names such as "video/repair/1" appear in the examples of this document for readability only.¶

6.2. Subscription Model

Subscribers SHOULD subscribe to the source track first, then subscribe to the repair track if:¶

1. The track's catalog entry signals FEC (a fec object naming a repairTrack, Section 5.1), AND¶
2. The subscriber desires FEC protection¶

Repair-track subscription is selective and per-need: a subscriber chooses whether to consume repair data based on its own path conditions, and MAY start or stop its repair-track subscription at any time during the session -- for example, subscribing only after observing loss, or not subscribing at all on a reliable path.¶

Publishers and relays MUST NOT require subscription to repair tracks and MUST NOT condition delivery of a source track on a repair-track subscription. Repair tracks are optional; subscribers MAY choose to rely solely on QUIC retransmission or to accept unrecovered loss.¶

6.3. Layered Repair Tracks

A source track MAY be protected by more than one repair track. Each such track is a repair layer: an independently subscribable set of repair symbols for the same source blocks. Layer 0 is the repair track named by repairTrack, carrying the source's repairSymbols symbols per block. Layers 1..n are the tracks that name this source in depends and carry a repairLayer (Section 5.1.1), one track per layer index.¶

Layered repair is an extension of [ISO.23008-1] that an ISO AL-FEC message cannot express: each FEC source flow has one FEC encoded flow, whose one-stage coding structure carries a single repair_flow_id ([ISO.23008-1] Clause C.6.3), so only layer 0 maps to an ISO repair flow. An in-band AL-FEC message names layer 0 and no other layer ([MOQ-MMT] Section 8.3). A repair layer is also unrelated to the layers of ISO layer-aware FEC (LA-FEC, Clause C.2.3).¶

Layering separates the two costs of FEC: the repair count P buys tolerance to random loss at a cost in bandwidth, and the interleave window buys tolerance to burst loss at a cost in recovery latency (Section 9). Layers let a receiver on a lossier path add repair without changing the source encoding. A source track names only layer 0; each further layer declares itself on its own tracks entry, so the layer set is validated as a whole (Section 6.3.4) and changed only as Section 6.3.9 allows. A relay that forwards a subset of a catalog MUST NOT forward a fec-repair track whose source track it does not forward (Section 6.3.4, rule 9).¶

O_i   = sum(P_j for j < i)
RS_ID = O_i + j, for the j-th symbol of layer i
ESI   = SSB_length + RS_ID

{
  "multicast": {
    "endpoints": [
      {
        "sourceAddress": "198.51.100.100",
        "groupAddress": "232.1.1.50",
        "port": 5000,
        "tracks": [
          { "name": "video",          "packetId": 1 },
          { "name": "video/repair",   "packetId": 2 }
        ]
      },
      {
        "sourceAddress": "198.51.100.100",
        "groupAddress": "232.1.1.51",
        "port": 5000,
        "tracks": [
          { "name": "video/repair/1", "packetId": 3 },
          { "name": "video/repair/2", "packetId": 4 }
        ]
      }
    ]
  }
}

6.4. Keyframe Overlay

A source track MAY additionally be protected by a keyframe overlay: a second, independent FEC instance whose source symbols are only the fragments of Random Access Points of that source track.¶

Losing part of a Random Access Point makes every dependent frame undecodable until the next one; the overlay protects RAP fragments across a block of its own, which can be wider than the base window, without changing the base instance's latency.¶

7.1. Repair Object Header

Each object on a repair track is one complete MMTP repair packet (packet type 0x03, FEC Type 2) carrying exactly one repair symbol. Its layout is the ISO 23008-1 AL-FEC repair packet form -- the MMTP packet header followed by the 13-byte Repair FEC Payload ID and the repair symbol data ([ISO.23008-1] Sections C.4.3 and C.5.3; ssbg_mode1, one-stage FEC with N = 1, and ffsrpts_flag = 0, so no FFSRP_TS, Section C.5.1) -- so the same repair packet is valid on MoQ, multicast UDP, and native broadcast paths without translation, and matches the repair-object depiction of [MOQ-MMT] Section 7. The layout below reproduces [ISO.23008-1] Section C.5.3 for convenience:¶

Repair Object {
  MMTP Packet Header (96),      # packet type 0x03, FEC Type 2
  Repair FEC Payload ID {
    SS_Start (32),
    RSB_length (24),
    RS_ID (24),
    SSB_length (24),
  },
  Repair Symbol Data (..),      # exactly one symbol, T bytes
}

MMTP Packet Header: The standard 12-byte MMTP packet header ([MOQ-MMT] Section 3.1) with packet type 0x03 (repair) and FEC Type 2; its packet_id routes the repair flow. Like every packet of its MMTP packet flow, source and signaling packets included, a repair packet has the packet counter flag C = 0 ([MOQ-MMT] Section 3.1; [ISO.23008-1] Clause 9.2.3). A repair packet MUST NOT carry a header extension (X = 0). Because C = 0 and X = 0, the Repair FEC Payload ID always begins at byte offset 12.¶

SS_Start (32 bits): The SS_ID of the first source symbol of the protected source block ([ISO.23008-1] Section C.5.3). The blocks of an FEC instance are consecutive: the block after this one starts at SS_Start + SSB_length, modulo 2^32 (Section 7.4), so this block is the SS_ID range [SS_Start, SS_Start + SSB_length) and is identified by its SS_Start. Extended to 62 bits, SS_Start is also the MoQ Group ID of the block's repair objects (Section 7.5). Every field below is that of the packet's FEC instance (Section 6.4.1).¶

RSB_length (24 bits): The number of repair symbols generated for the block: the instance's total repair count P, identical on every repair packet of the instance; a layer does not carry its own P_i.¶

RS_ID (24 bits): The zero-based index of this repair symbol among the block's P repair symbols. The RFC 6330 Encoding Symbol ID is derived as ESI = SSB_length + RS_ID (Section 7.2). Layer i of the base instance carries RS_ID in [O_i, O_i + P_i) (Section 6.3.2).¶

The encoder performs one RaptorQ encoding pass per source block of each instance, producing the total repair count, and then assigns the disjoint RS_ID ranges to the layer tracks according to O_i. It MUST NOT run a separate encoding per layer: separate encodings of the same block are not symbols of a single code, so they could not be combined by a receiver holding more than one layer, which is the property Section 6.3.2 depends on.¶

SSB_length (24 bits): The number of source symbols in the protected source block ([ISO.23008-1] Section C.5.3), from 1 to K, where K is the instance's sourceSymbols (Section 5.1); it is K for a full block. It is authoritative for the block: the block is a RaptorQ source block of SSB_length source symbols, its repair ESIs start at SSB_length (Section 7.2), and its decoder is configured with F = SSB_length x T (Section 4.2). A value below K marks a short source block, to which this document's framing adds no padding symbols (Section 7.4). A publisher MUST NOT send 0 or a value above K; a receiver discards a repair packet carrying either (Section 7.4).¶

Repair Symbol Data: Exactly one repair symbol of Symbol Size (T) bytes, generated per Section 7.2. Carrying one symbol per object aligns the loss unit with the FEC symbol (Section 11.3) and requires no symbol-count field.¶

7.2. 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 (Section 7.1). 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.¶

Repair symbol generation for extension algorithms (Section 4.3) is not specified by this document.¶

7.3. Sub-Blocks and ssbg_mode

Per ISO 23008-1 [ISO.23008-1] Section C.3.3 (signalled per C.6.3, Table C.5), the FEC block structure is described by the source symbol block generation (SSBG) mode (ssbg_mode). The iso-ssbg1-v1 block profile (Section 5.1) uses ssbg_mode1, with the one-stage FEC coding structure and FEC payload ID mode 0 ([ISO.23008-1] Clause C.1).¶

ssbg_mode1: One MMTP source packet = one source symbol, which records the packet's length. Each MoQ object or multicast UDP datagram carries exactly one FEC symbol. Repair symbols are exactly T bytes on the wire; a SOURCE packet MAY be shorter than T on the wire -- the length field and the zero padding that complete its T-byte source symbol are applied by the encoder and decoder as part of the source symbol construction below and are NOT transmitted. This is the natural model for MMTP because packets are sized to fit in UDP datagrams and no fragmentation or reassembly is needed at the FEC layer. Every source symbol is exactly T bytes, so a block of SSB_length source symbols is exactly SSB_length x T bytes -- the property the derived Transfer Length of Section 4.2 relies on. This is ssbg_mode1 of [ISO.23008-1], not ssbg_mode0, which carries no length and requires every packet of the flow to be exactly one symbol long.¶

Source symbol construction: The protected packet of an FEC source packet is the complete MMTP packet -- the MMTP packet header, including any header extension, followed by the MMTP payload -- before its 4-byte Source FEC Payload ID is appended ([ISO.23008-1] Section C.4.2; Section 8.5). Its T-byte source symbol is ([ISO.23008-1] Section C.3.3):¶

Source Symbol {
  Length (16),                  # protected packet length, octets
  Protected Packet (..),        # Length octets
  Padding (..),                 # zero octets, up to T in total
}

The Length field is in network byte order and every Padding octet is zero, so the largest protected packet a symbol can carry is T - 2 octets. A publisher MUST size every FEC source packet so that its protected packet does not exceed T - 2 octets. A receiver that observes a source packet whose protected packet exceeds T - 2 octets MUST NOT feed it to the decoder -- a truncated symbol would corrupt recovery for the entire block -- but MAY still deliver the packet as media. On a RAP packet under a keyframe overlay (Section 6.4), the base and the overlay instance form the symbol from the same protected packet, so the two protect one identical T-byte symbol.¶

Recovery yields the block's SSB_length source symbols. From each, the receiver takes the Length octets that follow the Length field as the recovered protected packet, and delivers that packet to the MMTP parser. A receiver MUST NOT deliver a recovered symbol whose Length is less than 12, the size in bytes of the MMTP packet header ([MOQ-MMT] Section 3.1), or points past the end of the symbol, or whose Padding octets are not all zero: each means that the symbol is not the one the publisher encoded.¶

A recovered packet carries no Source FEC Payload ID, of either instance: the trailer is appended after FEC encoding and is not part of the protected packet. A receiver MUST NOT re-append a trailer before delivering the recovered packet to the MMTP parser, and MUST NOT expect the recovered bytes to end in a block coordinate. This holds identically for a symbol recovered by a keyframe overlay, which the receiver delivers as media on the strength of the overlay recovery alone. The 0x8B01 header extension of a RAP packet under an overlay (Section 8.5.1) is part of the protected packet, by contrast, and is recovered with it.¶

The packet's base SS_ID was in the trailer, and this document defines no mapping from an overlay coordinate to a base one: a receiver MUST NOT place an overlay-recovered symbol into a base source block unless it has determined that packet's base SS_ID independently. Absent that, an overlay recovery is usable as media but MUST NOT be counted toward base block recovery, and in particular MUST NOT be treated as reducing the number of erasures the base decoder still has to solve. The other direction needs no such determination, because a RAP packet recovered by the base instance still carries its overlay SS_ID (Section 8.5.1).¶

In-band signaling: An AL-FEC message ([MOQ-MMT] Section 8.3) that describes a track under iso-ssbg1-v1 carries the coding byte 0x14: fec_coding_structure 0001 (one-stage), ssbg_mode 01, ffsrpts_flag 0 (no FFSRP_TS) and fec_payload_id_mode 0 (a Source FEC Payload ID is appended to every FEC source packet), in that bit order, per Table C.3 of [ISO.23008-1] as replaced by [ISO.23008-1.AMD1]. A message carrying any other value for such a track contradicts the catalog (Section 5.2).¶

Sub-blocks: When a single source block produces a large number of source symbols, RFC 6330 permits dividing each block into N sub-blocks (the Number of Sub-Blocks field of the OTI). The derived OTI of Section 4.2 fixes N = 1, so catalog-signaled sessions do not use sub-blocks; sub-block operation by broadcast systems that carry an explicit OTI is described informatively in Section 12.2. A publisher using MMTP packaging under iso-ssbg1-v1 therefore uses ssbg_mode1 without sub-blocks, and never ssbg_mode2.¶

7.4. Short Source Blocks

A publisher MUST close a source block when it has assigned K source symbols to it. It MAY close a source block earlier, for example at an access-unit, media-unit, or MoQ Group boundary, or to keep the actual source/repair send span within a positive interleaveDepthMs when that field is present (Section 5.1). Such a block is a short source block, and it is a block with a smaller source symbol count: every block holds SSB_length source symbols, 1 <= SSB_length <= K ([ISO.23008-1] Section C.5.3), and K -- the catalog sourceSymbols, carried in band as maximum_k_for_repair_flow -- is an upper bound on SSB_length, not the size of any particular block. A short block differs from a full one only in SSB_length:¶

1. The publisher encodes the block as a RaptorQ source block of its SSB_length source symbols (F = SSB_length x T, Section 4.2), at ESIs 0 to SSB_length - 1 in SS_ID order, and MUST carry that count in the SSB_length field of every repair packet of the block, on every repair track of the instance. This document's framing adds no padding symbols to the block: none 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.¶

2. The next block starts at the SS_ID that follows the block's last source symbol: its SS_Start is SS_Start + SSB_length, modulo 2^32. No SS_ID is skipped, so every SS_ID belongs to exactly one block.¶

3. The block's repair ESIs start at SSB_length: ESI = SSB_length + RS_ID (Section 7.2).¶

4. The block is complete, and needs no repair, once the receiver holds all SSB_length of its source symbols. It is recoverable once the source and repair symbols the receiver holds together number at least SSB_length, plus the decoding overhead of Section 6.3.2.¶

5. Recovery yields the SSB_length source symbols, SSB_length x T bytes, each consumed per the source symbol construction of Section 7.3.¶

Source packets carry only SS_ID, so the (SS_Start, SSB_length) of a repair packet is the only wire signal of a block's extent. Until a receiver has accepted a repair packet of a block it knows neither: it holds the source packets of that block without placing them in any block (Section 8.3), and a run of SS_IDs that it does not hold is a run of lost source packets of one or more blocks it cannot yet delimit. It MUST NOT infer a block boundary, or SSB_length, from a gap in SS_IDs, from a group or MPU boundary, from elapsed time, or from sourceSymbols. A block all of whose repair packets are lost therefore remains undelimited until a repair packet of the block arrives, including one obtained by unicast repair (Section 11.4), which conveys (SS_Start, SSB_length) in the same way. When the receiver accepts a repair packet of a block that starts after the end of the blocks it has delimited, the SS_IDs between the two belong to one or more blocks of which it holds no repair packet.¶

A receiver MUST fail closed on inconsistent block signaling. It MUST discard a repair packet whose SSB_length is 0 or exceeds K. It MUST discard a repair packet whose SSB_length differs from the value it has already accepted for the block with the same SS_Start, and one whose range [SS_Start, SS_Start + SSB_length) overlaps a different block that it has already accepted, in each case leaving the state of every block unchanged.¶

7.5. SS_ID Wrap and Repair Group IDs

SS_ID and SS_Start are 32-bit values that start from an arbitrary value and wrap to 0 after their maximum ([ISO.23008-1] Section C.5.2). Every comparison, distance and range test on them in this document, block membership (Section 8.3) included, uses serial number arithmetic [RFC1982] with SERIAL_BITS = 32. A block can span the wrap: a block with SS_Start 2^32 - 3 and SSB_length 4 holds the SS_IDs 2^32 - 3, 2^32 - 2, 2^32 - 1 and 0, and the next block starts at SS_ID 1.¶

A MoQ Group ID is a 62-bit integer, and the groups of a track are ordered by it [I-D.ietf-moq-transport], so the repair objects of a block are grouped not under its 32-bit SS_Start, which wraps, but under its extended SS_Start:¶

ext(SS_Start) = (wrap_epoch << 32) | SS_Start

wrap_epoch, from 0 to 2^30 - 1, counts the times that SS_Start has wrapped in the FEC instance before this block: it is 0 for the first block of the FEC instance's source encoding, and increases by one at each block whose SS_Start is numerically below its predecessor's. Equivalently, the ext(SS_Start) of a block is that of its predecessor plus the predecessor's SSB_length. On every repair track of the instance, the repair objects of a block form the MoQ Group whose Group ID is the block's ext(SS_Start) (Section 6.3.2). Repair Group IDs are therefore sparse, one per block at the block's first SS_ID, and strictly increasing.¶

A repair object received over MoQ thus carries its block's start twice: in the SS_Start of its Repair FEC Payload ID and in its Group ID. The SS_Start is authoritative. A receiver MUST discard a repair object whose Group ID modulo 2^32 differs from its SS_Start and, once it has established the wrap epoch, one whose Group ID differs from ext(SS_Start) or whose SS_Start it cannot extend (below), in each case leaving the state of every block unchanged. The Group ID of a discarded repair object is not a reference value r.¶

A receiver establishes the wrap epoch of an FEC instance in one of the following ways, and MUST NOT assume a wrap epoch that it has not established in one of them:¶

1. From the Group ID of a repair object of the instance that it has received over MoQ and not discarded (above). That Group ID is the reference value r. The publisher assigns it and MoQ delivers it unaltered, so it stands on the same footing as the Largest Location of way 2: the modulo 2^32 test above screens out an object to discard, and does not verify the epoch.¶

2. From the Largest Location that a TRACK_STATUS request for a repair track of the instance reports ([I-D.ietf-moq-transport] Section 9.13). The publisher answers TRACK_STATUS with a REQUEST_OK, which that document calls TRACK_STATUS_OK, carrying the parameters that it would set in a SUBSCRIBE_OK, among them the LARGEST_OBJECT parameter ([I-D.ietf-moq-transport] Section 9.20.18). The receiver reads the Group of the Location that LARGEST_OBJECT carries, whichever name the reply bears, and that Group is the reference value r. A reply without LARGEST_OBJECT reports a repair track on which no object has been published, and establishes no epoch.¶

3. As epoch 0, when the receiver has observed the instance from its first block, whose wrap_epoch is 0 (above). The reference value r is then that block's SS_Start.¶

A reference value r is an extended SS_Start, and the epoch is r shifted right by 32 bits. The receiver relates its own SS_IDs to it with serial arithmetic: it extends a later 32-bit SS_Start or SS_ID x relative to an extended value r that it already holds -- its reference value, or a value it extended before -- to the 62-bit value congruent to x modulo 2^32 that is nearest r in serial order: r advanced by the serial distance from the low 32 bits of r to x when x follows them, r moved back by the serial distance from x to them when x precedes them, and r itself when the two are equal. A receiver MUST NOT extend an x that lies exactly 2^31 from the low 32 bits of r, a pair that [RFC1982] leaves unordered, or one whose extension falls outside [0, 2^62).¶

Serial arithmetic cannot detect an x that lies more than 2^31 SS_IDs from r: it extends such an x into the wrong epoch without error. A receiver therefore extends values relative to an r only while it can bound the number of SS_IDs between them below 2^31, and MUST re-establish the wrap epoch, in one of the ways above, after any gap that it cannot so bound, such as one that spans a rejoin of a multicast group or a reconnection of its MoQ session.¶

A receiver that has lost the source packet with SS_ID x, and holds no repair packet of the block that contains x, requests that block's repair by a FETCH [I-D.ietf-moq-transport] of the absolute, inclusive Group range¶

[ max(ext(S_prev) + 1, ext(x) - (K - 1)), ext(x) ]

on each repair track it requests from, where:¶

• K is the instance's sourceSymbols (Section 5.1), the largest SSB_length that a block can have (Section 7.4), so the block that contains x starts at most K - 1 SS_IDs before x;¶
• S_prev is the SS_Start of the last block that the receiver has delimited that ends before x. When the receiver has delimited no such block, the first term is absent and the range is [ max(ext(x) - (K - 1), 0), ext(x) ];¶
• ext(x) is x extended relative to ext(S_prev) when S_prev exists, and otherwise relative to the reference value r of the receiver's wrap epoch.¶

Repair Group IDs sit at block starts, so the range returns the repair of every block that starts within it, up to and including the block that contains x, and the last Group it returns is that block. The range is never empty: it always contains ext(x). A receiver that has not established the wrap epoch, or that may not extend x, has no range to request until it establishes one. A receiver that holds a repair packet of the block requests the one Group ext(SS_Start) instead.¶

The 32-bit wrap of SS_ID and SS_Start is that of [ISO.23008-1]. The extended SS_Start, and its use as a MoQ Group ID, are defined by this document, outside [ISO.23008-1].¶

8.1. Blocks Within a Group

For example, a source Group can contain two consecutive blocks:¶

Group G:    SS_ID s   .. s+a-1      -> block A, SS_Start = s
            SS_ID s+a .. s+a+b-1    -> block B, SS_Start = s+a
Group G+1:  SS_ID s+a+b ..          -> next block or continuation
...

8.2. Blocks Across Groups

A block can also span a Group boundary:¶

Group G:    SS_ID s   .. s+a-1      -> block A, still open
Group G+1:  SS_ID s+a .. s+L-1     -> block A completes
            SS_ID s+L ..            -> next block
...

A block's repair objects form the repair-track Group whose Group ID is the block's extended SS_Start (Section 7.5), a number space unrelated to the source track's Group IDs. No fixed number of MoQ Groups is required for a block, and no Group boundary can be used to infer SSB_length.¶

8.3. Source Symbol Location

Under iso-ssbg1-v1, every FEC source packet carries a Source FEC Payload ID (Section 8.5), and a receiver that parses the packet takes each source symbol's SS_ID from that field on every path that delivers the packet with its trailer. The SS_ID is also carried alongside the packet where the packaging says so: on the MoQ path every object carrying a source symbol carries it in the FEC Source Info Object Property (Section 5.3), under the same value and the same definition, whether or not that object also delivers the trailer. A receiver that does not parse the FEC source packet -- a relay, or a MoQ receiver with no MMTP parser -- takes the SS_ID from there. The SS_ID advances by one per FEC source packet, modulo 2^32, in the order the publisher emits the packets ([ISO.23008-1] Section C.5.2), and the blocks of an FEC instance are consecutive: each starts at the SS_ID that follows the last source symbol of its predecessor (Section 7.4).¶

A source symbol is located by range membership. It belongs to the block whose Repair FEC Payload ID (Section 7.1) carries an (SS_Start, SSB_length) such that the symbol's SS_ID lies in [SS_Start, SS_Start + SSB_length) under the serial arithmetic of Section 7.5, and its ESI is its serial distance from SS_Start:¶

ESI = (SS_ID - SS_Start) mod 2^32,   0 <= ESI < SSB_length

No source symbol's block can be computed from its SS_ID alone, because blocks differ in length (Section 7.4), and this document defines no block number. A receiver holds a source symbol whose block it has not yet delimited, and places it when it accepts a repair packet of that block. Because consecutive FEC source packets carry consecutive SS_IDs, a lost source packet is visible as a missing SS_ID even before its block is delimited, and a run of SS_IDs that a receiver holds in full needs no repair, whatever its block boundaries.¶

An object that a packaging profile defines as carrying no source symbol -- for example, the in-band AL-FEC signaling object of [MOQ-MMT] Section 8 -- carries no SS_ID, has no ESI, and is not counted in K or in any block. This document defines no derivation of a source symbol's position from MoQ Group or Object IDs: on the mmtp packaging of [MOQ-MMT], Object IDs are not positions in the FEC block, and a packaging profile that defines source objects carrying neither a Source FEC Payload ID nor a FEC Source Info Object Property (Section 5.3) needs a block profile of its own (Section 5.1).¶

Every transport path yields the same SS_ID for the same packet, because each path carries the same MMTP packet, so receivers MAY combine symbols from any transport path toward the same FEC block recovery. Within one FEC instance (Section 6.4.1), a receiver deduplicates source symbols by SS_ID and repair symbols by (SS_Start, RS_ID).¶

8.4. Encoder Constraints

For FEC block alignment and timing to be deterministic, encoders MUST:¶

1. Assign consecutive SS_ID values in source-packet emission order, close a block at K source symbols or earlier as permitted by Section 7.4, and publish the resulting (SS_Start, SSB_length) in every repair packet for that block. A publisher MAY close at an access-unit, media-unit, or Group boundary, but MUST NOT use any boundary or elapsed-time observation as a substitute for that wire signaling.¶

2. Signal the catalog-authored group duration and frame rate in the MoQ catalog: for mmtp-packaged tracks, publish a positive duration as groupDurationMs when its integer-millisecond form is exact, or as the exact positive groupDurationTicks; when both are present, groupDurationTicks wins and groupDurationMs is informational. Signal the keyframe cadence in keyframeIntervalMs (or keyframeIntervalTicks), and the frame rate in the framerate field ([MOQ-MMT] Sections 4.4.2, 4.4.3 and 12.1). The ISO 23008-1 AL-FEC message has no field for either value ([ISO.23008-1] Table C.3), so an encoder signals neither there, and a receiver takes neither from it.¶

3. If frame rate or GOP size changes mid-session, update the MoQ catalog and signal a manifest discontinuity for DASH/HLS.¶

4. When interleaveDepthMs is positive, choose it so that the actual elapsed send span from the first source or repair packet of every block to its last does not exceed the signaled value. A zero value is usable only with the ISO protection_window_size alternative described in Section 5.1. The value is not derived from a group count, frame count, or per-symbol interval.¶

8.5. Source FEC Payload ID and ATSC 3.0 Signed Region

Exactly one 4-byte Source FEC Payload ID (SS_ID; ffsrpts_flag = 0, so no FFSRP_TS, [ISO.23008-1] Section C.5.1) is appended at the END of each MMTP FEC source packet -- following the MMTP payload, outside the MMTP packet header -- with or without a keyframe overlay (Section 8.5.1). Per ATSC A/360 Section 5.2.2.5, the ATSC 3.0 Signed Application (A3SA) signing mechanism covers signaling messages and MA3 messages (packet type 0x2) but excludes asset packets (type 0x00 MPU and type 0x03 repair).¶

Neither [ISO.23008-1] nor [ATSC-A331] carries the SS_ID inside the A3SA signed region. In particular the MMT hint sample does not: neither its ISO syntax ([ISO.23008-1] Clause 8.3.2) nor the ATSC MMTHSampleATSC3 syntax ([ATSC-A331] Section 7.2.4.2.2.3) has a Source FEC Payload ID field, and hint samples travel as MPU-mode data units on the Asset's own packet_id ([ATSC-A331] Section 7.2.4.2.3), that is in asset packets, which A3SA does not sign. This document therefore defines no A3SA-authenticated FEC block assignment: block assignment taken from the trailing Source FEC Payload ID of an A3SA verified packet is unauthenticated. A receiver that requires authenticated FEC block assignment MUST obtain it from an integrity mechanism, other than A3SA signing, whose coverage includes the complete MMTP packet, the trailer included. The bc-provenance profile is not such a mechanism: its authenticated bytes exclude the Source FEC Payload ID ([MOQ-MULTICAST] Section 7.2.4).¶

For MoQ-only receivers (no A3SA verification), the trailing 4-byte Source FEC Payload ID remains the canonical identifier by which a source packet is placed in its block (Section 8.3). QUIC transport encryption provides equivalent integrity protection.¶

Whatever the receiver's verification posture, the FEC Source Info Object Property of Section 5.3 carries the same value for a receiver that does not parse the packet; where an object delivers both and they disagree, the trailer is the one that is canonical, because it is the field the FEC encoder emitted and the one Section 8.3 locates the symbol by. The Property restates it at the MoQ layer.¶

Source Packet with Overlay {
  MMTP Packet Header {
    ...,                          # X = 1, RAP_flag = 1
    Header Extension {
      Type (16) = 0x8B01,
      Length (16) = 4,
      Overlay SS_ID (32),
    },
  },
  MMTP Payload (..),
  Source FEC Payload ID (32),     # base instance SS_ID
}

11.1. Multicast and AMT Delivery

IP multicast (including Source-Specific Multicast per [RFC4607]) and Automatic Multicast Tunneling (AMT per [RFC7450]) provide efficient one-to-many delivery but are inherently unreliable. FEC enables receivers to recover from packet loss without retransmission:¶

• Native SSM: Receivers join multicast group directly¶
• AMT Tunneling: Receivers without native multicast connect via AMT relays discovered through DRIAD ([RFC8777])¶
• TreeDN Distribution: Hierarchical multicast trees per [RFC9706], with FEC protection at each hop¶

The same MoQ objects (source and repair) can be transmitted over both unicast (QUIC/WebTransport) and multicast (UDP/SSM/AMT) paths. Receivers on reliable unicast paths can skip FEC decoding (Section 3), while receivers on lossy multicast paths use FEC for recovery and apply the receiver repair policy of Section 11.4 to any block that FEC does not recover.¶

Publisher
    |
    v
+----------------+
|   MoQ Relay    |
| (Origin/Root)  |
+-------+--------+
        |
   +----+----+--------------------+
   |         |                    |
   v         v                    v
Unicast   SSM Multicast      AMT Tunnel
(QUIC)    (Native)           (Encapsulated)
   |         |                    |
   v         v                    v
[Web]    [Native SSM         [Mobile/
Client    Clients]            Remote]

FEC:      FEC:                FEC:
Optional  Expected            Expected

11.2. Deployment Applicability

The repair overhead this mechanism adds is justified only where the delivery path actually loses packets, and multicast loss characteristics differ by orders of magnitude across access technologies. FEC strength (P and Interleave Depth) is a per-path deployment choice, expressed by which tracks each endpoint carries, not a protocol constant.¶

• Engineered low-loss segments. On managed PON or DOCSIS delivered over a provisioned VLAN, steady-state loss is typically far below 10^-6. Disabling FEC for such a path is signaled by omitting the repair track from the tracks that path's endpoints carry. Adding repair symbols on such a path spends bandwidth to recover losses that do not occur.¶

• FEC-capable broadcast PHYs. ATSC 3.0, DVB-S2/S2X, and 5G broadcast already apply bit-error correction on their own radio link (e.g., LDPC/BCH in ATSC 3.0 and DVB-S2/S2X). Application-layer FEC is NOT a duplicate of that correction: it recovers packet erasures the PHY cannot address -- bursts when reception falls below the PHY threshold (rain fade, mobility, indoor reception), and losses on upstream aggregation or backbone hops that the last-hop PHY never sees. Its value on these paths comes primarily from Interleave Depth spreading a burst across the time domain, not from the code rate. On a one-way broadcast downlink with no return path, application-layer FEC is the only available erasure-recovery mechanism -- which is why ATSC 3.0 (see Section 12) specifies it above the PHY.¶

• Public Internet and AMT tunnels. Loss is real and bursty; a non-trivial repair count with interleaving is RECOMMENDED.¶

11.3. Interaction with Multicast QUIC

[QUIC-MULTICAST] defines a one-way QUIC transport in which a multicast channel carries QUIC packets bearing STREAM or DATAGRAM frames, recovering loss via unicast repair (the MC_CHANNEL_ACK mechanism) and defining no Forward Error Correction of its own. This FEC scheme MAY be used as the recovery layer on such a channel, and is RECOMMENDED over unicast repair for broadcast-scale audiences, where per-receiver retransmission does not scale.¶

When this scheme is carried over a multicast QUIC channel:¶

1. Symbol-to-datagram mapping. Each source or repair symbol (one MMTP packet, per [MOQ-MMT]) SHOULD be carried in exactly one QUIC DATAGRAM frame. This aligns the erasure unit (a lost QUIC packet) with the FEC symbol, so one lost packet erases exactly one source symbol. STREAM framing SHOULD NOT be used for FEC-protected media on a multicast channel: a lost packet then spans a byte range crossing symbol boundaries, defeating symbol-aligned recovery.¶

2. Crypto boundary. FEC encoding operates on application-layer objects, ABOVE the QUIC packet protection of [QUIC-MULTICAST]. Unlike bare multicast UDP -- which lacks QUIC's integrity guarantees (see Section 14.4) -- the multicast QUIC binding applies a shared-key AEAD per packet. A sender computes source and repair symbols over the unencrypted objects; the channel then applies its AEAD; a receiver decrypts each surviving packet and recovers erased objects from the decrypted source and repair symbols. A lost packet cannot be decrypted, but its object is reconstructed from other verified symbols, so recovery does not depend on possessing it.¶

3. Integrity of recovered objects. The integrity frames of [QUIC-MULTICAST] authenticate the bytes of each delivered packet. A FEC-reconstructed object was never carried in a single packet and is therefore NOT individually covered by a packet hash; it inherits trust transitively from the verified surviving symbols used to reconstruct it. Deployments requiring per-object authentication of recovered data SHOULD additionally apply an object-level scheme (for example the manifest-based bc-provenance profile of [MOQ-MULTICAST] Section 7.2) computed below the FEC layer, which survives reconstruction.¶

4. Repair channel versus unicast repair. A publisher using this scheme broadcasts repair symbols on the multicast channel (the repair track) rather than relying on unicast retransmission. Receivers covered by the repair flow SHOULD NOT drive unicast repair for losses the FEC recovers, preserving the O(1) sender cost that motivates broadcast FEC. Unicast repair MAY be retained as a last resort for losses exceeding the repair budget. Section 11.4 specifies that last resort.¶

Symbols delivered over a multicast QUIC channel are deduplicated by their FEC coordinates, source symbols by SS_ID and repair symbols by (SS_Start, RS_ID); [QUIC-MULTICAST] normatively requires only this deduplication, and Section 8.3 permits combining them with symbols received from other paths.¶

11.4. Receiver Repair Policy

This section specifies what a receiver of a multicast or AMT leg does with a base-instance block of a source track that in-band FEC has not recovered by the block's FEC deadline (Section 9). A receiver on a reliable MoQ/QUIC leg relies on transport retransmission (Section 3) and does not need it, and nothing in this section adds a deadline or a timer to such a leg.¶

Every step of this section is keyed on a block's FEC deadline, which exists only when the track's catalog carries a positive interleaveDepthMs (Section 9). On a multicast or AMT leg, this section therefore requires a positive interleaveDepthMs: a receiver of a track whose catalog omits it or sets it to zero MUST disable the block classification and unicast repair of this section for that track. The receiver still decodes in-band FEC from the symbols that arrive (Section 8.3), with open-block state bounded by the local policy of Section 9. Media still missing at its presentation time is lost: the loss of a RAP, or of a data unit that governs one, is handled as for an unrecoverable keyframe-bearing block (Section 11.4.2), and other loss is concealed as in Sections 11.4.3 and 11.4.4.¶

Every block receives in-band FEC processing. A receiver MUST attempt to recover every block, whatever its class, from the source and repair symbols received on its multicast and AMT paths, together with any it receives on other paths (Section 8.3), up to the block's FEC deadline. The rest of this section governs only a block that is still unrecovered at that deadline: the receiver does not hold all of its SSB_length source symbols (Section 7.4), and decoding from the symbols it holds has not recovered them.¶

A run of SS_IDs that the receiver lacks and that lies in no block it has delimited belongs to one or more blocks of which it holds no repair packet (Section 7.4). For this section the receiver treats such a run as one block of the instance: Section 11.4.1 classifies it from the source packets the receiver holds on either side of it, and its repair is requested by the Group range of Section 7.5, whose response also delimits the blocks it covers.¶

The policy distinguishes keyframe-bearing blocks, whose loss can stop video decoding until the next Random Access Point (RAP), from other blocks, whose loss damages only frames up to the next RAP. Keyframe-bearing blocks are protected by priority unicast repair and are the only blocks whose loss may stall video. Other blocks are repaired on a best-effort basis and, when repair fails, concealed. Every frame and audio sample a receiver presents MUST be presented at its authored time on the presentation clock shared by its tracks, and a receiver MUST NOT stall video or pause that clock except for a keyframe-bearing block (Section 11.4.2).¶

12.1. Mapping to A/331 AL-FEC

overhead is not carried in the catalog; it is converted to and from repairSymbols by the informative rules of [MOQ-MMT] Sections 12.2 and 12.3.¶

Publishers ingesting ATSC 3.0 broadcasts SHOULD preserve the original FEC parameters and pass them through in the catalog fec field. overhead in particular is not passed through verbatim: the catalog carries P rather than a percentage, and overhead is converted as above.¶

12.2. Sub-Blocks in Broadcast Systems

This subsection is informative broadcast-interoperability guidance, not an interoperability requirement of this document. Sub-block operation (Section 7.3) remains available to broadcast systems that carry an explicit OTI, such as the A/331 S-TSID fecOTI; the ISO 23008-1 AL-FEC message carries no OTI, and the split source blocks of [ISO.23008-1] are the two-stage FEC coding structure of Clause C.2.2, which this document does not use. The number of source symbols per sub-block (K_sub <= K) is derived from the signaled parameters: K_sub = ceil(K / N), where K is the block's source symbol count, at most the catalog sourceSymbols, and N is the Number of Sub-Blocks field of the explicitly signaled OTI.¶

When sub-blocks are used:¶

1. When positive, interleaveDepthMs keeps its Section 5.1 meaning, the span of the FULL block. A sub-block's own span can be estimated as interleaveDepthMs * K_sub / K for partial-recovery scheduling; the estimate never replaces the full-block field or deadline (Section 9). A zero value uses the ISO packet-count alternative and supplies no millisecond span. This enables faster partial recovery at the cost of higher repair overhead (P repair symbols per sub-block instead of per block).¶

2. The receiver tracks source symbol arrivals per sub-block (keyed by the block's SS_Start and the sub-block index) and can emit recovered data as soon as each sub-block completes, without waiting for the full block.¶

3. The receiver uses the derived sub-block length K_sub (not K from the catalog) for per-sub-block recovery when K_sub < K.¶

Sub-blocks are primarily useful for large-K configurations (K >= 64) where full-block recovery latency exceeds acceptable limits.¶

14.1. FEC Does Not Provide Confidentiality

FEC repair symbols are derived from source data. If source data is encrypted, repair symbols will also be encrypted by virtue of operating on ciphertext. However, FEC itself provides no confidentiality guarantees.¶

14.2. Repair Symbol Manipulation

An attacker who can modify repair symbols could cause receivers to reconstruct incorrect source data. Integrity protection of repair tracks is RECOMMENDED, using the same mechanisms as source tracks (e.g., QUIC packet protection).¶

14.3. Amplification

FEC repair symbols represent additional bandwidth. Publishers MUST NOT generate excessive repair symbols that could be used for bandwidth amplification attacks. The repair overhead (P/K) SHOULD be limited to reasonable values (e.g., <= 50%). The bound applies per FEC instance (Section 6.4.1).¶

Layering changes the shape of the amplification exposure, because the attacker's lever is now which layers a victim can be made to receive rather than only whether it receives repair at all. Each layer i adds P_i x T bytes per source block, so a receiver induced to hold more layers receives proportionally more repair traffic. Deployments SHOULD bound the number of layers any single receiver may hold, and SHOULD apply the same join authorization to repair-layer endpoints as to media endpoints; a repair-only endpoint (Section 6.3.6) is not less sensitive than a media one merely because it carries no media.¶

A receiver MUST NOT be made to receive a repair layer it did not join. A publisher or relay MUST NOT push a repair-layer endpoint to a receiver that has not joined it, and MUST NOT add a layer to an endpoint a receiver has already joined as a way of raising that receiver's protection.¶

14.4. Multicast FEC Security

When FEC is used over multicast (SSM/AMT), additional considerations apply:¶

1. No QUIC Protection: Multicast UDP lacks QUIC's integrity guarantees. Publishers SHOULD use DTLS-SRTP or equivalent for payload encryption when confidentiality is required.¶

2. Repair Injection: Attackers could inject malicious repair symbols on multicast networks. Receivers SHOULD verify FEC block consistency by checking that decoded data matches expected patterns (e.g., valid media container structure).¶

3. Source Authentication: See [MOQ-MULTICAST] Section 7.1.¶

4. Block Integrity: Receivers MAY implement block-level checksums to detect corrupted recovery. If decoded source data fails integrity checks, receivers SHOULD request retransmission via unicast fallback.¶

5. Repair Policy Inputs: The in-band evidence that Section 11.4.1 classifies blocks from, and the SSB_length by which Section 7.4 completes a short block, are unauthenticated on bare multicast. An injected packet that marks a block keyframe-bearing costs at most the unicast repair that block's own credit covers (Section 11.4.5). An injected source packet inside a block's gap can instead narrow the bounds of Section 11.4.1 until a keyframe-bearing block is classified otherwise, and an injected repair packet carrying a false SS_Start or SSB_length, accepted before the genuine ones, can mis-delimit a block, mark it complete early, or cause its genuine repair packets to be discarded as inconsistent (Section 7.4). Deployments exposed to injection SHOULD authenticate source and repair packets ([MOQ-MULTICAST] Section 7.2).¶

14.5. ATSC 3.0 Signed Region (A3SA) Considerations

The Source FEC Payload ID falls outside the A3SA signed region, and neither [ISO.23008-1] nor [ATSC-A331] provides a carriage of the SS_ID inside it (Section 8.5). An attacker who can modify it without detection could redirect source symbols to incorrect FEC blocks, causing recovery failures or corrupted output. A receiver that requires authenticated FEC block assignment therefore treats the trailer as Section 8.5 requires. On multicast networks without A3SA verification, receivers SHOULD cross-check the SS_ID against the MMTP packet_sequence_number to detect obvious tampering (e.g., an SS_ID that advances further than the packet_sequence_number of the same packet_id, whereas SS_ID advances by one per FEC source packet, Section 8.3).¶

15.1. MoQ Registrations

This document requests one registration in the MOQT Properties registry of [I-D.ietf-moq-transport]:¶

The type is odd, so under the key-value parity rule of [I-D.ietf-moq-transport] the Property is length-prefixed and byte-valued (Section 5.3). The scope is Object: FEC Source Info describes the individual object it tags, and carries no track-wide meaning.¶

0x11 lies in the range 0x00 to 0x77, for which [I-D.ietf-moq-transport] states a registration policy of Standards Action or IESG Approval. That policy is not reachable by an individual draft, so this document asks for 0x11 as a provisional registration in the table [I-D.ietf-moq-transport] maintains for other active drafts in the MoQ working group, on the same terms as the existing entries for draft-ietf-moq-loc and draft-ietf-moq-secure-objects. That ask is contingent on this document being adopted. If 0x11 is not available on those terms, an odd value in the range 0x80 to 0x37FF, whose policy is Specification Required, is obtainable by this document on its own; it costs one additional byte per tagged object and changes nothing else in this specification.¶

The even value 0x10, used by deployed implementations for this purpose, is deliberately not requested, and this document could not reserve it in any case: [I-D.ietf-moq-transport] already lists 0x10 as the TIMESTAMP Object Property of draft-ietf-moq-loc, at Object scope in the same Property Type space. Section 5.3 gives the resulting collision and its consequences.¶

This document requests no registration in any MoQ message type registry. FEC signaling uses no MoQ control message (Section 5.2); no document in this suite requests a control-message codepoint. The header extension type 0x8B01 of Section 8.5.1 is an MMTP value, not a MoQ one; [ISO.23008-1] Clause 9.2.3 defines no registry of MMTP header extension types, so its use requires no IANA action.¶

15.2. FEC Algorithm Registry

This document requests creation of a "MoQ FEC Algorithms" registry with the following initial values:¶

New registrations require Specification Required policy.¶

Only "None" (0x00) and RaptorQ (0x01) are specified for interoperation by this document; other registered values, including Reed-Solomon (0x02), are extension points whose interoperable use requires their own specifications (Section 4.3).¶

15.3. Catalog Packaging Value

This document defines the catalog packaging value "fec-repair" (Section 5.1) for repair tracks, extending the allowed packaging values of the MoQ Streaming Format [I-D.ietf-moq-msf] Section 5.2.4. If a registry of packaging values is established for that format, this document requests registration of:¶

A.1. Catalog-Driven FEC

The subscriber learns the complete FEC configuration from the track's catalog entry before subscribing:¶

"fec": {
  "algorithm": "raptorq",
  "blockProfile": "iso-ssbg1-v1",
  "sourceSymbols": 32,
  "repairSymbols": 8,
  "symbolSize": 1312,
  "interleaveDepthMs": 1000,
  "reorderToleranceMs": 40,
  "repairTrack": "video/repair"
}

Publisher                              Subscriber
    |                                       |
    |  (catalog obtained; fec field read)   |
    |                                       |
    |  SUBSCRIBE(sub_id=1, track=video)     |
    |<--------------------------------------|
    |                                       |
    |  SUBSCRIBE_OK(sub_id=1)               |
    |-------------------------------------->|
    |                                       |
    |  SUBSCRIBE(sub_id=2,                  |
    |    track=video/repair)                |
    |<--------------------------------------|
    |                                       |
    |  SUBSCRIBE_OK(sub_id=2)               |
    |-------------------------------------->|
    |                                       |
    |  [Source objects of group 0]          |
    |-------------------------------------->|
    |                                       |
    |  [Repair objects, group=0, obj=0..7]  |
    |-------------------------------------->|
    |                                       |

In this flow the track is mmtp-packaged with a one-second group duration (one MPU per MoQ Group, [MOQ-MMT] Section 4.3). That group duration describes the MoQ grouping; it does not derive an FEC block. For example, if the first block starts at SS_ID 0 and is full, its repair Group is its extended SS_Start, 0 (Section 7.5), the next block starts at SS_ID 32, and its repair Group is 32. A publisher MAY choose shorter blocks inside a Group or a block that crosses the Group boundary; each repair packet carries the actual SSB_length. The subscriber's decoder configuration is derived from the catalog fields and each block's SSB_length (Section 4.2): for a full block (SSB_length = K = 32), 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, and this track carries no AL-FEC signaling object ([MOQ-MMT] Section 8).¶