Re: Structuring the BKK spin bit discussion

Jana Iyengar <> Tue, 30 October 2018 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CFFC128BCC for <>; Tue, 30 Oct 2018 10:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3AEX0KA9YT5m for <>; Tue, 30 Oct 2018 10:55:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58F02127333 for <>; Tue, 30 Oct 2018 10:55:31 -0700 (PDT)
Received: by with SMTP id p17so3141178lfh.4 for <>; Tue, 30 Oct 2018 10:55:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8av/ek6NCT2D6EwKbWq13k9j0GkZW64J9cvS1YaBi5U=; b=okBerbXcbTA0WjQ9iRJX1nfbKAbbiCZwX3cH/ZPb/39Xco5VKq7l6AhYo+RScsmvaW kpA8/kPe6AKcMShlp5LaG2X67+nQp34hXVk7EdQRaE3aSCGBihgmfJpAIDjR/EQbeXqv xvOQcDZvoq+6Wr+1DPzeyfjIFIWaXsXfyjS8TPMPnCWlX+akwpQ4sdwuovlz4G6NSwRl R1HebRdw4DZA5UI/RnqNBaJoCY8kCQc02YIt+SfHT3XMEhrVdshpMxGNRExmmyWVgUfk hWxRKlQhXleKp/Fmm24r/AEMoiRpxedk5C/iVVgRRu+fFgDLrUdP/xgWHacYTQvllGYY tAZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8av/ek6NCT2D6EwKbWq13k9j0GkZW64J9cvS1YaBi5U=; b=TQNLmnk9oQs44hCmJfALAmfy3biY2MViR/VSZjHv75l9cazpJ2rtQBujjYwTWc6XAH TytnHJwBOYMlw3EVT68A7ejUes+t7hwGFB6VRbaRhZhA2APFEN2c+XAWIWtDtTnX7vAh zg9rCT43IeIrvtvnWUMREhqFAbQAKjN6UyEvzgeJ+DL7dE02NQ/fEXtaRGeUynVd/E06 HhCW58dznbH3eouRXSZpQNilgEyRTu40sDkXmsR7jvtz6J/SD3RJ17kL2Zoewq0t7aS2 D+Ynr5IMgvVWpLgf5TtD1PpuiEQFafjwR55vas9DzUm1RUhvszGAtoTBNcOWxX5+Khv1 Ng6Q==
X-Gm-Message-State: AGRZ1gIUI2ktpJbYY428tAX8vkyLR+efKl8fXjYpQKbUAm4sGxiFml3y jjmw0oFyRKOwKWo6qF4oNALTbrxlfQxWF7qWu4Q=
X-Google-Smtp-Source: AJdET5dolp75uq3bm0YdIO6oblCWQ3xXC7nqKilEJQTZndnJxc9oSaZUts34/MauCBjwjnsHBNzfUcE1uoxFyNxJMyw=
X-Received: by 2002:a19:1a41:: with SMTP id a62-v6mr2571613lfa.40.1540922129218; Tue, 30 Oct 2018 10:55:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <20181029160802.GD7258@ubuntu-dmitri> <> <> <> <> <DB6PR10MB1766E6B29792BB4401FF38F0ACCC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <> <>
In-Reply-To: <>
From: Jana Iyengar <>
Date: Tue, 30 Oct 2018 10:55:17 -0700
Message-ID: <>
Subject: Re: Structuring the BKK spin bit discussion
To: "Brian Trammell (IETF)" <>
Cc: QUIC WG <>, Mikkel Fahnøe Jørgensen <>, Marcus Ihlar <>, Christian Huitema <>
Content-Type: multipart/alternative; boundary="000000000000238240057975e42c"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Oct 2018 17:55:36 -0000

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

> 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 <>
> 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 <> On Behalf Of Mikkel Fahnøe Jørgensen
> > Sent: den 30 oktober 2018 08:01
> > To: Christian Huitema <>;
> > 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 <> on behalf of Christian Huitema <
> > Sent: Tuesday, October 30, 2018 5:27:47 AM
> > To:
> > 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 <>
> wrote:
> >
> > On Tue, Oct 30, 2018 at 3:54 AM Christian Huitema <>
> 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 to discuss
> this.
> >
> > -- Christian Huitema