[Moq] Re: Knowing the start of a Subgroup

[Luke Curley <[e-mail]>]

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