Forward Error Correction for Multicast Delivery of Media over QUIC

Status of This Memo

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

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

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

This Internet-Draft will expire on 6 May 2027.¶

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The FEC mechanism of [MOQ-FEC-CORE] lets a receiver recover lost source symbols from repair symbols that the publisher sends ahead of need, and lets each receiver choose how much repair it takes by subscribing to repair tracks. On a MoQ unicast path a receiver can also fall back on QUIC retransmission. On a multicast path it cannot: IP multicast and Automatic Multicast Tunneling (AMT) deliver the same packets to every receiver, no receiver can ask the network for a retransmission, and a receiver without a return path cannot ask anyone. FEC is therefore the primary recovery mechanism on a multicast leg, and this document specifies what is particular to it.¶

On a multicast endpoint the receiver does not choose tracks; the operator of the endpoint does. This document defines how the repair layers of an FEC instance are placed on endpoints, including endpoints that carry only repair, and how a receiver that measures loss moves between them Section 4. It states which tracks a multicast endpoint carries in this revision Section 3.3, and how the mechanism relates to the repair that a multicast QUIC channel may provide below it Section 3.4. Where a multicast content-authentication profile decides which packets a receiver may trust, it specifies how blocks delimited by packets that the profile has not admitted are held Section 5. Finally it specifies the receiver repair policy of a multicast or AMT leg Section 6: every block gets in-band FEC first, and a receiver that holds a MoQ session requests unicast repair, by the per-block FETCH of [MOQ-FEC-CORE], only for blocks that FEC did not recover, in an order and within a budget that the catalog fixes.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The terms below are used in this document with the meaning that [MOQ-FEC-CORE] gives them; every other term of that document, and of [MOQ-MULTICAST], keeps its meaning there.¶

Source Track: A MoQ track whose objects carry media, for example video or audio, and which an FEC instance protects.¶

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 of [MOQ-FEC-CORE]).¶

Base Instance: Of a source track that a keyframe overlay protects, the instance that is not the overlay; of any other source track, its only instance.¶

Source Symbol: A T-byte unit of source data that an FEC instance encodes. Under iso-ssbg1-v1 a source symbol is one FEC source packet, an MMTP packet framed as Section 7.1 of [MOQ-MMT] specifies.¶

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 of [MOQ-FEC-CORE]).¶

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 packet of the block (Section 7.5 of [MOQ-FEC-CORE]).¶

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

Repair Track: A MoQ track whose objects each carry one repair symbol of one FEC instance. Under iso-ssbg1-v1 its objects are MMTP FEC repair packets ([ISO.23008-1] Section C.4.3), the layer-0 repair track carries the FEC repair flow that an ISO AL-FEC message names for the source track's FEC encoded flow (Section 8.3 of [MOQ-MMT]), and further repair layers and a keyframe overlay are repair tracks that only the catalog declares.¶

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 of [MOQ-FEC-CORE]). Layer 0 is the base layer. Layer i may use RS_IDs from its RS_ID offset O_i, and carries P_i repair symbols per block.¶

Symbol Track: A MoQ track whose objects each carry exactly one source symbol of one FEC instance, grouped by block (Section 6.2 of [MOQ-FEC-CORE]).¶

Keyframe Overlay: A second, independent FEC instance over an MMTP-packaged source track whose source symbols are only the fragments of Random Access Points, defined in Section 7.4 of [MOQ-MMT]. An overlay is not a repair layer and carries no layer index.¶

Interleave Depth: When positive, the complete time span, in milliseconds, of one FEC source/repair packet block, signaled as interleaveDepthMs (Section 9.3 of [MOQ-FEC-CORE]). Zero is not a millisecond span: under iso-ssbg1-v1 it selects the ISO packet-count alternative (Section 7.5 of [MOQ-MMT]).¶

