Alternate Priority Clarification Proposal

[afrind]

This is an individual technical proposal for modifying the priority algorithm added in draft-05 (herein called "Seattle").

Draft-05 contains the following text:

When two or more subscriptions have equal subscriber priority, the original publisher priority is considered next and can change within the track, so subscriptions are prioritized based on the highest priority data available to send. For example, if the subscription had data at priority 6 and priority 10 to send, the subscription priority would be 6.

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:

1. Subscriber Subscription Priority: Subscriber specified priority of a subscription relative to other subscriptions
2. Publisher Subscription Priority: Publisher specified priority of a subscription relative to other subscriptions
3. Subscriber Group Order: Subscriber specified group order preference within a subscription, Ascending, Descending or Default to Publisher
4. Publisher Group Order: Publisher specified group order preference within a subscription; only considered when Subscriber Group Order is Default to Publisher.
5. Object Priority: Publisher specified priority of subgroup and datagram relative to other subgroups/datagrams in the same group

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;

  • If more than one subscription has this priority; select the subscription with the highest Publisher Subscription Priority;
    • If more than one subscription has this priority; the implementation chooses, with the assumption that every subscription makes some progress

• 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 more than one subgroup has the same priority; choose the one with the lower subgroup ID.

• If using datagrams, select the Object with the highest Object Priority

  • if more than one datagram has the same priority; choose the one with the lower Object ID

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:

Group 0, Subgroup 0, Priority 1
Group 1, Subgroup 0, Priority 3
Group 2, Subgroup 0, Priority 2

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:

1. • Subscribe OK contains a mandatory field for Publisher Subscription Priority
2. • One or more new messages to change the Publisher Subscription Priority:

• A new Object Status “Family”, eg:

UPDATE_PUBLISHER_SUBSCRIPTION_PRIORITY 0x100 - 0x1FF where the last 8 bits are the new priority

• A new unidirectional stream header

UPDATE_PUBLISHER_SUBSCRIPTION_PRIORITY {
    Subscribe ID (i)
    Priority (8)
}

• A control message

UPDATE_PUBLISHER_SUBSCRIPTION_PRIORITY {
    0xTBD
    Length (i)
    Subscribe Id (i)
    Priority (8)
}

Any of these messages could work but they have tradeoffs that can be discussed.

[vasilvv]

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.