MoQ Feedback

1.1. 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 following terms are used throughout this document:¶

• MOQT: Media over QUIC Transport, following [MoQTransport].¶

• Object: The smallest semantic unit of data delivery in MOQT.¶

• Relay: A MoQ node that forwards a media Track between its publisher and subscribers, following [MoQTransport].¶

• Media Original Publisher: The Original Publisher, as defined by [MoQTransport], of the media Track associated with a Feedback Track.¶

• Adjacent Media Publisher: The Publisher from which a Subscriber receives the associated media Track on a particular MOQT session. It can be a Relay or the Media Original Publisher.¶

• Feedback Publisher: The Publisher of a Feedback Track, typically a Subscriber of the associated media Track.¶

• Feedback Track: A MoQ Track that carries MMF feedback.¶

• Feedback Type: A Relay-visible Track Property that identifies whether a Feedback Track terminates at the Adjacent Media Publisher or is delivered to the Media Original Publisher.¶

• MMF (MoQ Multimodal Feedback): A receiver report at the MoQ layer containing per-Object delivery status.¶

• Cross-Layer Control Interface: A mechanism for the MoQ layer to issue control commands to CC algorithms; the specific form is implementation- defined.¶

2.1. Feedback Improves QoE in Relay-Based Scenarios

In relay-based audio/video conferences, media can traverse a cascade of multiple relays before reaching participants. Adaptive bitrate is commonly used in such topologies to preserve the participants' quality of experience (QoE) as downstream path conditions change. Implementations can support adaptive bitrate in two ways:¶

• Representation tiers at the Media Original Publisher: The Media Original Publisher transcodes the media into multiple resolution and bitrate tiers, allowing a suitable tier to be selected for each participant. This approach is appropriate for conferences with many participants because the tiers can be shared. In a small conference with only two or three participants, however, most tiers may remain unused, making their transcoding cost a waste of resources.¶

• Multi-level feedback-driven adaptation: The last-hop Relay combines participant feedback with its local forwarding context and generates feedback that is meaningful to the Media Original Publisher. The Media Original Publisher considers this information when choosing an appropriate source bitrate. This approach avoids generating unused tiers and is suitable for small conferences or when the Media Original Publisher does not provide tiered transcoding.¶

By exposing delivery quality across the relay topology, MMF can support the second approach and help the Media Original Publisher make bitrate decisions before late or lost Objects degrade participant QoE.¶

3.1. Three-Layer Architecture: Application / MoQ / Transport

This mechanism adopts a three-layer architecture: the application layer serves as the media source, the transport layer implements CC algorithms, and the MoQ layer resides in between, responsible for semantic understanding and signal distribution.¶

3.2. Dual-Layer Feedback Model: QUIC receive-ts and MMF

CC algorithms rely on per-packet delay signals for bandwidth estimation and congestion detection; this signal is provided by QUIC receive-ts ([quic-receive-ts]). MMF operates at the MoQ layer, forming a dual-layer feedback which could cooperate with QUIC receive-ts. Both mechanisms can be enabled simultaneously in implementations.¶

The two layers cover different granularities:¶

QUIC receive-ts provides per-packet inter-arrival delta, enabling CC algorithms to perform delay-based congestion detection and bandwidth estimation.¶

MMF supplements additional signals:¶

• Per-Object Signals: QUIC transport layer cannot determine whether an Object is complete or arrived within deadline. MMF provides per-Object status (RECEIVED_LATE, NOT_RECEIVED, etc.).¶

• Application-Layer Metrics: Playout headroom (PLAYOUT_AHEAD), receiver-side bandwidth estimation, etc.¶

3.3. Cross-Layer Control Interface

MoQ implementations could provide a cross-layer control interface that enables the MoQ layer to issue control commands to CC algorithms. The specific form of the interface is implementation-defined.¶