FEC Deadline: The elapsed-time deadline that a receiver derives for a block from a positive interleaveDepthMs together with reorderToleranceMs (Section 9.3 of [MOQ-FEC-CORE]). A block has an FEC deadline only when its instance carries a positive interleaveDepthMs.¶

Multicast Endpoint: One multicast group of a catalog's multicast extension, with the list of tracks it carries (Section 4.1 of [MOQ-MULTICAST]).¶

Unlisted Track and Admitted Packet: Within a consumer that the bc-provenance profile of [MOQ-MULTICAST] protects, an unlisted track is one that no endpoint of a flow the consumer is protected under lists, and an admitted packet is one that step 2 of the receiver procedure of that profile (Section 7.2.7 of [MOQ-MULTICAST]) has admitted.¶

3. Hybrid Unicast and Multicast Delivery

The FEC mechanism of [MOQ-FEC-CORE] is designed to support hybrid delivery architectures where the same media stream is delivered via multiple transport paths simultaneously. Multicast delivery paths, TreeDN integration, and the transport hierarchy are defined in [MOQ-MULTICAST] (its Sections 1 and 3); this section covers FEC-specific considerations for hybrid delivery.¶

The catalog's authority over FEC configuration (Section 10 of [MOQ-FEC-CORE]) 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, 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.¶

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

4. Repair-Only Multicast Endpoints

Multicast endpoints carry only mmtp tracks and their repair tracks (Section 3.3), so this section concerns tracks under iso-ssbg1-v1.¶

On a multicast endpoint the receiver cannot choose tracks; the operator of the endpoint chooses which tracks that path carries. Each repair layer carried on an endpoint is listed with its own packetId ([MOQ-MULTICAST] Section 4.1), exactly as a source track is, and a receiver MUST route every such packetId to the decoder of the FEC instance that layer serves, the one its source and instanceId name (Section 10.2 of [MOQ-FEC-CORE]). Because every endpoint carries the same source packets under the same block partition (Section 7.3 of [MOQ-FEC-CORE]), a receiver that moves between endpoints, or that is side-fed over MoQ unicast, mixes symbols from all of them in one decode. Layers not carried on any endpoint the receiver holds remain reachable over MoQ unicast (Section 7.2 of [MOQ-FEC-CORE]) for receivers that have a return path.¶

An operator MAY carry the source track and its layers together on one endpoint, or MAY place layers on endpoints of their own. An endpoint whose track list contains only fec-repair tracks (the packaging value of Section 3.3 of [MOQ-FEC-CATALOG]) is a repair-only endpoint:¶

{
  "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 }
        ]
      }
    ]
  }
}

The first endpoint suits a regional path with low random loss. The second is repair-only: a receiver on a lossy path holds both, and receives source packets once while adding layers 1 and 2 to the same decode.¶

A repair-only endpoint is never a media tier. A receiver MUST NOT treat one as a rendition or quality choice, and endpoint or ladder selection MUST exclude it on every path by which a receiver picks what to render. A repair-only endpoint's bandwidth ([MOQ-MULTICAST] Section 4.1) is the cost of adding repair to a stream the receiver has already selected, not the cost of an alternative rendition, and MUST NOT be compared against a media endpoint's bandwidth when choosing one.¶

A receiver joins a repair-only endpoint on measured loss: the rate at which its FEC blocks fail to recover, and the margin by which recovering blocks consume the repair symbols available to it. A receiver MUST NOT use goodput, throughput, or estimated available bandwidth to decide whether to add or drop a repair layer. The capacity check that Section 7.4 of [MOQ-FEC-CORE] recommends before a layer is added is the one exception: it can withhold an add that measured loss calls for, but it is neither a trigger for adding a layer nor a reason to drop one.¶

