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

draft-ietf-moq-transport.md

@@ -534,101 +534,32 @@ 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}
-
-TODO: This is a placeholder section to capture details on how the MOQT
-protocol deals with prioritization and congestion overall.
-
-This section is expected to cover details on:
-
-- 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.
-
-## Order Priorities and Options
-
-At the point of this writing, the working group has not reached
-consensus on several important goals, such as:
-
-* 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.
-
-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.
-
-### Proposal - Send Order {#send-order}
-
-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.
-
-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.
-
-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.
+# Priorities {#priorities}
 
+MoQ priorities allow a subscriber and original publisher to influence
+the transmission order of Objects within a session in the presence of
+congestion.
+
+The subscriber can indicate the priority of a subscription via the
+SUBSCRIBER_PRIORITY param and the original publisher indicates priority
+in every stream header.
+
+The publisher SHOULD respect the subscriber and publisher's priorities.
+
+In addition, the 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.
+
+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.
+
+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 populatity of the
+content or policy.
 
 # Relays {#relays-moq}
 
@@ -638,6 +569,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
@@ -885,6 +820,13 @@ information in a SUBSCRIBE or ANNOUNCE message. This parameter is populated for
 cases where the authorization is required at the track level. The value is an
 ASCII string.
 
+#### SUBSCRIBER_PRIORITY Parameter
+
+The SUBSCRIBER_PRIORITY parameter (key 0x03) allows a subscriber to specify the
+priority of a subscription relative to other subscriptions in the same session.
+Lower numbers get higher priority and values range from 0 to 255 inclusive.
+More details on priorities are documented in {{}}
+
 ## CLIENT_SETUP and SERVER_SETUP {#message-setup}
 
 The `CLIENT_SETUP` and `SERVER_SETUP` messages are the first messages exchanged
@@ -1039,6 +981,7 @@ SUBSCRIBE Message {
   Track Alias (i),
   Track Namespace (b),
   Track Name (b),
+  Delivery Order (8),
   Filter Type (i),
   [StartGroup (i),
    StartObject (i)],
@@ -1068,6 +1011,10 @@ close the session with a Duplicate Track Alias error ({{session-termination}}).
 
 * Track Name: Identifies the track name as defined in ({{track-name}}).
 
+* 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}}).
@@ -1252,8 +1199,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.
+* 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 +1281,7 @@ OBJECT_STREAM Message {
   Track Alias (i),
   Group ID (i),
   Object ID (i),
-  Object Send Order (i),
+  Priority (8),
   Object Status (i),
   Object Payload (..),
 }
@@ -1371,7 +1318,7 @@ OBJECT_DATAGRAM Message {
   Track Alias (i),
   Group ID (i),
   Object ID (i),
-  Object Send Order (i),
+  Priority (8),
   Object Status (i),
   Object Payload (..),
 }
@@ -1403,7 +1350,7 @@ stream header.
 STREAM_HEADER_TRACK Message {
   Subscribe ID (i)
   Track Alias (i),
-  Object Send Order (i),
+  Priority (8),
 }
 ~~~
 {: #stream-header-track-format title="MOQT STREAM_HEADER_TRACK Message"}
@@ -1442,8 +1389,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),
+  Priority (8),
 }
 ~~~
 {: #stream-header-group-format title="MOQT STREAM_HEADER_GROUP Message"}
@@ -1478,7 +1425,7 @@ Sending a track on one stream:
 STREAM_HEADER_TRACK {
   Subscribe ID = 1
   Track Alias = 1
-  Object Send Order = 0
+  Priority = 0
 }
 {
   Group ID = 0
@@ -1504,7 +1451,7 @@ STREAM_HEADER_GROUP {
   Subscribe ID = 2
   Track Alias = 2
   Group ID = 0
-  Object Send Order = 0
+  Priority = 0
 }
 {
   Object ID = 0