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

From: Brian Trammell <[email-masked]>
Date: Wed, 07 Nov 2018 06:49:35 -0800

unparking together with #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-436647884

---

From: Brian Trammell <[email-masked]>
Date: Wed, 07 Nov 2018 14:54:22 +0000 (UTC)

Agree with @kazuho, this should be per 5-tuple. However, it's not clear what the best way is to reconcile that with our desire to try to reduce CID linkability on migration by making the spin bit reset state (and indeed, even reset spin-participation state) on CID 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-436649593

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 07 Nov 2018 10:28:58 -0800

Based on the offline discussion at Bangkok, my understanding is that we have two possibilities; either suggest that:
* when more than one connections are coalesced onto a single 5-tuple, spin *none* of them
or 
* when more than one connections are coalesced onto a single 5-tuple, spin *at most one* of them

The latter gives the observers better chance of seeing the signal, at the cost of being required to determine the CID that actually spins. 

Assuming that we would have enough connections that are spinning, it might also be safe to assume that many connections will not be coalesced onto a single 5-tuple. If that is the case, the former would be sufficient.

-- 
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-436728629

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Nov 2018 17:37:50 -0800

You could spin them all together.  Detecting an edge across all connections based on an increase in largest received packet number in each should work.

Keep in mind that a single connection can use multiple connection IDs on the same path, switching between them arbitrarily.  That could appear to the path to be multiple connections sharing a path.  Spinning multiple connections together would appear to be no different.

-- 
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-436841824

---

From: erickinnear <[email-masked]>
Date: Wed, 07 Nov 2018 18:49:42 -0800

> That could appear to the path to be multiple connections sharing a path. Spinning multiple connections together would appear to be no different.

This seems to make sense to me -- do we spin per CID or per 5-tuple? That seems to be the main question in my mind. 

-- 
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-436854689

---

From: ianswett <[email-masked]>
Date: Wed, 07 Nov 2018 19:53:35 -0800

I'm not sure per 5-tuple is actually implementable in most environments.  Servers in particular would have a hard time coordinating the right value.

And the algorithm of latching the value to reflect to the largest packet number's value is undefined if there are a multiple packet number spaces.

So I think we need to do per CID?

-- 
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-436864870

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Nov 2018 19:59:33 -0800

I agree that per-path is not feasibly implemented.  We'd have to acknowledge the possibility that multiple connections that share a path are not required to coordinate.

-- 
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-436865714

---

From: MikkelFJ <[email-masked]>
Date: Thu, 08 Nov 2018 00:24:35 -0800

Yes definitely - two connections should be required to coordinate.

-- 
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-436911426

---

From: Brian Trammell <[email-masked]>
Date: Thu, 08 Nov 2018 09:59:35 +0000 (UTC)

I tend to agree with @ianswett here -- while different CIDs may often represent connections between the same processes (and therefore with similar e2e delays at a given instant in time), this is not guaranteed to be the case. Is per-CID spin a useful passive measurement signal in the general case, though?

Stepping back, there seem to be two broad usage patterns with partially conflicting requirements here:

- possibly-mobile client with load-balanced server. Here the server proposes non-zero-length CIDs, and the client proposes a zero-length CID. The client will generally not use one server CID at a time. Since the CID reserve a client has exists to attempt to reduce address linkability on a rebinding event, the spin state should not be shared across CIDs -- this language has been in spin-exp since London (*)

