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

[Suhas Nandakumar <[e-mail]>]

On Thu, Oct 22, 2026 at 1:59 PM Mo Zanaty (mzanaty) <mzanaty=
[e-mail]> wrote:

> What about a Mandatory Track Property “Mind the Gap”? Publishers MUST add
> it if the track can have any gaps in Group or Object ID, and SHOULD signal
> each one via Prior Group/Object ID Gap Object Properties. Relays can then
> assume any track without this is “dense” like Suhas’ AI. :)
>
> This puts the burden of unknown gap handling on relays which specifically
> advertise they can “Mind the Gap”. A basic relay can assume dense tracks if
> it never advertises this, so it can always fetch upstream if it needs to
> fill a cache without wasting any fetch requests on non-existent gaps. This
> doesn’t guarantee the relay won’t see gaps, but it will know they are
> missing objects, not unknown status.
>
> If we want to simplify the spec and push more things to extensions, which
> seemed to be the sentiment at the interim, we could move all of this (Mind
> the Gap MTP, Prior Group/Object OPs) to an extension draft. The core draft
> would only define behavior for dense tracks. The extension draft would
> define tracks with gaps.
>

[Suhas] The specification as defined today does already provide a natural
way for applications that follow continuous sequences to work fine
end-to-end. We have been building such applications and/or relays for a
while.  For cases , as defined in my earlier email, the spec provides
mechanisms to specify it in the wire-format.  Even for applications that
have need for continuous sequence numbers, OP needs a way to say there will
be a gap, relays need a way to handle gaps ( datagrams lost, stream reset
and restart across pause/resumes and sub-group mappings ) . F


>
> Cheers,
> Mo
>
>
> *From: *Ian Swett <[e-mail]>
> *Date: *Thursday, October 22, 2026 at 3:52 PM
> *To: *Mo Zanaty (mzanaty) <[e-mail]>
> *Cc: *Aman Sharma <amsharma=[e-mail]>; Christian Huitema
> <[e-mail]>; MOQ Mailing List <[e-mail]>
> *Subject: *Re: [Moq] Re: Simplifying the Object ID Model and caching
>
> Yes, Prior Object ID Gap can help, though I'm unsure how to make it
> required in practice?  I guess a Subscriber to an OP could declare a Track
> Malformed if it didn't include the Prior Object ID gaps?
>
> Unless we did something like what Luke suggested, the cache will have gaps
> and Relays will have to deal with that, but sequential IDs (or required
> Prior Object ID Gaps) do make the problem easier.
>
> Ian
>
> On Thu, Oct 22, 2026 at 9:03 AM Mo Zanaty (mzanaty) <[e-mail]>
> wrote:
>
> 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]>
> 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]> 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]
>
> _______________________________________________
> Moq mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>