[Moq] Re: Consensus call on way forward on REWIND

[Luke Curley <[e-mail]>]

Yeah, I just want to adopt CurrentGroup so we can make *some* progress.


IMO the problem with the REWIND proposal... is that we first need to
acknowledge the problems with FETCH. I'm pessimistic because we've face
planted on this so many times, but here's one more shot:

HoLB is a fundamental "feature" of FETCH. For example, if you issue a FETCH
for groups 64 - 67, and group 64 is not in the cache, oops we can't start
transferring groups 65+ from cache. FETCH introduces HoLB so a dumb VOD
client doesn't have to reorder frames, but the cost is under-utilizing the
network.

A smart VOD client is much better off issuing a separate FETCH request per
group, mimicking HLS/DASH. It can avoid the HoLB of FETCH (via priorities)
and makes it possible to target a specific buffer size (ex. 30s).
Ironically, a smart VOD client doesn't want the aforementioned "vod
semantics" provided by FETCH.

In my ideal world, we would use "live semantics" for VOD too. Deliver
sub-groups on their own stream.

But please I need a win: CurrentGroup would be a huge improvement.


On Fri, Apr 17, 2026 at 5:30 PM Alan Frindell <[e-mail]> wrote:

> > While REWIND is undoubtedly an improvement over LargestGroup, we should
> make incremental progress. Does anyone object to a LargestGroup filter?
>
> I don't object to this conceptually and I even sketched a PR which you can
> see here <https://github.com/afrind/moq-transport/pull/15> -- I called it
> "CurrentGroupFill" -- the Fill part distinguishing the request behavior
> from a straight "Filter".
>
> I feel like it has less to do with the HOLB problems we are discussing and
> REWIND was intended to solve, and more to do with ironing out the most
> common MOQ use case -- joining via a single message and keeping the
> response in a more consistent format.  It does handle the one case we are
> missing in the *current *group (in-cache low-pri subgroups/datagrams),
> but doesn't address it for previous groups.
>
> Thanks
>
> -Alan
>
>
> On Fri, Apr 17, 2026 at 4:10 PM Luke Curley <[e-mail]> wrote:
>
>> IMO the root problem with SUBSCRIBE + JOINING FETCH is that subscribers
>> want "live semantics". However, the first half, of the first group uses
>> "vod semantics". live semantics - Each sub-group is delivered via
>> independent
>> IMO the root problem with SUBSCRIBE + JOINING FETCH is that subscribers
>> want "live semantics". However, the first half, of the first group uses
>> "vod semantics".
>>
>>
>> *live semantics*- Each sub-group is delivered via independent streams.
>> - Either side may reset a sub-group stream, for any reason, to skip any
>> remaining objects.
>> - Objects within a sub-group are delivered reliably and in order, until
>> reset/fin.
>>
>> *vod semantics*
>> - Objects are delivered over a single stream.
>> - Objects are delivered in ID order, regardless of the sub-group.
>> - Objects cannot be skipped (authoritative).
>>
>>
>> Yes, it's possible to emulate "live semantics" using "vod semantics". The
>> end subscriber *could* issue multiple, sequentially prioritized, JOINING
>> FETCH requests for each specific groups/sub-group, merging each aligned
>> JOINING FETCH and SUBSCRIBE stream. Just for the first group of course!
>>
>> It's a gross hack. A complicated set of instructions. Just to command
>> the relay to serve the latest group *mostly* via "live semantics".
>>
>> We should add a LargestGroup filter for SUBSCRIBE instead. It is the
>> intended behavior 99% of the time and deserves a flag, not an incantation.
>> The first group within a subscription would no longer be special.
>>
>> While REWIND is undoubtedly an improvement over LargestGroup, we should
>> make incremental progress. Does anyone object to a LargestGroup filter?
>>
>> On Fri, Apr 17, 2026 at 12:31 PM Alan Frindell <afrind=
>> [e-mail]> wrote:
>>
>>> The working group should do nothing with this document at this time.
>>>
>>> I appreciate the effort Martin and others put in, however, now that
>>> FILL_TIMEOUT=0 has landed in the Editors’ Copy, the unique capabilities
>>> provided by REWIND to avoid HOL blocking are reduced.
>>>
>>> Specifically we’ve eliminated cases where the subscriber’s joining FETCH
>>> is blocked by cache misses – set FILL_TIMEOUT=0 (JFFT0).  So the following
>>> cases are no longer problematic:
>>>
>>> 1) Cache Hole in low-pri subgroup blocks hi-pri cached object
>>>
>>> Object ID:    0   1   2   _   4
>>>
>>> Subgroup:   0   1   0   1   0
>>>
>>> 3 is low priority and in flight.  JFFT0 skips over it and delivers the
>>> current cache state.  Object 3 can come later via SUBSCRIBE, assuming we
>>> allow a range filter (for new objects) to start at the current group.
>>>
>>> 2) Datagram or stream-per-object track with a cache hole:
>>>
>>> 0   1   2   3   _    5
>>>
>>> Cached objects all get delivered with no HOLB.
>>>
>>> 3) Old group has been evicted:
>>>
>>> Groups in Cache:   _   98   99   100
>>>
>>> Current Group: 100
>>>
>>> JFFT0, Relative -3
>>>
>>> The FETCH response begins immediately at 98, with previous marked
>>> “UNKNOWN”.
>>>
>>>
>>> There’s one remaining case where REWIND provides a HOLB advantage: when
>>> lower priority data *IS* in the cache, but you don’t want to HOL block
>>> on it.
>>>
>>> This can be addressed by adding a subgroup and/or priority filter to
>>> FETCH, which is a small subset of PR #1518.
>>>
>>> In the happy-cache case, REWIND also serves as a “single wire message”,
>>> and saves the subscriber from stitching together the current group from
>>> multiple streams, but the working group identified HOLB as the problem to
>>> solve.  I got the feeling that the non-deterministic nature of REWIND left
>>> others feeling unsatisfied.  But if you want determinism, you are
>>> acknowledging that some head-of-line blocking on cache fill is a
>>> feature and not a bug.
>>>
>>> The lively discussion in Boulder and at the recent interim indicates
>>> that despite all our efforts, there’s some friction in MOQT around
>>> SUBSCRIBE, FETCH and joining an ongoing Track.  The lack of clear consensus
>>> around a different direction forward indicates we’re probably close to the
>>> best we can achieve in the V1 timeframe.  We should stabilize around the
>>> core we have, and let innovation take place in extensions.  If there’s a
>>> better solution, it will emerge and it can be codified in a V2. Thanks
>>>
>>>
>>> -Alan
>>>
>>>
>>> On Thu, Apr 16, 2026 at 6:58 AM Magnus Westerlund <magnus.westerlund=
>>> [e-mail]> wrote:
>>>
>>>> WG, We spent Monday's interim talking about https: //github.
>>>> com/martinduke/draft-duke-moq-subscribe-rewind/tree/main. There was a lot
>>>> of interest to do something in this space but little agreement on the key
>>>> properties of a solution. This document
>>>> WG,
>>>>
>>>> We spent Monday's interim talking about
>>>> https://github.com/martinduke/draft-duke-moq-subscribe-rewind/tree/main.
>>>> There was a lot of interest to do something in this space but little
>>>> agreement on the key properties of a solution.
>>>>
>>>> This document is meant to resolve several issues and PRs related to
>>>> Joining Fetch :
>>>> #861, #1039, #1358, #1362, #1386
>>>> https://github.com/moq-wg/moq-transport/issues
>>>>
>>>>
>>>> As well as the conclusion of the Joining Fetch discussion in Boulder,
>>>> which is that people did not like head-of-line blocking in Joining Fetch.
>>>> https://datatracker.ietf.org/doc/minutes-interim-2026-moq-06-202602102030/#comparing-proposals
>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/minutes-interim-2026-moq-06-202602102030/*comparing-proposals__;Iw!!Bt8RZUm9aw!9HjM-Wgy-GAgW3ZCAeC4PBs135QHiMVv8dSYg32FL2OX3d0-sOfFvlXnIZ5LJ09o55MjHmm57vCeD2CAe4llqDNtCw$>
>>>>
>>>>
>>>> This is a consensus call for the disposition of this document. Please
>>>> state your preference.
>>>> 1) The working group does nothing with this document, at least until
>>>> MOQT is published
>>>> 2) The working group adopts this draft as the basis for an MOQT
>>>> extension
>>>> 3) The working group uses the draft as basis for a PR to be merged
>>>> into MOQT when the Editors feel the PR is ready.
>>>>
>>>> Please provide your input no later than Friday the first of May
>>>> (260501).
>>>>
>>>> Other proposals in this space are welcome, and subject to the same
>>>> consensus requirements.
>>>>
>>>> Magnus Westerlund
>>>> MoQ Chair
>>>>
>>>> --
>>>> Moq mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> --
>>> Moq mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>