Layer changes are make-before-break. A receiver MUST join the additional layer's endpoint and begin receiving from it before leaving any endpoint it currently holds, so that no source block is left with less coverage than the receiver already had. A layer whose endpoint the receiver has left is carried on no endpoint it holds, reachable over MoQ unicast as above; under the bc-provenance profile of [MOQ-MULTICAST] Section 7.2 a receiver holds an endpoint while joined to its group, reading its manifest track or receiving the broadcast that carries the flow (its Section 7.2.9), and a consumer is protected under that endpoint's flow only while the receiver holds it (step 2 of [MOQ-MULTICAST] Section 7.2.7).¶

Hysteresis MUST derive from the FEC block span, that is from interleaveDepthMs together with reorderToleranceMs, and MUST NOT come from a fixed timer or a fixed symbol count. A receiver MUST observe at least one full block span at the new layer set before making a further layer change.¶

That loss measure and this hysteresis both need a block deadline, which exists only for a positive interleaveDepthMs (Section 9.3 of [MOQ-FEC-CORE]). On a multicast or AMT leg, a receiver of a track whose catalog omits that field or sets it to zero MUST NOT add or drop a repair layer of the track on block-recovery evidence, and keeps its repair-layer selection for the track fixed. This is an exception to the layer addition that Section 7.4 of [MOQ-FEC-CORE] recommends when a block fails to recover: without a signaled span a receiver has only a deadline of its own (its Section 9.3), and on a multicast or AMT leg this document does not let it change layers on that basis.¶

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 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 (Section 14.4 of [MOQ-FEC-CORE]).¶

5. Provisional Blocks and Admitted Packets

The bc-provenance profile of [MOQ-MULTICAST] Section 7.2 decides, in step 2 of its receiver procedure (its Section 7.2.7), which packets of a protected flow a consumer admits. This section specifies what a receiver does with the blocks and symbols that the profile has not admitted; it adds no admission rule of its own. The block and short-block rules that it qualifies are those of Section 5.4 of [MOQ-FEC-CORE], the fail-closed layer check is that of Section 7.3.2, the Group-range FETCH is that of Section 7.7, and the block deadline and receiver-state policy are those of Sections 9.3 and 9.4.¶

6. 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.3 of [MOQ-FEC-CORE]). A receiver on a reliable MoQ/QUIC leg relies on transport retransmission (Section 3.3 of [MOQ-FEC-CORE]) and does not need it, and nothing in this section adds a deadline or a timer to such a leg. Multicast and AMT legs carry only mmtp tracks ([MOQ-MULTICAST] Section 5; Section 3.3), so this section, which classifies blocks from MMTP fields, concerns tracks under iso-ssbg1-v1.¶

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.3 of [MOQ-FEC-CORE]). 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 5.5 of [MOQ-FEC-CORE]), with open-block state bounded by the local policy of Section 9.4 of [MOQ-FEC-CORE] and Section 5.4. 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 6.2), and other loss is concealed as in Section 6.3 and Section 6.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 5.5 of [MOQ-FEC-CORE]), up to the block's FEC deadline. Within a consumer that the bc-provenance profile of [MOQ-MULTICAST] Section 7.2 governs for its blocks (Section 5.1), a symbol of an unlisted track (Section 5.1) enters a decode only as step 2 of [MOQ-MULTICAST] Section 7.2.7 allows, which takes none into a decode of a block that two decodes with such symbols' help have left unrecovered; the attempt continues from the symbols the profile admits. 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 5.4 of [MOQ-FEC-CORE]), and decoding from the symbols it holds has not recovered them. Within such a consumer, a source symbol the profile has not admitted, received or recovered, is not held for this purpose (step 2 of [MOQ-MULTICAST] Section 7.2.7).¶

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 5.4 of [MOQ-FEC-CORE]). For this section the receiver treats such a run as one block of the instance (within a consumer that the bc-provenance profile of [MOQ-MULTICAST] Section 7.2 governs for its blocks, Section 5.1, a block only symbols of an unlisted track have delimited being no block the receiver has delimited, and the run one only once a packet the profile has admitted lies above it, step 2 of [MOQ-MULTICAST] Section 7.2.7): Section 6.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.7 of [MOQ-FEC-CORE], 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 6.2).¶

