preferred_address and use of multipath frames

[kazuho]

At the moment, we have following statements regarding preferred_address:

• Inline with the definition in [QUIC-TRANSPORT] disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" (Section 18.2. of [QUIC-TRANSPORT]). (section 3)
• If the server uses the preferred_address transport parameter, clients SHOULD NOT assume that the initial server address and the addresses contained in this parameter can be simultaneously used for multipath. (section 4)

What do they exactly mean?

Regarding the first one, it sounds as if use of multipath frames incl. ACK_MP is prohibited on the original path if preferred_address TP is provided? But I do not think that in the intention.

Second statement is hard to digest as well. Does it imply that a server might stop responding to packets sent to the original address once both the client and the server validates the preferred path? EDIT: the second statement reflects RFC 9000 Section 9.6.2 stating that servers SHOULD drop newer packets received on the old IP address.

[kazuho]

In my view, we should state something like following:

1. Allow use of multipath against the original address even in the presence of preferred_address TP. Server Preferred Address is an optional feature of QUIC. I do not think we need to make it a mandatory in Multipath.

2. Once the client validates the path to the preferred address, it SHOULD retire all the paths established to the original address and MUST NOT open new paths to the original address.

EDIT. We also need the following:

3. When disable_active_migration TP exists, endpoints MUST NOT attempt to create new paths to the original server address (but otherwise use of multipath features (e.g., new frames) are allowed).

[kazuho]

Another question is if we want to call it a handshake failure if the server sends enable_multipath and disable_active_migration but not preferred_address.

Based on the fact that we send TRANSPORT_PARAMETER error when a zero-length CID is used, we might want to detect this case and call it an error as well.

OTOH, considering that we will have a case where use multipath-specific frames will be allowed but establishment of new paths are prohibited (this happens when the server sends enable_multipath, disable_active_migration, preferred_address but the client fails to establish a path to the preferred address), maybe we should just conclude the handshake as success and continue.