IETF MOQ WG: New Version Published: Feedback draft

Message Snapshot

• List: moq@ietf.org
• Thread subject: New Version Published: Feedback draft
• Message subject: [Moq] Re: New Version Published: Feedback draft
• Author: Yu You (Nokia)
• Published: 2026-08-04T07:41:40.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Yu You (Nokia) posted to the MOQ working group mailing list on August 4, 2026. Thanks for the updates. The draft addresses broader aspects of metrics and feedback more comprehensively. The current draft primarily relies…

Why It Matters

This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.

Message Excerpt

Thanks for the updates. The draft addresses broader aspects of metrics and feedback more comprehensively. The current draft primarily relies on receiver observations for network adjustments, which, while useful, presents a challenge in complex multi-relay topologies. Receivers simply can't distinguish whether a delay…

Plain-Text Body

Thanks for the updates. The draft addresses broader aspects of metrics and feedback more comprehensively.

The current draft primarily relies on receiver observations for network adjustments, which, while useful, presents a challenge in complex multi-relay topologies. Receivers simply can't distinguish whether a delay originates from the server, a specific backbone relay, or the last-mile link.

What if there’s ways that could include some crucial hop-by-hop metrics, like throughput and utilization, directly within object properties as they traverse the network, rather than solely depending on relay aggregation? An example of this hop-by-hop inspection is IETF SCONE, which allows network elements to provide rate signal advice regarding transport-layer throughput.

This “forward-path” advice could offer receivers proactive awareness of potential bottlenecks, potentially preventing “late" or “lost" status codes before they even occur. The MOQT specification, conveniently, already allows relays to access mutable object properties, making it possible for negotiating and understanding some metric-related properties across the network.


How does this approach sound or align with the draft's broader goals for cascaded relay architecture?

BRs, Yu

Sent from Outlook for Mac From: Yanmei Liu healing4d@gmail.com Date: Monday, 3. August 2026 at 7.10 To: moq@mail2.ietf.org moq@mail2.ietf.org Cc: r.wu@antgroup.com r.wu@antgroup.com; shimei.jmh@alibaba-inc.com shimei.jmh@alibaba-inc.com; Yanmei Liu miaoji.lym@alibaba-inc.com Subject: [Moq] New Version Published: Feedback draft

You don't often get email from healing4d@gmail.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

Hi all,

We have published a new version of the MoQ feedback draft:

https://datatracker.ietf.org/doc/draft-liu-moq-feedback/

The draft was renamed from “MoQ Multimodal Feedback” to “MoQ Feedback” because the mechanism is intended to support a broader range of use cases. In addition to multimodal transport for live-agent systems, it is also intended to support Relay-based architectures, live streaming, video conferencing, cloud rendering, and other interactive media applications.

The main updates in this version include:

• Motivation for using feedback to improve QoE and support source-rate adaptation in Relay-based deployments.
• Two Feedback Types: HOP_FEEDBACK, intended for the Adjacent Media Publisher, and ORIGIN_FEEDBACK, intended for the Media Original Publisher and able to traverse zero or more Relays.
• Rules for generating, establishing, binding, and forwarding Feedback Tracks across cascaded Relays.
• A Relay-visible MMF_FEEDBACK_TYPE Track Property and updated Feedback Track naming.
• Addition of Group ID to the report format so that media Objects are identified b…