7. Security Considerations

The security considerations of [MOQ-FEC-CORE] and of [MOQ-MULTICAST] apply. Join authorization for repair-layer endpoints and the amplification exposure of layers are covered in Section 4.¶

When FEC is used over multicast (SSM/AMT), which carries only mmtp tracks under iso-ssbg1-v1 ([MOQ-MULTICAST] Section 4.1; Section 3.3), additional considerations apply:¶

1. No QUIC Protection: Multicast UDP has neither the confidentiality nor the integrity of QUIC. A publisher that needs confidentiality SHOULD encrypt the media samples, for example with Common Encryption [ISO.23001-7] and its 'cbcs' scheme, as [MOQ-MMT] Section 14 describes for mmtp tracks. All receivers of the flow share the content keys, which reach each receiver over its unicast MoQ session or from a Digital Rights Management (DRM) system. Sample encryption leaves the MMTP headers and the Source FEC Payload ID in the clear and leaves every packet identical across paths, so FEC encodes the ciphertext (Section 14.1 of [MOQ-FEC-CORE]) and symbols still combine across paths (Section 5.5 of [MOQ-FEC-CORE]). Encrypting each MoQ object payload instead, as MoQ Secure Objects [I-D.ietf-moq-secure-objects] does, would make the MoQ copy of a packet differ from its multicast copy. A keying handshake per receiver, such as DTLS-SRTP, needs a return path and cannot key a one-to-many flow. A key that every receiver holds does not authenticate the publisher; item 3 covers authentication.¶

2. Repair Injection: Attackers could inject malicious repair symbols on multicast networks. The bc-provenance profile of items 3 and 5 is the mitigation: a receiver that enforces it admits a symbol only when its digest is in a verified manifest, so an injected symbol never enters a decode; a receiver that does not enforce it has, beyond the container parsing of its media pipeline, only the block-level checksum of item 4 where it implements one.¶

3. Source Authentication: SSM limits which sources reach a receiver ([MOQ-MULTICAST] Section 7.1), and version 2 of the bc-provenance profile ([MOQ-MULTICAST] Section 7.2) authenticates the datagrams themselves, repair symbols included, with a digest that covers the whole UDP payload, the Source FEC Payload ID included (Section 7.2 of [MOQ-MMT]).¶

4. Block Integrity: Receivers MAY implement block-level checksums to detect corrupted recovery. A block whose decoded source data fails such a check, or, within a consumer that the bc-provenance profile of [MOQ-MULTICAST] Section 7.2 governs for its blocks (Section 5.1), whose recovered packets step 2 of its Section 7.2.7 does not admit, is unrecovered: Section 6 governs it from its FEC deadline, and the receiver requests unicast repair for it only as that section directs, never by the multicast-to-unicast failover of [MOQ-MULTICAST], which replaces the multicast path.¶

5. Repair Policy Inputs: The in-band evidence that Section 6.1 classifies blocks from, and the SSB_length by which Section 5.4 of [MOQ-FEC-CORE] 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 6.5). An injected source packet inside a block's gap can instead narrow the bounds of Section 6.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 5.4 of [MOQ-FEC-CORE]). Deployments exposed to injection SHOULD authenticate source and repair packets with an integrity mechanism whose coverage includes the complete packet, the Source FEC Payload ID and the Repair FEC Payload ID included (Section 7.2 of [MOQ-MMT]). Version 2 of the bc-provenance profile ([MOQ-MULTICAST] Section 7.2) is such a mechanism: its digest covers the whole UDP payload of source and repair packets, both Payload IDs included.¶

8. IANA Considerations

This document has no IANA actions.¶

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

This appendix is informative. It lists what this document takes from [I-D.ramadan-moq-fec] and every sentence that is new or changed rather than carried.¶

