Re: Spin bit discussion - where we're at

Ted Hardie <ted.ietf@gmail.com> Mon, 27 November 2017 18:30 UTC

Return-Path: <ted.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 65CE7129353 for <quic@ietfa.amsl.com>; Mon, 27 Nov 2017 10:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 ud3Nut5q2Byx for <quic@ietfa.amsl.com>; Mon, 27 Nov 2017 10:30:39 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 671A31272E1 for <quic@ietf.org>; Mon, 27 Nov 2017 10:30:39 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id c123so23317719qkf.7 for <quic@ietf.org>; Mon, 27 Nov 2017 10:30:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tACeR/e5YOgMCxqlHVAyWTHY9aZFt5TC52txKyBrVZM=; b=C9jvewxU7K3w7O5g5xyxQJBv0sZvrTO8xw6KYQDS6LCP7rkvV/FNCG/ox49RfLhMRS asvz4IK3cAa9u0pWivQCeaHWwN4rgs7p0hnWKVqe5MWbCzAR7v072kAga2Or3V6CZFqC qfVyQhcrXFI33YqSIMt5YHfxsPgxnJY30DDx4laFYE9AJBDIxb7aLl5/pyFwnuWv0eXS AEJ10x9kvSEfPoNxNArW0vtISLCBO/AJuOrXgeYOtdUopkc1aXX+YFH1fSol4bqL2fIo G3GIIWMZWjmvoFOwped0cNID/HcbRRLNcLFWyRkjnBbRo10+n2xnk5r0fvErdKTAXH6Z AzVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tACeR/e5YOgMCxqlHVAyWTHY9aZFt5TC52txKyBrVZM=; b=lIxJq9ke1Bk90sVLyjpnN4+QnzQJLjCIHZLRRBSmg26TI1O+sSirwDktmXNrMUs5C1 iT1DXtrf/SgsEwpbpC4UE9ooNHACQvy/UCJFKboMdiMkycQt+2i+EfUuypepSKTceaqx UgxTxXd8U2NKVeEOzMKkbI3akGut3rZXx7pYjNl/zPQr2Ks+QvUfW4JkUULd79aScvgT pbsRFjLTsE9XYBG0GBL34f+7kl5gCBStDlFIWpXeD9QWQx3DZXaiX3E/9TnlPzSqnh7d oNJ8SIOa9m7Ct2RV1dRe9B1D9S8DomhQSixhVlpCdcjp8gn0ZRHFg3GPtXEkgESlTFzX 0h6g==
X-Gm-Message-State: AJaThX5nxxqSMV7+5G7ecqGcQ7mPJ6Eh3fYEkX9H0/B6AD2f//V7IZ/P DsWaT7kFm+fyylJl/XuuAKHuoAndXPHvu1DXayO1oA==
X-Google-Smtp-Source: AGs4zMYIpvZEU4eUfw0dB1HQ3ixItNupEySwCc6Q22SSqIv+kpyvtUpStudPRyIUTugWJr61JIV0KGDXuqGHLZQ61o0=
X-Received: by 10.55.60.12 with SMTP id j12mr46759248qka.232.1511807438344; Mon, 27 Nov 2017 10:30:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.36.169 with HTTP; Mon, 27 Nov 2017 10:30:07 -0800 (PST)
In-Reply-To: <CAGD1bZbYjB96nc1ud3xmSm8g6jHhPYpeT=iWWQiZxRzzyVvdRw@mail.gmail.com>
References: <AFEE7BBA-E5DC-4064-AA19-33921EAF4C01@mnot.net> <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <fd09b775-4c0e-9d99-e49c-421212f2e5e4@cs.tcd.ie> <F4F7A438-F30F-406B-9971-DA05DA458B44@netapp.com> <C8DDB9E3-C8F9-49CB-8C6D-E381C00AC02D@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <CAGD1bZbYjB96nc1ud3xmSm8g6jHhPYpeT=iWWQiZxRzzyVvdRw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 27 Nov 2017 10:30:07 -0800
Message-ID: <CA+9kkMBW8TGMorOBi7qHSWkc9QAyKSfRp8SkYpfC82v9QEPZRw@mail.gmail.com>
Subject: Re: Spin bit discussion - where we're at
To: Jana Iyengar <jri@google.com>
Cc: "MORTON, ALFRED C (AL)" <acmorton@att.com>, "Brian Trammell (IETF)" <ietf@trammell.ch>, Mark Nottingham <mnot@mnot.net>, QUIC WG <quic@ietf.org>, "Eggert, Lars" <lars@netapp.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="001a114a125654d7e5055efb1950"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cZ-ltyIHeW4Zvvsu6ai1po4w7j4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 27 Nov 2017 18:30:41 -0000

Howdy,

On Sun, Nov 26, 2017 at 11:03 PM, Jana Iyengar <jri@google.com> wrote:

