Re: Structuring the BKK spin bit discussion
Jana Iyengar <jri.ietf@gmail.com> Tue, 30 October 2018 17:55 UTC
Return-Path: <jri.ietf@gmail.com>
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 6CFFC128BCC for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 10:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3AEX0KA9YT5m for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 10:55:32 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F02127333 for <quic@ietf.org>; Tue, 30 Oct 2018 10:55:31 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id p17so3141178lfh.4 for <quic@ietf.org>; Tue, 30 Oct 2018 10:55:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <18A2F994-0E82-48E4-875D-93C674483D49@eggert.org> <20181029160802.GD7258@ubuntu-dmitri> <8268B90E-F109-424C-91A8-DB7BFE208F53@huitema.net> <CABkgnnU7W-_o_EGZWpJvTGRSm0KiL-hS7q_oQ6kT3LBoNKHGhw@mail.gmail.com> <5E1AB9AC-D24F-4E0D-9925-57816C5314A4@trammell.ch> <a088c411-1acc-8b0f-fc1b-8c79ce6f1cd7@huitema.net> <DB6PR10MB1766E6B29792BB4401FF38F0ACCC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <HE1PR0701MB23939472CAA7CC7C1CD42BB1E2CC0@HE1PR0701MB2393.eurprd07.prod.outlook.com> <2F288470-1659-4A8F-92BD-5640998917D8@trammell.ch>
In-Reply-To: <2F288470-1659-4A8F-92BD-5640998917D8@trammell.ch>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Tue, 30 Oct 2018 10:55:17 -0700
Message-ID: <CACpbDccPEkpdU0KW8iaUk=MKJwd2ptGRr09Z0ofKi+rOv9Ee0A@mail.gmail.com>
Subject: Re: Structuring the BKK spin bit discussion
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: QUIC WG <quic@ietf.org>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Marcus Ihlar <marcus.ihlar@ericsson.com>, Christian Huitema <huitema@huitema.net>
Content-Type: multipart/alternative; boundary="000000000000238240057975e42c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_rBq3Cjv1G_Uh0XW0-UlPc3PRs8>
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, 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) <ietf@trammell.ch> 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 <marcus.ihlar@ericsson.com> > 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 <quic-bounces@ietf.org> On Behalf Of Mikkel Fahnøe Jørgensen > > Sent: den 30 oktober 2018 08:01 > > To: Christian Huitema <huitema@huitema.net>; quic@ietf.org > > 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 <quic-bounces@ietf.org> on behalf of Christian Huitema < > huitema@huitema.net> > > Sent: Tuesday, October 30, 2018 5:27:47 AM > > To: quic@ietf.org > > 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 <martin.thomson@gmail.com> > wrote: > > > > On Tue, Oct 30, 2018 at 3:54 AM Christian Huitema <huitema@huitema.net> > 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 > >
- Structuring the BKK spin bit discussion Lars Eggert
- Re: Structuring the BKK spin bit discussion Dmitri Tikhonov
- Re: Structuring the BKK spin bit discussion Christian Huitema
- Re: Structuring the BKK spin bit discussion Martin Thomson
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Ted Hardie
- Re: Structuring the BKK spin bit discussion Christian Huitema
- Re: Structuring the BKK spin bit discussion Mikkel Fahnøe Jørgensen
- RE: Structuring the BKK spin bit discussion Marcus Ihlar
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Jana Iyengar
- Re: Structuring the BKK spin bit discussion Christian Huitema
- Re: Structuring the BKK spin bit discussion Martin Thomson
- Re: Structuring the BKK spin bit discussion Jana Iyengar
- Re: Structuring the BKK spin bit discussion Mikkel Fahnøe Jørgensen
- Re: Structuring the BKK spin bit discussion Kazuho Oku
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Kazuho Oku
- Re: Structuring the BKK spin bit discussion Ian Swett
- SV: Structuring the BKK spin bit discussion Marcus Ihlar
- Re: SV: Structuring the BKK spin bit discussion alexandre.ferrieux
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- RE: Structuring the BKK spin bit discussion Praveen Balasubramanian
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Roland Zink
- Re: Structuring the BKK spin bit discussion Mikkel Fahnøe Jørgensen
- Re: Structuring the BKK spin bit discussion Christian Huitema
- Re: Structuring the BKK spin bit discussion Kazuho Oku
- RE: Structuring the BKK spin bit discussion Mike Bishop
- Re: Structuring the BKK spin bit discussion Roland Zink
- Re: Structuring the BKK spin bit discussion Roland Zink
- RE: Structuring the BKK spin bit discussion Roni Even (A)
- Re: Structuring the BKK spin bit discussion Kazuho Oku
- Re: Structuring the BKK spin bit discussion Mikkel Fahnøe Jørgensen