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

[Ian Swett <[e-mail]>]

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 PR
<https://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

On Mon, Apr 27, 2026 at 4:32 PM Luke Curley <[e-mail]> wrote:

> And sorry to clarify that last email.
>
> If a relay has a fragmented cache:
>
>    - it MAY still serve a partial sub-group (ex. object 0 is always
>    valid).
>    - it MAY fetch upstream (via REWIND or FETCH)
>    - it MAY skip one or more sub-groups
>
>
> It's very open ended, of course. Relays should reaaaally try to avoid
> fragmented caches because they cause havok, but MoQ makes it difficult with
> LargestObject + gaps + sub-groups.
>
> On Mon, Apr 27, 2026 at 1:18 PM Luke Curley <[e-mail]> wrote:
>
>> Absolutely. A relay MUST deliver objects within a sub-group in order
>> (SUBSCRIBE semantics). Otherwise, the relay MUST skip the remainder of the
>> sub-group.
>>
>> So long as it's clear that skipping a group (ex. CurrentGroup ->
>> NextGroup) will cause user impact. It would be the same if a relay returned
>> an error for a JOINING FETCH; valid but undesirable.
>>
>> On Mon, Apr 27, 2026 at 12:53 PM Martin Duke <[e-mail]>
>> wrote:
>>
>>> Luke, so are you happy with something that is still best-effort (i.e.
>>> the publisher MAY refuse based on its cache state) but does not preclude
>>> the relay doing something more aggressive?
>>>
>>>
>>> On Mon, Apr 27, 2026 at 12:47 PM Luke Curley <[e-mail]>
>>> wrote:
>>>
>>>> Martin, I think we're close. Victor's PR
>>>> <https://github.com/moq-wg/moq-transport/pull/1607> would work for me
>>>> too.
>>>>
>>>> I just want to avoid any language that mandates behavior based on the
>>>> state of the cache. A relay should be allowed to cache fill from upstream,
>>>> or S3, or disk, or whatever. Failing that, the relay can (silently) drop
>>>> the tail of a sub-group just like a normal SUBSCRIBE.
>>>>
>>>>
>>>>
>>>> On Mon, Apr 27, 2026 at 12:23 PM Martin Duke <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Luke,
>>>>>
>>>>> The "best-effortness" of REWIND is critical to the design, and is
>>>>> consistent with what I briefed in Boulder and people wanted to see. I
>>>>> have concerns about the relay complexity of requiring more than
>>>>> best-effort, but you're welcome to write a draft that does something
>>>>> different and see if people like it better.
>>>>>
>>>>> On Mon, Apr 27, 2026 at 8:33 AM Luke Curley <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Yes, Suhas, that was my complaint with REWIND as written.
>>>>>>
>>>>>> In my opinion, any behavior dependent on the cache state is wrong.
>>>>>> For example, imagine if HTTP operated based on the cache state. Instead of
>>>>>> returning the full resource, a HTTP server was allowed to return a partial
>>>>>> response with byte range 68-419. Or if the HTTP server decided to return a
>>>>>> 599 INCOMPLETE CACHE error. It might be "easy" for the server to fulfill
>>>>>> requests solely from cache, but that's never the *intent *behind the
>>>>>> request, and the net result is a more complicated and inefficient protocol.
>>>>>>
>>>>>> In my opinion, if the subscriber requests a group, the
>>>>>> publisher/relay *should *make every effort to deliver it, including
>>>>>> requesting it from upstream (ie. like JOINING FETCH). I'd be in support of
>>>>>> REWIND if that change were made. Note that skipping an unservable sub-group
>>>>>> would be valid, much like a normal SUBSCRIBE request, but the relay must
>>>>>> recognize that this will hurt the user experience.
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 27, 2026 at 7:06 AM Suhas Nandakumar <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Clarifying question. IIUC REWIND was not addressing this use-case.
>>>>>>> Looks like the switch needs continuous groups with no gaps as it expects
>>>>>>> Relay to have cached the objects. REWIND does give up if there are gaps
>>>>>>>
>>>>>> --
>>>>>> 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]
>