Distinct from approaches that pass raw data to CC algorithms for independent judgment, this mechanism could help the MoQ layer to achieve better performance. The MoQ layer possesses three kinds of information resource: MMF feedback, local CC output (BWE), and frame-level statistics (Section 9.1), achieving higher information completeness than CC algorithms alone.¶

CC algorithms could still run their own congestion detection logic, or adapted to accept control commands issued by the MoQ layer.¶

Control Commands:¶

MoQ Layer Decision Inputs:¶

The MoQ layer synthesizes the following signals for control decisions:¶

• MMF Signals (from peer): Object loss rate, expiration rate, Avg Inter-Arrival Delta, PLAYOUT_AHEAD_MS¶

• CC Output (from local): BWE, RTT, loss rate¶

• Frame-Level Statistics (from local, Section 9.1.3): per-Object transmission/loss/delivery duration¶

CC Algorithm Behavior:¶

CC algorithms SHOULD execute control commands after receiving them:¶

• Upon pacing_gain: Update sending rate as pacing_rate = BWE x pacing_gain¶

• Upon pacing_rate: Use this value directly as sending rate¶

• Upon target_bitrate: Record current application-layer sending budget for internal decision reference¶

When no control commands are issued by the MoQ layer, CC algorithms operate normally according to their own logic.¶

The cross-layer control interface is optional. CC algorithms that do not support this interface can still operate independently but cannot benefit from MMF-driven frame-level control capabilities.¶

3.4. Bidirectional MMF: Output Feedback and Input Feedback

The MMF report direction described in the preceding sections is from client to server, reporting delivery quality of downstream media (audio_response, text_response). In streaming input scenarios, the server simultaneously subscribes to upstream media (audio_input, video_input) and MAY establish a reverse feedback Track to report upstream media delivery quality to the client.¶

Client Server | | |----- audio_input ------------->| Server subscribes |<---- input feedback (MMF) -----| Server reports input delivery quality | | |<---- audio_response -----------| Client subscribes |-- output feedback (MMF) ------>| Client reports output delivery quality | | ¶

Output MMF (client-->server) and Input MMF (server-->client) use the same report format (Section 6). Their purposes differ:¶

• Output MMF: Server adjusts encoding bitrate, inference parameters, and CC based on it.¶

• Input MMF: Client adjusts upstream behavior based on it:¶

  • Audio Input: Adjust chunk size, encoding bitrate, transmission frequency¶

  • Video Input: Adjust frame rate, resolution, pause/resume¶

Input MMF is optional. Support of the input MMF is declared via bit-2 of the Setup Parameter bitmap. Input and output feedback independently use the Feedback Track naming and type rules in Section 5.¶

4.1. Cascaded Relay Architecture

In a cascaded Relay architecture, media from a Media Original Publisher traverses multiple Relays before reaching a Subscriber. The Subscriber is the feedback source, the Relay adjacent to the Subscriber can consume feedback for the last-mile path, and the Relay chain can carry a separate Feedback Track to the Media Original Publisher.¶

Media: Media Original Publisher -> ... -> L2 Relay -> L1 Relay -> Subscriber HOP_FEEDBACK: L1 Relay <- Subscriber ORIGIN_FEEDBACK: Media Original Publisher <- ... <- L2 Relay <- L1 Relay ¶

The following Feedback Tracks serve different consumers:¶

• A HOP_FEEDBACK Track terminates at the L1 Relay. It enables the L1 Relay to react to last-mile delivery conditions, for example by selecting an ABR Track, changing Object scheduling or priority, or adjusting pacing on the downstream connection.¶

• The L1 Relay MAY use received HOP_FEEDBACK together with its local media forwarding state to generate a new ORIGIN_FEEDBACK Track when required by application policy. It MUST NOT relabel or mechanically forward the HOP_FEEDBACK Objects as ORIGIN_FEEDBACK. The new report can provide the Media Original Publisher with context suitable for source bitrate, frame-rate, resolution, or generation-rate adaptation.¶

