Subject: [quicwg/base-drafts] Spin per peer (#1982)

From: Christian Huitema <[email-masked]>
Date: Thu, 08 Nov 2018 11:36:29 +0000 (UTC)

Specify that the enabling/disabling of the spin bit should depend on the peer address. The goal is to create an anonymity set that consistent with avoidance of spin bit for hidden servers.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1982

-- Commit Summary --

  * Merge pull request #8 from quicwg/master
  * Specify spin enabling depends on peer address.

-- File Changes --

    M draft-ietf-quic-spin-exp.md (12)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1982.patch
https://github.com/quicwg/base-drafts/pull/1982.diff

-- 
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/pull/1982

---

From: Christian Huitema <[email-masked]>
Date: Thu, 08 Nov 2018 03:41:37 -0800

@huitema pushed 1 commit.

961ac76  Trailing whitespace

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/8b2601234558f6991860d5235498abcc55595085..961ac76703e08560c7c841c2c491daa1af687921

---

From: MikkelFJ <[email-masked]>
Date: Thu, 08 Nov 2018 03:43:53 -0800

mikkelfj commented on this pull request.

-When the spin bit is disabled, endpoints SHOULD set the spin bit value to zero,
+The selection process SHOULD be designed such that
+on average the spin bit is disabled for at least 1/8th of the connections, or
+1/8th of the paths when doing migrations. The random choice SHOULD be dependent
+on the address of the peer, so that the spin bit is consistently enables or
+disabled for repeated connections to the same address.
+

That won't work well in server p2p where many connections go through the same 5-tuple because either all or no traffic will get spins. It will also will not work well when a cluster of servers target the same IP using the same PRNG /hash algorithm. You need to depend on the source address as well.

I think 1/8th of CIDs would be better.

-- 
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/pull/1982#pullrequestreview-172917791

---

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

erickinnear commented on this pull request.

It does seem like after reading the discussion in issue #1828 that spinning per CID would be better. 

-- 
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/pull/1982#discussion_r231858963

---

From: Christian Huitema <[email-masked]>
Date: Thu, 08 Nov 2018 18:25:14 -0800

huitema commented on this pull request.

The goal here is to provide an anonymity set for client/servers when the RTT would reveal the presence of a VPN or proxy. These clients and servers will disable the spin bit when talking to each other. The adversary will observe that the spin bit is never set for the corresponding 5 tuple. My goal is to specify a masking behavior in which "non hiding" clients also never set the spin bit for a few 5-tuples.

In the case of multiplexed use of a 5 tuple, I actually like the global on-off switch. It matches the style of anonymity set that we want.

And, yes, I should add the source address in the mix. 

-- 
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/pull/1982#discussion_r232126306

---

From: Christian Huitema <[email-masked]>
Date: Thu, 08 Nov 2018 18:29:05 -0800

c37f2ca  Specify enabling depend on both source and dest addresses

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/961ac76703e08560c7c841c2c491daa1af687921..c37f2ca69868398779ee0f20e7e09376d91920ef

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Nov 2018 19:49:51 +0000 (UTC)

MikeBishop commented on this pull request.

But if you include the source address as well, doesn't that mean that most clients would ordinarily spin and a server that gets spin from clients at a near-zero rate remains suspicious?

-- 
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/pull/1982#discussion_r233197831

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Nov 2018 16:45:21 -0800

martinthomson commented on this pull request.

This is essentially right, but I think that this needs to be primarily per-path, with an allowance for per-connection ID.

```suggestion
on average the spin bit is disabled for at least one eighth of network paths.
```

```suggestion
The random choice SHOULD be dependent
```

+on the source and destination addresses of the connection,

```suggestion
on the source and destination addresses of the path,
```

-When the spin bit is disabled, endpoints SHOULD set the spin bit value to zero,
+The selection process SHOULD be designed such that
+on average the spin bit is disabled for at least 1/8th of the connections, or
+1/8th of the paths when doing migrations. The random choice SHOULD be dependent
+on the source and destination addresses of the connection,
+so that the spin bit is consistently enabled or
+disabled for repeated connections between the same addresses.

```suggestion
disabled for repeated use of the same path.
```

-When the spin bit is disabled, endpoints SHOULD set the spin bit value to zero,
+The selection process SHOULD be designed such that
+on average the spin bit is disabled for at least 1/8th of the connections, or
+1/8th of the paths when doing migrations. The random choice SHOULD be dependent
+on the source and destination addresses of the connection,
+so that the spin bit is consistently enabled or
+disabled for repeated connections between the same addresses.
+
+When the spin bit is disabled, endpoints SHOULD set the spin bit value to
+a constant value randomly chosen to be 0 or 1,

```suggestion
a constant value that is randomly chosen to be 0 or 1 for the path,
```

-When the spin bit is disabled, endpoints SHOULD set the spin bit value to zero,
+The selection process SHOULD be designed such that
+on average the spin bit is disabled for at least 1/8th of the connections, or
+1/8th of the paths when doing migrations. The random choice SHOULD be dependent
+on the source and destination addresses of the connection,
+so that the spin bit is consistently enabled or
+disabled for repeated connections between the same addresses.
+
+When the spin bit is disabled, endpoints SHOULD set the spin bit value to
+a constant value randomly chosen to be 0 or 1,
 regardless of the values received from their peer. Addendums or revisions to

```suggestion
regardless of the values received from their peer.  Alternatively, endpoints MAY
change this value when changing connection ID.  Addendums or revisions to
```

-- 
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/pull/1982#pullrequestreview-174654553

---

From: MikkelFJ <[email-masked]>
Date: Wed, 14 Nov 2018 00:56:16 +0000 (UTC)

> disabled for repeated connections between the same addresses.

Isn't this the part that is hard to coordinate when multiple processes handle different connections - though you could share a hash key.

-- 
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/pull/1982#discussion_r233280194

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Nov 2018 17:32:11 -0800

Yes, this is why I added the extra clause about connection ID.  That should give enough wiggle room for that sort of implementation strategy (which is indistinguishable from having a load balancer).

-- 
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/pull/1982#discussion_r233286658

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 13 Nov 2018 22:35:03 -0800

loganaden commented on this pull request.

@huitema this makes sense to me.

-- 
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/pull/1982#discussion_r233327485

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Nov 2018 12:38:00 -0800

1967291  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/c37f2ca69868398779ee0f20e7e09376d91920ef..1967291a24ee9abc6e4e5a40f0e92d8a8aa68799

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Nov 2018 12:38:26 -0800

a781397  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/1967291a24ee9abc6e4e5a40f0e92d8a8aa68799..a78139700a500c3a5dd0bed895f4038a87631937

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Nov 2018 12:38:49 -0800

aae19a6  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/a78139700a500c3a5dd0bed895f4038a87631937..aae19a69179b0b8b2454614e9cda21050f7c35bb

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Nov 2018 12:39:13 -0800

819ea0f  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/aae19a69179b0b8b2454614e9cda21050f7c35bb..819ea0f3d3f071287ac99ee9e36b7b97e8a61aa6

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Nov 2018 12:40:12 -0800

b748b8a  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/819ea0f3d3f071287ac99ee9e36b7b97e8a61aa6..b748b8aa246c8942332db6226aafd917c5956f17

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Nov 2018 17:07:56 -0800

martinthomson approved this pull request.

The suggestion is purely discretionary, I'm not sure we need it at all.  The proposed text, we definitely need.

> @@ -235,11 +235,19 @@ Implementations SHOULD allow administrators of clients and servers to disable
 the spin bit either globally or on a per-connection basis.
 Even when the spin bit is not disabled by the administrator implementations
 SHOULD disable the spin bit on a randomly chosen
-fraction of connections.  The selection process should be designed such that
-on average the spin bit is disabled for at least 1/8th of the connections.
-
-When the spin bit is disabled, endpoints SHOULD set the spin bit value to zero,
-regardless of the values received from their peer. Addendums or revisions to
+fraction of connections.
+
+The selection process SHOULD be designed such that
+on average the spin bit is disabled for at least one eighth of network paths.
+The random choice SHOULD be dependent
+on the source and destination addresses of the path,
+so that the spin bit is consistently enabled or
+disabled for repeated use of the same path.
+

```suggestion

Note that where multiple connections use the same path,
the use of the spin bit MAY be coordinated by endpoints,
recognizing that this might not be possible in many cases.
```

-- 
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/pull/1982#pullrequestreview-177792705

---

From: ekr <[email-masked]>
Date: Fri, 23 Nov 2018 11:01:55 -0800

ekr requested changes on this pull request.

I don't think you want this to be random but rather deterministic and unpredictable.

"The selection process should be externally unpredictable but consistent for any given combination of source and destination address/port. For instance, the implementation might have a static key which it uses to key a pseudorandom function over these values and use the output to determine whether to send the spin bit:".

With that said, is your thought that if there is migration the spin bit might suddenly start or stop working? If not, you need to rephrase this as being about the initial parameters.

+regardless of the values received from their peer.  Alternatively, endpoints MAY
+change this value when changing connection ID.  Addendums or revisions to

I have a number of problems with this text:

1. I don't think we need to specify anything
2. If we are to specify something, I would prefer it to be random on a per-packet basis.
3. The combination of SHOULD/MUST isn't even clear about whether other behaviors are permissible.

-- 
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/pull/1982#pullrequestreview-178010552

---

From: Christian Huitema <[email-masked]>
Date: Sat, 24 Nov 2018 10:24:32 -0800

The static 0 or 1 was pretty much a consensus in the previous discussions. People were not enthusiastic with the idea of firing the random generator for each packet for one bit. If you really insist, we could have a MAY that allows the random bit behavior.

-- 
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/pull/1982#discussion_r236049960

---

From: Christian Huitema <[email-masked]>
Date: Sat, 24 Nov 2018 10:28:47 -0800

My preference would be to make a policy decision to spin or not at the connection level, that is flip the coin based on the initial pair of addresses. But then, we also need a paragraph stating that the initial value of the spin bit is randomly computed for each path in a connection. If the policy decides to spin, this value will spin. If not, it will stay constant, to zero or one. 

-- 
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/pull/1982#discussion_r236050063

---

From: Christian Huitema <[email-masked]>
Date: Sat, 24 Nov 2018 10:30:11 -0800

... but I don't like allowing multiple behaviors, because of finger printing risks. What are yoy trying to achieve with a random spin per packet?

-- 
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/pull/1982#discussion_r236050097

---

From: ekr <[email-masked]>
Date: Sun, 25 Nov 2018 12:31:46 -0800

ekr commented on this pull request.

Well, as I said, I would prefer not specifying anything. As far as I can tell, there's no valid interop reason to do so. What I'm trying to avoid is having a characteristic "I am not doing spin bit" behavior that people anchor on, and "this is always 1" is totally that. Random is at least somewhat better.

As far as needing a PRNG, there's plenty of randomness floating around in packet processing. Specifically, because the PNE mask generation function generates 128 bits at a time.

-- 
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/pull/1982#discussion_r236088907

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2018 20:48:05 +0000 (UTC)

@EKR Removing text is easy, and I would be willing to do that if there is consensus. But I would like to hear another couple of voices advocating that -- say @martinthomson or @kazuho, who expressed opinions on the subject before.

As for PNRG,  it cannot be the PNE mask for the spin bit. The spin bit is protected by the AEAD checksum and has to be set before AEAD protection. The PNE mask is computed using the AEAD output, and is not available in time for randomizing the spin bit.  

-- 
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/pull/1982#discussion_r236089415

---

From: MikkelFJ <[email-masked]>
Date: Sun, 25 Nov 2018 12:48:23 -0800

You can't use the PNE mask for creating random data that is part of the data protected by AEAD tag because the PNE process might be offloaded to a separate process or hardware.

-- 
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/pull/1982#discussion_r236089425

---

From: ekr <[email-masked]>
Date: Sun, 25 Nov 2018 13:46:10 -0800

@huitema: this text is a PR, so it needs consensus to be added at all. As for the PRNG: you can use data generated from the PNE for a previous packet. As I said, there's plenty of surplus. I don't think that @mikkelfj's point is persuasive. Nobody is telling you how to generate random data. I am merely observing that it's effectively free to do so with most implementations.

Again, I think this document should remain silent on the contents of this bit if you aren't doing spin. My position is: silent > random > the current text.

-- 
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/pull/1982#discussion_r236091378

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2018 17:30:09 -0800

I am concerned with fingerprinting. If implementations invent their own scheme, than the observed patterns will identify the implementation, and that's a moderate privacy risk. The other issue is of course ossification. if middle boxes "learn" that there are a few one specific patterns for that bit. The current spec specifies a random constant, which does entail a moderate ossification risk.

Specifying nothing amount to trusting the implementations. That will probably lead implementers to copy whatever Google does, in order to not stick out. That may be fine. Specifying random would work if implementations were really using good random sources, but implementations have very often failed to do that. If they use a predictable pseudo-random pattern, they can be easily fingerprinted. 

I am looking at the "interop" reason. The main risk is that an overzealous receiver barfs because the spin bit is not what it expected. So maybe we should just say that endpoints that do not enable the spin bit MAY put whatever value they see fit, and MUST accept any incoming value.

-- 
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/pull/1982#discussion_r236102252

---

From: ekr <[email-masked]>
Date: Sun, 25 Nov 2018 17:50:04 -0800

I would be fine with what you propose here.

-- 
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/pull/1982#discussion_r236103807

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2018 19:39:56 -0800

a7a29c7  Do not specify disabled behavior.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/b748b8aa246c8942332db6226aafd917c5956f17..a7a29c7fe469dc48d9268d7bd2134df8f060d3cd

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2018 19:40:24 -0800

OK, I just updated the text by removing the specification.

-- 
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/pull/1982#discussion_r236114458

---

From: Martin Thomson <[email-masked]>
Date: Sun, 25 Nov 2018 20:45:14 -0800

Correction:

> this text is a PR, so it needs consensus to be added at all

That isn't the standard we've been holding to.  That will begin soon, but not yet.

As for the specific recommendation: I think that the concrete requirement is that the "spin/not" decision has to be made per-path, but the "how to not spin" decision is one best left to implementation discretion - other than perhaps recommending that the value does not leak any private information (about what is encrypted, or about what might happen on other paths for the same 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/pull/1982#discussion_r236120706

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2018 20:50:30 -0800

c02e357  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/a7a29c7fe469dc48d9268d7bd2134df8f060d3cd..c02e357fb757d831c25a8cca2a4f28e17cb1ee07

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2018 20:59:27 -0800

42d0aef  Specify predictable random behavior per connection

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/c02e357fb757d831c25a8cca2a4f28e17cb1ee07..42d0aef75b50a39899cc592d92a98ab01fca3d82

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2018 21:00:33 -0800

I replaced the random selection text by EKR's suggestion, and added a clarification that the choice is done once per 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/pull/1982#discussion_r236122189

---

From: MikkelFJ <[email-masked]>
Date: Mon, 26 Nov 2018 00:58:07 -0800

I don't like unspecified. Why not just set it to zero and apply the header protection mask bit that is otherwise not applied. This means AEAD sees it as 0, and middleboxes sees it as random. Setting it to anything else is not going to fool endpoints wrt. deactivated spinning. Using header protection mask also avoids PRNG issues in packet construction. Having to store extra PRNG state is just a burden and grows state.

-- 
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/pull/1982#discussion_r236165561

---

From: ekr <[email-masked]>
Date: Mon, 26 Nov 2018 05:22:56 -0800

> That isn't the standard we've been holding to. That will begin soon, but not yet.

This was in response to Christian's claim that there was consensus to do 0/1.

-- 
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/pull/1982#discussion_r236251222

---

From: ekr <[email-masked]>
Date: Mon, 26 Nov 2018 05:24:39 -0800

> I don't like unspecified. Why not just set it to zero and apply the header protection mask bit that is otherwise not applied. This means AEAD sees it as 0, and middleboxes sees it as random.

Assuming I understand this proposal, that means the peer would need to know if you were spinning or not, which is an anti-goal.

> Setting it to anything else is not going to fool endpoints wrt. deactivated spinning. Using header protection mask also avoids PRNG issues in packet construction. Having to store extra PRNG state is just a burden and grows state.

Not by any significant amount compared to the existing buffers you need to store

-- 
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/pull/1982#discussion_r236251772

---

From: MikkelFJ <[email-masked]>
Date: Mon, 26 Nov 2018 05:28:11 -0800

> Assuming I understand this proposal, that means the peer would need to know if you were spinning or not, which is an anti-goal.

You are right. So how to solve this. Random per packet is too obvious, fixed 0 or 1 (randomly) per connection/path also too obvious. It is at all possible to do 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/pull/1982#discussion_r236252879

---

From: ekr <[email-masked]>
Date: Mon, 26 Nov 2018 05:30:06 -0800

To do what? I'm not trying to make it impossible to determine whether an endpoint is spinning; I'm trying to avoid a constant 0 or 1 signal when we've elsewhere tried not to do that.

-- 
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/pull/1982#discussion_r236253534

---

From: MikkelFJ <[email-masked]>
Date: Mon, 26 Nov 2018 05:42:12 -0800

> To do what? 
Leaking that the endpoint is not spinning

But if you don't care about the endpoint finding out, why try to hide it. Maybe masking the bit requires more coordination than worthwhile - I am not too keen on this either, but alternatives are not really a lot better. Setting random per packet before AEAD would make it random on wire and would not require endpoint coordination, but it is yet another thing to deal with in header protection (tracking PRNG state to set a bit per packet). Leaving it undefined and unmasked would make the pattern arbitrarily detectable by middleboxes - fingerprinting as @huitema says - this is bad.

> I'm trying to avoid a constant 0 or 1 signal when we've elsewhere tried not to do that.

That is mostly on wire, no? TP values have lots of 0 signals by default.

-- 
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/pull/1982#discussion_r236257596

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Nov 2018 15:19:57 -0800

Yes, this would be on the wire.  We're talking about creating the impression that a particular value of the bit carries a particular meaning.

-- 
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/pull/1982#discussion_r236466090

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Nov 2018 17:05:17 -0800

I am going to mark this conversation as resolved, since the most recent commits address EKR review.

-- 
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/pull/1982#discussion_r236487004

---

From: janaiyengar <[email-masked]>
Date: Mon, 26 Nov 2018 22:57:42 -0800

janaiyengar approved this pull request.

-- 
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/pull/1982#pullrequestreview-178631665

---

From: MikkelFJ <[email-masked]>
Date: Tue, 27 Nov 2018 15:16:48 +0000 (UTC)

> @@ -239,14 +239,17 @@ fraction of connections.
 
 The selection process SHOULD be designed such that
 on average the spin bit is disabled for at least one eighth of network paths.
-The random choice SHOULD be dependent
-on the source and destination addresses of the path,
-so that the spin bit is consistently enabled or
-disabled for repeated use of the same path.
+The selection process SHOULD be externally unpredictable but consistent for
+any given combination of source and destination address/port. For instance,
+the implementation might have a static key which it uses to key a pseudorandom
+function over these values and use the output to determine whether to
+send the spin bit. The selection process performed at the beginning
+of the connection SHOULD be applied for all paths used by the connection.

It's unclear if "selection process" means that different paths can have different spin as long as the PRNG is done the same way, or the connection should reuse the result of the first selection.

-- 
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/pull/1982#pullrequestreview-178837938

---

From: mirjak <[email-masked]>
Date: Tue, 27 Nov 2018 15:34:42 +0000 (UTC)

mirjak commented on this pull request.

> @@ -244,11 +244,8 @@ on the source and destination addresses of the path,
 so that the spin bit is consistently enabled or
 disabled for repeated use of the same path.

Sorry to re-open this conversation but the spin should really be set to zero and not random per packet or anything like that because this makes it harder to impossible to detect valid spinning signals in the network and may render the valid spin signal useless for aggreates.

-- 
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/pull/1982#pullrequestreview-178848692

---

From: ianswett <[email-masked]>
Date: Tue, 27 Nov 2018 07:38:42 -0800

ianswett commented on this pull request.

I thought the agreement was that it SHOULD be set to a fixed value, but that value should vary by connection?  Or at least that was my understanding.  I don't think a MUST is enforceable, but a SHOULD seems appropriate.

-- 
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/pull/1982#discussion_r236718869

---

From: mirjak <[email-masked]>
Date: Tue, 27 Nov 2018 07:46:20 -0800

Correction for my side: it doesn't need to be zero but set to a fixed value. However the text saying this got removed. 

This is not enforcable but as a good citizian you should not try to disturb the spin signal provided by other flow and therefore I would even go for a MUST.

-- 
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/pull/1982#discussion_r236722714

---

From: erickinnear <[email-masked]>
Date: Tue, 27 Nov 2018 08:09:56 -0800

I thought removing that text was intentional, per the discussion above. If we wanted to change the outcome of that discussion, then I could maybe see a SHOULD, but based on that conversation I can't see it being a MUST.

-- 
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/pull/1982#discussion_r236734671

---

From: mirjak <[email-masked]>
Date: Tue, 27 Nov 2018 08:25:57 -0800

Sorry, I was on holidays and couldn't comment on the discussion above, that why I reopen this conversation. Also Brian is on parental leave, so he was also not able to comment. What I'm saying is that text should not have been removed. We can have more discussion about SHOULD and MUST.

-- 
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/pull/1982#discussion_r236742053

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Nov 2018 08:37:00 -0800

The question is what to do when a connection migrates to multiple path. There are two options: make a global decision to spin or not for the duration of the connection; or, make an independent decision to spin or not for each path. The text here intend to say, make a global decision.  

-- 
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/pull/1982#discussion_r236747086

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Nov 2018 08:38:27 -0800

I assume that this comment applies to the next paragraph, "When the spin bit 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/pull/1982#discussion_r236747778

---

From: erickinnear <[email-masked]>
Date: Tue, 27 Nov 2018 08:41:36 -0800

@huitema I think so, yeah. 
@mirjak Of course, I'm not saying that we shouldn't keep discussing, I just didn't want to copy/paste everything from above, so I referred back to that. 😃 

-- 
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/pull/1982#discussion_r236749281

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Nov 2018 08:58:26 -0800

+The selection process SHOULD be designed such that
+on average the spin bit is disabled for at least one eighth of network paths.
+The selection process SHOULD be externally unpredictable but consistent for
+any given combination of source and destination address/port. For instance,
+the implementation might have a static key which it uses to key a pseudorandom
+function over these values and use the output to determine whether to
+send the spin bit. The selection process performed at the beginning
+of the connection SHOULD be applied for all paths used by the connection.
+
+Note that where multiple connections use the same path,
+the use of the spin bit MAY be coordinated by endpoints,
+recognizing that this might not be possible in many cases.
+
+When the spin bit is disabled, endpoints MAY set the spin bit to any value,
+and MUST accept any incoming value.

This text reflects feedback from @ekr. There are two opinions there:

1) Many people, for example @mirjak, want to make it easy for observers to find which connections are spinning, so they can easily draw statistics from these connections. If you follow that logic, then you will say that when not spinning, the bit should be set to a constant value.

2) @ekr is concerned with middlebox behavior if we make it easy for observers to recognize whether a connection is spinning or not. His preference would be to specify nothing, or if we specify something specify that when not spinning the bit should be set to a random value.

