Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove 'Expires' from SUBSCRIBE_OK #391

Closed
wants to merge 3 commits into from
Closed

Remove 'Expires' from SUBSCRIBE_OK #391

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f72662d
Remove 'Expires' from SUBSCRIBE_OK
ianswett Feb 19, 2024
71d3207
Merge branch 'main' into ianswett-no-expires
ianswett Feb 20, 2024
f1963f5
Merge branch 'main' into ianswett-no-expires
ianswett Mar 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 2 additions & 8 deletions draft-ietf-moq-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -625,9 +625,8 @@ For successful subscriptions, the publisher maintains a list of
subscribers for each track. Each new OBJECT belonging to the
track within the subscription range is forwarded to each active
subscriber, dependent on the congestion response. A subscription
remains active until it expires, until the publisher of the track
terminates the track with a SUBSCRIBE_FIN
(see {{message-subscribe-fin}}) or a SUBSCRIBE_RST
remains active until the publisher terminates the subscription
with a SUBSCRIBE_FIN (see {{message-subscribe-fin}}) or a SUBSCRIBE_RST
(see {{message-subscribe-rst}}).

A relay MUST not reorder or drop objects received on a multi-object stream when
Expand Down Expand Up @@ -1322,7 +1321,6 @@ A SUBSCRIBE_OK control message is sent for successful subscriptions.
SUBSCRIBE_OK
{
Subscribe ID (i),
Expires (i),
ContentExists (1),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do feel expires is needed. This is a way for CDN/relay provider to indicate the subscriber to renew their interest in subscription. I would think Hops within a CDN network might configure a different (larger) value for this compared to end point client subscribing to edge relay.

I might be convinced otherwise, but love to discuss this a bit.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know we've talked at length about this, but can you give some example use-cases?

If the intent is an idle timeout, then QUIC already provides most of that. The connection will be closed and any subscriptions cancelled after a period of inactivity. There's also a congestion window that will prevent sending bytes well before that timeout is hit. Performing the idle timeout at the MoQ level will catch some more scenarios, like a bug in the MoQ library that prevents unsubscribes, but eh it's fringe.

If the intent is to force reauthorization, well that needs to be thought out a bit more. What behavior should the subscriber perform on expiration? Does it need to refresh it's authorization token every time, or only every x minutes? Heh I already know the answer is going to be "it depends on the application". And I agree!

The expiration should be part of the authorization scheme itself and signaled independently. For example, you can put the expiration in the token itself. A client already needs to understand the authorization scheme in order to refresh tokens, so it can totally parse the expiration out of the token too.

[Largest Group ID (i)],
[Largest Object ID (i)]
Expand All @@ -1332,10 +1330,6 @@ SUBSCRIBE_OK

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

* Expires: Time in milliseconds after which the subscription is no
longer valid. A value of 0 indicates that the subscription stays active
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I agree that the transition from a valid to invalid subscription at an arbitrary point in time is problematic

If we end up keeping expires, then an explicit SUBSCRIBE_RESET message (with an error code) should actually be required to terminate the subscription.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Individual Comment:

That might be a nice middle ground -- expires is advisory to the client that it's going to get a SUBSCRIBE_RESET at that time. It can avoid that (make before break) by resubscribing before that point.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@afrind That's not just the middle ground. but expected behavior for relay provider not to waste its resources if the susbcriber doesn't renew its interest in a given track. Also good point on make before break scenario.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does renewing its interest mean? It continues to ACK packets and supply flow control for streams to allow the data for the subscription to be delivered, so it's not completely passive.

I don't know what action to take based on this field a subscriber. There's no guarantee the subscription will last as long as the expires indicates. There's also no guarantee it won't last much longer, especially if we still require a SUBSCRIBE_RESET or FIN, which I think we should to ensure the state machine is simpler.

until it is explicitly unsubscribed.

* ContentExists: 1 if an object has been published on this track, 0 if not.
* If 0, then the Largest Group ID and Largest Object ID fields will not be
* present.
Expand Down
Loading