Clarify Objects from different subgroups can be sent on the same FETCH stream

[yekuiwang]

Can Subgroups be used in a FETCH response? My current understanding of the MOQT draft is no. Is that understanding correct?

If so, why? It seems to me there is no such an essential difference between sending Objects of a Group as a response to a FETCH or as a response to a SUBSCRIBE that would determine the use or not use of Subgroups. Appreciate any clarification!

[afrind]

The subgroup ID is sent, but you cannot break the fetch response into multiple streams by subgroup, as is done in subscribe responses. One of the functions of FETCH is to help the receiver understand where the gaps of non-existent objects are in the track. Splitting into multiple streams makes this very difficult. Another purpose of the single stream is to make the response easily flow controlled by the receiver.

[yekuiwang]

@afrind Thank you! I can understand the first reason. For the second reason (i.e., to make the response easily flow controlled by the receiver), what is the difference herein between FETCH and SUBSCRIBE?

[yekuiwang]

BTW, Sec. 2.2 includes the following sentence: "Objects from two subgroups cannot be sent on the same stream." I did not check whether such sentences exist also in other places. A clarification should be made to the text to make it clear that such statement(s) do not apply when Objects are sent as a response to a FETCH request.

[afrind]

what is the difference herein between FETCH and SUBSCRIBE?

Let's say a Track uses an object per stream and the underlying transport has a 1000 stream maximum and an initial max stream data of 64k. A FETCH over a wide range could result in the publisher immediately opening all 1000 streams and sending 64MB of data.

By forcing FETCH to a single stream, the most the publisher can send without the peer sending additional credit is a single max stream data.

To some degree SUBSCRIBE also has this problem however it's limited to the publisher's ability to produce the data for this track at the live edge. We felt like FETCH was worse since it can be used to request a very large amount of past data. That said, there's also #869, to which we don't really have an answer yet. I think we discussed this a bunch at the interim last October in Boston, I'm sure the YouTube recording is very entertaining.

Minutes Session 1. You can find additional minutes for sessions 19,20 and 21.

[yekuiwang]

@afrind Thank you so much for the clarifications and the pointers to earlier related discussions; great to learn! I will do something to add myself to the loop of further discussions in #869.

[yekuiwang]

BTW, Sec. 2.2 includes the following sentence: "Objects from two subgroups cannot be sent on the same stream." I did not check whether such sentences exist also in other places. A clarification should be made to the text to make it clear that such statement(s) do not apply when Objects are sent as a response to a FETCH request.

@afrind Any opinion herein?

[suhasHere]

Since fetch talks about objects matching the request and how it is sent on a unidirectional stream, subgroups doesn't seem to apply. Object header carry subgroupIds, but from fetch perspective it is filling in objects from the requested range.

"The publisher responding to a FETCH is responsible for delivering all available Objects in the requested range in the requested order. The Objects in the response are delivered on a single unidirectional stream"

Would you think adding some text that says Object's SubGroupID is not used in determining the stream mapping ?

[afrind]

Objects from two subgroups cannot be sent on the same stream.

We could add "in a subscription" to differentiate from FETCH.

I'm marking this issue past deadline since sending FETCH responses on a single stream represents working-group consensus.

[afrind]

Also, if you want subgroups on different streams in a FETCH response, then #1164 might allow you to make N fetches, each filtering for a particular subgroup.

[yekuiwang]

Would you think adding some text that says Object's SubGroupID is not used in determining the stream mapping ?

But in response to a SUBSCRIBE with Forwarding Preference = Subgroup, each Subgroup is sent in its own stream, isn't that essentially saying that there is a one-to-one mapping between Subgroup ID and stream?

[yekuiwang]

Objects from two subgroups cannot be sent on the same stream.

We could add "in a subscription" to differentiate from FETCH.

Is that sufficient, since a joining FETCH is associated with a subscription?