• An ORIGIN_FEEDBACK Track can traverse zero or more Relays. When Relays are present, its MMF Payload remains opaque to intermediate Relays. In a direct Subscriber-to-Media-Original-Publisher connection, the Subscriber can publish ORIGIN_FEEDBACK without an intervening Relay.¶

A Subscriber behind an L1 Relay SHOULD publish its feedback report to that Relay using HOP_FEEDBACK. A deployment MAY instead allow Subscriber-originated ORIGIN_FEEDBACK when the Media Original Publisher has sufficient context to interpret it.¶

The relative importance of the two Feedback Types depends on the application:¶

• Live streaming: The Media Original Publisher commonly provides an ABR ladder. The L1 Relay primarily consumes HOP_FEEDBACK and selects a representation suitable for the last-mile path.¶

• Audio/video conferencing: The Media Original Publisher might need feedback from every participant session, particularly when it does not provide an ABR ladder. ORIGIN_FEEDBACK gives the Media Original Publisher the information needed for source-rate adaptation. In large conferences, forwarding every participant report can produce a 1:N feedback implosion. A Relay performing aggregation acts as a new Feedback Publisher and publishes a distinct Feedback Track. The aggregation format and policy are outside the scope of this document.¶

Other applications include live-agent media between a user and an inference service, cloud rendering, and cloud gaming. These applications can use ORIGIN_FEEDBACK so that the source reacts directly to receiver QoE.¶

5.1. Track Definition

The Feedback Track is a normal MoQ Track where the Payload of each Object is an MMF. Each MMF is published as an independent Object with monotonically increasing Object ID within a Group.¶

Each Feedback Track has exactly one Feedback Type and MUST NOT mix HOP_FEEDBACK and ORIGIN_FEEDBACK. The type controls Track distribution and is carried in the Relay-visible MMF_FEEDBACK_TYPE Track Property. A feedback source that generates both types MUST publish two distinct Feedback Tracks.¶

The MMF_FEEDBACK_TYPE Track Property has a varint value:¶

Every Feedback Track MUST include the MMF_FEEDBACK_TYPE Track Property (TBD2) in its PUBLISH Track Properties. This Property is immutable for the lifetime of the Track. A Relay that recognizes it MUST NOT modify or remove it. A Relay that does not recognize it forwards and caches it according to the unknown Property rules in [MoQTransport]. An MMF-aware Relay uses this Property without inspecting MMF Object Payloads. A terminal feedback consumer that receives an unsupported value MUST reject the Feedback Track.¶

The Group division strategy for Feedback Track is implementation-defined. It is RECOMMENDED to use a single Group (Group ID = 0) with continuously incrementing Object IDs to simplify implementation.¶

Each Feedback Track MUST be associated 1:1 with a media Track. The association is encoded in the Feedback Full Track Name (Section 5.2) and is not repeated in MMF reports. This Full Track Name binding is the media Track binding mechanism defined by this document; no per-Object binding parameter is required.¶

When feedback is needed for multiple media Tracks, independent Feedback Tracks MUST be established separately.¶

Each feedback publisher or publication session MUST use a distinct Feedback Full Track Name. This prevents independent publishers from producing different Payloads for the same Group ID and Object ID on what MOQT would otherwise treat as a single Track.¶

5.2. Track Naming

The Feedback Full Track Name carries the information that Relays need to distribute a Feedback Track without inspecting Object Payloads. Let ++ denote appending fields to a Track Namespace tuple. A Feedback Track MUST use:¶

• Track Namespace: The media Track Namespace with three fields appended in this order: the literal mmf, the feedback type label, and the feedback source ID.¶

• Track Name: The Track Name of the associated media Track.¶

The feedback-type-label is the ASCII string hop-feedback for HOP_FEEDBACK or origin-feedback for ORIGIN_FEEDBACK. It enables Namespace prefix matching. The label MUST agree with the MMF_FEEDBACK_TYPE Track Property. A node that detects a mismatch MUST reject the Feedback Track.¶

