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: An addressable unit whose Payload is a sequence of bytes, following [MoQTransport].¶

• Media Publisher: The Publisher of a media Track on a given MOQT session.¶

• Media Subscriber: A Subscriber of a media Track on a given MOQT session.¶

• Relay: A MoQ node that forwards media Tracks or Feedback Tracks between Publishers 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 Media 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 Media Subscriber of the associated media Track or a Relay generating a new Feedback Track.¶

• Feedback Subscriber: A Subscriber of a Feedback Track. An intermediate Relay can subscribe to a Feedback Track for forwarding without consuming its Payload.¶

• Feedback Consumer: The terminal Feedback Subscriber that interprets MQF reports. The Feedback Consumer is the Adjacent Media Publisher for HOP_FEEDBACK and the Media Original Publisher for ORIGIN_FEEDBACK.¶

• Feedback Track: A MoQ Track that carries MQF reports.¶

• 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.¶

• MQF (Media over QUIC Feedback): A feedback report at the MoQ layer containing per-Object delivery status for an associated media Track.¶

1.2. Scope and Non-Goals

This document specifies:¶

• how a Feedback Track is associated with a media Track;¶

• how Feedback Tracks are established, forwarded, and terminated;¶

• the Relay behavior associated with each Feedback Type;¶

• the MQF report format and capability negotiation; and¶

• endpoint behavior required to generate and interpret interoperable MQF reports.¶

This document does not specify:¶

• how an application adjusts encoding, generation, subscription, or scheduling in response to MQF;¶

• the algorithm a Relay uses to derive or aggregate a new MQF report from downstream observations and local state;¶

• how Relays are deployed or configured, including path selection, Relay-to-Relay monitoring, and path remediation.¶

An implementation can use MQF reports as one input when adapting media or local forwarding behavior. Such use does not replace transport congestion control, and an implementation MUST NOT use MQF to bypass the sending limits imposed by its congestion controller.¶

3.1. Feedback Model

A Feedback Track is a normal MOQT Track whose Objects carry MQF reports. MQF introduces no new QUIC frame or MOQT control message type. The associated media Track identifies the Object sequence being reported, and the Feedback Type identifies the intended Feedback Consumer and Relay behavior.¶

MQF operates at Object granularity. The interpretation of an Object as a frame, chunk, or other media unit is defined by the media format or application.¶

MQF complements, rather than replaces, transport-layer signals. QUIC acknowledgments describe packet delivery on one QUIC connection, and receive timestamps such as [quic-receive-ts] can provide additional packet timing information. MQF describes delivery outcomes using media Object coordinates and can carry application-level observations such as playout headroom.¶

An ORIGIN_FEEDBACK report can reflect the cumulative delivery outcome observed downstream of the Media Original Publisher, but it does not identify which Relay hop or path segment caused that outcome. Hop-by-hop path diagnosis is not defined by MQF.¶

3.2. Feedback for Bidirectional Media

Feedback direction is defined relative to the associated media Track, not by an endpoint role or an application-specific direction label. A Media Subscriber that generates feedback acts as the Feedback Publisher. The intended Feedback Consumer is determined by the Feedback Type: the Adjacent Media Publisher for HOP_FEEDBACK, or the Media Original Publisher for ORIGIN_FEEDBACK.¶

An endpoint can be a Media Publisher for one Track and a Media Subscriber for another Track. Each media Track can independently have one or more associated Feedback Tracks:¶

Endpoint A                         Endpoint B
  |--- media Track A ------------>|  B: Media Subscriber
  |<-- Feedback Track A -----------|  B: Feedback Publisher
  |                                |
  |<-- media Track B --------------|  A: Media Subscriber
  |--- Feedback Track B ---------->|  A: Feedback Publisher

The two Feedback Tracks use the same report format and establishment rules. The associated media Track identifies the media flow being reported, and each Feedback Track independently declares HOP_FEEDBACK or ORIGIN_FEEDBACK. The PUBLISH_FEEDBACK and SUBSCRIBE_FEEDBACK Setup Option bits indicate whether the endpoint that declares them can publish or subscribe to Feedback Tracks on the current MOQT session.¶

3.3. Feedback Routing through Relays

