Re: On the passive measurability of QUIC

"Brian Trammell (IETF)" <ietf@trammell.ch> Thu, 01 June 2017 15:07 UTC

Return-Path: <ietf@trammell.ch>
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 A1C0B12ECA3 for <quic@ietfa.amsl.com>; Thu, 1 Jun 2017 08:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 qmOtT9lgMg3C for <quic@ietfa.amsl.com>; Thu, 1 Jun 2017 08:07:15 -0700 (PDT)
Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC29112ECA7 for <quic@ietf.org>; Thu, 1 Jun 2017 08:07:14 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 554BF3407BA; Thu, 1 Jun 2017 17:07:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.25229); Thu, 1 Jun 2017 17:07:12 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 1 Jun 2017 17:07:12 +0200 (CEST)
Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19411720; Thu, 01 Jun 2017 17:07:09 +0200
Subject: Re: On the passive measurability of QUIC
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_6106A0B7-D75B-4513-8E7A-46AAA8D46667"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
In-Reply-To: <CABcZeBPZR2+YjN6TGP=GJqGqJS4p9-LVi=-KWkSA8+USkJ1VfA@mail.gmail.com>
Date: Thu, 01 Jun 2017 17:07:07 +0200
Cc: QUIC WG <quic@ietf.org>
Message-Id: <ADD9E4FC-C337-42F4-A5DD-517B4BCF15BF@trammell.ch>
References: <FCCAC281-BC7B-4E4B-AC34-9517FD336A65@trammell.ch> <CABcZeBPZR2+YjN6TGP=GJqGqJS4p9-LVi=-KWkSA8+USkJ1VfA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/wIt_g1V7yeUgImwAnddIV0c85r8>
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: Thu, 01 Jun 2017 15:07:18 -0000

hi ekr,

> On 01 Jun 2017, at 15:55, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> I like the general framing of these questions, but it's pretty hard to address them in
> the abstract. Rather, I think it would be more useful to start not with the specific properties
> but rather with the *services* that collecting these measurements is intended to facilitate
> and then work forward to the various baskets of measurements you would need to
> support said services and from that try to make a cost/benefit analysis [0]. Do you or
> someone else have such a list of services?

Sure. Here are the ones I know about off the top of my head. Note here, for "services", I understand "higher-level measurement activities", or what would be called "solutions" on the marketing-heavy websites of the vendors who build these boxes. Please correct me if I'm wrong here. "Service" is unfortunately so overloaded a term as to be unclear in many cases, even with context.


1. Access network performance measurement. This is largely the problem the LMAP WG is chartered to address, using IPPM metrics. Here, peak achievable throughput (of an access link), loss, latency, and (sometimes) jitter are the metrics of interest, both in controlled testing (active measurement) as well as passive measurement of user traffic, on the theory both that accidental and intentional differential treatment of measurement traffic will make active measurement unreliable, as well as to reduce network load due to unproductive active measurement traffic. Loss/congestion and latency are the primary passively measurable metrics of interest here. This measurement activity is used by network operators for capacity planning and troubleshooting purposes, as well as by national and supranational regulatory agencies to hold network operators within their jurisdictions accountable. The deployment location changes depending on who's performing the measurements, but it's generally run as close as possible to the access link (for broadband access) or on the handset itself (for mobile measurements).


2. Interdomain troubleshooting of network performance issues. See https://github.com/quicwg/base-drafts/issues/166. Though it proposes a mechanism, it clearly calls out the key metrics as packet loss and congestion, with the ability to localize congestion using multi-observation-point measurement as important.


3. Service performance monitoring (my example here was Boundary, which is apparently called bmc TrueSight Pulse (tm) now) uses passive network-level latency and throughput measurements to augment information collected by agents running on servers themselves to isolate performance issues on those servers.


4. Perimeter security monitoring of access and enterprise networks. Related to work in the DOTS WG, which focuses specifically on the DDoS mitigation aspect of this broad topic. This is largely concerned with detecting and blocking attack traffic. Most of the measurement task in this case is classifying traffic as benign or not, and it uses any input available to make that determination. None of the metrics I talk about in the previous message are really relevant here, though -- spoofed traffic detection is more useful in this context than latency. It's relevant to QUIC, though, in that one of the inputs to this classification is whether traffic is TCP or not: the more likely QUIC traffic is to be classified as default-benign, the better its deployability on networks employing this monitoring.


The obvious one mentioned in our charter, for completeness:

-1. Billing, both for metered consumer-grade access as well as transit contracts. This is -1 because it's not really relevant to transport protocol design, as it generally doesn't require anything beyond byte/packet count per billable user, where the billable user is usually associated with something that happens below layer 3, zero-rating and other such practices notwithstanding.


> -Ekr
> 
> [0] Where the cost clearly has to include future unknown privacy risk.

Evaluating an unknown risk is a pretty cool trick. ;)

Seriously, though, I'd really appreciate any suggestions you would have as to how to concretely evaluate this risk, at least for purposes of comparison of proposals. Information theoretic metrics seem to me to be not very useful here, since they make the implicit (and false) assumption that all bits of entropy are equally potentially dangerous to privacy.

Thanks, cheers,

Brian