MoQ priorities allow a subscriber and original publisher to influence the transmission order of Objects within a session in the presence of congestion.
Given the critical nature of control messages and their relatively small size, the control stream SHOULD be prioritized higher than all subscribed Objects.
Both SUBSCRIBE and FETCH messages indicate a subscriber priority and group order, so the following text applies equally to both types of subscriptions.
The subscriber indicates the priority of a subscription via the Subscriber Priority field and the original publisher indicates priority in every stream or datagram header. As such, the subscriber's priority is a property of the subscription and the original publisher's priority is a property of the Track and the Objects it contains. In both cases, a lower value indicates a higher priority, with 0 being the highest priority.
When Objects are contained in Subgroups, all Objects in the Subgroup have the same priority.
The Subscriber Priority is considered first when selecting a subscription to send data on within a given session. 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. When both the subscriber and original publisher priorities for a subscription are equal, how much data to send from each subscription is implementation-dependent, but the expectation is that all subscriptions will be able to send some data.
The subscriber's priority can be changed via a SUBSCRIBE_UPDATE message. This updates the priority of all unsent data within the subscription, though the details of the reprioritization are implementation-specific.
Subscriptions have a Group Order of either 'Ascending' or 'Descending', which indicates whether the lowest or highest Group Id SHOULD be sent first when multiple Groups are available to send. A subscriber can specify either 'Ascending' or 'Descending' in the SUBSCRIBE message or they can specify they want to use the Original Publisher's Group Order, which is indicated in the corresponding SUBSCRIBE_OK.
Within the same Group, and the same priority level, Objects with a lower Object Id are always sent before objects with a higher Object Id, regardless of the specified Group Order. If the group contains more than one Subgroup and the priority varies between these Subgroups, higher priority Subgroups are sent before lower priority Subgroups. If the specified priority of two Subgroups in a Group are equal, the lower Subgroup ID has priority. Within a Subgroup, Objects MUST be sent in increasing Object ID order.
The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and instead an UNSUBSCRIBE and SUBSCRIBE can be used.
Relays SHOULD respect the subscriber and original publisher's priorities. Relays SHOULD NOT directly use Subscriber Priority or Group Order from incoming subscriptions for upstream subscriptions. Relays use of Subscriber Priority 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.
MoQ 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 MoQ sessions, either within a single connection or on multiple connections can be used.