MQF supports deployments in which feedback is consumed by the Adjacent Media Publisher as well as deployments in which feedback is delivered to the Media Original Publisher. The Feedback Type Track Property defined in Section 4.1 identifies the intended consumer and required Relay behavior.¶

In a cascaded Relay architecture, media from a Media Original Publisher traverses multiple Relays before reaching a Media Subscriber. The Media Subscriber is the feedback source, the Relay adjacent to the Media Subscriber can consume its reported delivery outcomes, and the Relay chain can carry a separate Feedback Track to the Media Original Publisher.¶

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

The following Feedback Tracks serve different consumers:¶

• A HOP_FEEDBACK Track carries delivery outcomes observed by the Media Subscriber and terminates at the L1 Relay for local interpretation.¶

• The L1 Relay can derive a new ORIGIN_FEEDBACK Track from received HOP_FEEDBACK and other information available to the Relay when configured to do so. When doing so, the Relay acts as a new Feedback Publisher and publishes a distinct Feedback Track in the context of its upstream media Track.¶

• An ORIGIN_FEEDBACK Track can be published by a Media Subscriber or a Relay and can traverse zero or more Relays. Its MQF Payload remains opaque to intermediate Relays. Subscriber-generated ORIGIN_FEEDBACK requires the Media Original Publisher to have sufficient application context to interpret the report and its associated media Track coordinates.¶

A Media Subscriber behind an L1 Relay SHOULD use HOP_FEEDBACK when the report requires Relay-local interpretation or translation into the context of an upstream media Track. It MAY instead publish ORIGIN_FEEDBACK when the Media Original Publisher has sufficient application context to interpret the report and its associated media Track coordinates.¶

The relative importance of the two Feedback Types depends on the application. For example, a deployment can use HOP_FEEDBACK as input to local Track selection or forwarding behavior and ORIGIN_FEEDBACK as input to source adaptation. A Relay that derives a report from one or more downstream reports acts as a new Feedback Publisher and publishes a distinct Feedback Track. The base MQF format does not define the semantics of deriving ORIGIN_FEEDBACK from downstream reports, whether from one report or by aggregating multiple reports. Such derivation requires an extension or application agreement that defines observation provenance, timestamp handling, metric interpretation, and, when applicable, the represented Media Subscribers and aggregation method.¶

4.1. Track Definition

The Feedback Track is a normal MoQ Track where the Payload of each Object is an MQF report. Each MQF report 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 MQF_FEEDBACK_TYPE Track Property. A Feedback Publisher that generates both types MUST publish two distinct Feedback Tracks.¶

The MQF_FEEDBACK_TYPE Track Property has an MOQT variable-length integer (vi64) value, encoded as specified in [MoQTransport], Section 8.1:¶

Every Feedback Track MUST include the MQF_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 MQF-aware Relay uses this Property without inspecting MQF 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 4.2) and is not repeated in MQF 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.¶

4.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 mqf, 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 MQF_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, mqf, hop-feedback, subscriber-17, audio_response)
(example.com, meeting, mqf, origin-feedback, relay-l1-4, audio_response)

The same naming construction applies independently to every media Track. The associated media Track determines the media direction being reported; a separate direction 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.¶

4.3. Track Establishment and Lifecycle

The Feedback Track is established by the Feedback Publisher (a Media Subscriber or a Relay generating new feedback) through MOQT's PUBLISH / REQUEST_OK exchange on a bidirectional request stream. In [MoQTransport], PUBLISH_OK is a descriptive alias for REQUEST_OK, not a separate wire message type. The MQF capabilities required by Section 6 MUST be negotiated before establishment.¶

For a HOP_FEEDBACK Track, the terminal Feedback Consumer is the Adjacent Media Publisher on that MOQT session. The Feedback 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 MQF Payload. It can derive that Payload from HOP_FEEDBACK, local media transmission state, and the mapping between its upstream and downstream media Tracks.¶

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_TRACKS 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 4.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 / REQUEST_OK and SUBSCRIBE / SUBSCRIBE_OK procedures in [MoQTransport] to establish forwarding with Forward State 1.¶