> In addition to how the spin bit can be designed and used, I'd like those
> taking on this effort to consider this question: Whatever network
> management problem you're considering solving with a bit, what does it take
> to solve this problem without the bit exposed? I'm asking you to consider
> "zero-bit" solutions, or at least for a cost/benefit analysis of developing
> solutions with and without the spin bit for specific network management
> functions. Specifically,
>
> (i) What's impossible or very difficult to do, from a network management
> perspective, of not having the spin bit? Note that I'm not asking for what
> is and is not measurable -- not everything measurable is useful. I'm
> specifically asking in terms of network management functions, in practice,
> as used by operators. Some of this has been addressed in the
> discussions/drafts I've seen, but I think it's most useful when framed in
> terms of network management functions.
>
> (ii) What are the alternatives for building the same functions without the
> spin bit? Let's consider for a moment that the spin bit isn't actually
> available in practice. What will operators do to continue managing their
> networks? This might be expensive, but that's precisely what I'm looking
> for -- the cost to operators of not having the spin bit. For instance,
> active probes are a fine way to measure network RTT within operator
> networks, and that is an alternative. There are surely others too. Their
> costs and limitations are important to know about in order to reason about
> their viability, so I'd like to see alternatives considered.
>

I think the trade-offs here are harder to assess than this request
implies.  Let's imagine, for a moment, that the operator chooses to use the
coloring methods described in
https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark .  There are
clearly expenses required for this and those might be higher than the
expenses for analyzing a QUIC-marked spin bit (with some variation,
depending on whether you do or don't require synchronization).  But the
other side of the assessment is the privacy assessment of this method.  If
an operator begins using this method, the very nature of the packet
coloring exposes the same data as the QUIC-marked spin bit does (and a bit
more because of the countable packet sets in flights).

Unless the replacement measurement uses purely synthetic flows, in other
words, it will also have privacy implications and, potentially, performance
implications.    Asking for a full-field analysis of all the options here
is not a reasonable task, at least in my opinion.  I think the best we can
realistically do is compare this against nothing (no bit and not
replacement effort), against synthetic flows (a.k.a. active measurements),
and against one or two systems either already deployed or fully described.


> I don't mean to start the discussion on this thread, but I'd like to urge
> those going off to do the writing to consider these questions.
>
>
While I am happy to consider the questions, I hope you are equally happy to
bound the universe of "alternatives for the same function" to be
considered.  Without doing so now, we run the risks of the goalposts
receding ever out of sight.

regards,

Ted



> - jana
>
>
> On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) <acmorton@att.com>
> wrote:
>
>> Hi Brian, Stephen, Lars, Mark and all,
>>
>> one join, one suggestion, and one question below.
>> see [ACM]
>> > -----Original Message-----
>> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell
>> > (IETF)
>> > Sent: Wednesday, November 22, 2017 5:59 AM
>> > To: Eggert, Lars
>> > Cc: Mark Nottingham; QUIC WG; Stephen Farrell
>> > Subject: Re: Spin bit discussion - where we're at
>> >
>> > hi Lars,
>> >
>> > > On 22 Nov 2017, at 11:35, Eggert, Lars <lars@netapp.com> wrote:
>> > >
>> > > Hi,
>> > >
>> > > On 2017-11-22, at 11:01, Stephen Farrell <stephen.farrell@cs.tcd.ie>
>> > wrote:
>> > >> What I thought was being requested and what I do think is reasonable
>> > >> is to document a privacy analysis for any quic protocol bits that are
>> > >> visible to the path. Whether or not some or all of that text ends up
>> > >> in some RFC is another day's work.
>> > > Lars wrote:
>> > > for the Spin Bit specifically, the intent was to permanently capture
>> > the analysis the DT has done, so that when others review the proposed
>> > Spin Bit specification, they can take that as a given and direct any
>> > further analysis to other aspects. It made sense to the chairs that that
>> > specific analysis should become part of the Spin Bit specification. I
>> > think we'd be open to a discussion on whether a broader document
>> > analyzing the QUIC wire image would be a better home for this. The main
>> > point is for the work that the DT has done to be documented.
>>
>> > Brian wrote:
>> > Okay. That's somewhat more reasonable than what I read the ask to be
>> > ("we're going to gate this on the people who care about this doing some
>> > non-trivial amount of work"). Those of us who volunteer (help, please,
>> > anyone? :) ) can certainly pull together what we have in a single I-D
>> > and ask the WG what more it thinks it needs. To me all this seems pretty
>> > clear, but I've been working on this topic for a while.
>> [ACM]
>> Having reached the end of the "Thanksgiving thread",
>> I'm scrolling back a few pages to join the task of
>> permanently capturing the work of the DT in an I-D (at least):
>> There should be lasting value in some of our findings
>> and IMO they are worthy of a persistent reference.
>>
>> > Lars wrote:
>> > > For proposals other than the Spin Bit (I think I have seen individual
>> > contributors at least mention "loss" and "congestion" bits, but without
>> > much detail), we wanted to clarify that we'd like to see an analysis and
>> > discussion of their privacy aspects to roughly the same degree as the DT
>> > has performed for the Spin Bit proposal.
>> >
>> [ACM]
>> I suggest that this might be a different I-D, at least to start.
>> Question: Is there a privacy analysis of present ECN available?
>> (a search yielded many results with Missing: privacy)
>>
>> regards,
>> Al
>>
>>
>