Closed afrind closed 2 weeks ago
I don't think the algorithm proposed here is what we want.
The biggest problem I see with it is that the group order takes precedence over any priority assigned to individual subgroups, which means that all subgroups of a given group will be delivered before any subgroups of the subsequent group. This sounds like the opposite of desirable for SVC (we presumably want the base layer in the next group before enhancement on the current one).
The other thing it does is it introduces a track-wide publisher priority, which, given the use cases I've heard described so far (see my analysis here) is probably not what we want.
+1 to Victor. What we want is to pick the object to send next that is of higher priority regardless of what group it belongs to .. So for example if we had following at the relay to pick the next : G1, Sub1 (priortity = 2) O1 , Sub2 (priority = 3) O2 G2, Sub1(priority = 2) O1, Sub2 (priority = 3) O2
the order we want the objects to go out is G1,O1, G2 O1, G1 02, G2 O2
This would need the priority algorithm to pick the high priority sub-group available at any given point . I am still not convinced GroupOrder makes much sense for Subscriptions ( may be that's adding more confusion )
The WG indicated interest in the other approach on the list and in today's MoQ session.
This is an individual technical proposal for modifying the priority algorithm added in draft-05 (herein called "Seattle").
Draft-05 contains the following text:
My interpretation of this text is that when a relay receives a new object with higher priority than any queued objects on that subscription, it elevates the publisher subscription priority to this new higher priority. When it receives objects with lower priority than any queued objects, there is no impact to the publisher subscription priority. When the relay dequeues an object of higher priority than remaining queued objects, it lowers the priority of the subscription.
Maintaining the subscription priority in this way is complex and potentially computationally expensive. The following proposal is intended to address that while otherwise maintaining the properties of Seattle algorithm, specifically selecting the next group within a prioritized subscription before selecting a subgroup from that group.
MoQ Priority Proposal “Boston”
The proposal supports the following priority signals:
When “highest” and “lowest” are used to compare priorities, “highest” means the highest priority, which has the lowest numerical value, and vice versa.
The priority algorithm is:
A relay selects the subscription with the highest Subscriber Subscription Priority;
From the selected subscription, use the Group Order to choose the group to send from (either highest or lowest available).
If using stream-per-track, send the object with the lowest Object ID.
If using stream-per-subgroup, select the subgroup with the highest Object Priority
If using datagrams, select the Object with the highest Object Priority
Analysis:
The proposal in #518 uses the Object Priority as both the Publisher Subscription Priority and Object Priority. In order to express increased importance of a particular subscription or track, it must also elevate the priority of the subgroup or datagrams relative to the subgroups and datagrams in the same group and other groups.
Both Seattle and 518 can only change subscription priority by sending new subgroups or datagrams, although the wire format proposed below could also address this.
The 518 proposal also relegates Group Order to a less significant place in the priority hierarchy. Consider a track with a single subgroup per group. The subscriber may have asked for Group Order Ascending, but the publisher sets Object Priority as follows:
Assuming queuing happens at the relay, it will send the groups 0, 2, 1 which is neither ascending nor descending, and overrides the subscriber preference.
In the new proposal, when the relay receives a new publisher priority signal, all unsent data in the subscription updates to that priority, the send order of groups and objects within that subscription remains unchanged. Subscription Priority can be changed at any time and does not require producing an object or beginning a new subgroup.
“Boston” Wire Format changes:
Identical to draft-06 with the following additions:
UPDATE_PUBLISHER_SUBSCRIPTION_PRIORITY 0x100 - 0x1FF
where the last 8 bits are the new priorityAny of these messages could work but they have tradeoffs that can be discussed.