IETF MOQ WG: Joining FETCH Replacement Proposal

Message Snapshot

• List: moq@ietf.org
• Thread subject: Joining FETCH Replacement Proposal
• Message subject: [Moq] Joining FETCH Replacement Proposal
• Author: Alan Frindell
• Published: 2026-06-02T17:01:49.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Alan Frindell posted to the MOQ working group mailing list on June 2, 2026. The MOQT editors and authors met to review the survey input https://mailarchive.ietf.org/arch/msg/moq/n01ZcT7bVbIQlwajwbXp2u1CtNQ/, and creat…

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

The MOQT editors and authors met to review the survey input https://mailarchive.ietf.org/arch/msg/moq/n01ZcT7bVbIQlwajwbXp2u1CtNQ/, and created this PR

Plain-Text Body

The MOQT editors and authors met to review the survey input https://mailarchive.ietf.org/arch/msg/moq/n01ZcT7bVbIQlwajwbXp2u1CtNQ/, and created this PR https://github.com/moq-wg/moq-transport/pull/1642 (#1642) for the working group's consideration. This supersedes all previous Joining FETCH Replacement proposals from Ian, Victor and me.

For motivation and the problems we're trying to solve, please refer to Joining FETCH Dissent issues https://github.com/moq-wg/moq-transport/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Joining%20Fetch%20Dissent%22 or meeting minutes from Boulder or the 4/27 interim.

I've made an explainer presentation https://datatracker.ietf.org/meeting/interim-2026-moq-08/materials/slides-interim-2026-moq-08-sessa-the-new-joining-fetch-00 which summarizes the proposal, which I'll repeat below in text form.

Please review the summary and the PR and provide feedback on list or in GitHub prior to next week's meeting. The goal is to put these issues to rest now, either by moving forward with this proposal and addressing feedback, or sticking with Joining FETCH and applying any necessary fixes to get us to ship.

Thanks

Alan and Ian

---

Remove Joining FETCH, Expand Subscribe

Existing filters are unchanged - these only set the filter for new objects

1. Largest Object
2. Next Group Start
3. Absolute Start
4. Absolute Range

New filters added:

1. CurrentGroup
2. RelativePreviousFill (N)
3. AbsoluteStartFill (Location)
4. AbsoluteRangeFill (Location, End Group Delta)

---

Past Group Delivery

Any groups before the current group requested with a new mode are delivered on a FETCH formatted stream (called a fill fetch stream).

We could easily add a mode that also delivers the current group up to Largest Object on a FETCH formatted stream – this would exactly replicate Joining FETCH

Each REQUEST_UPDATE with a Fill type param will open a new fill fetch stream

AbsoluteRangeFill entirely in the past is very much like FETCH but did not try to eliminate standalone FETCH.

---

Current Group Delivery

For any of the new filters that include the current group:

• CurrentGroup
• RelativePreviousFill
• AbsoluteStartFill (start <= current),
• AbsoluteRangeFill (start <= current <= end)

Objects are delivered using SUBSCRIBE subgroups and datagrams

Publisher needs to serve the beginning of the group from cache, via an upstream SUBSCRIBE, or using FETCH

Once caught up, seamlessly transitions to live objects in the current group

---

Future Group Delivery

Entirely unchanged

---

Shared Params, Shared Fate

Subscriber Priority, Auth, etc apply to both the subscription and fill fetch stream

Group Order is effectively separate, but combined into a three-mode enum: Both Ascending → Ascending (default) Both Descending → Descending Fill Descending, Sub Ascending → FillDescending In FillDescending, Subscribe groups win tiebreakers with the fill fetch stream.

Forward = 0 implicitly…