Priorities

5.1.1. Definitions

MOQT maintains priorities between different schedulable objects. A schedulable object in MOQT is either:

1. The first or next Object in a Subgroup that is in response to a subscription.

2. An Object with forwarding preference Datagram.

3. An Object in response to a FETCH where that Object is the next Object in the response.

An Object is not schedulable if it is known that no part of it can be written due to underlying transport flow control limits.

A single subgroup or datagram has a single publisher priority. Within a subscription, it can be useful to conceptualize this process as scheduling subgroups or datagrams instead of individual objects on them. FETCH responses however can contain objects with different publisher priorities.

A priority numberis an unsigned integer with a value between 0 and 255. A lower priority number indicates higher priority; the highest priority is 0.

Subscriber Priority is a priority number associated with an individual request. It is carried in the SUBSCRIBER_PRIORITY parameter (Section 9.20.8), and can be updated. The subscriber priority of an individual schedulable object is the subscriber priority of the request that caused that object to be sent. When subscriber priority is changed, a best effort SHOULD be made to apply the change to all objects that have not been scheduled, but it is implementation dependent what happens to objects that have already been scheduled.

Publisher Priority is a priority number associated with an individual schedulable object. A default for the subscription is specified in the DEFAULT_PUBLISHER_PRIORITY Track Property (Section 10.4). Publisher priority can also be set per subgroup or datagram in the subgroup header or datagram (see Section 11), which overrides the default.

Group Order is a property of an individual subscription. It can be either 'Ascending' (groups with lower group ID are sent first), or 'Descending' (groups with higher group ID are sent first). The subscriber optionally communicates its group order preference in the SUBSCRIBE or SUBSCRIBE_TRACKS message; the publisher's preference, carried in the DEFAULT_PUBLISHER_GROUP_ORDER Track Property (Section 10.5), is used if the subscriber did not express one (by omitting the Group Order parameter). The group order of an existing subscription cannot be changed.

5.1.2. Scheduling Algorithm

When an MOQT publisher has multiple schedulable objects it can choose between, the objects SHOULD be selected as follows:

1. If two objects have different subscriber priorities associated with them, the one with the highest subscriber priority is scheduled to be sent first.

2. If two objects have the same subscriber priority, but different publisher priorities, the one with the highest publisher priority is scheduled to be sent first.

3. If two objects in the same subscription have the same subscriber and publisher priority, but belong to two different groups of the same track, the group order of the subscription is used to decide the one that is scheduled to be sent first. When a subscription fill's Group Order differs from the subscription's Group Order, the subscription-delivered object is scheduled first.

4. If two objects in the same subscription have the same subscriber and publisher priority and belong to the same group of the same track, and one is delivered by the fill fetch stream while the other is subscription-delivered, the fill-delivered object is scheduled first. Otherwise, the one with the lowest Subgroup ID (for objects with forwarding preference Subgroup), or the lowest Object ID (for objects with forwarding preference Datagram) is scheduled to be sent first. If the two objects have different Forwarding Preferences the datagram is sent first.

Within the same group, fill-delivered objects win the tie-break over subscription-delivered objects (rule 4) because objects with smaller Locations are assumed to be needed before those with larger Locations.

The definition of "scheduled to be sent first" in the algorithm is implementation dependent and is constrained by the prioritization interface of the underlying transport. For some implementations, it could mean that the object is serialized and passed to the underlying transport first. Other implementations can control the order packets are initially transmitted.

This algorithm does not provide a well-defined ordering for objects that belong to different subscriptions or FETCH responses, but have the same subscriber and publisher priority. The ordering in those cases is implementation-defined, though the expectation is that all subscriptions will be able to send some data.

A publisher might not utilize the entire available congestion window, session flow control, or all available streams for lower priority Objects if it expects higher priority Objects will be available to send in the near future or it wants to reserve some bandwidth for control messages.

Given the critical nature of control messages and their relatively small size, the control streams SHOULD be prioritized highest, followed by the bidi request streams and then all Objects. Bidi request streams MAY be prioritized within themselves by Subscriber Priority if specified.

5.1.3. Considerations for Setting Priorities

For downstream subscriptions, relays SHOULD respect the subscriber and original publisher's priorities. Relays can receive subscriptions with conflicting subscriber priorities or Group Order preferences. Relays SHOULD NOT directly use Subscriber Priority or Group Order from incoming subscriptions for upstream subscriptions. A Relay's use of these fields for upstream subscriptions can be based on factors specific to it, such as the popularity of the content or policy, or relays can specify the same value for all upstream subscriptions.

MOQT Sessions can span multiple namespaces, and priorities might not be coordinated across namespaces. The subscriber's priority is considered first, so there is a mechanism for a subscriber to fix incompatibilities between different namespaces prioritization schemes. Additionally, it is anticipated that when multiple namespaces are present within a session, the namespaces could be coordinating, possibly part of the same application. In cases when pooling among namespaces is expected to cause issues, multiple MOQT sessions, either within a single connection or on multiple connections can be used.

Implementations that have a default priority SHOULD set it to a value in the middle of the range (eg: 128) to allow non-default priorities to be set either higher or lower.