The feedback-source-id is an opaque, non-empty byte string selected by the Feedback Publisher. It MUST distinguish that publisher and publication session from every other Feedback Publisher and session for the associated media Track. It is not required to identify a user and MUST NOT be interpreted as a user identity. A publisher MUST select a new value before reusing a Group ID and Object ID pair or restarting its Report Sequence space.¶

For example, feedback for media Full Track Name (example.com, meeting, audio_response) can use:¶

(example.com, meeting, mmf, hop-feedback, receiver-17, audio_response) (example.com, meeting, mmf, origin-feedback, relay-l1-4, audio_response) ¶

The same naming construction applies to output and input feedback. The media Track being reported determines the direction; a separate Track Name prefix is not used.¶

A node receiving a PUBLISH for a Feedback Track reconstructs the associated media Full Track Name by removing the final three Namespace fields and retaining the Feedback Track Name. If it cannot identify the associated media Track or does not support the indicated type, it SHOULD respond with REQUEST_ERROR.¶

5.3. Track Establishment and Lifecycle

The Feedback Track is established by the feedback generator (a media receiver or a Relay generating new feedback) as Publisher through MOQT's PUBLISH / PUBLISH_OK negotiation.¶

For a HOP_FEEDBACK Track, the terminal feedback consumer is the Adjacent Media Publisher on that MOQT session. The consumer accepts the PUBLISH and MUST NOT advertise or forward that Feedback Track on another MOQT session.¶

An L1 Relay that generates ORIGIN_FEEDBACK is a new Feedback Publisher. It uses a new Feedback Full Track Name, Report Sequence space, and MMF Payload. It can derive that Payload from HOP_FEEDBACK, local media transmission state, and application policy.¶

An ORIGIN_FEEDBACK type does not create a route by itself. Before feedback Objects can be delivered, an interest and authorization chain MUST be established between the Media Original Publisher and the Feedback Publisher:¶

1. The Media Original Publisher, acting as a Feedback Subscriber, expresses interest in the origin-feedback Namespace for the media Track. It can use SUBSCRIBE_NAMESPACE for the corresponding Namespace prefix, or use deployment-specific prior interest and authorization as permitted by [MoQTransport].¶

2. Each intermediate Relay binds the Feedback Track to the media forwarding state identified by Section 5.2. It propagates feedback interest only to downstream peers to which it forwards the associated media Track. Feedback Objects travel in the opposite direction, toward the peer from which the Relay received that media Track.¶

3. The Feedback Publisher sends PUBLISH for its unique Feedback Full Track Name. Each hop uses the PUBLISH / PUBLISH_OK and SUBSCRIBE / SUBSCRIBE_OK procedures in [MoQTransport] to establish forwarding with Forward State 1.¶

PUBLISH_NAMESPACE is not a route discovery mechanism. A Relay MUST NOT use it to search a richly connected Relay topology for a path to the Media Original Publisher. A Relay forwards ORIGIN_FEEDBACK only toward the peer from which it received the associated media Track, and MUST NOT forward it back toward the feedback publisher or another downstream media peer. If there is no unique reverse media-path binding, the Relay MUST reject the Feedback Track. These rules prevent a feedback loop in the single-upstream media topology defined by this document.¶

If any hop has no matching interest, lacks authorization, has no media-path binding, or rejects the request, that hop MUST reject establishment using the applicable MOQT request error. The Feedback Publisher MUST NOT send MMF Objects until its PUBLISH is accepted. It MAY continue or fall back to a separately established HOP_FEEDBACK Track, but it MUST NOT relabel a rejected Track to bypass the failure.¶

