If you can't deliver an entire Group, should you send any Objects for a Track?

[ianswett]

There are times when you are certain you cannot deliver the entire Track/Group due to bandwidth constraints. The draft today is written with the idea that you'd send what you could according to priority, but I think there are cases that's just going to risk causing congestion for other Subscriptions and delay their delivery.

I think there are potentially valid use cases for either behavior, so we might want a way to specify what you want? Alternatively, we could add text pointing this out and leave it at that.

[afrind]

So you want a GROUP_DELIVERY_TIMEOUT, and the publisher tries to estimate how long it will take to send the entire group?

[gwendalsimon]

Shouldn't it be at the level of subgroup?
I thought that the subgroup would be the concept where we put together inter-related objects, although Groups are mainly join points. When I present MOQ, I often explain that subgroup is a key MOQ feature because it is where you can use QUIC stream reset and cancels to a specific set of consecutive video frames if you know for sure that these frames will arrive too late.

[wilaw]

There are times when you are certain you cannot deliver the entire Track/Group due to bandwidth constraints. The draft today is written with the idea that you'd send what you could according to priority, but I think there are cases that's just going to risk causing congestion for other Subscriptions and delay their delivery.

I don't believe it should be the publishers' concern. It should faithfully execute the prioritization instructions which were given to it by the subscriber. If the subscriber prioritizes tracks poorly, resulting in congestion, that congestion is a feedback mechanism to the subscriber that they should adjust their prioritization strategy. It is important for a control system that there is a deterministic output for the input actions of the initiator of the traffic, which is the subscriber. If the relay starts taking de-coupled actions, based on its own adjudged inability to deliver a group, it can lead to an unstable system with worse consequence for both parties.

[ianswett]

Thanks for the feedback. It sounds like this might be a case where you only want the behavior I'm describing if you're doing some flavor of server-side ABR and you know that two (or more) Tracks are alternatives and there's no need in delivering them both?

[ianswett]

If we were going to make a change, I was thinking it'd be something as simple as a bool for "FullGroupsOnlyPlease". Somewhat similar to HTTP extensible priorities where you can indicate if you want incremental delivery or not.

[afrind]

This sounds like an extension to me, or something to be tackled with publisher side ABR, which maybe should also be an extension.