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

[Victor Vasiliev <[e-mail]>]

The first group within a subscription is always special (at least if you
aim for low latency).

That said, I don't hate the LargestGroup idea.  Wrote up a version of this
that I think will work: <https://github.com/moq-wg/moq-transport/pull/1607>.

On Fri, Apr 17, 2026 at 7: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 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]
>>
> --
> Moq mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>