SUBSCRIBE_NAMESPACE discovers published Namespaces; it does not request PUBLISH messages for their Tracks. SUBSCRIBE_TRACKS expresses that Track interest in [MoQTransport].¶

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 MQF 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 MQF_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 MQF Payload can therefore be protected between the Feedback Publisher and the Media Original Publisher. A HOP_FEEDBACK MQF Payload can be protected for its adjacent terminal Feedback Consumer.¶

Direct Establishment Flow Example:¶

Both endpoints have completed the MQF Setup exchange in Section 6. The Media Original Publisher has prior interest in and authorization to receive the Feedback Track. The diagram omits request identifiers and other MOQT fields.¶

Media Subscriber                  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 ++     |
  |     ("mqf", "origin-feedback",     |
  |      "subscriber-17"),             |
  |   track=audio_response,            |
  |   property=MQF_FEEDBACK_TYPE(1))   |
  |----------------------------------->|
  | REQUEST_OK                         |
  |<-----------------------------------|
  |                                    |
  | [Object: MQF seq=0]                |  (3) Send MQF report
  |----------------------------------->|
  | [Object: MQF 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 Publisher SHOULD send PUBLISH_DONE for the Feedback Track after transmitting the final MQF report 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 MQF Objects can be served from cache. A terminal feedback consumer MUST NOT apply an MQF report from a previous publication session.¶

4.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 5.1). Example priority assignment:¶

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

5.1. Report Structure

MQF Report {
  Report Timestamp (i),
  Report Sequence (i),
  Object Entry Count (i),
  Object Entry (..) ...,
  Summary Stats (..),
  Optional Metric Count (i),
  Optional Metric (..) ...,
}

This document defines MQF report format version 0. The MOQT_FEEDBACK Setup Option (Section 6.1) declares support for this format; it does not negotiate a separate version number. The format version is not repeated in each report.¶

Each MQF report describes Object delivery status for a single media Track associated with its Feedback Track (1:1 association, see Section 4.1).¶

Report Timestamp (varint): The moment when the report is generated, using the Feedback Publisher'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).¶

5.2. Object Entry

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

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

5.3. Delivery Status Codes

5.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 MQF report and are not controlled by the negotiation bitmap. They provide a windowed aggregate view for Feedback Consumers that do not process every Object Entry.¶

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 7.4).¶

delta(i) = (A(i) - A(i-1)) - expected_interval
Avg Inter-Arrival Delta = mean(delta(i)) for all i

5.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 the following MQF type/value pair. Both fields use the QUIC variable-length integer encoding defined for report Payloads in Section 5:¶

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 summary information about the Feedback Publisher's local QUIC connection to the Feedback Consumer.¶

Object Entries and Summary Stats carry the core MQF report information. Optional Metrics provide supplementary application- or transport-level observations.¶

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

The Feedback Consumer MUST ignore unrecognized Metric Types.¶

Optional Media Metrics MAY be included in an MQF report only when both endpoints have declared OPTIONAL_METRICS in their Setup Options (Section 6). When that capability is not enabled, Optional Metric Count MUST be 0.¶

5.6. Report Size Control

A single MQF report 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 MQF report, the Feedback Publisher 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).¶

MQF Report:
  Report Timestamp: 2000000 (2000000us = 2s since setup)
  Report Sequence: 10 (10th report)
  Object Entry Count: 5 (5 Objects)

  Object Entry [0]: (smallest media Object location, first in list)
    Group ID: 7
    Object ID: 96
    Status: 0x00 (RECEIVED)
    Recv Ts Delta: 189999 (ZigZag(-95000): 95ms before Report Timestamp)
    (First received Object, baseline=Report Timestamp)

  Object Entry [1]:
    Group ID: 7
    Object ID: 97
    Status: 0x02 (NOT_RECEIVED)
    (No Recv Ts Delta)

  Object Entry [2]:
    Group ID: 7
    Object ID: 98
    Status: 0x01 (RECEIVED_LATE)
    Recv Ts Delta: 100000 (ZigZag(+50000): 50ms later than Object 96)
    (Skip NOT_RECEIVED 97, baseline=Object 96)

  Object Entry [3]:
    Group ID: 7
    Object ID: 99
    Status: 0x00 (RECEIVED)
    Recv Ts Delta: 40000 (ZigZag(+20000): 20ms later than Object 98)

  Object Entry [4]:
    Group ID: 7
    Object ID: 100
    Status: 0x00 (RECEIVED)
    Recv Ts Delta: 40000 (ZigZag(+20000): 20ms later than Object 99)

  Summary Stats:
    Report Interval: 100000 (100000us = 100ms)
    Total Objects Evaluated: 5
    Objects Received: 3
    Objects Received Late: 1
    Objects Lost: 1
    Avg Inter-Arrival Delta: 6000
      (ZigZag(+3000): avg arrival interval 3ms larger)

  Optional Metric Count: 2
  Optional Metric [0]:
    Metric Type: 0x02 (PLAYOUT_AHEAD_MS)
    Metric Value: 150 (playout headroom 150ms)
  Optional Metric [1]:
    Metric Type: 0x04 (ESTIMATED_BANDWIDTH_KBPS)
    Metric Value: 800 (estimated bandwidth 800kbps)

