Re: Structuring the BKK spin bit discussion

["Brian Trammell (IETF)" <[e-mail]>]

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