Relays route both Feedback Track types solely from the Full Track Name and MMF_FEEDBACK_TYPE Track Property. In accordance with [MoQTransport], the Object Payload is opaque to a Relay and is not processed to make a forwarding decision. An ORIGIN_FEEDBACK MMF Payload can therefore be protected between the Feedback Publisher and the Media Original Publisher. A HOP_FEEDBACK MMF Payload can be protected for its adjacent terminal feedback consumer.¶

Direct Establishment Flow Example:¶

Media Receiver Media Original Publisher (Media Subscriber / (Media Publisher / Feedback Publisher) Feedback Subscriber) | | | SUBSCRIBE(track=audio_response) | (1) Subscribe media Track |----------------------------------->| | SUBSCRIBE_OK | |<-----------------------------------| | | | PUBLISH( | (2) Publish origin-feedback Track | namespace=media_namespace ++ | | ("mmf", "origin-feedback", | | "receiver-17"), | | track=audio_response, | | property=MMF_FEEDBACK_TYPE(1)) | |----------------------------------->| | PUBLISH_OK | |<-----------------------------------| | | | [Object: MMF seq=0] | (3) Send MMF |----------------------------------->| | [Object: MMF seq=1] | |----------------------------------->| | ... | ¶

Lifecycle Rules:¶

The Feedback Track lifecycle SHOULD align with the subscribed media Track it covers. After the media Track publisher sends PUBLISH_DONE for the media Track, the Feedback Track publisher (i.e., the media receiver) SHOULD send PUBLISH_DONE for the Feedback Track after transmitting the final MMF and stop publishing Objects.¶

When a MOQT session carrying a Feedback Track is disconnected, a Relay MUST discard the associated forwarding state and MUST NOT re-advertise the old Feedback Track after reconnecting. The Feedback Publisher establishes a new Feedback Track with a new feedback-source-id; its Report Sequence SHOULD restart from 0.¶

Feedback is time-sensitive. A Feedback Publisher SHOULD use the MAX_CACHE_DURATION Track Property defined by [MoQTransport] to bound the period for which MMF Objects can be served from cache. A terminal feedback consumer MUST NOT apply an MMF from a previous publication session.¶

5.4. Transport and Priority

The Feedback Track SHOULD be carried over QUIC Stream (consistent with ordinary MoQ Objects).¶

The Subscriber Priority for Feedback Track SHOULD be set lower than media Tracks ([MoQTransport], Section 7). Example priority assignment:¶

When bandwidth contention occurs, media data SHOULD take precedence over feedback data transmission.¶

6.1. Report Structure

MoQ Multimodal Feedback { Report Timestamp (i), Report Sequence (i), Object Entry Count (i), Object Entry (..) ..., Summary Stats (..), Optional Metric Count (i), Optional Metric (..) ..., } ¶

The MMF format version is negotiated via Setup Parameter (Section 7.1) and is not repeated in each report. This document defines version 0.¶

Each MMF reports Object delivery status for a single media Track associated with its Feedback Track (1:1 association, see Section 5.1).¶

Report Timestamp (varint): The moment when the report is generated, using receiver's local monotonic clock value in microseconds. This value is only used for Receive Timestamp Delta chain anchoring and report ordering, not for cross-end time alignment. Monotonic clock MUST be used.¶

Report Sequence (varint): Monotonically increasing from 0 independently for each Feedback Track. A gap can indicate an omitted report only when the publication policy for that Track requires a contiguous Report Sequence. An Object ID gap alone, without a Prior Object ID Gap property as defined by [MoQTransport], MUST NOT be interpreted as feedback loss. Because HOP_FEEDBACK and ORIGIN_FEEDBACK use separate Tracks, terminating one type cannot create sequence gaps in the other type's sequence space.¶

Object Entry Count (varint): Number of Object Entries that follow. When the value is 0, the report contains only Summary Stats (for heartbeat purposes).¶

6.2. Object Entry

Object Entry { Group ID (i), Object ID (i), Status (i), [Receive Timestamp Delta (i)], } ¶