6.1. Setup Option

This extension is defined for MOQT draft-22. Endpoints declare MQF support using the MOQT_FEEDBACK Setup Option in the symmetric SETUP exchange described in [MoQTransport], Sections 6.3.2 and 9.1. Each endpoint sends SETUP as the first message on its own unidirectional control stream. Either endpoint can send first, without waiting for the other endpoint's SETUP.¶

The MOQT version is selected during session establishment using ALPN for native QUIC or WT-Available-Protocols for WebTransport, as specified in [MoQTransport], Section 6.2. The protocol identifier for draft-22 is moqt-22. SETUP carries neither a transport version field nor a ROLE option. The SETUP message has Type 0x2F00, a 16-bit message Length, and a sequence of Setup Options bounded by that Length; there is no option count.¶

MOQT_FEEDBACK has an even Option Type, TBD1. It uses the Key-Value-Pair encoding in [MoQTransport], Section 8.3:¶

MOQT_FEEDBACK Setup Option {
  Delta Type (vi64),
  Capability Bitmap (vi64),
}

Delta Type is TBD1 minus the previous Option Type in this SETUP, or TBD1 if this is the first option. Options are ordered by their decoded Type. Because TBD1 is even, the value is a single MOQT variable-length integer and no option Length field is present. These fields use MOQT vi64, not the QUIC integer encoding used in MQF report Payloads.¶

An endpoint MUST NOT include more than one MOQT_FEEDBACK option in SETUP. An MQF endpoint receiving a duplicate MUST close the session with PROTOCOL_VIOLATION. A value that does not match this serialization is handled as KEY_VALUE_FORMATTING_ERROR under [MoQTransport], Section 8.3. An endpoint that does not recognize the option ignores it under the MOQT Setup Option rules.¶

The option declares support for MQF report format version 0. Its Capability Bitmap has the following bit definitions:¶

Negotiation Example:¶

The following diagram shows logical option types and values. Other Setup Options, including any required by the transport, are omitted. On the wire, Option Types are delta-encoded as described above. The two SETUP messages are independent advertisements; their order here does not imply a response or a requirement to wait.¶

Endpoint A                          Endpoint B
  |                                    |
  | SETUP(options=[                    |
  |   {type=TBD1, value=0x06}          |  OPTIONAL_METRICS +
  | ])                                 |  SUBSCRIBE_FEEDBACK
  |----------------------------------->|
  |                                    |
  | SETUP(options=[                    |
  |   {type=TBD1, value=0x03}          |  PUBLISH_FEEDBACK +
  | ])                                 |  OPTIONAL_METRICS
  |<-----------------------------------|
  |                                    |
  | After both SETUPs:                 |
  |   B -> A feedback is enabled.      |
  |   A -> B feedback is disabled.     |
  |   Optional Metrics are enabled.    |

6.2. Capability Negotiation Rules

Each capability bit describes the endpoint that sends the Setup Option. PUBLISH_FEEDBACK and SUBSCRIBE_FEEDBACK are complementary endpoint capabilities; they do not require both endpoints to declare the same bit. A Feedback Track from Endpoint A to Endpoint B can be established only when Endpoint A has declared PUBLISH_FEEDBACK and Endpoint B has declared SUBSCRIBE_FEEDBACK.¶

