Re: preferred_address outside of handshake

[Jana Iyengar <[e-mail]>]

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]>
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]) 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!
>
>