Re: [ippm] [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)

Ian Swett <ianswett@google.com> Thu, 01 April 2021 13:42 UTC

Return-Path: <ianswett@google.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7093A1219 for <ippm@ietfa.amsl.com>; Thu, 1 Apr 2021 06:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 XIVQCpypFxgH for <ippm@ietfa.amsl.com>; Thu, 1 Apr 2021 06:42:21 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 919AB3A1221 for <ippm@ietf.org>; Thu, 1 Apr 2021 06:42:20 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id c8so1863722wrq.11 for <ippm@ietf.org>; Thu, 01 Apr 2021 06:42:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+2UkLBtPo+p0nwg8ZLw1r8AsJXAEkgdpwuCCaQFfmoI=; b=LnpvKkjpKlmlFdhDK5kEWik/JfRTwfoVVoH10RA3UdsIw5oV6c09KkIB19RSDiL7dD 8lOaKLk9PJXUMl4sTJKPa+Guo0g5NvB3AV0xwTESPmYOdOM9Ybh0eJf49CqRzpww9rLN Pie8EjX2NlkM3A3YN4v4jnZVw63kwcoHpl53RQHUdulze5UzjaXj6f+uNd5krtxRefxO RHvIGmJG5+zwdRE2vwmqNBgNIKOlpYEy0i2iE73D4ueFJH5QM3mfFwjt2Y7eMW5FQGdx AOdx4pctfeo7fcOlJSQkOqFsuuDkyO2EK9Dyd+rPhynWKnBVNyXD8/xUjQube+9M2q41 PjHQ==
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=+2UkLBtPo+p0nwg8ZLw1r8AsJXAEkgdpwuCCaQFfmoI=; b=cfB8/CzBg7aqb6adTkWoDdiqbiGuNBlNRDiJcFFPwDhvKCIIkMzT++XUAA3ei04Db4 66fXprSbbeBoDgtH1xzimQQ8ZPyIEQ+gh/L9HlRq1jV1Hqc4NFGIbpangl5F9uBiuxij Z7E77wOGRWoJEgBneQF1kOT60A71dR+dUxtdQkbxODEfc4yCz20EhmXnpO7Dixw++c0K ZWVGNJaazY2qbcmqJFpCePZ/lE1SyQhKMeEFJQ88nuJOZG5eB7exrTHoIO62wQJrnihQ uyah8lTJHjqaU5Ns6clkIQ0Hp6n2XAoYIVI58kCRCYQp2pnhrMC7iYofF03V5dCklmWV sfhA==
X-Gm-Message-State: AOAM532Y1eK1vOz6vhSHV8vR9j9ReOsYWS/dIrw+dJhJdiiGQIx/+TgM 5MKY1alf6u0rpRFIiYwzDJh9G8B5W9nf1ofjlg+qCQ==
X-Google-Smtp-Source: ABdhPJx/p7FXpCmShHZX/XV3hyf/mwlMPWhmUiqm4cr4/QkiY1A3xhHj1WOT3K3ZQS8viqEIfp5AmfN4W/50+AfCVTU=
X-Received: by 2002:a05:6000:c7:: with SMTP id q7mr9861620wrx.356.1617284537521; Thu, 01 Apr 2021 06:42:17 -0700 (PDT)
MIME-Version: 1.0
References: <8f60ffc8e0fd4376ba911c03f5c43039@TELMBXD14BA020.telecomitalia.local> <56398ea2e37a4a6ca53e85eb39add9a2@usma1ex-dag1mb5.msg.corp.akamai.com> <CAKcm_gNb-J59S3w806V4h2P_K5TkozRXNJCpNmMHbUcSOVjnUQ@mail.gmail.com> <CAKKJt-dXpDGF79_5HJ1aQanPyJBcPEizvKt4rJBJ2jsNthOaJw@mail.gmail.com> <8332062d02c04f40af1ed3baef49dafc@usma1ex-dag1mb5.msg.corp.akamai.com> <CAKKJt-f5OJdKGXrJPZffTLEd4UhhtfgJWCvXHRpNheVFKN9JjQ@mail.gmail.com> <5d60e177b8ee477fb6409a4a0d2af81a@huawei.com>
In-Reply-To: <5d60e177b8ee477fb6409a4a0d2af81a@huawei.com>
From: Ian Swett <ianswett@google.com>
Date: Thu, 1 Apr 2021 09:42:05 -0400
Message-ID: <CAKcm_gMBT441MHwaujNvq=G98YG8Z3FMGDdLTWjCzusY9DQRNw@mail.gmail.com>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "Lubashev, Igor" <ilubashe@akamai.com>, "explicit-meas@ietf.org" <explicit-meas@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, "HAMCHAOUI Isabelle IMT/OLN" <isabelle.hamchaoui@orange.com>, Cociglio Mauro <mauro.cociglio@telecomitalia.it>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005c896905bee96659"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/HLxQWtsuMrIcum1t-oUoabxPPz0>
X-Mailman-Approved-At: Mon, 05 Apr 2021 10:42:33 -0700
Subject: Re: [ippm] [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2021 13:42:26 -0000

Thanks Igor, the security considerations are definitely helpful.  I'm not
sure other working groups in the IETF(thinking QUIC) will find that
sufficient, but I agree that I don't have any specific concerns as an
individual.

I also agree that scoping this to a specific signal(loss) makes the privacy
implications possible to reason about, vs PLUS which was much more
expansive.

Ian

On Wed, Mar 31, 2021 at 1:49 PM Giuseppe Fioccola <
giuseppe.fioccola@huawei.com> wrote:

> Hi Spencer, Igor, Ian, All,
>
> It is interesting to look at the similar discussion for PLUS back in 2016
> and the related concerns about endpoints sending information to network
> entities.
>
> On the one hand, this draft describes several “explicit” measurement
> methods which send information to an on-path observer. But, on the other
> hand, it is worth mentioning that each one of the methods has different
> privacy implications. Different kinds of information are exposed to the
> on-path observer depending on which method is chosen.
>
> For example the Spin bit exposes an end-to-end delay metric while the
> sQuare bit exposes only endpoint-to-observer loss metric. So, in principle,
> it is possible to choose the method or the combination of methods based on
> the level of security that must be guaranteed.
>
>
>
> Regards,
>
>
>
> Giuseppe
>
>
>
>
>
> *From:* Explicit-meas [mailto:explicit-meas-bounces@ietf.org] *On Behalf
> Of *Spencer Dawkins at IETF
> *Sent:* Tuesday, March 30, 2021 11:44 PM
> *To:* Lubashev, Igor <ilubashe@akamai.com>
> *Cc:* explicit-meas@ietf.org; tsvwg@ietf.org; IETF IPPM WG (ippm@ietf.org)
> <ippm@ietf.org>rg>; alexandre.ferrieux@orange.com; HAMCHAOUI Isabelle
> IMT/OLN <isabelle.hamchaoui@orange.com>om>; Cociglio Mauro <mauro.cociglio=
> 40telecomitalia.it@dmarc.ietf.org>gt;; Ian Swett <ianswett=
> 40google.com@dmarc.ietf.org>gt;; quic@ietf.org
> *Subject:* Re: [Explicit-meas] Comparing Alternate Marking and Explicit
> Flow Measurements (Spin bit, ...)
>
>
>
> Hi, Igor,
>
>
>
> On Tue, Mar 30, 2021 at 11:11 AM Lubashev, Igor <ilubashe@akamai.com>
> wrote:
>
> Thank you, Ian and Spencer.
>
>
>
> Sorry for top posting (the thread could otherwise get a little long and I
> am using Outlook…).
>
>
>
> Ian, we did consider privacy implications of the markings. Because all
> markings and internal counters are completely reset when there is a CID
> change, we did not see the markings compromise linkability during
> migrations. Otherwise, since the markings are minimal, we see them only
> disclosing the information they are meant to disclose – upstream/downstream
> loss.  We do discuss privacy-related implications of disclosing
> upstream/downstream loss in
> https://datatracker.ietf.org/doc/html/draft-ferrieuxhamchaoui-quic-lossbits-03#section-8.
> However, the discussion in the ID is theoretical and is not a result of
> large global study whose results are confirmed by independent third
> parties. I would be happy to collaborate on this with an interested PhD
> student or another researcher.
>
>
>
> Spencer, I will review the PLUS minutes. In a setup when endpoints are
> sending information to unknown third parties, my immediate concern is less
> with the third parties being unknown and more with the extent of the
> information sent being unknown. After all, endpoints are already sending
> information to “unknown third parties” on path every time they communicate
> over the Internet. With the explicit measurements proposals, the set of
> “unknown third parties” is not changing. What endpoints must focus on is
> the information content of the signal. In any case, the abovementioned
> draft allows for endpoints to decide whether this signal is being sent AND
> ensures that a certain portion of all connections does not use this
> signaling (so connections explicitly opting out do not stand out).
>
>
>
> This was exactly the concern PLUS tripped over (IMO).
>
>
>
> The concern being expressed was that the PLUS format allocated a
> fixed-length field (IIRC) that did not define every bit in the fixed-length
> field, so in the mind of the SEC types, a (let's just say it out loud)
> mobile operator who also sends you your phone, so controls both ends, could
> start sending itself interesting bits of information without a user "opting
> in", OR knowing that they should be trying to "opt out".
>
>
>
> PLUS happened at IETF 96 (in 2016), and I'm guessing that we are doing
> more with automated updates in 2021 than we were doing in 2016 (also the
> year QUIC was chartered, although Google had been using gQUIC for several
> years previously, so "change the behavior after a browser upgrade" was on
> our horizon).
>
>
>
> One didn't have to be a mobile operator mailing you a cell phone to add
> interesting behaviors without you, the user, realizing that.
>
>
>
> Brian and Mirja would remember the details better (they were at the front
> of the room, while I was in the back, where ADs usually live).
>
>
>
> But that's what I was trying to describe. I hope it makes sense. And good
> luck. This was important work that we didn't know how to charter at the
> time (again, IMO).
>
>
>
> Best,
>
>
>
> Spencer
>
>
>
> Delivery of qlog to specific operators is possible, but it does not help
> much to locate the source of the loss/delay (upstream of the operator?
> downstream? in the operator’s own systems?) – the primary goal of this
> draft.
>
>
>
> Very best,
>
>
>
>    - Igor
>
>