Personally, I don't care very much. I believe that it is not very hard for a middle box to distinguish random from spinning -- average flip every 2 packets for random, every W packets for spinning. If observers can distinguish random behavior from spinning, then both arguments above become somewhat moot. 

The other side of this argument is "ossification", the risk of embedding of hardwired knowledge about bits in the middle boxes. From that point of view, "random" or "say nothing" are preferable, because they make it easier to ship a new meaning later.

As I said, I have no strong preference. But I wanted to make sure that @ekr's point was properly aired, and that whatever we put in the document reflects consensus.

-- 
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/pull/1982#pullrequestreview-178898177

---

From: ianswett <[email-masked]>
Date: Tue, 27 Nov 2018 17:06:14 +0000 (UTC)

Thanks for the summary.

My experience with ossification is that as long as it's not fixed across all connections, the likelihood of ossification is much lower.  But past experiences may not predict the future.  The 'QUIC bit' will likely be helpful as a single thing middleboxes can latch onto, possibly preventing more nefarious ossification.

I think leaving it completely unspecified has a cost.  Namely that I think either setting it randomly or setting a fixed value are safe, and other approaches could inadvertently leak information.  Previously I was concerned that setting it randomly could leak information, but people tell me that's not a real concern.  So if we're going to leave it flexible, I think we should add a SHOULD that if you're not going to spin, you should either randomize or pick a fixed value.  Martin made some clever suggestions previously that I was immediately able to infer loss and reordering from, so I think other options are prone to information leakage.