Moved here, by section of this document:¶

• Section 3: -01 Section 11 and, as its second paragraph, the last paragraph of -01 Section 5.2 (control messages cannot reach multicast or sessionless receivers).¶
• Section 3.1: -01 Section 11.1.¶
• Section 3.2: -01 Section 11.2, without its last paragraph (the moq-object-v1 scoping that the core supersedes), which Section 3.3 replaces.¶
• Section 3.3: new.¶
• Section 3.4: -01 Section 11.3.¶
• Section 4: -01 Section 6.3.6 and the second and third paragraphs of -01 Section 14.3 (join authorization for repair-layer endpoints). The multicast rule of -01 Section 5.1 (no block classification, no unicast repair and a fixed layer selection without a positive interleaveDepthMs) is restated by this section's last paragraph and by Section 6.¶
• Section 5: the bc-provenance clauses of -01 Sections 7.4 (provisional blocks), 6.3.9 (anchoring of the fail-closed layer check), 7.5 (S_prev) and 9 (ts anchoring, discard policy).¶
• Section 6 and its subsections: -01 Sections 11.4 to 11.4.6.¶
• Section 7: -01 Section 14.4.¶
• Appendix "Acknowledgements": -01 Appendix E.¶

Changed sentences:¶

• In Section 3.1, "A multicast endpoint carries only mmtp tracks, so a loc or cmaf track under moq-object-v1 reaches multicast through an mmtp rendition track" now reads "A multicast endpoint carries only mmtp tracks, so a loc or cmaf track reaches multicast through an mmtp rendition track" and points at Section 3.3.¶
• In Section 3.4, "Item 1 assumes iso-ssbg1-v1, under which one MMTP packet is one source symbol. This document defines no multicast carriage for moq-object-v1 (Section 7.6.6)." now reads "Item 1 assumes iso-ssbg1-v1, under which one MMTP packet is one source symbol; Section 3.3 states that this is the only block profile a multicast endpoint carries in this revision."¶
• In Section 3.4, the four occurrences of "this scheme" in the -01 Section 11.3 text ("below this scheme", "This scheme can serve", "When this scheme is carried", "A publisher using this scheme") now read "this mechanism", because "scheme" is the core's term for the FEC code (Section 2 and Section 10.1 of [MOQ-FEC-CORE]).¶
• In Section 4, "Multicast endpoints carry only mmtp tracks and their repair tracks ([MOQ-MULTICAST] Section 4.1), so this subsection concerns tracks under iso-ssbg1-v1" now cites Section 3.3, and "the decoder of the source track that layer depends on" now reads "the decoder of the FEC instance that layer serves, the one its source and instanceId name", per the core's data model.¶
• In Section 4, "An endpoint whose track list contains only fec-repair tracks is a repair-only endpoint" gains the parenthesis "(the packaging value of [MOQ-FEC-CATALOG])".¶
• In Section 4, the two sentences of -01 Section 14.3 on receivers not being made to receive a layer they did not join now end with a citation of the core's amplification section.¶
• In Section 5.1, the -01 sentence that defined the governed consumer, the unlisted track and the provisional block is now three paragraphs: the first defines the consumer the profile governs for its blocks, and "is for this paragraph, Section 9 and Section 11.4 a consumer outside that profile" now reads "is, for this section, Section 5.4 and Section 6, a consumer outside the profile"; the second defines the unlisted track; the third states the provisional block. "the rules of the previous paragraph then apply among admitted packets" now reads "the fail-closed consistency rules of [MOQ-FEC-CORE] then apply among admitted packets".¶
• In Section 6.5, the non-keyframe FETCH rule names the priorities it compares: the FETCH's SUBSCRIBER_PRIORITY against the Publisher Priority of the repair track it fetches, citing the core.¶
• In Section 7, item 2 names the bc-provenance profile of items 3 and 5 as the mitigation for repair injection, in place of "checking that decoded data matches expected patterns".¶
• In Section 5.2, "whether or not that profile governs it for its blocks (Section 7.4)" now cites Section 5.1.¶
• In Section 5.2, "so that a relay on that path cannot stop FEC for the source track with one packet" now reads "so that a relay on that path cannot stop FEC for the instance with one packet", per the core's data model.¶
• In Section 5.4, the -01 Section 9 sentences that require a receiver to bound the state it holds for open blocks by a receiver-local policy (a memory cap, a local timeout, or a later block past its own deadline), forbid the policy to discard a block before its FEC deadline or while a unicast repair FETCH for it is outstanding except under a memory cap, and require the receiver to keep the policy separate from the catalog values are replaced by "A receiver bounds the state it holds for open blocks by the receiver-local policy of Section 9.4 of [MOQ-FEC-CORE], which forbids discarding a block that has an FEC deadline before that deadline, or while a FETCH for it is outstanding, the unicast repair FETCH of Section 6.2 included, except under a memory cap. A block so discarded is, under that section, treated from then on as having reached its FEC deadline unrecovered and, on a track whose blocks Section 6.1 classifies, of unknown class." and "The policy is not signaled and is kept separate from the configured values (Section 9.4 and Section 9.3 of [MOQ-FEC-CORE]): it changes neither interleaveDepthMs nor reorderToleranceMs nor a deadline derived from them, and discarding a block under it does not create an FEC deadline (Section 6).", because the requirements themselves are the core's; this document keeps only their consequences on a multicast or AMT leg.¶
• In Section 6.5, "where P_t is the total repair count of its base instance (Section 6.4.1)" now reads "where P_t is the total repair count of its base instance, the sum of P_i over its published layers ([MOQ-FEC-CORE])", and "in the Source Media range" now reads "in the source track range", the core's name for the 64-191 range.¶
• In Section 6.6, "The keyframe overlay of Section 6.4 and this policy are complementary" now reads "The keyframe overlay of [MOQ-MMT], an overlapping instance in the sense of [MOQ-FEC-CORE], and this policy are complementary".¶
• In Section 7, the preamble "When FEC is used over multicast (SSM/AMT), which carries only mmtp tracks under iso-ssbg1-v1 ([MOQ-MULTICAST] Section 4.1), additional considerations apply" is preceded by two new sentences (below).¶
• In Appendix "Acknowledgements", "Marc E. Fiuczynski reviewed this revision and reported how relays and MoQ Transport stacks of the time handle datagram-delivered repair objects (Sections 7.5, 10 and 11.4.2)." now reads "Marc E. Fiuczynski reviewed draft-ramadan-moq-fec-01 and reported how relays and MoQ Transport stacks of the time handle datagram-delivered repair objects, which shaped the FETCH behavior of Section 6.2 and the priority rules of Section 6.5". -01 Sections 7.5 and 10 are now sections of [MOQ-FEC-CORE].¶
• Every citation of a section of draft-ramadan-moq-fec-01 is re-pointed at the section of [MOQ-FEC-CORE], [MOQ-FEC-CATALOG] or [MOQ-MMT] that now holds it, and every intra-document reference at the section of this document.¶

