IETF MOQ WG: Joining FETCH Replacement Proposal

Message Snapshot

• List: moq@ietf.org
• Thread subject: Joining FETCH Replacement Proposal
• Message subject: [Moq] Re: Joining FETCH Replacement Proposal
• Author: Mo Zanaty (mzanaty)
• Published: 2026-06-11T02:28:27.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Mo Zanaty (mzanaty) posted to the MOQ working group mailing list on June 11, 2026. Several separable changes here, some clear wins, some thorny. Kudos to the editors for taking this on, lots to hash out. 1. Send cached…

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

Several separable changes here, some clear wins, some thorny. Kudos to the editors for taking this on, lots to hash out. 1. Send cached current group objects as subgroups / datagrams not a single fetch stream. Talking with Alan and Victor swayed me this is easier for an app than stitching fetch and subscribe streams.…

Plain-Text Body

Several separable changes here, some clear wins, some thorny. Kudos to the editors for taking this on, lots to hash out.

1. Send cached current group objects as subgroups / datagrams not a single fetch stream. Talking with Alan and Victor swayed me this is easier for an app than stitching fetch and subscribe streams. So I tried it in our app. But hit issues. TLDR, this doesn't work for multiple subgroups like video layers. Subgroups provide dependency and priority under congestion which works well for live data at its natural rate but not large bursts from cache. Without congestion, objects come in order no matter the subgroup. With congestion, subgroup priority kicks in to reorder objects and potentially drop them after delivery timeout. Cache bursts trigger 'congestion' (exceeding cwin, pacing rate, and maybe the true path rate) which impacts subgroup priority, object reordering, and delivery timeout in bad ways, causing severe playback delay of a full GOP (all SG=0 before any SG>0) which defeats the low latency startup intent of join/fill fetch. Cache delivery is best over a single fetch stream reliably in object order. We got this right in prior consensus after lots of churn. Also, apps must already stitch subgroup streams together into a playout buffer in object order, so stitching another fetch stream into that same buffer is no harder or easier. For these reasons, this change does more harm than good.

2. Single message for Subscribe+Fetch, auto fetch/fill from Subscribe parameters. This aligns with the app intent which is simply a range of objects. It also unifies the track name, alias, and subscription state. But some parameters may need to differ in subscribe vs fetch like filters. Extending group order enums to combos seems hacky and not a viable pattern for filters or priority (which must consider the entire connection absolute priorities not just a single track fetch vs subscribe relative priority via group order). The alternate spelling with custom parameters embedded within a fetch/fill parameter may work, although it seems convoluted over simply using an empty fetch message with its own parameters on the subscribe bidi. I'm unsure which is best. But I support completely removing standalone fetch and joining fetch with a subscribe parameter or empty message on the sub bidi.

3. Replace standalone fetch, too. Agreed. No need for redundant mechanisms with no added value.

4. Join Publish. All looks fine.

5. AbsoluteStart/Range filter in the past should fill. Why would the app request specific groups but then not want them?

6. Spelling. Location Filter is the simplest, most intuitive, and aligns with all other filters. Apps simply want a range of objects not 8 enums of choices.

Thanks, Mo

---

From: Alan Frindell afrind=40meta.com@dmarc.ietf.org Sent: Wednesday, June 10, 2026 2:36 AM To: MOQ Mailing List moq@ietf.org Subject: [Moq] Re: Joining FETCH Replacement Proposal

In addition to the expla…