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

["Mo Zanaty (mzanaty)" <[e-mail]>]

Prior Object ID Gap already handles the case where the original publisher made gaps. Maybe just make it required? But I don’t see how eliminating OP gaps helps relays or end subscribers, since they must still deal with non-OP gaps in subscribe and fetch, which seems like the dominant case.

If the problem is excessive relay upstream actions on a fragmented cache, can we just punt this downstream? If a fetch spans cached and unknown objects, deliver the cached and mark the rest unknown in the response. If it only spans unknown, only then request upstream.

Cheers,
Mo


________________________________
From: Aman Sharma <amsharma=[e-mail]>
Sent: Wednesday, 21 October 2026 23:02:02
To: Christian Huitema <[e-mail]>
Cc: Ian Swett <[e-mail]>; MOQ Mailing List <[e-mail]>
Subject: [Moq] Re: Simplifying the Object ID Model and caching

I think Ian’s proposal eliminates fetches needed merely to resolve intentionally unused ID slots, but you're right that fetches may still be needed to recover material omitted because of congestion (e.g. timeout cancellation, datagram dropping, etc).

On Wed, Oct 21, 2026 at 7:41 PM Christian Huitema <[e-mail]<mailto:[e-mail]>> wrote:


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]<mailto:[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]<mailto:[e-mail]>
>     To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>
>
> _______________________________________________
> Moq mailing list -- [e-mail]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>