Subject: On the passive measurability of QUIC

From: Brian Trammell (IETF) <[email-masked]>
Date: Thu, 1 Jun 2017 15:42:18 +0200

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.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 1 Jun 2017 06:55:10 -0700

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 <[email-masked]> wrote:

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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 1 Jun 2017 17:07:07 +0200

hi ekr,

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

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.

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

---

From: Dave Dolson <[email-masked]>
Date: Thu, 1 Jun 2017 17:42:15 +0000

And I have just uploaded https://tools.ietf.org/html/draft-dolson-transport-middlebox-00

as an update to what I presented in Chicago, attempting to incorporate feedback from the microphone and email.

Abstract

   This document summarizes benefits that operators perceive to be

   provided by intermediary devices that provide functions apart from

   normal IP forwarding.  Such intermediary devices are often called

   "middleboxes".

   RFC3234 defines a taxonomy of middleboxes and issues in the Internet.

   Most of those middleboxes utilize or modify application-layer data.

   This document primarily focuses on devices that observe and act on

   information carried in the transport layer, and especially

   information carried in TCP packets.

   A primary goal of this document is to provide information to working

   groups developing new transport protocols, to aid understanding of

   what might be gained or lost by design decisions that may affect (or

   be affected by) middlebox operation.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

     1.1.  Operator Perspective  . . . . . . . . . . . . . . . . . .   3

     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4

     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   5

   2.  Measurements  . . . . . . . . . . . . . . . . . . . . . . . .   5

     2.1.  Packet Loss . . . . . . . . . . . . . . . . . . . . . . .   5

     2.2.  Round Trip Times  . . . . . . . . . . . . . . . . . . . .   6

     2.3.  Measuring Packet Reordering . . . . . . . . . . . . . . .   7

     2.4.  Throughput and Bottleneck Identification  . . . . . . . .   7

    2.5.  Congestion Responsiveness . . . . . . . . . . . . . . . .   7

     2.6.  Attack Detection  . . . . . . . . . . . . . . . . . . . .   8

     2.7.  Packet Corruption . . . . . . . . . . . . . . . . . . . .   8

     2.8.  Application-Layer Measurements  . . . . . . . . . . . . .   9

   3.  Functions Beyond Measurement: A Few Examples  . . . . . . . .   9

     3.1.  NAT . . . . . . . . . . . . . . . . . . . . . . . . . . .   9

     3.2.  Firewall  . . . . . . . . . . . . . . . . . . . . . . . .   9

     3.3.  DDoS Scrubbing  . . . . . . . . . . . . . . . . . . . . .  10

     3.4.  Implicit Identification . . . . . . . . . . . . . . . . .  11

     3.5.  Performance-Enhancing Proxies . . . . . . . . . . . . . .  11

     3.6.  Network Coding  . . . . . . . . . . . . . . . . . . . . .  12

     3.7.  Network-Assisted Bandwidth Aggregation  . . . . . . . . .  12

     3.8.  Prioritization and Differentiated Services  . . . . . . .  13

     3.9.  Measurement-Based Shaping . . . . . . . . . . . . . . . .  13

     3.10. Fairness to End-User Quota  . . . . . . . . . . . . . . .  14

   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14

   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14

   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14

     6.1.  Confidentiality . . . . . . . . . . . . . . . . . . . . .  14

     6.2.  Active Attacks  . . . . . . . . . . . . . . . . . . . . .  15

     6.3.  More Information Can Improve Security . . . . . . . . . .  15

   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15

     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  15

     7.2.  Informative References  . . . . . . . . . . . . . . . . .  16

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

-Dave

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Brian Trammell (IETF)
Sent: Thursday, June 1, 2017 11:07 AM
To: Eric Rescorla
Cc: QUIC WG
Subject: Re: On the passive measurability of QUIC

hi ekr,

> On 01 Jun 2017, at 15:55, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

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

Thanks, cheers,

Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 5 Jun 2017 23:32:56 -0500

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

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

hi ekr,

address them in
intended to facilitate
[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.

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

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 6 Jun 2017 09:19:16 +0000

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:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, June 6, 2017 6:33 AM
To: Brian Trammell <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: On the passive measurability of QUIC

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

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.

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.

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.

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

Thanks, cheers,

Brian

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 6 Jun 2017 18:19:48 +0100

See my little postscript at the end.

On 06/06/2017 10:19, Mike Bishop wrote:
> 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:[email-masked]] *On Behalf Of *Spencer 
> Dawkins at IETF
> *Sent:* Tuesday, June 6, 2017 6:33 AM
> *To:* Brian Trammell <[email-masked]>
> *Cc:* Eric Rescorla <[email-masked]>; IETF QUIC WG <[email-masked]>
> *Subject:* Re: On the passive measurability of QUIC
> 
>     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).
> 
> 
>     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.
> 
> what Erik mentioned explicitly in the spoofing thread - thinking about 
> what trusts what, and what controls what. I thought that explictness 
> would be helpful.
> 
>     -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.
> 
> (*) 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
>      >
>     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
> 

I wrote this draft also:
https://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-transport-encrypt-01.txt

- It's not so much about middleboxes that change things, as about boxes 
that look at things. Some of this may be relevant to this thread. It's 
not specifically about QUIC, but I suspect that was what I had partly in 
mind as I tried to understand the implications of encrypting teh cntrol 
information.

Gorry