On the passive measurability of QUIC

[Brian Trammell (IETF) <[e-mail]>]

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.