Subject: Server's Preferred Address

From: Mike Bishop <[email-masked]>
Date: Thu, 5 Apr 2018 17:19:26 +0000

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.)

---

From: Ian Swett <[email-masked]>
Date: Thu, 05 Apr 2018 17:27:24 +0000

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 <[email-masked]> 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.)
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 6 Apr 2018 16:42:35 +0000

If connection migration is negotiated as suggested in issue 1271, then we can make the SHOULD a MUST. The server cannot of course validate the attempt but the client only ends up losing its own connection and possibly flagged for a DoS attack post migration.

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: Thursday, April 5, 2018 10:27 AM
To: Mike Bishop <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Server's Preferred Address

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 <[email-masked]<mailto:[email-masked]>> 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.

  *   IP version
  *   IP address
  *   UDP port

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.

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 6 Apr 2018 16:42:35 +0000

*   IP version
  *   IP address
  *   UDP port

---

From: Christopher Wood <[email-masked]>
Date: Fri, 27 Apr 2018 17:09:46 +0000

+1

I think this is a compelling change, at least for supporting migration in
the presence of anycast, and especially if the newly probed path properties
are superior to the one on which the handshake was performed.

Best,
Chris
On Thu, Apr 5, 2018 at 10:27 AM Ian Swett <ianswett=

>> 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.)

---

From: Rui Paulo <[email-masked]>
Date: Fri, 27 Apr 2018 10:37:59 -0700

> are superior to the one on which the handshake was performed.

I also support this change and the PR looks good to me.

—
Rui Paulo