Subject: Re: [quicwg/base-drafts] New connection ID message (#232)

From: Erik Nygren <[email-masked]>
Date: Thu, 30 Mar 2017 07:46:37 -0700

As pointed out by Subodh Iyengar, the server-proposed connection ID needs to be switched to before any server state is needed in order to enable stateless load balancing.

-- 
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/232#issuecomment-290433927

---

From: ianswett <[email-masked]>
Date: Thu, 30 Mar 2017 07:56:31 -0700

To summarize the only important missing point on #427, we currently have no way to specify a >4 byte packet number, and it seems reasonable we may want to skip to a packet number space quite a ways away to avoid linkability.

I suggest we specify the most significant 4(?) bytes of the packet number in this connection ID frame, because the alternative of using 8 byte packet numbers may increase linkability when migration occurs, since the obvious approach is to increase the packet number by a substantial amount.

Or we can add an 8 byte packet number if my concerns about linkability are unfounded, as it'd be a bit simpler.

-- 
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/232#issuecomment-290437178

---

From: ianswett <[email-masked]>
Date: Thu, 30 Mar 2017 08:02:45 -0700

I believe this issue also requires #423 

-- 
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/232#issuecomment-290439171

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Mar 2017 14:29:45 -0700

@ianswett, I always planned to add a packet number gap with each connection ID.  The client then skips that number of packet numbers when changing the connection ID.  The server can easily remember the delta that it bound to each connection ID.

-- 
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/232#issuecomment-290550609

---

From: ianswett <[email-masked]>
Date: Thu, 30 Mar 2017 14:40:34 -0700

@martinthomson  In order to deal with packet loss, I believe it needs to specify where the connection ID's packet number space begins(ie: what it's 0 value is) in real packet number space, not just the size of the gap.

-- 
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/232#issuecomment-290553101

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 30 Mar 2017 14:57:50 -0700

@martinthomson clever! I like that idea.

@ianswett I think it would be quite similar to how the server deals with packet loss today. On connection id X, when a packet is received, the server compares the (truncated) on the wire packet number to the largest received packet number and uses that to determine the full packet number. 

In the case where the connection id is now Y, it compares the (truncated) on the wire packet number to the packet_gap(Y) + largest received packet number and uses that to determine the full packet number.

Does that sound plausible?

-- 
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/232#issuecomment-290557170

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Mar 2017 15:53:18 -0700

@RyanAtGoogle has it precisely correct.  (In practice, this would in fact allow for a smaller gap than the agreed one to be used, but that's probably slightly nutty.)

-- 
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/232#issuecomment-290567815

---

From: ianswett <[email-masked]>
Date: Thu, 30 Mar 2017 16:01:10 -0700

So to clarify the algorithm, the receiver would prime the "expected next packet number" to be the last received packet + the specified gap?

I believe the size of the gap is related to the size of the packet number.  ie:  If you're using 4 byte packet numbers, you need the gap to be as much as 4 billion?

If the new connection ID is used to transmit over multiple paths at once, this could get a a bit messy because there's a risk the packet number spaces get relatively close?  What if two migrations occur close together in time and/or the first migration fails?  If the first migration fails, I think the connection must immediately close with the gap based approach?

-- 
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/232#issuecomment-290569151

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Mar 2017 16:09:50 -0700

Actually, the size of the gap is determined by the amount of entropy you want to add.  Obviously, <4 billion will lead to having some bits remaining the same, so I would recommend a number that is close to or larger than that size.

If you have to migrate twice, then you could go back to the baseline.  You could even use largest_acked on the sender as well as the receiver for the baseline.

-- 
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/232#issuecomment-290570613

---

From: ianswett <[email-masked]>
Date: Fri, 31 Mar 2017 07:22:12 -0700

Ok, now I understand exactly what you're saying, and it was originally what I had in mind, and I'm concerned about two potential issues:
1) You can't safely increase the packet number by more than ~2^31 today, because we only have 4 byte packet numbers on the wire.  Ideally you'd like the packet number gap introduced to be totally random within the full packet number range?  Or possibly we're ok with a single bit of correlation?
2) If you tried to migrate a second time before receiving an acknowledgement for the first time.  I guess that ends up being a sub-case of 1, where the amount you can further increase the packet number becomes limited because the peer hasn't acked the first migration.  Going back to the baseline is dangerous because you don't know if any packets on the intermediate path were received, and it would take some carefulness to avoid re-using packet numbers.

-- 
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/232#issuecomment-290725692

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Mar 2017 08:00:34 -0700

@ianswett,

On 1, a larger gap is possible if you are also changing the connection ID and you require that the connection ID change and gap be concurrent.

On 2, you are right, double migration is nasty.  You certainly can't send two packets with the same number.  Do you have any ideas on how we could avoid that?

BTW, ekr's design for connection ID obfuscation wouldn't suffer from this.

-- 
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/232#issuecomment-290736329

---

From: ianswett <[email-masked]>
Date: Fri, 31 Mar 2017 08:05:33 -0700

My solution to both was to send a connection ID paired with the starting packet number that Connection ID indexes to, but there may be better solutions.

If the packet number is encrypted, there are still potential problems we need to properly specify, but they aren't privacy problems.  

-- 
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/232#issuecomment-290737697

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Mar 2017 08:37:35 -0700

The problem with that is that you have to use the connection ID once you hit that packet number or burn that connection ID once you get too close (for some definition of close).

-- 
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/232#issuecomment-290747048