Re: Server's Preferred Address

[Ian Swett <[e-mail]>]

I and the traffic engineers I work with would REALLY like to have this
feature.  Also, in practice it's required to make connection migration work
with anycast.

At Google, we've started experimenting with this already in gQUIC, and it
works as expected, though you do need to probe before jumping to the new
server IP(as described in Mike's PR), or you risk a small but visible
number of connection failures post-handshake.

On Thu, Apr 5, 2018 at 1:19 PM Mike Bishop <[e-mail]> wrote:

> As we walk along the spectrum from fixed 4-tuple for the life of a
> connection to full multipath, #560 requested a solution to the problem of
> Anycast IP addresses.  There are some large server deployments where the
> front-end addresses are Anycast-based.  However, for a connection-oriented
> protocol, you want to be “sticky” to the server endpoint that you did the
> handshake with.  Currently, that’s addressed with some amount of
> re-forwarding internally and some amount of tolerated connection breakage.
> This gets more painful if we support connection migration, as the same
> Anycast address likely hits a different server from your new IP address.
>
>
>
> PR#1251 builds on the path verification approach to enable servers to hand
> off to a unicast IP address if desired.  It adds a transport parameter in
> which the server supplies:
>
>    - IP version
>    - IP address
>    - UDP port
>    - Connection ID (possibly empty)
>    - Stateless Reset Token
>
>
>
> At the end of the handshake, the client SHOULD perform path validation on
> the supplied address; if it succeeds, it transitions to the new address.
> If it fails, it just stays on the original (presumably Anycast) address and
> takes the risk that the connection will fail when routing changes.  (The
> SHOULD is a matter of some contention – servers want to be able to rely on
> this, but can’t actually tell whether the client’s path validation failed
> or was never attempted.)
>
>
>
> It’s important to note that this isn’t full server migration – it’s a step
> in that direction, but this is scoped strictly to the server making one
> change attempt to an address it provides at a specified time.  However,
> this isn’t something that has seen broad discussion, so I wanted to raise
> it for the WG’s consideration.
>
>
>
> (If we want to tackle server migration, I think the next piece would be a
> frame that carries essentially the same information, requesting the client
> to make a probe attempt.  This helps deal with NATs by making clients speak
> first, but it assumes that the server always maintains control of both
> addresses during a transition.  To support full P2P, where both sides could
> be make-after-break, you basically need something like ICE.)
>