Add Priority and Group Send Order to SUBSCRIBE, clarify Publisher Priority

draft-ietf-moq-transport.md

@@ -85,8 +85,7 @@ discovery and subscription.
 
 * {{session}} covers aspects of setting up a MOQT session.
 
-* {{priority-congestion}} covers protocol considerations on
-  prioritization schemes and congestion response overall.
+* {{priorities}} covers mechanisms for prioritizing subscriptions.
 
 * {{relays-moq}} covers behavior at the relay entities.
 
@@ -534,100 +533,61 @@ expects more OBJECTs to be delivered. The server closes the session with a
 'GOAWAY Timeout' if the client doesn't close the session quickly enough.
 
 
-# Prioritization and Congestion Response {#priority-congestion}
+# Priorities {#priorities}
 
-TODO: This is a placeholder section to capture details on how the MOQT
-protocol deals with prioritization and congestion overall.
+MoQ priorities allow a subscriber and original publisher to influence
+the transmission order of Objects within a session in the presence of
+congestion.
 
-This section is expected to cover details on:
+The subscriber indicates the priority of a subscription via the
+Subscriber Priority field and the original publisher indicates priority
+in every stream 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.
 
-- Prioritization Schemes.
-- Congestion Algorithms and impacts.
-- Mapping considerations for one object per stream vs multiple objects
-  per stream.
-- Considerations for merging multiple streams across domains onto single
-  connection and interactions with specific prioritization schemes.
+The Subscriber Priority is considered first when selecting
+a subscription to send data on within a given session. 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, send order is implementation-dependent, but the
+expectation is that all subscriptions will be able to send some data.
 
-## Order Priorities and Options
+The subscriber's priority can be changed via a SUBSCRIBE_UPDATE message.
 
-At the point of this writing, the working group has not reached
-consensus on several important goals, such as:
+The publisher SHOULD respect the subscriber and original publisher's
+priorities.
 
-* Ensuring that objects are delivered in the order intended by the
-  emitter
-* Allowing nodes and relays to skip or delay some objects to deal with
-  congestion
-* Ensuring that emitters can accurately predict the behavior of relays
-* Ensuring that when relays have to skip and delay objects belonging to
-  different tracks that they do it in a predictable way if tracks are
-  explicitly coordinated and in a fair way if they are not.
+In addition, SUBSCRIBE specifies a Delivery Order of either
+'Ascending' or 'Descending', which indicates whether the lowest or
+highest Group Id SHOULD be delivered first when multiple Groups are
+available to send.
 
-The working group has been considering two alternatives: marking objects
-belonging to a track with an explicit "send order"; and, defining
-algorithms combining tracks, priorities and object order within a
-group. The two proposals are listed in {{send-order}} and
-{{ordering-by-priorities}}.  We expect further work before a consensus
-is reached.
+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 Delivery Order.
 
-### Proposal - Send Order {#send-order}
+Relays SHOULD NOT directly use Subscriber Priority or Delivery Order
+from incoming subscriptions for upstream subscriptions. Relays use of
+Subscriber Priority for upstream subscriptions is based on
+a number of factors specific to it, such as the popularity of the
+content or policy.
 
-Media is produced with an intended order, both in terms of when media
-should be presented (PTS) and when media should be decoded (DTS).  As
-stated in the introduction, the network is unable to maintain this
-ordering during congestion without increasing latency.
+MoQ Sessions can span multiple namespaces, and priorities are treated
+equally, regardless of the namespace.  The subscriber's priority is
+considered first, so there is no incentive for the original publisher
+to attempt to prioritize all of its Tracks higher than another
+namespace.  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.
 
-The encoder determines how to behave during congestion by assigning each
-object a numeric send order.  The send order SHOULD be followed when
-possible, to ensure that the most important media is delivered when
-throughput is limited.  Note that the contents within each object are
-still delivered in order; this send order only applies to the ordering
-between objects.
+## Priority Algorithm
 
-A publisher MUST send each object over a dedicated stream.  The library
-should support prioritization ({{priority-congestion}}) such that
-streams are transmitted in send order.
-
-A subscriber MUST NOT assume that objects will be received in send order,
-for the following reasons:
-
-* Newly encoded objects can have a smaller send order than outstanding
-  objects.
-* Packet loss or flow control can delay the send of individual streams.
-* The publisher might not support stream prioritization.
-
-TODO: Refer to Congestion Response and Prioritization Section for
-further details on various proposals.
-
-### Proposal - Ordering by Priorities {#ordering-by-priorities}
-
-Media is produced as a set of layers, such as for example low definition
-and high definition, or low frame rate and high frame rate. Each object
-belonging to a track and a group has two attributes: the object-id, and
-the priority (or layer).
-
-When nodes or relays have to choose which object to send next, they
-apply the following rules:
-
-* within the same group, objects with a lower priority number (e.g. P1)
-  are always sent before objects with a numerically greater priority
-  number (e.g., P2)
-* 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.
-* objects from later groups are normally always sent before objects of
-  previous groups.
-
-The latter rule is generally agreed as a way to ensure freshness, and to
-recover quickly if queues and delays accumulate during a congestion
-period. However, there may be cases when finishing the transmission of
-an ongoing group results in better user experience than strict adherence
-to the freshness rule. We expect that that the working group will
-eventually reach consensus and define meta data that controls this
-behavior.
-
-There have been proposals to allow emitters to coordinate the allocation
-of layer priorities across multiple coordinated tracks. At this point,
-these proposals have not reached consensus.
 
 
 # Relays {#relays-moq}
