Remove 'Expires' from SUBSCRIBE_OK

[ianswett]

Fixes #390

[suhasHere]

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.

[kixelated]

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.

[kixelated]

This change might be controversial but I'm all for it.

[kixelated]

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.

[kixelated]

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.

[afrind]

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.

[suhasHere]

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

[ianswett]

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.

[vasilvv]

I believe this PR is a step in the right direction, since the current subscription expiry mechanism feels underspecified; I can think of some cases in which that would be useful, but I'd rather have a SUBSCRIBE_GOAWAY message that tells the peer they should resubscribe rather than a timer.

[fluffy]

Lets talk about this but I think we need very long lasting session ( imagine weeks or years that are common with security cameras ) to periodically be reauthenticated and I had imagined this was the place to do it.

[fluffy]

I'm concerned about state that never goes away if some downstream connection had a slight bug or timing hickup.

[ianswett]

Closing this for now, we can always remove 'Expires' easily later on.