[Moq] Re: Knowing the start of a Subgroup

[Suhas Nandakumar <[e-mail]>]

As I shared my inputs during the call, SubgroupId has semantic meaning,
they are part of prioritization and an essential tool for filtering. I also
agree having relays knowing the first object in a sub-group is useful and
making it explicit and not needing to muddle 2 different
semantic entities is a good idea.
It is expected  for applications using layered codec and inter stream
dependencies to have the subgroup carry the same meaning across groups,
regardless of object numbering ( which is a in different semantic scope)

+1 to make this singal explicit and mandatory and also willing to have a
config byte on the first object that identifies if it is the first object
of group, track, sub-group. This info will be useful for caches and also
for the end application to build their buffer logic.



Cheers
Suhas


On Thu, Apr 30, 2026 at 9:40 AM Alan Frindell <afrind=
[e-mail]> wrote:

> > The original issue is about saving a byte or two when Object ID ==
> Subgroup ID. That seems like a simple encoding flag that doesn't require
> changing the API.
>
> This compression is already possible (when the two are equal you can set a
> flag in the header, and send only one).
>
> >  what's the use-case?
>
> The utility is to support extensions like REWIND, etc.  A cache needs to
> know if it has the beginning of a subgroup in order to serve it.  There are
> some heuristics you can use to learn this sometimes but an explicit signal
> is helpful.
>
> Thanks
>
> -Alan
>
>
> On Thu, Apr 30, 2026 at 9:24 AM
>  Luke Curley <[e-mail]> wrote:
>
>> I missed the interim, what's the use-case? The original issue is about
>> saving a byte or two when Object ID == Subgroup ID. That seems like a
>> simple encoding flag that doesn't require changing the API. I would not
>> require that Subgroup
>> I missed the interim, what's the use-case?
>>
>> The original issue is about saving a byte or two when Object ID ==
>> Subgroup ID. That seems like a simple encoding flag that doesn't require
>> changing the API.
>>
>> I would not require that Subgroup ID equal the first Object ID. If you
>> use sub-groups for SVC, you *should *have a catalog entry indicating
>> that sub-group N is an enhancement layer with parameters X (even just for
>> filtering). But without tight control of the encoder, there's no way to
>> enforce that frame N is the first frame of sub-group N. You'd have to +100
>> each sub-group ID (or something) just to maintain this contract for the
>> first frame of a sub-group... and for what purpose?
>>
>> A flag indicating an object is the first within its sub-group would be
>> easy. However, that information is already implicit via FETCH or SUBSCRIBE
>> object arrival order. I'm not sure *why *we suddenly need an explicit
>> flag, but whatever; it's just a bit.
>>
>> A flag indicating an object is the last within its sub-group would be
>> very tough. Encoders don't emit this information, nor would an app know
>> ahead of time that there will be no more deltas. You only truly know that a
>> group has ended when a new group begins and a stream FIN accomplishes this
>> just fine.
>>
>> On Thu, Apr 30, 2026, 8:11 AM Ian Swett <ianswett=
>> [e-mail]> wrote:
>>
>>> Thanks for clarifying.  Using subgroup IDs in the catalog is an
>>> interesting usecase I hadn't considered. I'm not sure this would cause
>>> practical problems, but I need more time to think about it.
>>>
>>> Regarding consistency, today we indicate the end of the Subgroup with a
>>> stream FIN, not a bitflag on the Object. So I actually think using Subgroup
>>> ID==Object ID is more consistent, but that's my opinion.
>>>
>>> When we originally created Subgroups, we needed an ID to stitch them
>>> together in case they were split apart.  I'm not sure anyone intended this
>>> be exposed to the application, but it sounds like you want to?  QUIC
>>> doesn't expose Stream IDs as part of its API, which was an intentional
>>> choice and mostly a good one.
>>>
>>> If we go with the bitflag approach (#1618), are people ok with requiring
>>> it be set on the first Object in the Subgroup?  Requiring it gives the
>>> feature a lot more value IMO.
>>>
>>> Also, do people want to resolve the undefined prioritization between
>>> Subgroups and datagrams in some way?
>>> *"3. If two objects in response to the same request have the same
>>> subscriber*
>>>
>>>
>>>
>>>
>>> *   and publisher priority and belong to the same group of the same
>>> track, the   one with **the lowest Subgroup ID** (for objects with
>>> forwarding preference   Subgroup), or **the lowest Object ID** (for objects
>>> with forwarding preference   Datagram) is scheduled to be sent first.  If
>>> the two objects have   different Forwarding Preferences the order is
>>> implementation dependent."*
>>>
>>>
>>> Thanks, Ian
>>>
>>> On Thu, Apr 30, 2026 at 5:22 AM Magnus Westerlund <magnus.westerlund=
>>> [e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> My worry is exactly related to that one would like to bind sub-group
>>>> IDs to catalog info making clear what improvement a particular subgroup
>>>> contains. I think this matters in two ways. First related to end subscriber
>>>> processing it during decoding operations. This also matters if one want to
>>>> use the sub group filter as the subscriber need to know that the publisher
>>>> uses the subgroup IDs consistently.
>>>>
>>>> With the proposal in place I think it limits the possibility to apply
>>>> additional constraints on the object IDs. For example if one want the
>>>> object IDs in decoding order without gaps across a full tree of different
>>>> sub-groups then one have a constraint that may be difficult to fulfil if
>>>> one need to reconfigure the encoder between groups to handle bandwidth
>>>> limitation between the original publisher and the relay. The
>>>> reconfiguration could mean skipping a sub group completely in this group.
>>>> This will require a gap in the object ID to skip over the object ID = sub
>>>> group ID.
>>>>
>>>> Yes clearly if one assign no additional semantics and accept gaps in
>>>> object IDs the idea in #1608 can work. However, I think it is limitation
>>>> that people with more advanced use cases in the future will be annoyed with
>>>> and may result in significantly more additional signalling about gaps etc
>>>> than an explicit start of sub-group indicator would require.
>>>>
>>>> Cheers
>>>>
>>>> Magnus
>>>>
>>>>
>>>>
>>>> *From: *Cullen Fluffy Jennings <[e-mail]>
>>>> *Date: *Thursday, 30 April 2026 at 07:08
>>>> *To: *Ian Swett <ianswett=[e-mail]>
>>>> *Cc: *MOQ Mailing List <[e-mail]>
>>>> *Subject: *[Moq] Re: Knowing the start of a Subgroup
>>>>
>>>>
>>>> Three thoughts ….
>>>>
>>>> 1) I don’t deeply care about this one way or the other but I think we
>>>> should make it mirror the end marker bits. If the original publisher knows
>>>> it is the start, or knows it is the end, it should add the marker. I think
>>>> we should deal with start of track, start of group, at the same time as
>>>> subgroup as it is the same issue.
>>>>
>>>> 2) Imagine a case where you want to refer to the SubGroup ID in the
>>>> catalog to explain what layer of a codec is in that subgroup. And assume
>>>> you want  the object ID to increment by 1 in the group. I'm just not seeing
>>>> how it works in this case.
>>>>
>>>> 3) Mostly I don’t worry about how we spell it on the wire but FWIW … My
>>>> gut feel is we are pinning to very weird implicit signaling by taking two
>>>> things that have nothing to do with each other, the subgroup id and the
>>>> object id, then saying if they are equal, it means some third thing. I’d
>>>> rather just explicitly signal the third thing and not have it be some
>>>> implicit convention on how to use the first two things.
>>>>
>>>>
>>>>
>>>> > On Apr 29, 2026, at 3:10 PM, Ian Swett <ianswett=
>>>> [e-mail]> wrote:
>>>> >
>>>> > In Monday's interim, there was strong interest in knowing what the
>>>> starting Object Id of a Subgroup is, just like we know the end today.
>>>> >
>>>> > My proposal (#1608) was to require the Subgroup ID equal the Object
>>>> ID of the first Object of the Subgroup. The original publisher would do
>>>> this, and it would naturally be preserved downstream, just like Subgroup ID
>>>> and Object ID are today. Some people had concerns with this, but I don't
>>>> think I fully understood them?  If anyone wants to spell them out in more
>>>> detail, that would be great.
>>>> >
>>>> > To clarify, this retains the ability to stitch together a Subgroup
>>>> that arrived on two separate streams for whatever reason.  That is a core
>>>> requirement for Subgroups.
>>>> >
>>>> > I'm not set on my particular design, but I reviewed #1618 (which uses
>>>> a bitflag) and I think #1608 has two important advantages:
>>>> > 1) It's required
>>>> > 2) If you receive some Objects from a Subgroup, you know if the first
>>>> one is the first Object in the subgroup.
>>>> >
>>>> > Thoughts?
>>>> >
>>>> > Thanks, 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]
>>>
>> --
>> 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]
>