Thank you for pointing out the GH issues and PRs where PA was discussed.
On the one hand, it seems that we have reached common understanding on
the scope of PA as described in RFC9000. On the other hand, reading the
GH discussions, I see some issues being raised that can be addressed
using Additional Addresses.
In addition, this extension could enable a multihomed server to
advertise several addresses so that clients can migrate to one of these
addresses when their connections fail, for instance because of a
provider failure at the server.
I would be ready to shortly discuss all this during the "If Time
Permits" segment of the QUIC meeting ahead, although I would first like
to get a sense of whether other QUIC participants are interested in this.
Maxime
Le 19/10/22 à 02:34, David Schinazi a écrit :
Looking at the spec and the Chrome code more closely, it appears that my
recollection was wrong - Chrome only looks at the preferred address right
after the handshake.
Please ignore my previous concerns, I was wrong and the sentence I had
pasted from draft-piraux-quic-additional-addresses is fine.
David
On Tue, Oct 18, 2022 at 5:13 PM Martin Thomson <[email protected]> wrote:
On Tue, Oct 18, 2022, at 18:39, Maxime Piraux wrote:
To me, when reading RFC9000, addresses provided in preferred_address are
expected to be used shortly after the handshake. So a client that
prefers one address family over the other can use its "best server
preferred address" and migrate across address families indeed.
So I guess the question can be framed differently:
Why would a client choose to defer use of this transport parameter? And
how would the client decide that when the transport parameter should be
used?
To your other points, the expectation is that a preferred address is acted
upon immediately after the connection is complete. If the following is
unclear, we can improve it if and when we revise RFC 9000, but I don't see
this as implying unlimited license to use the address:
QUIC allows servers to accept connections on one IP address and attempt
to transfer these connections to a more preferred address shortly after the
handshake.
-- https://quicwg.org/base-drafts/rfc9000.html#section-9.6-1
