search

moq-wg / moq-transport

draft-ietf-moq-transport
Other
70 stars 16 forks source link

SUBSCRIBE_UPDATE #435

Closed ianswett closed 2 months ago

ianswett commented 2 months ago

Replace #385 based on the simplified SUBSCRIBE.

Fixes #269 Closes #385

afrind commented 2 months ago

Individual Comments:

Is there a response to a Subscribe Update? For example, maybe the auth has changed and is no longer valid?

I think there is weirdness with respect to track and group forwarding preferences when you create a gap by moving start forward. I think we should require the publisher to close QUIC streams with objects that haven't been requested and open new ones. eg:

-> Subscribe to a track with forward pref = track, start=0/0 <- Subscribe Ok <- Open stream 1, sending objects starting from 0/0 -> Subscribe update, start=10/0 <- Close stream 1 <- Open stream 2, sending objects starting from 10/0

Alternately, should we only allow End to be modified by SUBSCRIBE_UPDATE? This is should always succeed and doesn't have any hard edges. To move start forward, or change parameters, end the current subscription and start a new one?

ianswett commented 2 months ago

I wasn't intending for there to be a response to SUBSCRIBE_UPDATE. If auth fails, I think the right thing to do is terminate the subscription with an error.

Interesting point about forwarding preference. Do we have to say anything about stream states/etc there? This seems similar to the case when you have severe congestion and have to drop a bunch of Objects instead of delivering them.

I'd like to be able to modify start, because it is useful in live use cases, because it allows a client to tell the server 'stop sending content before this point'.

afrind commented 2 months ago

Individual Comment:

Interesting point about forwarding preference. Do we have to say anything about stream states/etc there? This seems similar to the case when you have severe congestion and have to drop a bunch of Objects instead of delivering them.

We're still spelling how this dropping works, but it seems like in those cases there will be OBJECT_DROPPED message or similar that explains the gap.

On the one hand, the publisher put a bunch of objects on a single stream for a reason, so skipping over a bunch seems like it could break things. On the other hand, it was the subscriber who asked for the gap, so it shouldn't be surprising. I think we need some guidance about how to handle this, but I guess we can come back to it later as well.