[Moq] Re: Simplifying the Object ID Model and caching

[Christian Huitema <[e-mail]>]

What happens if a relay is skipping some subsets as a response to 
congestion?

On 10/21/2026 7:36 PM, Aman Sharma wrote:
>
> I agree that this would be a simplification, and would allow us to 
> remove the Prior Object ID Gap property. Any implementation relying on 
> non-contiguous object IDs could trivially define its own parameter to 
> convey the information previously conveyed through object IDs.
>
>
>
> On Wed, Oct 21, 2026 at 7:00 PM Ian Swett 
> <ianswett=[e-mail]> wrote:
>
>     I believe all members of this WG can agree that the MoQ Object
>     Model is too complex. In the past, we've been unable to simplify
>     it, but I believe there is a simplification that improves caching
>     and is acceptable. That's sequentially
>     I believe all members of this WG can agree that the MoQ Object
>     Model is too complex. In the past, we've been unable to simplify
>     it, but I believe there is a simplification that improves caching
>     and is acceptable.
>
>     That's sequentially increasing Object IDs beginning at 0 (ie: 0,
>     1, 2, 3, etc).  This makes it trivial to know when all the Objects
>     in a Group have been received once the End of Group is received,
>     and it avoids unnecessary Fetches upstream when a Track is
>     initially Subscribe-delivered and then cached.
>
>     I realize there is an attraction to ascribing a meaning to the
>     Object ID (e.g., using it for the timestamp), but the byte savings
>     are minimal at best and this makes MoQ much more brittle. Don't
>     think I haven't tried.
>
>     Are there people for whom this would break their usecase and can
>     they explain why?
>
>     Ian
>     _______________________________________________
>     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]