What is the Subgroup ID of a Datagram FP object?

[martinduke]

if a Datagram object is delivered via FETCH (which doesn't really make sense, see #599 and #588), what Subgroup ID do I put in the FETCH object header?

The only answers that make sense are zero, or the object ID.

[ianswett]

I think the answer is getting datagrams via FETCH doesn't make much sense?

[martinduke]

Agreed! The point of this issue is that there is an ambiguity in the spec unless we choose to close it via 588 or 599

[fluffy]

I think we need to be able to fetch object that were originally delivered over datagram. Common use case is audio is over datagram and client got disconnected from the meeting for 10 seconds, rejoined, wants to get the missing 10 seconds and replay and 1.5x speed till it catches up then joins live meeting.

I was sort of assuming subgroup would be zero for datagrams but I had not thought about using object ID. I would be concerned when doing that that object id can be large but size sub groups are limited to be pretty small so we could make them work with priorities. My question would be, does it every matter in anyway what the subgroup is for fetch ? If not, then zero seems fine.

[afrind]

Individual Comment:

+1 for using zero

does it every matter in anyway what the subgroup is for fetch?

It does if data that is FETCHed can later be subscribed to. Today it's possible because SUBSCRIBE allows Current Group (#598). If adding JOIN removes that (I think it should) then the protocol wouldn't have a direct use for subgroup. I wonder if there's a case of FETCHing a static asset to a re-broadcast publisher that would recreated the broadcast and want the subgroups though. I'm inclined to keep them in the FETCH stream wire format, at least for now.

[suhasHere]

The easiest way to think about this probably is, datagrams for a track have just on subgroup and thus its value is 0.

I feel subgroup concept is important since it allows a publisher

• to control granularity of HOL blocking (based on subgroup size)
• support different priorities within a group

I am not too sure of the requirement of fetched data to serve subscription. Even in JOIN flows, it is internally fetch + subscribe. We have following cases:

Case 1: Objects are sent as datagrams and cached with subgroup of 0
On Join, fetch will return all the objects until live edge on a single stream and then subscribe will get all the new objects as datagrams. Basically fetch flattens the priorities, original stream mapping (datagram here) and just returns objects from the cache.

Case2: Objects are sent over streams and can have one or more subgroups. So when cached, objects can have different subgroupIds.
On Join, fetch will return all the objects until live edge on a single stream and then subscribe will get all the new objects based on the subgroup mapping in one or more streams. Even here, fetch flattened the subgroups and priorities and just returns objects from the cache.

What am i missing here ?

[afrind]

I am not too sure of the requirement of fetched data to serve subscription

Maybe you want this comment on #588 ?

I think for now a PR with subgroup=0 should resolve this.

[ianswett]

I don't have that strong a preference, but I would think having all Datagrams in a Group have the same subgroup ID would indicate I should be sending them over a single stream? Making the subgroup ID the same as the Object ID is more in keeping with the SubGroup == Stream transmission model.

[afrind]

Individual Comment:

I previously +1 using zero but I'm convinced by Ian's argument to set it to the object ID. That may result in ever-so-slightly larger FETCH responses when there are more than 64 objects in a group, but I think that's in the noise.