Re: On the passive measurability of QUIC

[Spencer Dawkins at IETF <[e-mail]>]

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

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

hi ekr,

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