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

ianswett · 2024-06-22T16:35:36Z

Adds a SUBSCRIBER_PRIORITY param that can be specified in SUBSCRIBE or SUBSCRIBE_UPDATE to indicate subscriber priority. Adds Group Order to SUBSCRIBE to allow indicating Ascending or Descending. Cleans up the existing priorities section and how Original Subscriber driven priorities are used.

Fixes #326
Fixes #396
Fixes #403
Fixes #419

Closes #445

Adds a SUBSCRIBER_PRIORITY param that can be specified in SUBSCRIBE or SUBSCRIBE_UPDATE to indicate subscriber priority. Adds Delivery Order to SUBSCRIBE to allow indicating Ascending or Descending. Cleans up the existing priorities section and how Original Subscriber driven priorities are used. Fixes #403 Closes #445

draft-ietf-moq-transport.md

vasilvv · 2024-06-22T23:39:54Z

draft-ietf-moq-transport.md


-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


Maybe call out relays specifically? This does not make sense for original publishers.

I can change it, though if one was using MoQ in a P2P application, wouldn't the subscriber's priority matter and the publlsher would be the original publisher?

This statement seems unnecessary. The para above says /how/ a sender uses priorities, what does this sentence add beyond that?

It adds a SHOULD, but I can put that elsewhere

draft-ietf-moq-transport.md

ianswett

In this PR, there isn't currently a default. I realize there could be, but unless there's different behavior for it, I'd prefer to make it required because the behavior is clear.

draft-ietf-moq-transport.md

ianswett · 2024-06-23T01:10:55Z

draft-ietf-moq-transport.md


-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


I can change it, though if one was using MoQ in a P2P application, wouldn't the subscriber's priority matter and the publlsher would be the original publisher?

draft-ietf-moq-transport.md

suhasHere

This is coming along pretty well. thanks for the PR. I plan to give proper read next week, but overall shape of this is pretty good.

draft-ietf-moq-transport.md

englishm · 2024-06-28T05:18:14Z

draft-ietf-moq-transport.md

+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


We may have a problem here. If we expect aggregating relays to not forward subscriber priority preferences, then, in fact, all middle hops are likely to fall to publisher priority and may incentivize priority inflation. On the other hand, relays are going to do what they're going to do, and, it's possible that publisher priorities may be ignored for middle hops in practice.

I get what you are saying here but relays have to deal with a reasonable solution to this just to even be able to run lots of different applications on the same relay network even when application never have more than one namespace. I think there are two keys parts of this 1) we are not trying to specify how a relay network moves data around inside the relays and 2) relays will do what relays do.

So thought relays could have if they don't think about this problem, I don't think we can say much more that this.

draft-ietf-moq-transport.md

fluffy

Ian, I think this does an great job of covering what we agreed to the the interim. Thank you for the hard work on it. Few comments on things that I think could be a bit clearer and one small thing that seemed under specified.

fluffy · 2024-06-28T15:10:11Z

draft-ietf-moq-transport.md

+When both the subscriber and original publisher priorities for a
+subscription are equal, send order is implementation-dependent, but the


given we use "send order" to talk about Ascending / Descending, I got confused when I read this. I think it could be less confusing to replace "send order" with "track selected to send next object" or something like that.

fluffy · 2024-06-28T15:12:52Z

draft-ietf-moq-transport.md

+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


We agreed on highest at this point, the latest is for other part. So I think this is correct as written here. Just to reason about this this, think about a track being send stream per object where publisher priorities changed. I don't think publisher priority is per stream - to start with it is for datagrams too.

fluffy · 2024-06-28T15:16:25Z

draft-ietf-moq-transport.md

-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 Group Order.


This seems correct as written and covers the case where the publisher priority is the same but we need to also cover the case where where publisher priorities are not the same in which case publisher priority determines which is sent first. This may just be implied here but better to say.

Ah I missed "...and the same priority level".

That may be workable - it affords an option to create a "virtual layer" within the track, which may be what Mo was asking for re temporal scalability?

eg: 30 fps objects get pri=<track priority> and 60 fps objects get pri=<track priority> + 1

True, I added a bit more text to clarify what happens when priority varies within a group.

draft-ietf-moq-transport.md

fluffy · 2024-06-28T15:31:30Z

draft-ietf-moq-transport.md

+In addition, SUBSCRIBE or SUBSCRIBE_OK specifies 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.


This seems slightly under specified. If a last mile relay received two different values in both SUBSCRIBE and SUBSCRIBE_OK, we need to say which one takes priority. We agreed on the end subscriber would take priority so this should have a bit more text to say value in SUBSCRIBE overrides in value in SUBSCRIBE_OK.

Good point, I rewrote this paragraph to better match the current framing.

draft-ietf-moq-transport.md

fluffy · 2024-06-28T15:41:23Z

draft-ietf-moq-transport.md

+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


