What if SPA migration fails?

[MikeBishop]

The draft currently says, from #256, that:

They can also start using multiple paths, unless both server preferred addresses and a disable_active_migration transport parameter were provided by the server, in which case a client is forbidden to establish new paths until "after a client has acted on a preferred_address transport parameter" (Section 18.2. of [QUIC-TRANSPORT]).

This is nearly correct. The disable_active_migration transport parameter indicates that "an endpoint ... MUST NOT use a new local address when sending to the address that the peer used during the handshake." This does not prohibit the client from connecting to any other server address that it might know about.

The targeted scenario for the RFC 9000 text is an Anycast IP, where attempting to connect from a different source may land on a different destination instance. The migration to the SPA will allow a direct connection to the server that performed the handshake regardless of source address.

Notably, if the migration fails, the current text prohibits the client from ever establishing any other paths, which is probably not what we want.

I would suggest that we clarify that this prohibition applies only to the handshake address, and that establishment of additional paths to other addresses (potentially including the SPA) is valid immediately.

[mirjak]

With the explicit path ID PR #403 now allows to open new paths even before migration to a preferred address happened. Let's confirm this at the meeting at IETF-120 and then hopefully merge and close this issue!