IETF MOQ WG: Consensus call on way forward on REWIND

Message Snapshot

• List: moq@ietf.org
• Thread subject: Consensus call on way forward on REWIND
• Message subject: [Moq] Re: Consensus call on way forward on REWIND
• Author: Gwendal Simon
• Published: 2026-04-28T10:38:31.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Gwendal Simon posted to the MOQ working group mailing list on April 28, 2026. Ian's statement that he would "be happy to remove Joining FETCH" is significant given his role as editor. The WG should clarify: is this edit…

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

Ian's statement that he would "be happy to remove Joining FETCH" is significant given his role as editor. The WG should clarify: is this editorial intent or an individual position? Joining FETCH was added via explicit WG consensus to address live streaming requirements. Removing it requires equivalent consensus, inclu…

Plain-Text Body

Ian's statement that he would "be happy to remove Joining FETCH" is significant given his role as editor. The WG should clarify: is this editorial intent or an individual position? Joining FETCH was added via explicit WG consensus to address live streaming requirements. Removing it requires equivalent consensus, including from the stakeholders who requested it. People active in the WG and coming from the live streaming industry are not prolific issue filers, but I trust that editors and chairs do not measure topic importance by GitHub activity.

CurrentGroupFill does not substitute for Joining FETCH. The primary use case for Joining FETCH is fast buffer filling at join: a subscriber needs several past groups, not just the current one. Being several groups behind the live edge is the normal operating state of a live player, not an edge case. The two mechanisms cover different ranges.

A cleaner alternative exists. Rather than a subscriber-initiated FETCH on the existing bidi (in the spirit of PR#1604 and issue #1602), the relay delivers past objects inline on the SUBSCRIBE or PUBLISH bidi proactively, without a subscriber FETCH request. A parameter in SUBSCRIBE_OK communicates the range [Start_Group, Live_Edge). The relay is not cache-constrained: it can fetch from upstream if needed. This removes the subscriber round trip, extends coverage beyond the current group, and makes Joining FETCH redundant.

---

From: Ian Swett ianswett=40google.com@dmarc.ietf.org Sent: Tuesday, April 28, 2026 2:12 AM To: Luke Curley kixelated@gmail.com Cc: Martin Duke martin.h.duke@gmail.com; Suhas Nandakumar suhasietf@gmail.com; Gwendal Simon gsimon@synamedia.com; Alan Frindell afrind@meta.com; Magnus Westerlund magnus.westerlund@ericsson.com; MOQ Mailing List moq@ietf.org Subject: Re: [Moq] Re: Consensus call on way forward on REWIND

Regarding the consensus call, I think we should make changes to the core draft (some variant of option 3).

As Luke said, I think CurrentGroupFill (Alan's PRhttps://github.com/afrind/moq-transport/pull/15) is a strict improvement on the current draft and fixes the worst of the "Joining Fetch Dissent" issues.

I'm open to some variant of REWIND, but not very optimistic that we'll get consensus on anything more complex than CurrentGroupFill. The motivation to tackle something slightly more complex like REWIND is if it would enable us to remove Joining Fetch, because Joining FETCH adds complexity in several ways. Personally, I'd be happy to remove Joining Fetch if we had CurrentGroupFill, but I'm not sure others would?

Ian