Does SUBSCRIBE with no timeouts require reliable delivery?

[vasilvv]

I was told that #620 may or may not imply that the publisher is not allowed to drop streams if the subscriber was so slow that the publisher has already evicted the necessary data from memory, and it always has to tear down the subscription. I am not sure if that is true (#620 does not add any normative language with that regard), but if so, it's not clear to me whether this is a correct answer.

[afrind]

Repasting parts of my individual comment from 714:

I believe MoQT needs a "high fidelity" mode - where relays are not allowed to drop any objects - they MUST buffer and when they exhaust their buffer space (implementation dependent), they MUST end the subscription.

In draft-08 I was signaling this by the absence of DELIVERY_TIMEOUTs from either the publisher or the subscriber, but I am ok with some other way of signaling this mode.

The catalog track is a good example of a track that must have 100% fidelity in order to work. Zafer's play/pause/seek control track is similar. There are many examples. Before you say "just use FETCH" - realize that the constant loop of FETCHing manifest files is something we are trying to improve on in moq/WARP.

See #582 for previous discussion.

[ianswett]

My understand is that the only reason you don't send an Object and create a gap in the space is because it doesn't exist and never will or the delivery timeout has expired. I don't think there's any other situation described in the draft.

Otherwise it's ambiguous about why an Object wasn't delivered, which makes caching of SUBSCRIBE potentially impractical.

[afrind]

The Stream Cancellation section references a behavior that contradicts the -08 text:

Streams aside from the control stream MAY be canceled due to congestion
or other reasons by either the publisher or subscriber. Early termination of a
stream does not affect the MoQ application state, and therefore has no
effect on outstanding subscriptions.

[afrind]

Individual Comment:

My understand is that the only reason you don't send an Object and create a gap in the space is because it doesn't exist and never will or the delivery timeout has expired

The other case that's been mentioned is a relay building a queue for a subscriber or a subscriber falling too far behind incoming objects, and delivery timeout is unspecified or too high to prevent forming a queue. Victor said their impl will drop any objects more than 3 groups old. See #462.

[fluffy]

I think what we agree on is streams are in order and reliable. So it something is in the same stream and you need to send 2,3,4 but due to resource constraints you have lost 3, then there is nothing to do but close that stream because sending 2,4 would be wrong. It seems we have discussed this many times and seem just an obvious consequence of using streams.

I don't think I understand what the issue is here we are trying to get at.