How to use ANNOUNCE_OK, ANNOUNCE_ERROR, and ANNOUNCE_CANCEL?

[ianswett]

QUIC provides reliability, so I know the peer received the ANNOUNCE (or UNANNOUNCE).

We have almost no text on what might constitute an ANNOUNCE_ERROR and the only text on ANNOUNCE_CANCEL is you're supposed to send it if you're not going to send subscriptions to the publisher for something you sent an ANNOUNCE_OK for previously.

As it's written today, I don't see why an implementation would send or take any action based on any of these messages?

I believe there is some functionality we'd like in MoQT, which is we don't want anyone to be able to announce a track without appropriate auth, but I don't think this trio of messages gives us that, certainly not in the current draft. I'd hope pretending to be authoritative for an entity you're not would be rare, and closing the session or another more abrupt approach would be fine.

[afrind]

Individual Comment:

ANNOUNCE_ERROR was intended tell the publisher their auth failed. I suppose closing the session is an alternative, but a potentially harsh one? ANNOUNCE_OK Is basically the opposite. Not all implementations (eg browser webtransport) offer callbacks on QUIC acks, and in H3 we decided that transport ACK was insufficient to communicate application ACK. But it's mostly a debugging thing. You could assume ANNOUNCE_OK unless you got an error, there's no action to take on it.

UNANNOUNCE is needed to support SUBSCRIBE_NAMESPACE (eg: the relay needs to tell a client that previously ANNOUNCEd publisher is gone).

ANNOUNCE_CANCEL I think was added to make the state machine more complete for the publisher. It might have a future use if we add something like MAX_ANNOUNCE_ID, which I think we will, since ANNOUNCE can cause the peer to add state. Or maybe it could have a use in make-before-break, like "I am not going to route subscriptions on this session because I have a different path". But agree that right now I don't have a reason to send it.

[ianswett]

We've been punting auth for a bit, but maybe the upcoming interim is a time to prioritize discussing it, because I think once we understand our auth model better, we'll be able to understand if we need all the ANNOUNCE messages we have.

I started thinking about this in detail when I was trying to propose replacing SUBSCRIBE_NAMESPACE with sending a SUBSCRIBE for announces. If we did that, I believe it would remove any functionality these three messages provide.

[martinduke]

I am unclear of the state machine for these messages.

A publisher sends ANNOUNCE, which may or may not be in response to SUBSCRIBE_ANNOUNCES (which has its own state machine which is orthogonal?)

If ANNOUNCE_ERROR comes back, we're done. If I get a later SUBSCRIBE, is that an error?

If ANNOUNCE_OK comes back, then we are serving any subscriptions, until I send UNANNOUNCE. So there's some sort of "ANNOUNCE_ACTIVE" state where the ANNOUNCE has been OKed but not canceled or UNANNOUNCED.

Does ANNOUNCE_CANCEL do the same thing as UNANNOUNCE, but in the opposite direction?

What does this state mean? As a relay, does this mean I'm prewarming it with a subscription? Does a relay not send its own ANNOUNCE_OK until it's gotten one from downstream (which might be a server in an upload scenario)? Does an uploading client give up if it gets ANNOUNCE_ERROR?

[martinduke]

Here are my preferred answers:

• In terms of state, SUBSCRIBEs are totally divorced from ANNOUNCEs. It is never a protocol error to SUBSCRIBE to anything regardless of the state of any ANNOUNCE lifecycle, although of course a subscription can be refused, which is not a protocol error. [This is a change from the current language in ANNOUNCE_CANCEL].

• ANNOUNCE triggers ANNOUNCE_OK/ANNOUNCE_ERROR because ANNOUNCE_ERROR is a useful signal, certainly in the upload case.

• Publishers SHOULD send UNANNOUNCE to avoid useless SUBSCRIBEs, unless the subscriber has sent ANNOUNCE_CANCEL.

• Subscribers SHOULD send ANNOUNCE_CANCEL in case the publisher is maintaining state (again, likely in an upload scenario). Again, this doesn't preclude future SUBSCRIBEs, though those are likely to fail.

I think the only thing inconsistent with the current text is removing the protocol error.

[VMatrix1900]

Subscribers SHOULD send ANNOUNCE_CANCEL in case the publisher is maintaining state (again, likely in an upload scenario). Again, this doesn't preclude future SUBSCRIBEs, though those are likely to fail.

How does the subscriber know that the publisher is maintaining state?

[martinduke]

The 1/22/25 interim indicated there is no interest in solving this problem. Inter-relay routing is out of scope for MoQT and the Working Group.

I will add some text to #643 explicitly saying that this is not to be used for this purpose.