Re: [ippm] QUIC concerns relating to draft-ietf-ippm-explicit-flow-measurements

Martin Thomson <mt@lowentropy.net> Thu, 11 May 2023 22:54 UTC

Return-Path: <mt@lowentropy.net>
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 799E8C16B5C6 for <quic@ietfa.amsl.com>; Thu, 11 May 2023 15:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b="VJUVvOjo"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="I8PwQZZE"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyTfxXvIieOh for <quic@ietfa.amsl.com>; Thu, 11 May 2023 15:54:12 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF54EC17B343 for <quic@ietf.org>; Thu, 11 May 2023 15:54:12 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A19055C0238; Thu, 11 May 2023 18:54:09 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute6.internal (MEProxy); Thu, 11 May 2023 18:54:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1683845649; x=1683932049; bh=Ik 01QvSIBu+8/sijLkL7bmoVIsfPInR2I1MUAmXXDi8=; b=VJUVvOjoueD5Nj/rtj t4kcvPapu7/K0ZQ44WyxQRKG7VMSt0uGJHrv3WdNKvdYLxzQOBPxN9YfA1tkJLgD VVM7aWL0BUU/ZJhzEf9LjILa6OsMwr1zQBOiKboV7tyiPlVgAxVFTW/xNDwZUzRF mL0kn7LNZ1KVLn37Xjlaf7GGGmqfFX9kSkP6+BNNzODep2CLfh7jeUFQ7AM5o5Na D8jU7m/qCOG/q3K+aqMES7cD0Dl55Hb2RXqAv3S0VSVOMjs5ZCXijRIwSAGOIbJp OQA9i4FE4PJWXGn7wxx5MyJgtrWRX8laPb14PiUcW9Y7L9x9PLKgqVT5Ol2bMTaT pT4Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1683845649; x=1683932049; bh=Ik01QvSIBu+8/ sijLkL7bmoVIsfPInR2I1MUAmXXDi8=; b=I8PwQZZEdFthSzKh4YmvPnfNv0pZP Z26g1luHmSDA+YnwYymfHGcBN91fQhcjx+rvA6gmczIOTqhqYkPkmmlBA5tfdtrx 57xdjMIeiSmS4igyBdrIRjsmlwZVnPZhKXL4Hl7KzZuRfoseS/1XgMnCwuMAyMqu WO05tYAMXz1+Y60dRV+A/kr+YEhEPUIMJT+lbHbZhQM3AWr+2rtgaqvz/O83O60e vCsvQcakXCQTogLSuRrfk9FVDT0PHOs5C2uWfJkkKZc8uaRY0iB6+HzOIBz5n3Ep iDspiMNUKT5xZMRr3QUJHBuqhXyUiHYSwNgv32iPPjziEL1DbyAmHFXTQ==
X-ME-Sender: <xms:EXJdZHK7PCOJWOHRjm2SwZw5YD9nNVs_C3QX9mI7ScnKTQbMupDcTA> <xme:EXJdZLJXUoIP_uiAVZfuzMWtWwePDtzKaLfqyAFT_FSVFKV9DSu62QssiFZ4upJu8 ME8ChWVJwRzPSptFjg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeegledguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:EXJdZPuaUaM5oefCX2ISDpG00vI70-VvcIYfFqa9Ei3WhsFtbAvgNg> <xmx:EXJdZAbrQ6mXfkT2uRuw2Dx6O7XE88Kle6-URjXH46k7NFcamIB4CQ> <xmx:EXJdZOY53jAs2s5xt0Y_bfWxqovzhPtqczY6UioW3R5YCJz-ALW00g> <xmx:EXJdZHD8WjAI_sPFN-b_iINWpgTUR9wqc7FzA0Kt4JY-rECpFT6IbQ>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 23238234007B; Thu, 11 May 2023 18:54:09 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-415-gf2b17fe6c3-fm-20230503.001-gf2b17fe6
Mime-Version: 1.0
Message-Id: <f7ee3a0d-c0f5-491f-a0f5-4fb41bb56ea8@betaapp.fastmail.com>
In-Reply-To: <4e85047d-2197-e75a-a665-211075925dad@huitema.net>
References: <CALGR9oZxFEXWD5hZZOJB7q+-f766FsjBGBTNjpuc1jyZyucz3Q@mail.gmail.com> <3103CBFB-5112-4FAC-A2F0-5209F52AB288@apple.com> <CALGR9oboNgFo-BA0Sqstog_JFPm+DL545VUSbksgF1chTnZ7VQ@mail.gmail.com> <791fd608-8112-bea7-9e22-5d0b8b9e8b1d@huitema.net> <5cf7edfcdf604f13b7fda36d206babfb@huawei.com> <18d470b2-ccfc-41a3-bbef-a572091502bb@betaapp.fastmail.com> <1cb7ab2a31394a19b20418ca7cd8ebb0@akamai.com> <4e85047d-2197-e75a-a665-211075925dad@huitema.net>
Date: Fri, 12 May 2023 08:53:48 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Christian Huitema <huitema@huitema.net>, "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>, "quic@ietf.org" <quic@ietf.org>
Subject: Re: [ippm] QUIC concerns relating to draft-ietf-ippm-explicit-flow-measurements
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/NILw45FiPKkfUHvXb8SCWc3CvAc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 11 May 2023 22:54:17 -0000

On Fri, May 12, 2023, at 01:21, Christian Huitema wrote:
> Igor is right. In fact, the "square bit" that he describes is 
> implemented in Picoquic, under an option negotiation.

It's not about whether endpoints could negotiate something that allows the use of these bits, it's about whether measurement systems are able to rely on that happening.

It's quite possible that some extension could be negotiated that creates a signal in these bits.  OK, so now you can deploy a measurement system that relies on that.  Most bits will be random, but some proportion will have the signal.  Enter statistical methods and you can recover some signal.

Well...almost.  This works until someone else decides to negotiate the use of those bits for carrying a different signal.  Now you have a harder statistical problem to solve.  Maybe you can boost your adaptation by observing connection initiation and looking for clients that advertise a certain version and set of transport parameters.

> The probability that these measurement features be turned on by default 
> is extremely low, and the draft should be very explicit about it, 
> including a description of the privacy/measurement tradeoff.

This is really the point of all this.