@@ -638,6 +598,10 @@ similar in functionality to Content Delivery Networks
 (CDNs). Additionally, relays serve as policy enforcement points by
 validating subscribe and publish requests at the edge of a network.
 
+Relays are not required to cache Objects, but relays need to have
+the ability to distribute one upstream subscription to multiple
+downstream subscriptions.
+
 ## Subscriber Interactions
 
 Subscribers interact with the Relays by sending a SUBSCRIBE
@@ -746,12 +710,6 @@ fields, such as priority order and other metadata properties in the
 OBJECT message header. Unless determined by congestion response, Relays
 MUST forward the OBJECT message to the matching subscribers.
 
-## Congestion Response at Relays
-
-TODO: Refer to {{priority-congestion}}. Add details to describe relay
-behavior when merging or splitting streams and interactions with
-congestion response.
-
 ## Relay Object Handling
 
 MOQT encodes the delivery information for a stream via OBJECT headers
@@ -760,8 +718,7 @@ forwarding.
 
 A relay MUST treat the object payload as opaque.  A relay MUST NOT
 combine, split, or otherwise modify object payloads.  A relay SHOULD
-prioritize streams ({{priority-congestion}}) based on the send
-order/priority.
+prioritize sending Objects based on {{priorities}}.
 
 A publisher SHOULD begin sending incomplete objects when available to
 avoid incurring additional latency.
@@ -1039,6 +996,8 @@ SUBSCRIBE Message {
   Track Alias (i),
   Track Namespace (b),
   Track Name (b),
+  Subscriber Priority (8),
+  Delivery Order (8),
   Filter Type (i),
   [StartGroup (i),
    StartObject (i)],
@@ -1068,6 +1027,14 @@ close the session with a Duplicate Track Alias error ({{session-termination}}).
 
 * Track Name: Identifies the track name as defined in ({{track-name}}).
 
+* Subscriber Priority: Specifies the priority of a subscription relative to
+other subscriptions in the same session. Lower numbers get higher priority.
+See {{priorities}}.
+
+* Delivery Order: Requests Objects for the subscription be delievered in
+Ascending (0x0) or Descending (0x1) order. See {{priorities}}.
+Values larger than 0x1 are a protocol error.
+
 * Filter Type: Identifies the type of filter, which also indicates whether
 the StartGroup/StartObject and EndGroup/EndObject fields will be present.
 See ({{sub-filter}}).
@@ -1118,6 +1085,7 @@ SUBSCRIBE_UPDATE Message {
   StartObject (i),
   EndGroup (i),
   EndObject (i),
+  Subscriber Priority (8),
   Number of Parameters (i),
   Subscribe Parameters (..) ...
 }
@@ -1137,6 +1105,10 @@ open-ended.
 * EndObject: The end Object ID, plus 1. A value of 0 means the entire group is
 requested.
 
+* Subscriber Priority: Specifies the priority of a subscription relative to
+other subscriptions in the same session. Lower numbers get higher priority.
+See {{priorities}}.
+
 * Subscribe Parameters: The parameters are defined in {{version-specific-params}}.
 
 ## UNSUBSCRIBE {#message-unsubscribe}
@@ -1252,8 +1224,8 @@ A canonical MoQ Object has the following information:
 IDs starts at 0, increasing sequentially for each object within the
 group.
 
-* Object Send Order: An integer indicating the object send order
-{{send-order}} or priority {{ordering-by-priorities}} value.
+* Publisher Priority: An 8 bit integer indicating the publisher's priority for
+the Object {{priorities}}.
 
 * Object Forwarding Preference: An enumeration indicating how a publisher sends
 an object. The preferences are Track, Group, Object and Datagram.  An Object
@@ -1334,7 +1306,7 @@ OBJECT_STREAM Message {
   Track Alias (i),
   Group ID (i),
   Object ID (i),
-  Object Send Order (i),
+  Publisher Priority (8),
   Object Status (i),
   Object Payload (..),
 }
@@ -1371,7 +1343,7 @@ OBJECT_DATAGRAM Message {
   Track Alias (i),
   Group ID (i),
   Object ID (i),
-  Object Send Order (i),
+  Publisher Priority (8),
   Object Status (i),
   Object Payload (..),
 }
@@ -1403,7 +1375,7 @@ stream header.
 STREAM_HEADER_TRACK Message {
   Subscribe ID (i)
   Track Alias (i),
-  Object Send Order (i),
+  Publisher Priority (8),
 }
 ~~~
 {: #stream-header-track-format title="MOQT STREAM_HEADER_TRACK Message"}
@@ -1442,8 +1414,8 @@ have the `Object Send Order` specified in the stream header.
 STREAM_HEADER_GROUP Message {
   Subscribe ID (i),
   Track Alias (i),
-  Group ID (i)
-  Object Send Order (i)
+  Group ID (i),
+  Publisher Priority (8),
 }
 ~~~
 {: #stream-header-group-format title="MOQT STREAM_HEADER_GROUP Message"}
@@ -1478,7 +1450,7 @@ Sending a track on one stream:
 STREAM_HEADER_TRACK {
   Subscribe ID = 1
   Track Alias = 1
-  Object Send Order = 0
+  Publisher Priority = 0
 }
 {
   Group ID = 0
@@ -1504,7 +1476,7 @@ STREAM_HEADER_GROUP {
   Subscribe ID = 2
   Track Alias = 2
   Group ID = 0
-  Object Send Order = 0
+  Publisher Priority = 0
 }
 {
   Object ID = 0