I get what you are saying here but relays have to deal with a reasonable solution to this just to even be able to run lots of different applications on the same relay network even when application never have more than one namespace. I think there are two keys parts of this 1) we are not trying to specify how a relay network moves data around inside the relays and 2) relays will do what relays do.

So thought relays could have if they don't think about this problem, I don't think we can say much more that this.

fluffy · 2024-06-28T15:47:02Z

draft-ietf-moq-transport.md

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


Alan, I don't think that would help, that just moves the same problem to the next layer and it would be turtles all the way down. The basic issue is when a content delivery network delivers content for lots of different applications/customers, it needs to decide how it will be "fair" between the application/customers and that is way more complicated that just use whatever the priority header asked for.

fluffy · 2024-06-28T15:52:28Z

draft-ietf-moq-transport.md

@@ -1118,6 +1089,7 @@ SUBSCRIBE_UPDATE Message {
  StartObject (i),
  EndGroup (i),
  EndObject (i),
+  Subscriber Priority (8),


Luke, I thought you were complaining about too many options :-) I don't see the use case with this but at first glance does not seem like it would complicated the implementation too much so I am fine with it getting added.

afrind

Individual Comments:

Buried in here is a proposal for a different algorithm to resolve the priority of a track when it has multiple different priorities in flight.

afrind · 2024-06-28T16:28:39Z

draft-ietf-moq-transport.md

+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


We agreed on highest at this point, the latest is for other part.

This was part of the discussion from Wednesday's call. The consensus was that using highest priority value in the track to select a track does not work well. If you use highest, then priority can only be increased and not decreased.

Example, assume two tracks, stream-per-group and each has 2 groups to send from:
Track A: group1, pri=1; group2, pri=2
Track B: group1, pri=2; group2, pri=1

Using max, the algorithm would treat these tracks with equal priority, and move to another tiebreaker.

The room felt (I think unanimously) that the most recent value should set the track priority, so in the above example, Track B would be higher than Track A. Which group from Track B is determined by the group-send-order.

Reflecting more, I think logically what bits we want to send in the above example depends on the group order. If using ascending groups, a track's priority is the priority of it's lowest group to send and if descending, a track's priority is the priority of it's highest group to send. Now, if Track A and Track B are both ascending, A > B. If they are both descending, B > A. If they mismatch, it is a tie.

When using stream/datagram-per-object, the priority of a group is the highest priority among queued object for that group.

That feels right to me but the implementation might be complex to implement.

afrind · 2024-06-28T16:39:34Z

draft-ietf-moq-transport.md

-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 Group Order.


Ah I missed "...and the same priority level".

That may be workable - it affords an option to create a "virtual layer" within the track, which may be what Mo was asking for re temporal scalability?

eg: 30 fps objects get pri=<track priority> and 60 fps objects get pri=<track priority> + 1

draft-ietf-moq-transport.md

afrind · 2024-06-28T16:47:59Z

draft-ietf-moq-transport.md

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


I agree with Luke that saying "this won't be a problem" is not good. We should say that there's some risk to blindly comparing publisher priorities when you don't know if they are coordinated, caveat emptor.

draft-ietf-moq-transport.md

ianswett

I tried to address most comments, PTAL

draft-ietf-moq-transport.md

ianswett · 2024-07-01T18:20:15Z

draft-ietf-moq-transport.md

