mirjak
commented
2 weeks ago I don't think we need to do anything here as well also allow opening new path before/instead of the preferred address migration. If an endpoint indicated a max path id of 0, it a clear sign it effectively doesn't want to used multipath (yet) and especially for the preferred address might prefer migration. So the only thing we could/should explicitly recommend is that if the max path is larger than 0, then a new path should be used instead of migration for the preferred address.
huitema
The current draft (version 11) says "Also, the Path ID for the connection ID specified in the "preferred address" transport parameter is 0. Use of the "preferred address" is considered as a migration event that does not change the Path ID." This point is further reinforced in the path management section: _"In particular, if the server uses the preferredaddress transport parameter, clients cannot assume that the initial server address and the addresses contained in this parameter can be simultaneously used for multipath (Section 9.6.2 of [QUIC-TRANSPORT])."
This is questionable, since support of RFC-9000 style "migration" is problematic, as explained in issue #458. With multipath negotiated, "path migration" uses the same code path as "NAT Rebinding", which is a poor fit for preferred address migration. The selected path will eventually depend on the order in which packets are received, which might bring back usage of the original address instead of the preferred address.
Clients will get a much more reliable result if they proceed in two steps: first establish a new path to the preferred address (typically path id 1), then abandon the initial path (path id 0). This is the "make before break" scenario that should generally be preferred to path migration. But this behavior is gated by two conditions: the server should allow a "max path id" value no lower than 1; and, the server shall provide the client with connection IDs for path 1. Otherwise, the client will have to wait until the server sends a new MAX_PATH_ID and PATH_CONNECTION_ID frames.
We may want to revise the text to explicitly authorize "make before break" behavior, i.e., using path creation instead of path migration for handling the preferred address. If we don't do that, stacks would probably need a special handling of the preferred address, as an exception to the normal code behavior, and that special handling should probably be discussed in the implementation section.