-- 
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/pull/1982#discussion_r236759398

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Nov 2018 09:15:58 -0800

So the proposed text would be:
```
When the spin bit is disabled, endpoints MAY set the spin bit to any value,
and MUST accept any incoming value. It is RECOMMENDED that they
set the spin bit to a random value either chosen independently for each packet,
or chosen independently for each path and kept constant for that path.
They MUST accept any incoming value.
```

-- 
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/pull/1982#discussion_r236763555

---

From: ianswett <[email-masked]>
Date: Tue, 27 Nov 2018 17:17:00 +0000 (UTC)

That works for me.

-- 
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/pull/1982#discussion_r236763949

---

From: MikkelFJ <[email-masked]>
Date: Tue, 27 Nov 2018 17:24:42 +0000 (UTC)

design by comittee ...

-- 
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/pull/1982#discussion_r236767022

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Nov 2018 17:27:10 +0000 (UTC)

@mikkelfj a.k.a. bikeshedding.

-- 
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/pull/1982#discussion_r236767935

---

From: erickinnear <[email-masked]>
Date: Tue, 27 Nov 2018 09:29:40 -0800

That proposed text works for me. Thanks for the great summary above too, @huitema.

-- 
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/pull/1982#discussion_r236768866

---

From: MikkelFJ <[email-masked]>
Date: Tue, 27 Nov 2018 09:30:51 -0800

