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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 30 March 2021 21:44 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: explicit-meas@ietfa.amsl.com
Delivered-To: explicit-meas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606EB3A0FC7; Tue, 30 Mar 2021 14:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eh7JabII_uiW; Tue, 30 Mar 2021 14:44:52 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 D67E23A0FC3; Tue, 30 Mar 2021 14:44:51 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id m132so18963753ybf.2; Tue, 30 Mar 2021 14:44:51 -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=cJDAeptqZCrjyVjKnCDTKSLrzDdIXTRB3txKTklAn9s=; b=NJZbTlIkZNPdbl5rmstX1Gqw8Gf04T/NMFcwitKMwdDzYieiXf4GoV8SQnyu6XeEwO fAFrKLD9g0rMMJEQZ1ibb7c8HIBFR4uSJc1leeNEKmUe0qgBnL6bVxwwxWulZo/OOhKF PDBa6OxyAHnoxhTuP7elGa3q68C6Jw1PmdufEwCzafLX3Rc7JRhJ0oRXlO2TcXRUmlen BpgtMGsAXgVKeWOMjOuYuMC1KLweNU4J3uX+gPKnLkD2Vfi0LQeWNmA/zK8VHk/aq40M mWXt6f3uwt4a4ktgo0gYxFhQG5U7pqk2e8TAniJ8cv8heLxBHn2vKFRGpUg6Xr/KSum5 +6dw==
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=cJDAeptqZCrjyVjKnCDTKSLrzDdIXTRB3txKTklAn9s=; b=Y0c72hgg0WHdegoIS9DDWgZ9LHh4e2ff+YMcHXkUEx8o8n/SOKbynhrIpDV/jJxZfZ quWWg9jnpvSjR+Xgp4pNBj5tV3Uj/wwoIJQ64ljBEwanQ4X+jPDu801PKrgD65sSr0RC U5/mhfoP74fPV+EDPJFVoyZ73/lU4WCFWw62DWcWDXhV4fUL68KaDiaP6SEfsJfI1Lmw sLqLjtFzq0jdq4tLLryrDQDGGhqZoKWKShZb8Ij+7AvMF2rXbduhRXOCWiotpizXOCup 8qx53dzApfBYBEJBqQzeQoxKobft3G9HBHoVZtebac40EPzzuVJW4Tm+0McTwygenGKC f7zw==
X-Gm-Message-State: AOAM53201hunD1KMYXqutuF6R0gltlatk9bkK5xwrqo3+eodg/p2UoIr sE5WzQqUx7T4061JEaMnhgOlqMTJ0ewTqJVS3tY=
X-Google-Smtp-Source: ABdhPJyZ3qFSTwhVA63ThXyrsxW27oNOS9BFTDbE+cKkbVG61WUScs/4k/ifXwSH5iWXkLkXCiq3QRpavX00m0e/Owc=
X-Received: by 2002:a25:1883:: with SMTP id 125mr337922yby.465.1617140690295; Tue, 30 Mar 2021 14:44:50 -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>
In-Reply-To: <8332062d02c04f40af1ed3baef49dafc@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 30 Mar 2021 16:44:24 -0500
Message-ID: <CAKKJt-f5OJdKGXrJPZffTLEd4UhhtfgJWCvXHRpNheVFKN9JjQ@mail.gmail.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, "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=40telecomitalia.it@dmarc.ietf.org>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000659fd605bec7e880"
Archived-At: <https://mailarchive.ietf.org/arch/msg/explicit-meas/5Vh_iMJ5rdnFygQtvK5a4CwrHHo>
Subject: Re: [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)
X-BeenThere: explicit-meas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This mailing list is intended for discussions relating to Explicit Flow Measurements Techniques." <explicit-meas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/explicit-meas>, <mailto:explicit-meas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/explicit-meas/>
List-Post: <mailto:explicit-meas@ietf.org>
List-Help: <mailto:explicit-meas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/explicit-meas>, <mailto:explicit-meas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 21:44:56 -0000

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
>
>