Re: On the passive measurability of QUIC

[Eric Rescorla <[e-mail]>]

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?

-Ekr

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

On Thu, Jun 1, 2017 at 6:42 AM, Brian Trammell <[e-mail]> wrote:

> Greetings, all,
>
> Here's a second, longer list of requirements questions I think we should
> ask directly:
>
>
> "To what extent should the design of QUIC support passive measurement of
> QUIC flows?" [1]
>
>
> There is one measurement task specifically called out in the text on
> manageability in our charter: "the ability to export information about
> flows for accounting purposes". To the extent that this process can map IP
> addresses to accountable entities, this is trivially supported by layering
> on top of UDP and IP. Accounting processes may additionally seek to
> classify traffic as QUIC or not-QUIC, which they can do as of -03 if they
> observe the 1-RTT handshake (or, simply, make the assumption that udp/443
> is always HTTP over QUIC). Which leads to the first related subquestion:
>
> 1. "Should QUIC packets / flows be distinguishable from non-QUIC flows on
> the wire?"
>
> Other accounting processes, of course, will want to classify applications
> atop QUIC, but I won't even ask that question. It's precluded by our
> charter: TLS over TCP (without STARTTLS) does not expose any
> application-layer protocol identification, except via server port number.
>
> Determining which other measurement primitives we want to support, IMO,
> requires a survey to determine which are actually used in network
> operations. Within IPPM and LMAP, the metrics that get the most attention
> are packet loss, latency, jitter, and throughput. I also asked a vendor of
> IPFIX collecting devices which passive TCP measurement information elements
> are most often exported by passive measurement boxes, and
> loss/retransmission and RTT were at the top of the list. So, two more
> subquestions:
>
> 2. "Should end-to-end latency of QUIC flows be measurable by observation?"
>
> and
>
> 3. "Should end-to-end packet loss, or reactions to loss, of QUIC flows be
> measurable by observation?
>
> Related to loss, but not yet widely deployed or measured, is explicit
> congestion notification. We anticipate growth in ECN deployment related to
> widespread and growing client- and server-default negotiation of ECN for
> TCP, and as such, I'd add the following related question:
>
> 4. "Should end-to-end congestion, indicated by explicit congestion
> notification, or reactions thereto, of QUIC flows be measurable by
> observation?"
>
> Passive measurement today is done by inference on information
> non-optionally exposed by the transport stack. We have the opportunity to
> change that with QUIC. Following the priniciples in [1], I'd therefore ask
> the following final question:
>
> 5. "What level of control over observer capability should be available to
> end users, application developers, and application and transport protocol
> implementors?"
>
>
> As with the spoofing question, it'd be useful IMO to try and stay off
> mechanisms for now, and to focus on desirability, and what cost we're
> willing to pay (and not to pay) for these properties of measurability.
>
>
> Thanks, cheers,
>
> Brian
>
> - - -
>
> [1] Way too much background on this in a paper in the April 2017 ACM CCR
> (I'm a coauthor); arXiv version at https://arxiv.org/abs/1612.02902 --
> the principles described there are IMO useful to guide thinking about any
> measurability we do build into the protocol.
>
>