Add SUBSCRIBE_UPDATE #385

ianswett · 2024-02-19T19:05:04Z

Fixes #363, Fixes #269

This attempts to provide the minimum functionality I expect we'll need, regardless of how SUBSCRIBE is changed in the near future.

Fixes #363 and #269

draft-ietf-moq-transport.md

suhasHere · 2024-02-20T04:26:37Z

draft-ietf-moq-transport.md

+SUBSCRIBE_UPDATE Message {
+  Subscribe ID (i),
+  EndGroup (Location),
+  EndObject (Location),


This needs to be optional and only set if the subscription needs to be ended.

In the context of this PR and the current draft, where the only thing you can change is the end, this message is OK. However, if we add more parameters to subscribe (eg #381), then we need a way to update some of the parameters and not others.

We should also clarify what happens if you issue the SUBSCRIBE twice for the same ID - I expect in this PR as is, we would make that an error?

suhasHere · 2024-02-20T04:28:23Z

draft-ietf-moq-transport.md

@@ -744,7 +744,7 @@ MOQT Message {
 |-------|-----------------------------------------------------|
 | 0x9   | UNANNOUNCE  ({{message-unannounce}})                |
 |-------|-----------------------------------------------------|
-| 0xA   | UNSUBSCRIBE ({{message-unsubscribe}})               |
+| 0xA   | SUBSCRIBE_UPDATE ({{message-subscribe-update}})     |
 |-------|-----------------------------------------------------|


I feel Unsubscribe makes more sense if one wants to end the subscription.
We don;t need a new message to update an existing subscription. A subscriber can update an existing subscription by sending SUBSCRIBE message with SubscribeId that matches an existing subscription ( as described in #381)

kixelated · 2024-02-20T08:08:02Z

draft-ietf-moq-transport.md

+modification to the end of an existing subscription.  One common type of
+modification is unsubscription.
+
+If an update cannot be completed by the relay, it replies with a SUBSCRIBE_ERROR


But what about SUBSCRIBE_OK? We should send it too, especially if the end groups use relative offsets.

Also what if there are multiple SUBSCRIBE_UPDATES? Do the SUBSCRIBE_ERRORs have to be returned in order? With no OK, it's impossible to differentiate if the 1st or 2nd UPDATE failed.

kixelated · 2024-02-20T08:12:37Z

draft-ietf-moq-transport.md

+modification is unsubscription.
+
+If an update cannot be completed by the relay, it replies with a SUBSCRIBE_ERROR
+with error code 'Update Failed' and the subscription is unchanged.


I don't like the subscription being unchanged. It causes a partial failure which is just really difficult to support.

kixelated · 2024-02-20T08:21:31Z

draft-ietf-moq-transport.md


 ~~~
-UNSUBSCRIBE Message {
-  Subscribe ID (i)
+SUBSCRIBE_UPDATE Message {


Can we also update the start group/object? It would be super useful for relays to deal with:

viewer1: SUBSCRIBE start=-2
(pause)
viewer2: SUBSCRIBE start=-3

Currently, the relay would issue to origin:
SUBSCRIBE start=-2
(wait for SUBSCRIBE_OK -2=65)
SUBSCRIBE start=64 end=65

Which is complicated and incurs delay. But if we allow updating start ranges:
SUBSCRIBE start=-2
SUBSCRIBE_UPDATE start=-3

Updating the start point can mess with object mapping to streams, especially moving backwards. In your example, if the track is stream-per-track, the publisher may open a stream and being publishing group=65. In the current design, where subscription ID appears in objects, the second subscribe for group=64 will come on its own new stream. If we allow updating the subscription start point backwards to 64, what should the publisher do? Should it close the open stream and open a new one, beginning at group=64, and resend objects from group=65?

I do think updating the start is potentially interesting and useful.

Updates of the start should not be able to move the start point of the subscription earlier. As you said, it's just too complex. For similar reasons, I think updating the end to be farther in the future is error prone as well, though there may be use cases for that.

+1 on start can only be moved forward, end can only be moved backwards

As a side note where I don't really care ... I'm not sure the use case to move the start forward

afrind

Individual Review:

We should have a way to update the endpoint of a subscription (like subscribe update), and also a way to unsubscribe immediately when you don't know or care about the end. I suppose we can do that by setting the new end-point to absolute 0/0.

afrind · 2024-02-26T18:09:54Z

draft-ietf-moq-transport.md


 ~~~
-UNSUBSCRIBE Message {
-  Subscribe ID (i)
+SUBSCRIBE_UPDATE Message {


Updating the start point can mess with object mapping to streams, especially moving backwards. In your example, if the track is stream-per-track, the publisher may open a stream and being publishing group=65. In the current design, where subscription ID appears in objects, the second subscribe for group=64 will come on its own new stream. If we allow updating the subscription start point backwards to 64, what should the publisher do? Should it close the open stream and open a new one, beginning at group=64, and resend objects from group=65?

afrind · 2024-02-26T18:12:39Z

draft-ietf-moq-transport.md

+SUBSCRIBE_UPDATE Message {
+  Subscribe ID (i),
+  EndGroup (Location),
+  EndObject (Location),


In the context of this PR and the current draft, where the only thing you can change is the end, this message is OK. However, if we add more parameters to subscribe (eg #381), then we need a way to update some of the parameters and not others.

We should also clarify what happens if you issue the SUBSCRIBE twice for the same ID - I expect in this PR as is, we would make that an error?

fluffy

My main comment is I don't think we shoudl try and use UPDATE as the way we do UNSUSCRIBE

fluffy · 2024-02-29T16:32:55Z

draft-ietf-moq-transport.md

+## SUBSCRIBE_UPDATE {#message-subscribe-update}
+
+A subscriber issues a `SUBSCRIBE_UPDATE` message to a publisher to request a
+modification to the end of an existing subscription.  One common type of


I think the "end of existing" should say the "end of the subscription range".

fluffy · 2024-02-29T16:36:22Z

draft-ietf-moq-transport.md

+
+A subscriber issues a `SUBSCRIBE_UPDATE` message to a publisher to request a
+modification to the end of an existing subscription.  One common type of
+modification is unsubscription.


I don't think this is right. The update should just be to change the metadata about the subscribe, not change the state of the subscribe. We should use some other message to cause the SUSBCRIBE to end and remove all the state about the SUBSCRIBE.

fluffy · 2024-02-29T16:37:52Z

draft-ietf-moq-transport.md

@@ -761,7 +761,7 @@ MOQT Message {
 |-------|-----------------------------------------------------|
 | 0x9   | UNANNOUNCE  ({{message-unannounce}})                |
 |-------|-----------------------------------------------------|
-| 0xA   | UNSUBSCRIBE ({{message-unsubscribe}})               |
+| 0xA   | SUBSCRIBE_UPDATE ({{message-subscribe-update}})     |
 |-------|-----------------------------------------------------|


I think we need both the UNSUBSCRIBE and UPDATE ( or whatever names we decide to call them ).

fluffy · 2024-02-29T16:40:17Z

draft-ietf-moq-transport.md

+modification to the end of an existing subscription.  One common type of
+modification is unsubscription.
+
+If an update cannot be completed by the relay, it replies with a SUBSCRIBE_ERROR


I think this should be an UPDATE_OK/ERROR. Don't care if it is two message or not. But should be clear that if some part of the UPDATE can not be applied, then no part of the update is applied, subscribe stays with same meta data as before, and error returned. So an update is all or nothing.

fluffy · 2024-02-29T16:41:44Z

draft-ietf-moq-transport.md

-A subscriber issues a `UNSUBSCRIBE` message to a publisher indicating it is no
-longer interested in receiving media for the specified track.
+The subscription is not fully terminated until a SUBSCRIBE_RST or SUBSCRIBE_FIN
+are received.


Uh, I think this needs to be UNSUBSCRIBE or whatever the SUBSCRIBE CLOSE/STOP/FIN/RST/END is called

fluffy · 2024-02-29T16:43:35Z

draft-ietf-moq-transport.md


 ~~~
-UNSUBSCRIBE Message {
-  Subscribe ID (i)
+SUBSCRIBE_UPDATE Message {


+1 on start can only be moved forward, end can only be moved backwards

fluffy · 2024-02-29T16:44:29Z

draft-ietf-moq-transport.md


 ~~~
-UNSUBSCRIBE Message {
-  Subscribe ID (i)
+SUBSCRIBE_UPDATE Message {


As a side note where I don't really care ... I'm not sure the use case to move the start forward

fluffy · 2024-02-29T16:45:56Z

draft-ietf-moq-transport.md

-  Subscribe ID (i)
+SUBSCRIBE_UPDATE Message {
+  Subscribe ID (i),
+  EndGroup (Location),


This is not a location this shoudl be an optional var int

fluffy · 2024-02-29T16:46:08Z

draft-ietf-moq-transport.md

+SUBSCRIBE_UPDATE Message {
+  Subscribe ID (i),
+  EndGroup (Location),
+  EndObject (Location),


This should be var int not Location

fluffy · 2024-02-29T16:54:58Z

draft-ietf-moq-transport.md


 * Subscribe ID: Subscription Identifer as defined in {{message-subscribe-req}}.

+* EndGroup: The last Group requested in the subscription, inclusive.  EndGroup's
+Mode is None for an open-ended subscription.


I would prefer to make the end group / object optional in the update instead of having a None value. I think it makes a better patter for how to add future things to the update.

Replace #385 based on the simplified SUBSCRIBE.

afrind · 2024-04-27T16:04:17Z

Is this overtaken by #435 ?

Replace #385 based on the simplified SUBSCRIBE. Fixes #269 Closes #385

Replace UNSUBSCRIBE with SUBSCRIBE_UPDATE

5bd6be6

Fixes #363 and #269

ianswett added the Subscribe Related to SUBSCRIBE message and subscription handling label Feb 19, 2024

ianswett added 2 commits February 19, 2024 14:10

Update draft-ietf-moq-transport.md

c86fa7e

Update draft-ietf-moq-transport.md

c3d7e3e

ianswett commented Feb 19, 2024

View reviewed changes

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

Update draft-ietf-moq-transport.md

f02f39f

ianswett commented Feb 19, 2024

View reviewed changes

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

ianswett added 2 commits February 19, 2024 14:14

Update draft-ietf-moq-transport.md

e46eec7

Update draft-ietf-moq-transport.md

cd92dba

ianswett commented Feb 19, 2024

View reviewed changes

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

Update draft-ietf-moq-transport.md

83ee597

ianswett commented Feb 19, 2024

View reviewed changes

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

ianswett added 2 commits February 19, 2024 14:38

Update draft-ietf-moq-transport.md

5b59dc3

Merge branch 'main' into ianswett-subscribe-update

6bb489e

suhasHere reviewed Feb 20, 2024

View reviewed changes

suhasHere requested changes Feb 20, 2024

View reviewed changes

kixelated requested changes Feb 20, 2024

View reviewed changes

afrind reviewed Feb 26, 2024

View reviewed changes

ianswett changed the title ~~Replace UNSUBSCRIBE with SUBSCRIBE_UPDATE~~ Add SUBSCRIBE_UPDATE Feb 28, 2024

Merge branch 'main' into ianswett-subscribe-update

938bc4c

fluffy requested changes Feb 29, 2024

View reviewed changes

ianswett added 2 commits March 3, 2024 21:57

Merge branch 'main' into ianswett-subscribe-update

7cefe68

Merge branch 'main' into ianswett-subscribe-update

6d13f6f

ianswett added a commit that referenced this pull request Apr 18, 2024

SUBSCRIBE_UPDATE

6b7cdb9

Replace #385 based on the simplified SUBSCRIBE.

ianswett mentioned this pull request Apr 18, 2024

SUBSCRIBE_UPDATE #435

Merged

ianswett closed this in #435 Apr 30, 2024

ianswett added a commit that referenced this pull request Apr 30, 2024

SUBSCRIBE_UPDATE (#435)

b66b303

Replace #385 based on the simplified SUBSCRIBE. Fixes #269 Closes #385

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add SUBSCRIBE_UPDATE #385

Add SUBSCRIBE_UPDATE #385

ianswett commented Feb 19, 2024 •

edited

suhasHere Feb 20, 2024

afrind Feb 26, 2024

suhasHere Feb 20, 2024 •

edited

kixelated Feb 20, 2024

kixelated Feb 20, 2024

kixelated Feb 20, 2024

kixelated Feb 20, 2024

afrind Feb 26, 2024

ianswett Feb 28, 2024

fluffy Feb 29, 2024

fluffy Feb 29, 2024

afrind left a comment

afrind Feb 26, 2024

afrind Feb 26, 2024

fluffy left a comment

fluffy Feb 29, 2024

fluffy Feb 29, 2024

fluffy Feb 29, 2024

fluffy Feb 29, 2024

fluffy Feb 29, 2024

fluffy Feb 29, 2024

fluffy Feb 29, 2024

fluffy Feb 29, 2024

fluffy Feb 29, 2024

fluffy Feb 29, 2024

afrind commented Apr 27, 2024

Add SUBSCRIBE_UPDATE #385

Add SUBSCRIBE_UPDATE #385

Conversation

ianswett commented Feb 19, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

suhasHere Feb 20, 2024 • edited

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

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 commented Apr 27, 2024

ianswett commented Feb 19, 2024 •

edited

suhasHere Feb 20, 2024 •

edited