An endpoint MUST send its SETUP and receive the peer's SETUP before establishing a Feedback Track or sending MQF Objects. An endpoint MUST NOT use capabilities remembered from an earlier session to send Feedback Track requests or MQF Objects in 0-RTT before the current exchange completes. After applying the default of zero for an omitted option, each endpoint computes the same directional result:¶

• A-to-B feedback requires A's PUBLISH_FEEDBACK and B's SUBSCRIBE_FEEDBACK.¶

• B-to-A feedback requires B's PUBLISH_FEEDBACK and A's SUBSCRIBE_FEEDBACK.¶

• Optional Metrics require both endpoints' OPTIONAL_METRICS bits and do not enable either feedback direction by themselves.¶

An endpoint that has not declared PUBLISH_FEEDBACK MUST NOT publish a Feedback Track. When an endpoint receives a PUBLISH for a Feedback Track, it MUST reject the request with REQUEST_ERROR if the peer did not declare PUBLISH_FEEDBACK or if the receiving endpoint did not declare SUBSCRIBE_FEEDBACK.¶

Optional Media Metrics are enabled only when both endpoints have declared OPTIONAL_METRICS. An MQF report MUST NOT include Optional Metrics when that capability is not enabled.¶

These capability rules apply to all MOQT endpoints, including Relays, independently on each MOQT session.¶

6.3. Behavior When Option Not Declared

When a peer's SETUP does not include the MOQT_FEEDBACK option, that peer is treated as having declared a zero Capability Bitmap and does not support publishing or subscribing to Feedback Tracks. An endpoint MUST NOT publish a Feedback Track to that peer and MUST reject a Feedback Track PUBLISH received from that peer. The absence of this option does not prevent ordinary media Track operation.¶

6.4. Runtime Capability Change

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

7.1. Arrival Time Recording

The Media Subscriber 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 Media Subscriber'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.¶

7.2. Delivery Status Determination

The Media Subscriber 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 5.3): NOT_RECEIVED (0x02).¶

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

Object status MAY be updated in subsequent MQF. 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 rather than final delivery statistics.¶

7.3. MQF Generation Timing

The frequency of MQF reports is application- and deployment-defined. A Feedback Publisher needs to balance the freshness required by its Feedback Consumer against the bandwidth and processing cost of the Feedback Track. This document does not define media-specific reporting intervals or require MQF reports to be used as a session heartbeat.¶

A Feedback Publisher MAY generate an additional report when a recent Object changes status rather than waiting for its next periodic report.¶

7.4. Object Entry Selection

The number of Object Entries in an MQF report is not fixed. A Feedback Publisher selects Object Entries according to its reporting policy and report-size budget.¶

When selecting Object Entries:¶

• If not all candidate Object Entries are included, the Feedback Publisher SHOULD prioritize recently observed Objects.¶

• An Object reported in a previous MQF report MAY be omitted when its status has not changed.¶

• A later report can update the reported status of an Object.¶

The absence of an Object Entry from a report does not indicate any delivery status for that Object. Each report represents the observations included at its generation time.¶

7.5. Exception Handling

• Object Out-of-Order Arrival: The Media Subscriber 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: The Media Subscriber SHOULD identify duplicates by Group ID and Object ID, ignore duplicate arrivals, and retain the first arrival time.¶

8.1. Report Consumption

A Feedback Consumer uses the media Full Track Name, Group ID, and Object ID in an MQF report to associate each reported status with an Object from the corresponding media Track.¶

MQF reports describe observations made by a Feedback Publisher. A Feedback Consumer can make valid reports available to the Application.¶

9.1. Relay-Local Feedback Consumption

Consider a live-streaming deployment that supports Relay-executed Track selection through a separate Track-switching mechanism. The application makes the same video available through a high-bitrate Track and a low-bitrate Track. A Media Subscriber configures these Tracks as acceptable alternatives and authorizes the adjacent Relay to select between them. While the Relay is forwarding the high-bitrate Track, several complete Objects arrive after their application-defined playback deadlines and the Media Subscriber's playout headroom decreases. The Media Subscriber publishes a HOP_FEEDBACK report containing RECEIVED_LATE Object Entries, a nonzero Objects Received Late count, and, when Optional Media Metrics have been enabled, a decreasing PLAYOUT_AHEAD_MS value.¶