- client-server connection using CID multiplexing. In this case, both client and server CIDs must be in use, though the CID size does not necessarily need to be the same in each direction. Migration linkability mitigation is harder in this case, and it's not clear to me that it's even a requirement. Here, per-5-tuple-spin would be possible. (note that in this case the server also has to keep CID-2-tuples around, so @ianswett's point that per-CID is hard on the server does not apply here)

Per-5-tuple spin is clearly more useful to the path -- otherwise, on-path devices has to use heuristics to guess the CID (node, this is not very hard if it has a few packets, but it needs to keep a header buffer up to max CID length until it locks on, and it can use heuristics about well-known servers/CDNs/configurations to make an initial guess that will be correct almost all of the time -- in any case, any on-path measurement device offering RTT information will also probably offer flow information). But it seems impossible to do for those cases where we care about reducing spin state contribution to rebinding linkability.

* as I've pointed out at many times in the past, rebinding linkability reduction still seems to rely on incredibly wishful thinking to me, and I'd really like to see some data on the anonymity set sizes for rebindings in the temporal domain. Even in the case that linkability reduction has a practical benefit, spin state adds a tiny fraction of a bit of information, so blanking spin state on CID change is of vanishingly small benefit. However, it is consistent with the rest of the protocol's design, and I'm still willing to pretend it's a useful exercise, because there seems to be broad consensus that we believe in 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/1828#issuecomment-436938812

---

From: MikkelFJ <[email-masked]>
Date: Thu, 08 Nov 2018 02:26:11 -0800

please note my above edit - connections should not need to coordinate.

@britram:

on your first point: if the client is potentially mobile and actively moving to a new IP, it MUST have a non-zero CID length. A stationary client can of course still rebind via NAT but then zero-length is valid.

on your second point - per CID spin-bit multiplexing: it may be acceptable for single connection, but not over multiple connections multiplexing because the entity that produces packets may be running independently in different logical processes or even on isolated hardware in extreme cases.

I agree on your last point the linkability is unrealistic to avoid in praxis. The consensus thinking is, however, that it should be attempted to the extend possible. While I disgree, this appears to be the working assumption.

I think spin bit per CID as as easy as 5-tuple because you need a hashed entry in either case to track state. A spin bit per connection should be impossible if anti-linkage is working. Of course with respect to reporting any operational issues, a 5-tuple is more useful than a CID, but the hashed entry can include path information.

The main problem with spin bit visiblity is a specific end-user standing out as the only one not contributing with spin bits.

-- 
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-436946686

---

From: erickinnear <[email-masked]>
Date: Thu, 08 Nov 2018 03:54:09 -0800

I think I agree with @mikkelfj that we shouldn’t require connections to coordinate. Given that CID is the identifier that we use/is most granular, it does make spinning per CID seem attractive. Although I am sensitive to @britram’s question about the signal that this generates... 

-- 
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-436969539

---

From: Brian Trammell <[email-masked]>
Date: Mon, 12 Nov 2018 02:46:09 -0800

@erickinnear I spent a little time thinking about how an observer generating RTT samples from a per-CID spin would work, and while it’s slightly messier than using 5-tuples as a flow key, it’s not at all hard. So I don’t think there are any concerns about signal quality.

I’ll put together a PR for language about this in the management draft when I get a moment.

-- 
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-437835278

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 12 Nov 2018 04:16:35 -0800

I agree that from endpoint's perspective spinning per connection is the easiest thing to do.

>From observer's perspective, it becomes hard to track which client CID is associated to which server CID when multiple CIDs rotate simultaneously, but all you lose in that case is the capability to observe the distance between the observation point and the endpoints. The RTT of the connection would still be observable.

-- 
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-437858230

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Nov 2018 22:56:50 +0000 (UTC)

I don't think that we need fancy here.  Simply state that - ideally - spinning is scoped to a 5-tuple.  You might then observe that if connections share the same path, then they might not be able to coordinate spinning.

Aside from it being logistically difficult to coordinate across connections, coordination isn't possible in all cases. With diverse endpoints, there could be NATs/load-balancers/middleboxes that know how to multiplex and demultiplex based on connection ID at both ends.  That makes @britram's thinking useful (...minimum publishable unit?).  Of course, if spinning could be coordinated, that would make the signal cleaner.

Note that multiple connections on the same path is hard to distinguish from the same connection with alternating connection IDs, unless the end-to-end latency differs.  (Note to self: look into gaming 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/1828#issuecomment-438058714

---

From: mirjak <[email-masked]>
Date: Wed, 28 Nov 2018 09:35:39 -0800

Is the assumption of the current discussion that the connection ID is present/non-zero? I guess if no connection ID would be present a per-CID spin signal would look quite random from the network, no? 

-- 
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-442535987