Re: Structuring the BKK spin bit discussion

[Kazuho Oku <[e-mail]>]

2018年10月31日(水) 7:55 Martin Thomson <[e-mail]>:
>
> On Wed, Oct 31, 2018 at 5:42 AM Christian Huitema <[e-mail]> wrote:
> > Mikkel is correct, we may not want a purely random per connection behavior, but rather something "random per destination". This would better mimic the opt-out behavior of a privacy-sensitive endpoint, which would always opt out when contacting a specific destination. If I had to implement it, I would not use a PRNG, but rather something compute the hash of a local secret and either the peer address or the peer name. That way, the client would opt out for all 16 Netflix connections, or for none of them.
>
> Or are we looking for random per-path?
>
> That notion would seem to tilt the balance more in favour of the
> "discretionary" option over the "negotiated" one on the basis that
> spinning/not doesn't become a linkability consideration.

Even though spin-bit is a per-path thing, I am not sure if the
probabilistic opt-out needs to be per-path. This is because what we
need to ensure is having at least some portion of QUIC packets flows
floating on each path not using the spin bit.

That can be achieved either by having QUIC endpoints turning off the
spin-bit for every path at a fixed probability, or by having them
turning off the spin-bit for every connection at a fixed probability.

-- 
Kazuho Oku