RE: On the passive measurability of QUIC

[Mike Bishop <[e-mail]>]

Regarding the billing question….  For mobile devices, I believe the major OSes support pushing policies to the clients that differently-billed traffic should be sent over a different APN.  We’re doing work in RS3 to enable more apps to hook into these policies and have their traffic correctly routed to the right APN.  (In previous versions, it was implemented in our HTTP stack and required extra work if you were using your own stack.) This might just be a problem that gets solved at a different layer, rather than via traffic inspection, and not something we need to cater to in QUIC (or TLS).

From: QUIC [mailto:[e-mail]] On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, June 6, 2017 6:33 AM
To: Brian Trammell <[e-mail]>
Cc: Eric Rescorla <[e-mail]>; IETF QUIC WG <[e-mail]>
Subject: Re: On the passive measurability of QUIC

So a couple of things, while wearing a couple of hats.

On Jun 1, 2017 10:07, "Brian Trammell (IETF)" <[e-mail]<mailto:[e-mail]>> wrote:
hi ekr,

> On 01 Jun 2017, at 15:55, Eric Rescorla <[e-mail]<mailto:[e-mail]>> 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.

As AD: this thread, like the spoofing thread, is the type of discussion on the management deliverable I was hoping the working group would have, when I agreed to approve the QUIC charter. Thank you.

I know this conversation isn't easy, and so does the rest of the IESG, and so does the IAB. We had high level discussions in this space on the joint IAB-IESG day of our retreat a couple of weeks ago, and the ADs continued that discussion during both days of the IESG retreat.

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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F166&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C88ec89b10e6644f53c1908d4ac952076%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636323203891635662&sdata=NzTkpTK%2FUwRJx695JPDH4WY6C7%2FEY0ikKVz2OD5Sd6Q%3D&reserved=0>. 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.

As a possibly helpful individual, this list seems to include implicitly what Erik mentioned explicitly in the spoofing thread - thinking about what trusts what, and what controls what. I thought that explictness would be helpful.

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.

As AD: this would be an especially useful assertion to converge on (after the interim, of course).

If QUIC isn't able to help with billing(*), that needs to not be a Late Surprise (tm).

Spencer

(*) Back to speaking as an individual, one of the responses that would not surprise me is "applications using QUIC aren't much harder to bill for than applications using TLS or TCPINC, so, whatever you do for those, do it for QUIC". If something like that turns out to be the answer, people who care about billing need to be figuring out what Plan B is ...

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