ANNOUNCE (and maybe SUBSCRIBE?) infinite loops

[ianswett]

I believe that if we're not careful, we can end up with ANNOUNCE infinite loops today.

If there are three relays connected: A -> B -> C -> A, then we need to ask relays to see if they've already seen an ANNOUNCE before forwarding it along to applicable SUBSCRIBE_NAMESPACEs. Similarly, I can imagine an ANNOUNCE/UNANNOUNCE loop, which aren't as trivially prevented by ensuring you don't forward the same ANNOUNCE twice.

SUBSCRIBE has a temporal ordering, so this feels more tractable, but given we allow arbitrary gaps in Objects and Groups, tracking everything you've already forwarded for a subscription is potentially very costly/complex. If a relay is subscribing to the same track twice because two different relays announced it, I think it needs to keep state to ensure it doesn't forward the same Object multiple times?

BGP has loop prevention mechanisms and so do QUIC stateless resets.

Possibly deployments can ensure data flows in only one direction, but given this is pub/sub, not request/response, it's a lot easier to create loops.

[TimEvens]

Typical feedback. Good to call this out as we are already are keeping state for both subscribes and announces. Subscribes do have the same problem.

The relay needs to maintain state that it sent the announce and subscribe. I agree it is costly with MOQT. This is not the only costly state requirement that MOQT requires the relay to maintain. Unfortunately, MOQT is pretty heavy in state at many levels. Having to maintain state without protection measures can lead to exploiting resources to cause a DoS. It also adds latency/join times.

While not required to mitigate loops, it would help if both announce and subscribe had the originating relay ID included to enable features such as Reverse-path forwarding (RPF).

[afrind]

Seems like the solution is to disallow sending the same announce twice on the same session.

[martinduke]

One problem is the discretion we have to forward ANNOUNCE.

Suppose SUBSCRIBE_ANNOUNCE flows C->B->A but C and A are directly connected.

A gets an ANNOUNCE for that namespace from upstream and forwards it A->B->C.

C did not get a SUBSCRIBE_ANNOUNCE but decides to send it to A. Then even if A's upstream goes away, it will think it has a route to the namespace.

Worse yet, A might even have sent SUBSCRIBE_ANNOUNCE to C, which would further encourage A to send an ANNOUNCE.

[martinduke]

The 1/22/25 interim indicated there is no interest in solving this problem; routing between relays is out of scope for the WG. I will add some text to #643 warning that this is not a relay routing protocol.