Re: Structuring the BKK spin bit discussion

[Jana Iyengar <[e-mail]>]

Brian, (and Martin),

I like this structuring of the discussion, and I think it'll be good to use
this structure for the discussion in BKK.

- jana

On Tue, Oct 30, 2018 at 6:37 AM Brian Trammell (IETF) <[e-mail]>
wrote:

> hi Marcus, all,
>
> So let me step back a bit and suggest a starting point (borrowing heavily
> from MT in an offlist discussion) for discussing what we want to do in BKK.
> (Or rather, I should say, let me suggest a starting point for y'all to
> discuss, because I doubt I'll be in a position to join remotely at 03:00
> next Wednesday local time. Have fun! :)
>
> There seem to be three broad options we've discussed to date:
>
>
> - No spin bit. Grease it if we can't use it for something else.
>
> - "Discretionary" spin: reserve the bit for spinning, implementations
> MAY/SHOULD/whatever spin. MUST doesn't make any sense here, since there's
> no impact on end-to-end interop or the end-to-end properties the protocol
> guarantees.
>
> - "Negotiated" spin: reserve the bit for spinning, define two versions,
> one in which the endpoints MUST NOT spin the bit, one in which the
> endpoints MUST spin the bit. This has the nice property that negotiation of
> the spin bit is an actual exercise of the version negotiation mechanism,
> which will keep it flexible for future use better that greasing alone.
> (This was discussed in a thread after the NYC interim, but there's no text
> for it in spin-exp. I'd be happy to try and bang out a PR for it if that'd
> make it easier for people to understand/discuss in BKK.)
>
> Beyond this, there seem to be a few other qualities we want, and the
> details matter for these. The most important quality discussed is the
> maintenance of an anonymity set of non-spinning flows so that an endpoint
> that does not want to spin will not immediately stick out. So we can define
> some parameters that meet those qualities for both of the discretionary and
> negotiated variants. Let me propose the following values for these
> parameters, as a starting point for discussion in BKK:
>
>
> (1) No spin bit: no parameters. If the bit is reserved, it must be
> greased. (I'd submit that experimental use of the spin bit is a good form
> of greasing, so an implementation can offer discretionary spin if it likes,
> but without large-scale implementation, such experimental use is seen on a
> tiny minority of traffic and becomes a wholly academic exercise.)
>
>
> (2) Discretionary spin bit: here we want to determine compliance levels
> and participation probability. I'd suggest:
>
> - client SHOULD implement and server SHOULD implement (I acknowledge this
> is a personal preference; I suggest it because I think it will drive
> deployment better than MAY/SHOULD or MAY/MAY).
>
> - both client and server SHOULD allow the application and/or user/system
> configuration to force a given connection or set of connections to spin
> (for targeted diagnostic purposes) or not to spin. (This is a REALLY
> SHOULD, only because MUST on the interface doesn't make a lot of sense.)
>
> - in the absence of such configuration, both client and server SHOULD
> independently decide to spin the bit on a given connection with a set
> probability. I'd suggest probabilities at each endpoint of 7/8, so 3/4 of
> flows between implementing endpoints will expose RTT. This is a wild guess
> at a good starting point, though, picked to cause a large proportion of
> flows to spin even if only a small number of large implementations decide
> to implement; it is possible to set the recommendation smaller if it looks
> like the majority of implementations will spin. These proportions SHOULD be
> user/system/application configurable.
>
> - when not spinning, each of the client and server should randomly select
> a value for the spin bit for each new CID the duration of the connection,
> and send that value on every packet with that CID.
>
> This will ensure that even in a future with perfect deployment, the set of
> flows that aren't spinning because of deliberate configuration at any given
> time will have a large enough anonymity set to hide in. It also makes the
> job of recognizing non-spinning flows easy. In any case, it is important
> that all non-spinning flows (due to non-implementation, random choice, or
> deliberate configuration) non-spin in the same way.
>
>
> (3) Negotiated spin bit: same question. I'd suggest that the starting
> points be chosen to result in the same proportion of spinning bits as in
> discretionary case (2) above, so:
>
> - client SHOULD implement and server SHOULD implement (same comment as
> above)
>
> - both client and server SHOULD allow the application and/or user/system
> configuration to force a given connection to offer/accept to spin, or to
> not offer/refuse to spin.
>
> - in the absence of such configuration, the client SHOULD offer to spin
> (request the spin version of the protocol) with a set probability, and the
> server SHOULD accept an offer to spin with a set probability. Suggest 7/8
> as above, for target probability 3/4, same caveats.
>
> - when negotiated, both endpoints MUST spin the bit (as described in
> quic-spin-exp). If one endpoint detects the other is not spinning, it MUST
> terminate the connection, as this may indicate an error in the version
> negotiation mechanism itself.
>
> - when not negotiated, each of the client and server should randomly
> select a value for the spin bit for each new CID the duration of the
> connection, and send that value on every packet with that CID.
>
> The additional properties negotiated spin has with respect to
> discretionary spin are that it is a real exercise of the version
> negotiation mechanism, and that it provides an explicit signal to on-path
> devices that a given connection will spin.
>
>
> I suggest we try to start from these three points, separating the question
> of which pattern (none, discretionary, negotiated) we prefer, from the
> questions about the particular parameters applied thereto. Key is that we
> can tweak the parameters for either pattern to arrive at a given deployment
> curve and proportion of spinning bits in the network.
>
> Thanks, cheers,
>
> Brian
>
>
>
> P.S.: I'm not ignoring the "hold two other bits out for measurement
> experimentation" question, but I consider it to be an orthogonal question
> to these; I think it's worth discussing, but we can treat it separately, so
> we should. In any case I think the work you (Marcus) have done has shown
> that relatively simple heuristics at the measurement point deliver most of
> the benefit in terms of measurement fidelity in the presence of loss and
> reordering that the VEC can for realistic loss and reordering rates, for
> two fewer bits per packet. So the spin bit is worth doing on its own.
>
>
>
>
>
> > On 30 Oct 2018, at 12:55, Marcus Ihlar <[e-mail]>
> wrote:
> >
> > Making it more difficult to differentiate explicit opt-out from random
> opt-out is likely useful even if it doesn’t help in the particular Netflix
> case.
> > Furthermore, just like Brian points out it is necessary to grease the
> bit if we want to change the bit semantics later on.
> > I think the proposal has low enough complexity and potential benefits to
> be worthwhile.
> >
> > From: QUIC <[e-mail]> On Behalf Of Mikkel Fahnøe Jørgensen
> > Sent: den 30 oktober 2018 08:01
> > To: Christian Huitema <[e-mail]>; [e-mail]
> > Subject: Re: Structuring the BKK spin bit discussion
> >
> > In the Netflix case it just takes 16 connections by the same user, or
> less when multiple users originate from the sane IP range.. Is it really
> practical (and thus worthwhile) to hide probabilistically as in Huitemas PR?
> >
> > From: QUIC <[e-mail]> on behalf of Christian Huitema <
> [e-mail]>
> > Sent: Tuesday, October 30, 2018 5:27:47 AM
> > To: [e-mail]
> > Subject: Re: Structuring the BKK spin bit discussion
> >
> > On 10/29/2018 3:58 PM, Brian Trammell (IETF) wrote:
> >
> > hi Martin, Christian, all,
> >
> > On 29 Oct 2018, at 23:29, Martin Thomson <[e-mail]>
> wrote:
> >
> > On Tue, Oct 30, 2018 at 3:54 AM Christian Huitema <[e-mail]>
> wrote:
> > I think the strongest objection to the spin bit was put up by Marten
> during the last interim: measuring the RTT with the spin bit discloses the
> use of hidden path segments like VPN. This issue was not discussed during
> the privacy analysis.
> > I had assumed that was part of the analysis and it was covered by the
> > assumption that spinning could be disabled
> > +1. Probabilistically disabling spinning, which seems necessary if we
> want some grease to help us reserve the right to change the semantics of
> the bit at the spin bit's location in the wire image, should ensure that
> endpoints that want to disable spinning for their own reasons will have a
> large anonymity set to hide in, even in a future with perfect
> implementation and deployment of the spin bit.
> >
> > I opened PR https://github.com/quicwg/base-drafts/pull/1931 to discuss
> this.
> >
> > -- Christian Huitema
>
>