New sentences:¶

• The Abstract, Section 1 and Section 1.1 are new.¶
• In Section 2: the paragraph "The terms below are used in this document with the meaning that [MOQ-FEC-CORE] gives them; every other term of that document, and of [MOQ-MULTICAST], keeps its meaning there."; the definitions of Base Instance, FEC Deadline, Multicast Endpoint, and Unlisted Track and Admitted Packet; the sentence "Layer i may use RS_IDs from its RS_ID offset O_i, and carries P_i repair symbols per block." in the definition of Repair Layer; and the sentence "Under iso-ssbg1-v1 a source symbol is one FEC source packet, an MMTP packet framed as [MOQ-MMT] specifies." in the definition of Source Symbol. Five definitions are not copied whole: Repair Track joins the core's definition to the iso-ssbg1-v1 clauses of -01 Section 2, without the moq-object-v1 clause, the ISO 3.1.7 and 3.1.9 term citations and the -01 Section 6.3 and 6.4 pointers, and cites [MOQ-MMT] at the AL-FEC message, where -01 cited it after "only the catalog declares"; Keyframe Overlay reads "over an MMTP-packaged source track", drops "with its own source symbol count, its own repair symbols, and its own repair track" and the scope keyframe declaration, drops the sentence "It is defined only under iso-ssbg1-v1.", and cites [MOQ-MMT] in place of -01 Section 6.4; Interleave Depth drops "the catalog form of protection_window_time in [ISO.23008-1] Sections 11.2 and C.6.3" and the moq-object-v1 clause; Source Symbol carries only the first sentence of the core's definition; and SS_Start and SSB_length carries only the first sentence of -01's. The other definitions are copied from Section 2 of [MOQ-FEC-CORE] or of draft-ramadan-moq-fec-01.¶
• In Section 3: "The catalog's authority over FEC configuration ([MOQ-FEC-CORE]) holds uniformly across a MoQ receiver's delivery paths, its multicast and AMT legs included." (reworded from -01 Section 5.2, which named the catalog fec object).¶
• In Section 3.2: "Which tracks a multicast endpoint carries in this revision, and so which of the core's carriages reach a multicast leg, is stated in Section 3.3."¶
• Section 3.3 is new in its entirety, including its Editor's Note.¶
• In Section 4, after the sentence that forbids a receiver to use goodput, throughput, or estimated available bandwidth to decide whether to add or drop a repair layer: "The capacity check that [MOQ-FEC-CORE] recommends before a layer is added is the one exception: it can withhold an add that measured loss calls for, but it is neither a trigger for adding a layer nor a reason to drop one." The core's receiver selection adds that check, which -01 Section 6.3.5 did not have, and this sentence reconciles the -01 Section 6.3.6 rule with it.¶
• In Section 4, after "keeps its repair-layer selection for the track fixed": "This is an exception to the layer addition that [MOQ-FEC-CORE] recommends when a block fails to recover: without a signaled span a receiver has only a deadline of its own, and on a multicast or AMT leg this document does not let it change layers on that basis."¶
• In Section 5: the preamble paragraph, and the first sentence of each of Section 5.2, Section 5.3 and Section 5.4, which name the core rule that the carried clause qualifies.¶
• In Section 6: the citation "([MOQ-MULTICAST]; Section 3.3)" added to "Multicast and AMT legs carry only mmtp tracks", and "and Section 5.4" added to the local-policy citation.¶
• In Section 6.1: the first paragraph, which scopes the section to tracks under iso-ssbg1-v1, names [MOQ-MMT] for the fields, and states that the classification is a receiver-side repair-ordering policy on MMTP packet headers and not instance membership, so that it does not conflict with the core's rule that receivers never classify media for FEC membership or for the repair they take, and that what it decides is only the order and budget of per-block unicast repair, which the core leaves to the receiver.¶
• In Section 7: "The security considerations of [MOQ-FEC-CORE] and of [MOQ-MULTICAST] apply." and "Join authorization for repair-layer endpoints and the amplification exposure of layers are covered in Section 4."¶
• Section 8: "This document has no IANA actions."¶
• In Appendix "Acknowledgements": "He proposed the division of draft-ramadan-moq-fec-01 into the core document and its companions, of which this document is one."¶

Acknowledgements

Marc E. Fiuczynski reviewed draft-ramadan-moq-fec-01 and reported how relays and MoQ Transport stacks of the time handle datagram-delivered repair objects, which shaped the FETCH behavior of Section 6.2 and the priority rules of Section 6.5. He proposed the division of draft-ramadan-moq-fec-01 into the core document and its companions, of which this document is one.¶

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

Author's Address