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

[Luke Curley <[e-mail]>]

Yeah, Prior Object ID helps a lot in the usual case. It gives the relay
enough information to know that 0..N has been delivered within a group,
unless there's loss and multiple sub-groups.

I strongly recommend making Prior Object ID required. However, this would
break disjoint multi-publisher (two publishers, interleaved objects in the
same group). That use-case is completely broken anyway for FETCH (and thus
FILL).

Also, timestamps in moq-transport are a great replacement for Object ID
gaps. Each object in a sub-group would be +1, while the timestamp can jump
forward (or backward) an arbitrary amount.

On Thu, Oct 22, 2026 at 12:53 PM Ian Swett <ianswett=
[e-mail]> wrote:

> 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]
>