Subject: [quicwg/base-drafts] Spin bit should be applied per each 5-tuple rather than per connection (#1828)

From: Kazuho Oku <[email-masked]>
Date: Tue, 02 Oct 2018 16:19:17 -0700

Section 2.2 of the spin-bit draft states that "each endpoint, client and server, maintains a spin value, 0 or 1, for each QUIC connection."

However, this does not work when both endpoints try to coalesce multiple QUIC connections onto a single UDP port.

In such case, multiple connections will be sharing the same 5-tuple.

Since an observer cannot track each connection<sup>1</sup>, the spin bit needs to be applied for that 5-tuple so that it would be an useful signal to the observer (who does not have the ability to track each connection across CID changes).

[1]  Although the initial pair of CIDs is observable, it becomes impossible to track the client's CID and the server's CID that maps to the same connection once the CID changes for the connection.

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

---

From: ianswett <[email-masked]>
Date: Tue, 02 Oct 2018 16:59:56 -0700

Agreed, this should definitely be per-path.

-- 
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/1828#issuecomment-426469383

---

From: Lars Eggert <[email-masked]>
Date: Wed, 03 Oct 2018 01:17:40 -0700

"Per-path" would be based on the IP address pair, which is not the same though

-- 
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/1828#issuecomment-426550472

---

From: MikkelFJ <[email-masked]>
Date: Wed, 03 Oct 2018 01:21:32 -0700

Different processes can connect on the same IP pair.

-- 
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/1828#issuecomment-426551514

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 03 Oct 2018 02:14:44 -0700

> Different processes can connect on the same IP pair.

Or diffrent machines when a NAT or a L4 load balancer is present.

Anyways, I assume that we agree that the identifier needs to be the 5-tuple (setting aside what “path” means).

-- 
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/1828#issuecomment-426566405

---

From: MikkelFJ <[email-masked]>
Date: Wed, 03 Oct 2018 02:20:12 -0700

Actually two bridges could route traffic between two cloud private networks over a fixed 5-tuple.
I'm not sure it is safe it mix any information across connections.

-- 
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/1828#issuecomment-426567798

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 03 Oct 2018 06:11:19 -0700

> Actually two bridges could route traffic between two cloud private networks over a fixed 5-tuple. I'm not sure it is safe it mix any information across connections.

It is impractical (if not impossible) for an uncoordinated middlebox to coalesce multiple QUIC connections onto a single 5-tuple, even in case both endpoints use non-zero-length CIDs.

This is because, as I have stated, it is impossible for such a middlebox to track a connection across CID changes. Consider the case where a NAT is coalescing multiple QUIC connections coming from more than one client machine. When a CID change is initiated for one of the connections *by a server*, the NAT cannot determine to which client it should forward the packet that contains the new CID.

Therefore, my view is that it is safe for an observer running on the Internet to consider QUIC connection(s) using a 5-tuple to be a communication between two machines, and that it is safe to expect the Spin bit state to be shared among such connections.

FWIW, my expectation is that it would not be uncommon to see multiple QUIC connections coalesced onto one 5-tuple (at least that will happen when H2O/quicly is run as an edge server), and that spin bit design should take such deployments into consideration.

-- 
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/1828#issuecomment-426631755

---

From: MikkelFJ <[email-masked]>
Date: Wed, 03 Oct 2018 06:19:56 -0700

You are making assumptions about the bridges not understanding the information encoded in the CID's.

-- 
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/1828#issuecomment-426634449

---

From: MikkelFJ <[email-masked]>
Date: Wed, 03 Oct 2018 06:34:25 -0700

Also, in the bridge scenario, it is not likely that the CID will change.

-- 
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/1828#issuecomment-426639166

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 03 Oct 2018 13:39:52 +0000 (UTC)

If the bridge can decrypt the information encoded in CID, it would mean that the bridge is not an "uncoordinated" middlebox.

What I am pointing out is that it is impossible for an *uncoordinated* middlebox to coalesce QUIC connections. Such middlebox (i.e. NATs) will be far more common than *coordinated* middlebox.

It is also my understanding that most endpoints running on the Internet will support CID change.

Considering these aspects, my argument is to design spin bit for the cases where such uncoordinated middleboxes exist and CID changes mid-connection, rather than for the cases where you would have coordinated ones.

-- 
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/1828#issuecomment-426640992

---

From: MikkelFJ <[email-masked]>
Date: Wed, 03 Oct 2018 06:43:53 -0700

As long as it is clear that those assumptions are present.

-- 
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/1828#issuecomment-426642439

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Oct 2018 15:49:55 -0700

Parking based on the resolution of #631 

-- 
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/1828#issuecomment-430428281