Re: comments on the spin bit, in lieu of the mic line

Lars Eggert <lars@eggert.org> Tue, 06 November 2018 16:13 UTC

Return-Path: <lars@eggert.org>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B11124BE5 for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 08:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EEgq-vI_fEQ for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 08:13:55 -0800 (PST)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F313C12426A for <quic@ietf.org>; Tue, 6 Nov 2018 08:13:54 -0800 (PST)
Received: from eggert.org (unknown [62.248.255.56]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 797A4200C1; Tue, 6 Nov 2018 18:13:52 +0200 (EET)
Received: from [172.20.15.95] (unknown [103.40.147.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id C8384642F17; Tue, 6 Nov 2018 18:13:44 +0200 (EET)
From: Lars Eggert <lars@eggert.org>
Message-Id: <4116462A-D0E8-411A-89A8-983B9423F339@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_7A2E556B-9E39-4CAF-8D8E-E5DEC2D8D06A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Subject: Re: comments on the spin bit, in lieu of the mic line
Date: Tue, 6 Nov 2018 23:13:39 +0700
In-Reply-To: <31F20CF7-3B82-4856-B8AF-485117A10B7B@trammell.ch>
Cc: IETF QUIC WG <quic@ietf.org>
To: Brian Trammell <ietf@trammell.ch>
References: <31F20CF7-3B82-4856-B8AF-485117A10B7B@trammell.ch>
X-MailScanner-ID: C8384642F17.A1D79
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/VX9nm2MaGL5NygAqk0blaz9rKnk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 16:13:58 -0000

Hi

thanks Brian (and best wishes!)

If others who aren't going to be able to make it to the meeting, or who would prefer to make comments in writing would do so, that would be helpful in making sure we are receiving the full community input.

Lars

On 2018-11-6, at 23:02, Brian Trammell (IETF) <ietf@trammell.ch>; wrote:
> 
> Greetings, all,
> 
> As I might not make it to tomorrow's discussion remotely, I wanted to go ahead and say a few things that I would say in the mic line. To the questions posed in the agenda:
> 
> 
> - Yes, we should consider only the 1-bit variant. The VEC protects the fidelity of the signal very well (indeed, well beyond the bounds of network conditions the transport will tolerate), but (1) Marcus' work in particular has shown that even in challenging network conditions, relatively simple heuristics at the observers can compensate for not having it, so (2) at the cost of two extra bits the marginal value is low.
> 
> - Yes, the spin bit is clearly fit for purpose. I'll note we've done more research on this question than for any other single feature under consideration for inclusion in QUIC.
> 
> - I am not at this time responsible for any sizeable deployment, so I can't speak directly to the third question. While I hope we'll hear from more implementers during the discussion tomorrow that they intend to implement, IMO even just a deployment from Microsoft would be sufficient to generate enough spinning flows to make deployment of observers useful.
> 
> - The spin bit should be included in the specification. It provides the continued ability to measure RTT passively in a future world where TCP traffic is increasingly replaced by QUIC traffic, at negligible complexity cost, essentially zero runtime overhead, with negligible privacy impact, and what negligible impact it may have on privacy in certain corner cases can be easily mitigated.
> 
> - As to requirement levels, I'd stick with my own recommendation from the earlier thread: client and server SHOULD implement, though server SHOULD is IMO marginally more important than client SHOULD.
> 
> 
> Now some details (presuming, of course, that the discussion gets that far):
> 
> - In any case, both server and client SHOULD independently randomly disable spinning on some proportion of connections (1/8 to 1/16) to target a given proportion (1/4 to 1/8) of connections spinning, as in [section 4 of the author's copy of spin-exp](https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc..section.4). This is to ensure that those endpoints that wish to opt out have a large anonymity set to hide in.
> 
> - If we want to maintain the principle of linkability reduction across CIDs, then this non-spinning-state should be independent for each CID. In contrast to what's in section 4 of spin-exp, non-spinning spin bits shouldn't be set to zero, rather to a random value on a per-CID basis. This is easily recognizable by an observer in all cases (client/server participate/nonparticipate-1/nonparticipate-0), and reduces the risk of ossification around nonparticipant action. (This risk is small, to be sure, but we should not clamp a bit to a constant value, if only because we want the protocol's design to consistent.)
> 
> - As to whether non-spinning should be negotiated (see [the appendix in the author's copy](https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc.appendix.A)) versus "discretionary", I was originally a fan of negotiation (as it provides a better-than-greasing way to exercise the version negotiation mechanism), but the rules for maintaining the principle of linkability reduction across CIDs become more complicated for negotiated spin, and the benefits for observers (i.e., that an observer can classify flows by version) become far less clear in the face of that linkability reduction. So I would lean toward the discretionary approach for the sake of simplicity -- we'll just have to exercise version negotiation by shipping version 2 soon after version 1. ;)
> 
> 
> If I can't join, have fun tomorrow. Cheers,
> 
> Brian
>