Re: preferred_address outside of handshake

[Mikkel Fahnøe Jørgensen <[e-mail]>]

This lands under migration.

It was deliberate choice to only allow clients to migrate in QUIC v1 to
avoid excessive complexity and because the most common use case are mobile
clients connecting to stationary servers.

There is an inherent feed-back problem in allow both to migrate. Even
seeming simple problems such as allowing both peers to change encryption
keys has caused at lot of design discussions and change.

QUIC v2 will likely explore multi-path connections and server migration.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 16 September 2019 at 08.02.05, Luke Curley ([e-mail]) wrote:

Hey guys,

I've spent the last few days reading the QUIC spec and it's amazing. One
thing I love is preferred_address as it gives the server the ability to
redirect traffic from an anycast address to a unicast address (among other
uses). This would obsolete DNS load balancing in many cases!

However, it's only possible to use preferred_address during the handshake.
If there was a frame that behaved the same way, then it would be possible
to migrate traffic to another address. This would be extremely useful; you
could migrate to another port for graceful restarts or another IP address
(including anycast!) to drain the entire host.

This is almost possible today as the new server can send packets (from a
new address) and cause the client to initiate a PATH_CHALLENGE. However,
this won't always work when the client is behind a NATs. What you really
need is the client to punch a hole in the NAT by explicitly telling the
client when to initiate a PATH_CHALLENGE.

What about something like PATH_CHALLENGE_REQUEST, containing similar
information as preferred_address? I even think this frame should replace
preferred_address as it's not a critical handshake parameter.


Thanks!