Object Entries within the same MMF MUST be sorted in ascending order by (Group ID, Object ID).¶

6.3. Delivery Status Codes

6.4. Summary Stats Block

Summary Stats { Report Interval (i), Total Objects Evaluated (i), Objects Received (i), Objects Received Late (i), Objects Lost (i), Avg Inter-Arrival Delta (i), } ¶

Summary Stats MUST always be included in every MMF, not controlled by negotiation bitmap. It provides windowed aggregate information, enabling lightweight CC consumers that do not parse Object Entry to obtain effective signals. The MoQ layer can compute control decisions based on this block and issue them to CC algorithms via the cross-layer control interface (Section 3.3).¶

The Report Interval window of Summary Stats is independent from the coverage of Object Entries. Object Entries MAY include Objects outside the Report Interval window (e.g., continuously reported NOT_RECEIVED entries, see Section 8.4).¶

6.5. Optional Media Metrics

Optional Media Metrics immediately follow Summary Stats. Optional Metric Count (varint) specifies the number of subsequent Optional Metrics; a value of 0 indicates no optional metrics are included.¶

Each metric uses Key-Value-Pair encoding (draft-ietf-moq-transport-17, Section 1.4.2):¶

Optional Metric { Metric Type (i), Metric Value (i), } ¶

Defined metric types are divided into two categories: Application-Layer Metrics and QUIC Layer Summary Metrics.¶

Application-Layer Metrics:¶

QUIC Layer Summary Metrics:¶

The following metrics expose the receiver's local QUIC connection transport state to the sender for CC algorithm cross-validation.¶

MMF's core CC signals rely on Receive Timestamp Delta in Object Entry (Section 6.2.3, referencing QUIC receive-ts / WebRTC TWCC per-packet delta encoding approach) and Summary Stats (Section 6.4), not Optional Metrics. Optional Metrics serve only as supplements.¶

Type values 0x00-0x1f are reserved for this specification. Values 0x20 and above are available for application-layer custom use.¶

Receiver MUST ignore unrecognized Metric Types.¶

Optional Media Metrics MAY be included in MMF only when both parties have declared bit1=1 in Setup negotiation (Section 7). When not negotiated or bit1=0, Optional Metric Count MUST be 0.¶

6.6. Report Size Control

A single MMF is RECOMMENDED not to exceed 1200 bytes to avoid QUIC packet fragmentation.¶

When the number of Objects to report exceeds the capacity of a single MMF, receiver SHOULD:¶

• Prioritize including recent Object Entries (largest media Object locations).¶

• Trim the oldest Object Entries.¶

• Ensure Summary Stats covers the complete Report Interval window (Summary Stats is not affected by Object Entry trimming).¶

7.1. Setup Parameter

During MOQT Setup phase, both parties declare Multimodal Feedback capability via Setup Parameter.¶

MOQT_MULTIMODAL_FEEDBACK Setup Parameter { Type = TBD1 (i), Length (i), Value (i), } ¶

The Value field is a capability bitmap (varint) with the following bit definitions:¶

Negotiation Example:¶

Client Server | | | CLIENT_SETUP( | | version=16, | | params=[ | | {type=0x00, value=0x02}, | (ROLE=Publisher) | {type=TBD1, value=0x03} | (MULTIMODAL_FEEDBACK: bit0|1=1) | ]) | |----------------------------------->| | | | SERVER_SETUP( | | version=16, | | params=[ | | {type=0x00, value=0x03}, | (ROLE=PubSub) | {type=TBD1, value=0x01} | (MULTIMODAL_FEEDBACK: bit0=1) | ]) | |<-----------------------------------| | | | Negotiation Result: | | bit0=1 (Output Feedback) | | bit1=0 (Client declared but | | Server did not, | | Optional Metrics disabled) | ¶

7.2. Capability Negotiation Rules

