moq-wg / moq-transport

draft-ietf-moq-transport
Other
87 stars 22 forks source link

Alternate Priority Clarification Proposal #585

Closed afrind closed 2 weeks ago

afrind commented 1 month ago

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:

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:

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

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

UPDATE_PUBLISHER_SUBSCRIPTION_PRIORITY {
    Subscribe ID (i)
    Priority (8)
}
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 commented 1 month 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.

suhasHere commented 3 weeks ago

+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 )

ianswett commented 2 weeks ago

The WG indicated interest in the other approach on the list and in today's MoQ session.