If we use two bits for non-spin, we can also have a superposition of the two most recently spinning 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/pull/1982#discussion_r236769305

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Nov 2018 15:45:50 -0800

@huitema, can you make the edit based on [your comment](#discussion_r236763555)?

@britram, I know you are on leave, so we're inclined to merge this change so that this doesn't rot.  If you happen to think this is a terrible idea, we'll apologize and fix it later.

-- 
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/pull/1982#issuecomment-442262078

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Nov 2018 16:01:54 -0800

95b3380  bikeshedding the random spin bit

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1982/files/42d0aef75b50a39899cc592d92a98ab01fca3d82..95b33807a831a09a8db0730fd25c233b649d7ac7

---

From: Christian Huitema <[email-masked]>
Date: Wed, 28 Nov 2018 00:02:42 +0000 (UTC)

@martinthomson done.

-- 
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/pull/1982#issuecomment-442265737

---

From: mirjak <[email-masked]>
Date: Wed, 28 Nov 2018 02:23:56 -0800

Given that setting it random per packet or to a fixed value per path is both seen as acceptable and save, I strongly prefer to recommend the later. I dont' think that is it true that random values can be easily distringuished from valid signals because exactly those patterns in a valid signal where things look strange are often the interesting ones to detect problems, e.g. large amounts of re-odering. If you filter out random spinning connections and may also filter out exactly those cases you are most interesting of. 

-- 
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/pull/1982#discussion_r237022117

---

From: ianswett <[email-masked]>
Date: Wed, 28 Nov 2018 02:45:41 -0800

I understand that perspective, but I'm wondering if this is a detail that now needs to be brought ot the list to decide, since I think there are people who specifically want to randomize it?  What do you think @martinthomson ?

-- 
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/pull/1982#discussion_r237030144

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Nov 2018 20:43:48 +0000 (UTC)

i don't know if a must-level admonition will achieve consensus, but if the proposal is to recommend something, that's different

what i've gotten from this discussion is that we don't have consensus on having a specific mandate.  at least with the current text we are able to make forward progress.  i'd suggest that anyone who has a desire to argue for something more specific, they should go to the list, and maybe open an issue.  

-- 
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/pull/1982#discussion_r237252863

---

From: Lars Eggert <[email-masked]>
Date: Wed, 28 Nov 2018 12:52:48 -0800

larseggert commented on this pull request.

"1/8th of network paths" is unclear - how can an endpoint identify paths? I think what is meant is 1/8th of *peers*

-- 
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/pull/1982#discussion_r237255687

---

From: Lars Eggert <[email-masked]>
Date: Wed, 28 Nov 2018 12:54:24 -0800

I don't have a strong opinion, but at least Marcus seemed to believe that a random signal can be filtered out just as easily as a fixed zero or one.

-- 
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/pull/1982#discussion_r237256304

---

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

Yes, it's not hard to filter out, if your the goal/use case is to only get valid samples. However if you are interested in e.g. detecting large amount of re-ordering which will cause invalid samples within a flow that otherwise provides a valid spin signal, that would be harder to detect because re-ordering will also look like random noise. Therefore I would like to see us recommening a constant value. Of course we cannot enforce this and still have to handle noise, however, if the noise is low enough, it should still be fine.

-- 
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/pull/1982#discussion_r237270159

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Nov 2018 16:49:29 -0800

I see, your point is that it will be harder to distinguish between those who are spinning but encountering reordering and those who are just setting the value randomly.  Doesn't that wash out with time?  I mean, you need time to recover the spin signal anyway, so how much time do you need to discover that you are getting rubbish?

-- 
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/pull/1982#discussion_r237318285

---

From: mirjak <[email-masked]>
Date: Thu, 29 Nov 2018 00:47:53 -0800

I guess that depends on the heuristic you use. However, for a single flow you don't really have a recovery phase. Either you have a valid sample or not. If the base RTT didn't change, you should get a valid sample right after the re-ordering event is over. The interesting part is to observe the number of invalid samples. So for a single, long-lasting flow that you know has provided a valid spin signal previously, there is also no problem. What I'm worried about is if you monitor the invalid sample rate for an aggregate; especially if you have a lot of short flows, as you need more time to detect that a flow is spinning randomly than when using a constant value. Thus for short flows you may not be able make a decision in time and you have to filter them out. Given we have a lot of short flows on the internet, that can potentially strongly reduce your sample rate. Actually I would even prefer that disabled flows set the bit to 0 while enabled clients start with 1 because that would make it possible to have valid spin signals from he beginning. Still for any constant value, you can at least make a decision within about one RTT.

I mean this is certainly something to experiment with and the actual impact really depends on how many flows do what as well as the traffic patter of the flows. What I’m saying is that a constant value makes measurability at least a bit easier, and if there are no further concern about using a constant value, I would prefer if we recommend that.

My understanding of ekr’s initial comment was that he wanted to leave it open how to set the bit when disabled, as he didn’t see an advantage in (over-)specifying that behavior. Others were actually concerned that setting it randomly (if the randomness is not sufficiently provided) could enable fingerprinting. As such I don’t see a reason to not recommend a constant value when 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/pull/1982#discussion_r237395093

---

From: ekr <[email-masked]>
Date: Thu, 29 Nov 2018 05:07:54 -0800

I don't agree with this. I see a *disadvantage* in specifying the behavior to be fixed, which is that it makes discrimination against endpoints which used fixed values easier.

-- 
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/pull/1982#discussion_r237478800

---

From: Brad Lassey <[email-masked]>
Date: Thu, 29 Nov 2018 12:44:26 -0800

bslassey commented on this pull request.

One of the main concerns seems to be that an network could discriminate against a client that doesn't spin. For that reason, I think we should specify that an implementation that does spin should not spin for some percentage of clients. 

```suggestion
The selection process SHOULD be designed such that on average the spin
 bit is disabled for at least one eighth of clients regardless of destination.
```

-- 
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/pull/1982#pullrequestreview-180005138

---

From: Brad Lassey <[email-masked]>
Date: Thu, 29 Nov 2018 12:47:58 -0800

-this document MAY define alternative behaviors in the future.

```suggestion

-- 
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/pull/1982#pullrequestreview-180006466

---

From: Brad Lassey <[email-masked]>
Date: Thu, 29 Nov 2018 13:01:38 -0800

> @@ -235,12 +235,23 @@ Implementations SHOULD allow administrators of clients and servers to disable

```suggestion
The selection process SHOULD be designed such that on average the spin
bit is disabled for at least one eighth of clients regardless of destination.
The selection process SHOULD be externally unpredictable but consistent for
any given client. For instance, the implementation might have a static key which
it uses to key a pseudorandom function over these values and use the output to 
determine whether to send the spin bit. The selection process performed for the first
connection on a given network and SHOULD be consistent for all subsequent 
connections on that network.
```

-- 
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/pull/1982#pullrequestreview-180012097

---

From: Martin Thomson <[email-masked]>
Date: Thu, 29 Nov 2018 14:55:59 -0800

I would prefer to keep this as a per-path option.  Having it per-client means that some people will never spin and can thus be identified by that as they move around.  It's a low entropy signal, but one that would add to linkability.

That said, I don't think that having the same client exhibit the same spin behaviour on a given path when time passes is right either.  If implemented poorly, I could clear cookies and still be identifiable by whether I was spinning on a particular path or not.

Based on this, I'm going to advocate for dropping the consistency recommendation as well.  Can someone restate the problem we were attempting to solve with that?

-- 
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/pull/1982#discussion_r237690900

---

From: Christian Huitema <[email-masked]>
Date: Thu, 29 Nov 2018 15:03:19 -0800

This is the "server behind a proxy" problem. Clients connecting to that server from a dangerous place will most likely disable spinning for all connections to that server -- in fact, the server itself might do that. So you get a client/server address pair for which you never see spinning. You don't want that to stick out, so you need to ensure that there are other client/server address pairs that never spin.

-- 
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/pull/1982#discussion_r237692837

---

From: Martin Thomson <[email-masked]>
Date: Thu, 29 Nov 2018 15:07:27 -0800

It's more than that.  If I consistently spin or not for a given path then I leak some bits of entropy about whether I was the same entity last time I used that path.  And I leak that to everyone on the network.  Consistency => linkability.

-- 
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/pull/1982#discussion_r237693823

---

From: Christian Huitema <[email-masked]>
Date: Thu, 29 Nov 2018 15:10:53 -0800

By the way, just like Martin, I do not think that we should make this per-client. In fact, I don't think this is practical. Consider a device running Firefox, Google Chrome, and the Facebook app. Three different applications, each with their own stack, each managed their own way. You would have to count them as 3 clients. But then, their connections share the same IP source address. So what would disabling 1/8th of those achieve, exactly?

-- 
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/pull/1982#discussion_r237694554

---

From: Christian Huitema <[email-masked]>
Date: Thu, 29 Nov 2018 15:55:21 -0800

@martinthomson the text mentions making the decision based on the addresses for the path -- client address and server address. If the client changes location, it will change address, and the decision will not be correlated to what happens at different locations.

-- 
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/pull/1982#discussion_r237704043

---

From: Mike Bishop <[email-masked]>
Date: Thu, 29 Nov 2018 16:06:36 -0800

But unless the algorithm is specified, each of those implementations might choose differently.  Doesn't that affect things as well?

-- 
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/pull/1982#discussion_r237706274

---

From: Christian Huitema <[email-masked]>
Date: Thu, 29 Nov 2018 16:32:36 -0800

I sense we might be over engineering 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/pull/1982#discussion_r237710751

---

From: ianswett <[email-masked]>
Date: Thu, 29 Nov 2018 16:37:22 -0800

I think we have consensus on that.

-- 
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/pull/1982#discussion_r237711505

---

From: Martin Thomson <[email-masked]>
Date: Fri, 30 Nov 2018 01:16:17 +0000 (UTC)

That was my point.  In addition to the recommendation about stable decisions being over-engineering, I believe that it's a privacy risk, because it lets an observer link activity from the same location over time.  It's not a huge risk, but when we're so specific about advice, people will implement that and when that advice is potentially bad, that's not 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/pull/1982#discussion_r237717889

---

From: MikkelFJ <[email-masked]>
Date: Fri, 30 Nov 2018 19:02:30 +0000 (UTC)

Fingerprinting might be easier to track than stable decisions.

-- 
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/pull/1982#discussion_r237967337

---

From: Brad Lassey <[email-masked]>
Date: Fri, 30 Nov 2018 12:54:54 -0800

Agreed that this might be getting to prescriptive. Perhaps its best to call out the concerns to be addressed by implementers and leave it at that.

```suggestion
The selection process SHOULD be designed such that on average
the spin bit is disabled for at least one eighth of connections. The implementation
SHOULD take linkability across sessions where state would otherwise be cleared as well as
masking whether the client probabilistically spins or never spins into
account when designing the selection process.
```

-- 
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/pull/1982#discussion_r237999304