Feature enable conditions (both parties MUST declare corresponding bit as 1):¶

When a feature is not enabled:¶

• Receiver MUST NOT publish Feedback Track in corresponding direction.¶

• When sender receives PUBLISH request for Feedback Track in un-negotiated direction, it SHOULD respond with REQUEST_ERROR (draft-ietf-moq-transport-17, Section 9.8).¶

• MMF MUST NOT include un-negotiated optional fields (e.g., Optional Metrics).¶

The Setup Parameter is required for an endpoint that generates or consumes MMF. An intermediate Relay that only forwards an ORIGIN_FEEDBACK Track does not need to parse MMF or negotiate an additional Feedback Type capability. It forwards the MMF_FEEDBACK_TYPE Track Property according to the unknown Property rules in [MoQTransport].¶

7.3. Behavior When Parameter Not Declared

When peer's Setup does not include MOQT_MULTIMODAL_FEEDBACK Parameter, it is equivalent to Value=0 (no Multimodal Feedback capability supported).¶

This end MUST NOT proactively establish Feedback Track.¶

7.4. Runtime Capability Change

This version does not support runtime changes to Multimodal Feedback capability. If change is needed, MoQ session MUST be re-established.¶

8.1. Arrival Time Recording

Receiver MUST record the arrival time of each Object. Arrival time is defined as the moment when the last byte of the Object arrives at the receiver's MoQ layer. Implementation MUST use monotonic clock, unaffected by system time adjustments. Time precision SHOULD be no less than 1 millisecond, RECOMMENDED to be microsecond-level.¶

8.2. Delivery Status Determination

Receiver MUST maintain delivery status for each known Object:¶

• Last byte of Object arrives and within deadline: RECEIVED (0x00).¶

• Last byte of Object arrives but exceeds deadline: RECEIVED_LATE (0x01).¶

• Object has not arrived but is reasonably considered lost (see Section 6.3): NOT_RECEIVED (0x02).¶

• Object partially arrived and carrying Stream is closed: PARTIALLY_RECEIVED (0x03).¶

Object status MAY be updated in subsequent MMF. For example, from NOT_RECEIVED to RECEIVED (when a delayed Object is eventually received). Therefore, counts such as Objects Lost in Summary Stats reflect an observation snapshot at report generation time and are not guaranteed to be consistent with final statistics. Sender SHOULD use them as immediate signals rather than precise statistics.¶

8.3. MMF Generation Frequency

Receiver SHOULD generate MMF at the following recommended frequencies:¶

Generation frequency SHOULD NOT exceed once per 50ms (to avoid feedback itself consuming excessive bandwidth). Generation frequency SHOULD NOT be lower than once per 2s (to ensure sender receives timely feedback).¶

When receiver detects rapid deterioration in delivery quality (e.g., consecutive Object losses), it MAY immediately generate an additional MMF (without waiting for the scheduled cycle) to accelerate sender response.¶

8.4. Object Entry Selection

When generating MMF, receiver SHOULD follow these Object Entry selection strategies:¶

• Prioritize covering recent Objects (most recent in time).¶

• Total number of Object Entries per MMF is RECOMMENDED not to exceed 50.¶

• For Objects already reported in previous MMF with unchanged status, they MAY be omitted.¶

• Objects with status NOT_RECEIVED SHOULD be continuously reported (for at least 3 MMF cycles) until status changes or exceeding the report window.¶

8.5. Exception Handling

• Object Out-of-Order Arrival: Receiver MUST record by actual arrival time without reordering. Arrival time reflects actual network behavior; out-of-order itself is a valid network signal.¶

• Duplicate Objects: Receiver SHOULD identify duplicates by Group ID and Object ID, ignore duplicate arrivals, and retain the first arrival time.¶

• Feedback Track Publish Failure: Receiver SHOULD retry establishing Feedback Track with backoff strategy. Retry interval is RECOMMENDED to use exponential backoff (initial 1s, maximum 30s).¶

