Re: Structuring the BKK spin bit discussion

Christian Huitema <> Mon, 29 October 2018 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DA25131007 for <>; Mon, 29 Oct 2018 09:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3gQJeqx97ASu for <>; Mon, 29 Oct 2018 09:54:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01817127333 for <>; Mon, 29 Oct 2018 09:54:42 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <>) id 1gHAoI-00050t-UG for; Mon, 29 Oct 2018 17:54:40 +0100
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1gHAoB-0004fR-AM for; Mon, 29 Oct 2018 12:54:35 -0400
Received: (qmail 21957 invoked from network); 29 Oct 2018 16:54:28 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 29 Oct 2018 16:54:28 -0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <>
X-Mailer: iPhone Mail (16A404)
In-Reply-To: <20181029160802.GD7258@ubuntu-dmitri>
Date: Mon, 29 Oct 2018 09:53:22 -0700
Cc: Lars Eggert <>, IETF QUIC WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <20181029160802.GD7258@ubuntu-dmitri>
To: Dmitri Tikhonov <>
Subject: Re: Structuring the BKK spin bit discussion
Authentication-Results:; auth=pass smtp.auth=
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.30)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5ut4lLhpkcDzlxRJGCRtKWN602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViUdM2cv0uLcJB++IXjL6ofM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1VzUjpi3KNxdQZ39cmOPHk5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseygOIcx4SICe6nNcjjd/M50Y6QGVSvC9ATxEYI3bPwB8UgAvmhWj0Kt 6GdNtnBBpzNqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1Z+7sPmjIM3bM0ihYRE0YjPM ySEj7fwLz33nMnt8v2VACW4JJLnVejFxn/py1lO++mCP6KnOBvL4JpDTCrFGRy0l6PreDq/GwcsQ Fh1Do775kEu0bIDGx6Hc2akp+kPAbSHqAeeZGuerhbgzLuS7t5uWwhEJBPk7WpO8jVZh2VH4zM60 voqUUzJmvILAkkfgILwrzxcMEL7SnkJgQ5VKYC9Xgjmuntq3xZgBxhdNFJUcZu3d9ZNXJQW8HUxK X5uYJmvDK3PKrieG7T6bf9hS7hR0q7xASYaBUaOtmtSkj3iuxJhh7EHDojb6D9Mx+gs1+GHf4ys4 4rg2B8/9FmK9a1O9x7lsssuZ/53sObhu0YJN
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: Mon, 29 Oct 2018 16:54:46 -0000


> On Oct 29, 2018, at 9:08 AM, Dmitri Tikhonov <> wrote:
>> On Mon, Oct 29, 2018 at 05:26:34PM +0200, Lars Eggert wrote:
>> We'd specifically like to ask client and server implementors with
>> projected sizable deployments to indicate whether they intent to
>> implement and deploy, if the WG decided to include the spin-bit in
>> the spec.
> LiteSpeed Technologies will support the spin bit -- both in our
> server and client QUIC implementations -- if it make it into the
> draft.

My implementation is not used in any large scale deployment, but it does support the spin bit. In fact, it has configuration options to support spin bit variants: node, just spin, spin + vec, spin + QR. 

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.

The privacy issue could be mitigated by turning off the spin bit at privacy sensitive clients, but this would make these clients "stick out". 

One solution would be to remove the spin bit from the spec, trading off better privacy for worse management. I am considering another solution in which privacy sensitive clients hide the RTT by controlling the spin, for example spinning at fixed intervals. I plan testing that option in Picoquic.

-- Christian Huitema