RE: preferred_address outside of handshake

[Mike Bishop <[e-mail]>]

We’ve talked about what would be involved in server migration.  Given the reality of NAT behavior, the client usually needs to be the party actually changing what address it’s communicating with, even if it’s the server that’s changing.  A server migration implementation would probably include a frame that looks a lot like a preferred address transport parameter, asking the client to please probe the new path and switch if successful.  However, it was a deliberate decision not to open the door further for v1.  One of the features that might be considered for v2 or extensions is more extensive migration or multipath support, but we’re not there yet.

From: QUIC <[e-mail]> On Behalf Of Jana Iyengar
Sent: Monday, September 16, 2019 8:23 PM
To: Mikkel Fahnøe Jørgensen <[e-mail]>
Cc: Luke Curley <[e-mail]>; QUIC WG <[e-mail]>
Subject: Re: preferred_address outside of handshake

Luke,

I agree with what Mikkel said. To your point, this parameter was meant specifically for the anycast case, but not the more general case. Doing the more general server migration is a complex beast. We'll see what happens in the future with QUICv2, but I don't think we should pursue this general case right now.

- jana

On Sun, Sep 15, 2019 at 11:07 PM Mikkel Fahnøe Jørgensen <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[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!