@@ -1118,6 +1089,7 @@ SUBSCRIBE_UPDATE Message {
  StartObject (i),
  EndGroup (i),
  EndObject (i),
+  Subscriber Priority (8),


I added a sentence in the Priorities section about how you need to use UNSUBSCRIBE and SUBSCRIBE.

One use case I can think of (ie: switching from live head (Descending) to slightly behind live (Ascending)) is better suited to UNSUBSCRIBE and SUBSCRIBE anyway, because you'd want to specify the new start point at wherever you currently are in time, not what's in scope for the current subscription.

ianswett · 2024-07-01T19:15:40Z

draft-ietf-moq-transport.md

-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 Group Order.


True, I added a bit more text to clarify what happens when priority varies within a group.

suhasHere · 2024-07-02T03:57:35Z

draft-ietf-moq-transport.md

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


s/ send order is / the track whose object is being selected is /

Good point, this text was a bit unclear. I rewrote it to hopefully be more clear.

suhasHere

@ianswett the new changes look great. I have one change for removing the Group Order from the Subscribe Update message and define an error type when someone changes it in the update message.

draft-ietf-moq-transport.md

vasilvv · 2024-07-02T09:40:22Z

draft-ietf-moq-transport.md

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


I'm confused, does this imply that a single group can have multiple priorities within it?

With Stream-per-Object, each Object can have a different priority in the current wire format.

afrind

Individual Comments:

afrind · 2024-07-02T17:40:55Z

draft-ietf-moq-transport.md

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


I am ok with merging the new language. Long term, I don't plan to compare uncoordinated publisher priorities in my generic relay, and may make a proposal for how to avoid doing so.

afrind · 2024-07-02T17:41:32Z

draft-ietf-moq-transport.md

@@ -1118,6 +1089,7 @@ SUBSCRIBE_UPDATE Message {
  StartObject (i),
  EndGroup (i),
  EndObject (i),
+  Subscriber Priority (8),


The new text looks good.

The scheme implements priority assignment that follows the semantics of moq-wg/moq-transport#470 and is compatible with how WebTransport scheduling works. PiperOrigin-RevId: 651476056

ianswett added 3 commits June 22, 2024 12:35

Merge branch 'main' into ianswett-uber-priority

0d45b9d

More text on relays going upstream

c1346ec

ianswett commented Jun 22, 2024

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

ianswett added 2 commits June 22, 2024 15:56

Update draft-ietf-moq-transport.md

31b0ba2

Fix references to priority-congestion

0b693ae

ianswett commented Jun 22, 2024

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

Update draft-ietf-moq-transport.md

f1b88f4

ianswett commented Jun 22, 2024

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

ianswett added 3 commits June 22, 2024 16:03

Update draft-ietf-moq-transport.md

f5043c6

Update draft-ietf-moq-transport.md

3c0f6e5

Update draft-ietf-moq-transport.md

9097d73

ianswett commented Jun 22, 2024

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

ianswett added 6 commits June 22, 2024 16:26

Update draft-ietf-moq-transport.md

81c6a32

Update draft-ietf-moq-transport.md

9fc4721

Update draft-ietf-moq-transport.md

619bc11

Update draft-ietf-moq-transport.md

436605f

Update draft-ietf-moq-transport.md

081554d

Move Subscriber Priority to be a field, not an optional param

a085820

vasilvv reviewed Jun 22, 2024

View reviewed changes

Rename Priority to Publisher Priority

441ecf0

ianswett commented Jun 23, 2024

View reviewed changes

Update draft-ietf-moq-transport.md

a97a91f

ianswett commented Jun 23, 2024

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

Update draft-ietf-moq-transport.md

7ddfd11

suhasHere reviewed Jun 23, 2024

View reviewed changes

draft-ietf-moq-transport.md Show resolved Hide resolved

suhasHere reviewed Jun 23, 2024

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

ianswett commented Jun 24, 2024

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

Update draft-ietf-moq-transport.md

1bd6788

englishm reviewed Jun 28, 2024

View reviewed changes

suhasHere reviewed Jun 28, 2024

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

fluffy approved these changes Jun 28, 2024

View reviewed changes

afrind reviewed Jun 28, 2024

View reviewed changes

ianswett changed the title ~~Add Priority and Delivery Order to SUBSCRIBE, clarify Publisher Priority~~ Add Priority and Group Send Order to SUBSCRIBE, clarify Publisher Priority Jul 1, 2024

ianswett added 2 commits July 1, 2024 13:39

stream or datagram header

a2a29de

afrind suggestion

09e6d8e

ianswett mentioned this pull request Jul 1, 2024

Add psuedocode for the priority algorithm from #470 #478

Open

ianswett added 5 commits July 1, 2024 13:45

Remove empty section

74ca340

Update draft-ietf-moq-transport.md

e32a488

Reprioritization is implementation-specific

4da15a1

Group Order cannot be changed in SUBSCRIBE_UPDATE

779ddae

Update draft-ietf-moq-transport.md

cc451f2

ianswett commented Jul 1, 2024

View reviewed changes

ianswett added 3 commits July 1, 2024 15:32

Elaborate on upstream subscriptions

d366503

Namespace concerns

37fa963

Update draft-ietf-moq-transport.md

0d351ff

ianswett mentioned this pull request Jul 1, 2024

Add a priority field to subscriptions #445

Closed

suhasHere reviewed Jul 2, 2024

View reviewed changes

suhasHere approved these changes Jul 2, 2024

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

vasilvv approved these changes Jul 2, 2024

View reviewed changes

ianswett added 2 commits July 2, 2024 09:58

Remove Group Order from SUBSCRIBE_UPDATE

c528c9c

Clarify how subscriptions share a connection

fd21a0d

afrind reviewed Jul 2, 2024

View reviewed changes

ianswett merged commit 2706491 into main Jul 3, 2024
2 checks passed

ianswett mentioned this pull request Jul 5, 2024

Proposal: Subscriber Prioritization #411

Closed

englishm mentioned this pull request Jul 26, 2024

WIP: draft-05 updates kixelated/moq-rs#179

Draft

afrind mentioned this pull request Jul 29, 2024

Relative prioritization of streams and datagrams w3c/webtransport#610

Open

englishm mentioned this pull request Aug 9, 2024

Recommend use of mid-range values as default priority in implementations #504

Open

		When both the subscriber and original publisher priorities for a
		subscription are equal, send order is implementation-dependent, but the

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

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

Conversation

ianswett commented Jun 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

suhasHere left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fluffy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afrind left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

suhasHere left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afrind left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett commented Jun 22, 2024 •

edited

Loading