The adjacent Relay terminates the Feedback Track and can use the report as an application-level input in addition to transport information available on the downstream MOQT session. For example, the Relay's Track-selection logic might change the selected representation from the high-bitrate Track to the low-bitrate Track. A later series of reports showing timely Object delivery and recovered playout headroom might contribute to selecting the high-bitrate Track again. MQF identifies the affected media Track and conveys the observations, but it does not identify alternative representations, authorize Relay-executed selection, define when a switch occurs, or provide a Track-switching procedure.¶

9.2. Source Adaptation with End-to-End Feedback

Consider an interactive conference in which a Media Original Publisher produces only one representation of a real-time video Track. A Media Subscriber receives the Track either directly with no Relay or through one or more Relays. The rate of the published representation persistently exceeds what can be delivered in time over the complete path. Suppose a report interval covers five Objects: two are RECEIVED, two are RECEIVED_LATE, and one is NOT_RECEIVED. On a direct path, or when Relays forward the media Track without republishing or transforming it, the Media Original Publisher can interpret the reported Group ID and Object ID. The Media Subscriber therefore publishes these observations as ORIGIN_FEEDBACK.¶

When the path contains Relays, they forward the ORIGIN_FEEDBACK Track without interpreting its MQF Payload. In either topology, MQF reports whether Objects reached the Media Subscriber before their application-defined deadlines. In a cascaded topology, transport feedback on the Media Original Publisher's immediate MOQT session describes only that session and does not provide this end-to-end outcome. A Relay also has no lower-bitrate Track to select in this example and, when acting solely as a forwarding Relay, cannot modify the opaque media Payload to reduce the source bitrate.¶

The Media Original Publisher can use a continuing pattern of late or missing Objects as one input when deciding whether to reduce the source encoding or generation rate. This is an action that neither the Media Subscriber nor a Relay acting solely as a forwarding Relay can perform on the original media source.¶

9.3. Selecting Feedback Tracks with TopN

Consider a deployment that supports the proposed Top Tracks Filter mechanism [TopTracks]. Ten Media Subscribers receive the same media Track through one or more Relays and publish separate ORIGIN_FEEDBACK Tracks. The application defines a ranking Property for feedback selection. Tracks with larger values of this Property are selected first. Each Feedback Publisher exposes the ranking value as a Relay-visible Object Property on its feedback Objects, outside the MQF Payload.¶

The Media Original Publisher, acting as the Feedback Subscriber, requests the five Feedback Tracks with the highest values of that Property from its adjacent Relay. The candidate set is scoped to feedback for the associated media Track. The Relay executes the requested selection using the exposed Property, without interpreting or modifying the MQF Payload. As ranking values change, the selected Tracks can change according to the Track-selection mechanism.¶

In a multi-relay deployment, the requested filter can be propagated toward the Feedback Publishers so that intermediate Relays also perform selection. For example, Relay C can request up to five Feedback Tracks from each of Relays A and B and select five from their combined candidates:¶

Subscribers A --> Relay A --+
                  (Top5)   |
                           +--> Relay C --> Media Original Publisher
                           |    (Top5)
Subscribers B --> Relay B --+
                  (Top5)

Subscribers A and B are two subsets of the ten Media Subscribers. Arrows show the feedback flow; filter requests travel in the opposite direction. Each Top5 selection forwards up to five Feedback Tracks.¶

Each branch uses the same ranking Property with comparable values and restricts its candidates to feedback for the associated media Track. This allows filtering before feedback reaches the Relay adjacent to the Media Original Publisher. Selection updates, tie handling, and timeouts follow the separate Track-selection mechanism; MQF does not define a distributed selection algorithm or require simultaneous selection changes across Relays.¶

The Media Original Publisher receives MQF reports from up to five selected Feedback Tracks, each carrying the observations of its individual Feedback Publisher.¶

9.4. Cache Feedback as an Optional Extension

Consider a deployment in which a Relay caches a media Track and serves subsequent FETCH requests for its Objects. The Media Original Publisher supplies MAX_CACHE_DURATION as defined in [MoQTransport], Section 10.3. For example, an Object has a cache duration of ten seconds, measured from when the Relay began receiving it. The Relay evicts the cached Object after three seconds due to local resource constraints. A FETCH requesting that Object after five seconds encounters a local cache miss. The cache duration limits how long an Object can be served from a cache; it does not guarantee retention until that limit.¶

