Subject: Re: [quicwg/base-drafts] Connection migration optional? (#1271)

From: erickinnear <[email-masked]>
Date: Thu, 14 Jun 2018 18:52:21 -0700

There's still the issue that many expected migrations aren't explicitly initiated by the client but rather by the network (NAT rebinding, etc). If we want clients to be able to switch connection IDs on the same path, and we also want to be resilient to the path changing out from underneath the client, then we need to be very careful how we specify such a transport parameter. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-397489893

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 14 Jun 2018 19:06:27 -0700

If the option is explicitly to disable migration, and migration is assumed to be supported by default, I think the text can be written sufficiently carefully. We want to allow the default case for clients to work.

The peer-to-peer case of one peer being stuck behind a NAT, signaling that the other peer shouldn't migrate is an interesting point, and one of the points I find more compelling for not migrating automatically to the same address. It is a bit comparable to the NAT detection mechanisms used by IKE, which determine some later protocol behavior. Let's make sure to call out this scenario in the text, as well as others, perhaps specifying that deployments that don't fall into these scenarios in which migration is not useful SHOULD NOT disable migration, so as to encourage mobility of clients.

Doing the negotiation in the handshake as a TP is preferable to version indication in this case, I'd argue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-397492029

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 14 Jun 2018 22:12:59 -0700

@erickinnear supporting connection migration on server side requires updating of load balancers to be QUIC aware which will not be possible in many deployments for a while especially when the web server and the load balancer are not under the same administrative domain. In these cases even NAT rebinding will not work correctly and the solution is to use keep-alives if connections become inactive and want to be long-lived.  So if the server doesn't negotiate the TP then the client can automatically turn on keep-alives.

@tfpauly I am fine making the default as enabled and the TP flips it to disabled. The goal is to allow incremental deployment until load balancers can be upgraded.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-397515603

---

From: erickinnear <[email-masked]>
Date: Thu, 14 Jun 2018 22:29:08 -0700

Yes, I think we're in agreement that it will be useful to have a transport parameter, I just want to make sure that we're careful not to back clients into a corner where they cannot behave correctly due to influences outside of their control. A client that is behind a NAT might be surprised that the server thinks it's behaving incorrectly if it wasn't aware that some portion of the routing/NAT binding changed significantly. 

That's mostly a wording issue, I think, not a problem with the concept itself. 

It almost seems like it could be as simple as using the same terminology that we used previously ("local address" vs. "from an IP address"): 
```
The server does not support connection migration (link to the other section). 
Clients MUST NOT send any packets, including probing packets (probably 
use the real name from later), from a local address other than that 
used to perform the handshake.
```
It might be interesting to add, either in the definition or later where the second reference is made, a note that clients may wish to be more aggressive about using keepalives if connection migration is disabled. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-397517679

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Jun 2018 10:47:25 -0700

@erickinnear, what do you mean by "use the real name from later"?  "Probing packets" is a defined term later in the document.

However, I like the remainder of these updates and have made them, plus a forward reference to the definition of probing packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-397694837

---

From: janaiyengar <[email-masked]>
Date: Mon, 18 Jun 2018 17:16:18 -0700

@martinthomson : There's another use case, which I had to think about when getting connection migration out for GQUIC. This is where if you have a CDN server inside of an ISP, you want to explicitly disable migrating connections to other client ISPs, since that would constitute "leakage" at the server. You may still want to hand out new CIDs to allow a client to use it after a long quiescent period, in anticipation of NAT rebinding. An explicit signal from the server is a clear policy indication to the client not to migrate connections across networks.

This is admittedly difficult to enforce at the server without being too restrictive (by not handing out new CIDs). As I see it, a TP tells the client to not migrate connections across network changes. I would even suggest that a server MAY detect migrations across networks and close the connection with PROTOCOL_VIOLATION if it finds that a client violated this policy.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-398234657

---

From: erickinnear <[email-masked]>
Date: Mon, 18 Jun 2018 22:40:22 -0700

@MikeBishop by "use the real name from later", I was just thinking that we should use a defined term that we can link to -- if "probing packets" fits the bill, then that's great! 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-398280390

---

From: erickinnear <[email-masked]>
Date: Fri, 22 Jun 2018 10:51:04 -0700

Another thought, spurred by Rui's comment on the PR: 

Sending this TP means that the other end doesn't get to *knowingly* initiate migration. However, both sides (or the client since we're currently not direction-agnostic) still need to handle path challenge frames and generate path response frames. 

If this is just for use in datacenter environments, then there isn't really anything gained by having a TP, just don't do migration. 
However, I do still see the value for cases, especially until load balancers can cope with connection IDs, where you'd want to indicate that a client on the public internet shouldn't perform migration. 

Of course, even in that case, you still have to implement all the code on the server itself to deal with the observed client endpoint changing. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-399524870

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 15:55:39 -0700

Closed #1271 via #1447.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#event-1702649374