Subject: [quicwg/base-drafts] Simultaneous connection migration (#490)

From: Martin Thomson <[email-masked]>
Date: Mon, 01 May 2017 21:04:58 -0700

It's not clear if this is possible.  If it is, then we have to decide whether the cost is worth bearing.

-- 
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/490

---

From: janaiyengar <[email-masked]>
Date: Wed, 03 May 2017 15:18:09 -0700

This seems possible as is... what is the cost you are thinking about?

-- 
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/490#issuecomment-299051535

---

From: Martin Thomson <[email-masked]>
Date: Wed, 03 May 2017 15:30:35 -0700

OK, simplest possible migration, change of port number on both ends, same connection ID.  I don't understand how this would work.  Whichever peer sends first will send to a port on which the other side isn't listening.  Same happens if the IP and port change together.   It's worse if the connection ID is changed and that seems highly likely given that this is why you migrate in the first place.

We already have an unwritten caveat on migration in that the migrating endpoint has to be the one to speak first.  We probably have an additional unwritten caveat that only a client can migrate, given that a changing source address likely runs afoul of any firewalls and NATs and we more or less assume that the server isn't afflicted with that sort of curse.

As for costs, I don't know what the solution looks like, so I can't even speculate on costs.

-- 
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/490#issuecomment-299053847

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 16:46:04 -0700

Ah -- so you're assuming that the peer has stopped listening on the previous port. Sure, that case won't work at all. But the case where both endpoints choose to use a new port while being able to "drain" the old one is possible to do simultaneous migration with.

-- 
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/490#issuecomment-299339092

---

From: Martin Thomson <[email-masked]>
Date: Thu, 04 May 2017 18:34:02 -0700

If you make before break, this *might* work.  You would need a trigger to cause the other side to start using the new address, which I don't think that we have.  It might be possible for a client to receive packets from a different remote address and start sending on that address, but how does it decide to switch over?  That suggests a new signal of some sort, which costs.  Also, many firewalls and NATs will stomp on packets from a new address, which would prevent spontaneous migrations at the server side.

-- 
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/490#issuecomment-299351549

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 18:54:35 -0700

It does work. So, say both sides use a new IP to send new data, but are able to receive on the old and the new IP (because the interfaces are cellular and wifi, say, and both are active, but the devices would prefer to switch from using cellular to using wifi.) I agree that NATs are an issue, but that just means that if you're brave enough to try to do simultaneous migration, it's very unlikely to work due to NATs.

Forbidding has costs -- endpoints will need to write code to disallow certain things. If they never happen, it's even worse, since it's largely unused code. If we agree that simultaneous migration doesn't hurt us, then let's leave it out. 

-- 
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/490#issuecomment-299353546

---

From: Martin Thomson <[email-masked]>
Date: Thu, 04 May 2017 19:07:39 -0700

I understand how new address could be used, I even understand how one peer might choose to start using a new source address.  I just don't know how it might decide to start using a different remote address without first receiving packets on that address.

Leaving aside the NAT thing, which I don't think you can dismiss so casually, let's look at the scenario in the simple case where all addresses are equally reachable from all others.  In a simultaneous migration, you have A1->A2 simultaneous with B1->B2.  As the change happens, A2 sends to B1, B2 sends to A1.  How does A decide that A2 to B2 is the path it should use?

To be clear, I don't think we need to forbid any of this, but if we need to make it work, that will take effort, if only to write down where it works, how, caveats, etc...

-- 
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/490#issuecomment-299354753

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 19:40:02 -0700

Ah, as long as we're not trying to forbid this I think we're on the same page... I don't think simultaneous migrations are interesting, but I'd rather not spend energy on how to forbid... I'm comfortable with saying that they "aren't supported", and endpoints SHOULD not attempt it.

-- 
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/490#issuecomment-299357700

---

From: mirjak <[email-masked]>
Date: Mon, 08 May 2017 02:15:56 -0700

As a side note, if we design this carefully, we basically might get multipath for free. I think the important part is that we should not assume that if we see a new connection ID that the old one is dead immediately. Might be even worth it actually try and shut down the old connection ID properly if you don't receive any new packets there for a while and see if the other end of the old connection id is actually dead or might reply.

-- 
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/490#issuecomment-299815594

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 18 May 2017 16:45:15 -0700

@martinthomson 
>  In a simultaneous migration, you have A1->A2 simultaneous with B1->B2. As the change happens, A2 sends to B1, B2 sends to A1. How does A decide that A2 to B2 is the path it should use?

If each endpoint uses the rules:

1. "Send FROM your new address"
2. "Send TO the latest address you've heard from"

Then, after "A2 send to B1" and "B2 send to A1", A (on A1) will have heard from B (sent from B2).  Hence, A will send from A2 to B2.

By the way, I do not see NAT as a problem here.  When A sends from A2 (NAT exit point), NAT will associate A2 with A.

(Assumption here is that NAT does not validate an entire 5-tuple.  Instead, compatible NATs only care about the local address/port.)

-- 
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/490#issuecomment-302570869

---

From: MikkelFJ <[email-masked]>
Date: Thu, 18 May 2017 22:59:04 -0700

If latest heard from does not mean highest packet number seen rather than last packet received, this could fail.

-- 
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/490#issuecomment-302616056

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 19 May 2017 08:10:21 -0700

Even if it is strictly "last received", how would it fail?  At worst, it would take an extra rtt to settle, in case pre-migration and post-migration packets get re-ordered.

-- 
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/490#issuecomment-302729320

---

From: MikkelFJ <[email-masked]>
Date: Fri, 19 May 2017 08:26:56 -0700

> Even if it is strictly "last received", how would it fail? At worst, it would take an extra rtt to settle, in case pre-migration and post-migration packets get re-ordered.

right, though sender might be lazy with acks resulting in unexpected latency.

-- 
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/490#issuecomment-302733931

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 19 May 2017 10:26:09 -0700

Good point, although this issue is not specific to simultaneous connection migration.

We should recommend that when an endpoint receives a packet on a de-prefered path, it sends an ACK over the prefered path ASAP (not be lazy about it).  This assume that the sender is aware of the migration event.

-- 
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/490#issuecomment-302762879