9.1. Object to QUIC Packet Mapping

If a sender needs to correlate MMF feedback with local transmission events, it MUST maintain the mapping relationship between media Object coordinates (Full Track Name, Group ID, and Object ID) and QUIC packets. Without this mapping, the sender cannot determine the number of packets, packet loss count, and delivery duration for a single video frame, and the per-Object status reported by MMF cannot be aligned with sender-side statistics.¶

9.2. Application-Layer Consumption

After the sender's MoQ layer receives MMF, it exposes the following information to the inference scheduler/ABR through application-layer callbacks:¶

• Delivery quality (loss rate, expiration rate) of the associated media Track¶

• Per-Object status and timestamps (can be used for detailed analysis)¶

• Optional media metrics (playout headroom, bandwidth estimation, etc.)¶

The inference scheduler makes decisions based on the above information (see Section 10 for details).¶

9.3. Transport-Layer Consumption (Cross-Layer Control)

The MoQ layer synthesizes MMF signals and local CC output, computes control decisions, and issues them to CC algorithms via the cross-layer control interface (Section 3.3). CC algorithms do not directly parse MMF, but instead execute control commands from the MoQ layer. Decision inputs, issuable commands, and CC behavior are described in Section 3.3.¶

9.4. Example: MoQ Layer Controlling BBR

The core formula of BBR is pacing_rate = bandwidth x pacing_gain.¶

BBR itself estimates bandwidth through ACK sampling and controls pacing_gain via its state machine. In cross-layer control mode, the MoQ layer takes over control of pacing_gain. BBR remains responsible for bandwidth estimation, while pacing_gain is determined by the MoQ layer based on MMF feedback:¶

``` MoQ Layer: 1. Read BBR's BWE 2. Read MMF: Objects Lost, Late, PLAYOUT_AHEAD_MS, Delta 3. Compute pacing_gain (comprehensive judgment) 4. Issue pacing_gain --> CC¶

BBR: 1. Receive pacing_gain 2. pacing_rate = BWE x pacing_gain 3. Send at pacing_rate ```¶

Example logic for MoQ layer computing pacing_gain:¶

1. Objects Lost > 0 and BBR local loss = 0 --> Reduce pacing_gain to 1.0 (CC local ACK is normal, but peer is actually losing frames; stop probing upward)¶

2. PLAYOUT_AHEAD_MS < 100ms --> Reduce pacing_gain to 1.0 (Insufficient playout headroom; avoid aggressive probing)¶

3. Avg Inter-Arrival Delta consistently positive --> Reduce pacing_gain to 0.9 (Receiver-side queuing is worsening; proactively reduce speed)¶

4. High proportion of Objects Received Late --> Reduce target_bitrate (Transmission has no packet loss but delay exceeds deadline; reduce per-frame data volume at the source)¶

5. None of the above conditions met --> Do not issue commands; BBR runs according to its own state machine¶

When the MoQ layer does not issue commands, BBR operates normally according to its own state machine. The MoQ layer overrides pacing_gain only when MMF signals indicate intervention is needed; otherwise, BBR operates fully autonomously.¶

10.1. MMF-Driven Rate-Quality Adaptation

The following adaptation rules apply to all MoQ streaming media scenarios:¶

These adaptations can be executed at the MoQ publishing layer with per-Object granularity and latency < 1 frame cycle, without requiring application-layer media source cooperation. When the application layer is an AI inference pipeline, MMF can also adjust inference pipeline parameters (real-time flush, dynamic chunk_size).¶

Unidirectional and bidirectional adaptation modes are described in Section 3.4 (Bidirectional MMF).¶

10.2. Typical Use Cases

The following use cases assume BBR as the CC algorithm (integration method described in Section 9.4) and illustrate the effects of MMF in different scenarios. All cases follow the strategy of prioritizing audio output and progressively reducing quality.¶