A separate extension or application agreement could define feedback describing such misses. The Relay has direct knowledge of its cache operations and, when it retains sufficient metadata, can distinguish an Object that was cached and evicted early from one that was never cached or whose cache duration has expired. A downstream Media Subscriber cannot infer this cause solely from a missing Object. A local cache miss also does not necessarily imply a delivery failure, since the Relay might retrieve the Object from an upstream Publisher.¶

Under such an extension, the Relay acts as a Feedback Publisher and publishes a new ORIGIN_FEEDBACK Track associated with the media Track. It uses a distinct Feedback Full Track Name and Report Sequence space. The Feedback Track follows the existing establishment, authorization, and reverse media-path binding rules. Intermediate Relays forward its MQF Payload without interpreting it. The Media Original Publisher consumes the Relay's own cache observations, rather than interpreting them as delivery outcomes observed by a downstream Subscriber.¶

The extension could use Optional Media Metrics to convey scalar counters, such as the number of FETCH requests evaluated and the number affected by early eviction. These metrics would supplement the existing MQF report structure and would be carried only when Optional Media Metrics are enabled. The extension would define the metric identifiers and meanings, the reporting interval and counting rules, and the scope and completeness of the observations, including how to represent unavailable eviction history. The generic OPTIONAL_METRICS capability does not establish agreement on these extension-specific semantics. Cache misses would not change the meanings of Object delivery status or the Summary Stats fields, including Objects Lost.¶

The Media Original Publisher could use these observations to assess how cache retention affects retrieval and recovery in the deployment. For example, frequent cache misses caused by early eviction could lead the Media Original Publisher to extend its own Object retention window. This can reduce the risk that a Relay's upstream retrieval fails because the Object is no longer available at the origin. Any resulting cache or application policy remains outside MQF. This example does not define cache feedback metrics or require Relays to retain eviction history. Interoperable cache feedback requires the separate extension or application agreement.¶

9.5. Relay-Derived Feedback from Multiple Subscribers

Consider an interactive conference in which an adjacent Relay forwards the same media Track to multiple Media Subscribers. Each Media Subscriber publishes HOP_FEEDBACK describing the delivery outcome it observes. The Relay can interpret each report together with local forwarding observations, such as whether an Object was available at the Relay in time for downstream delivery and whether similar outcomes were reported by multiple Media Subscribers.¶

A future extension could define how a Relay aggregates these observations before sending feedback upstream. For example, it could distinguish an outcome reported by one Media Subscriber from an outcome reported by several Media Subscribers, or combine several reports to limit the number of Feedback Tracks delivered to the Media Original Publisher. If the Relay makes the resulting observations available to the Media Original Publisher, it acts as a new Feedback Publisher and publishes a new ORIGIN_FEEDBACK report associated with the upstream media Track.¶

Under such an extension, the Relay consumes the Subscriber-generated HOP_FEEDBACK reports and combines them with its local observations. It then generates a separate ORIGIN_FEEDBACK report with a new Feedback Full Track Name, Report Sequence space, and MQF Payload. The Relay does not relabel or mechanically forward the received HOP_FEEDBACK Objects. Intermediate Relays forward the new ORIGIN_FEEDBACK Track without interpreting its Payload. Such aggregated reports are not interoperable based on this document alone; an extension defining them needs to specify the represented Media Subscribers, the aggregation method, and the interpretation of each reported field.¶

Applications such as interactive conferencing, live streaming, cloud rendering, gaming, and live-agent media can interpret Object delivery status according to their own media format and latency objectives.¶

12.1. Normative References

[MoQTransport]

Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-22, 1 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-22>.

[QUIC-TRANSPORT]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

12.2. Informative References

[quic-receive-ts]

Swett, I. and J. Beshay, "QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps", Work in Progress, Internet-Draft, draft-ietf-quic-receive-ts-01, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-receive-ts-01>.

[TopTracks]

Zanaty, M., "Top Tracks Filter (MOQT Pull Request #1981)", 12 October 2026, <https://github.com/moq-wg/moq-transport/pull/1981>.