Subject: I-D Action: draft-ietf-quic-manageability-01.txt

From: [email-masked]
Date: Wed, 25 Oct 2017 01:11:58 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the QUIC WG of the IETF.

        Title           : Manageability of the QUIC Transport Protocol
        Authors         : Mirja Kuehlewind
                          Brian Trammell
	Filename        : draft-ietf-quic-manageability-01.txt
	Pages           : 13
	Date            : 2017-10-25

Abstract:
   This document discusses manageability of the QUIC transport protocol,
   focusing on caveats impacting network operations involving QUIC
   traffic.  Its intended audience is network operators, as well as
   content providers that rely on the use of QUIC-aware middleboxes,
   e.g. for load balancing.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-quic-manageability-01
https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-manageability-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Christian Huitema <[email-masked]>
Date: Wed, 25 Oct 2017 10:23:51 -0700

> 	Filename        : draft-ietf-quic-manageability-01.txt

I am reading your draft, and it seems that you are of two minds about
RTT measurements. On one hand, in section 3.5 about Round-trip time
measurement, you write:

   The lack of any acknowledgement information or timestamping
   information in the QUIC wire image makes running passive RTT
   estimation impossible.

On the other hand, in section 4.2 about Passive network performance
measurement and troubleshooting, you write:

   Extremely limited loss and RTT measurement are possible by passive
   observation of QUIC traffic; see Section 3.5 and Section 3.6.

Which is somewhat contradictory. Either the measurement is "impossible",
or it is "extremely limited".

We had lots of discussion about that in the ad hoc RTT measurement team,
and the conclusion was that measurement is limited, but by no means
impossible. In particular, it is trivially possible to estimate RTT
during the handshake period. This is limited when you consider an
individual connection, but it does provide a steady stream of
measurements when observing an aggregate of multiple connections. That
alone means that the word "impossible" is too strong.

Another outcome of the discussion in the ad hoc team was that any
measurement scheme requires some guessing about the behavior of the
application. This is also true for marking schemes like the spinning bit
or even the comparison of TCP sequence numbers and ACK numbers. One end
of the connection will send some data, and the other end will respond
after a delay. The observed end-to-end delay will encompass both the RTT
and the "response delay" by the application. That response delay can be
quite large when the application traffic is "sparse", such as for
example the RTCP stream in an RTP application. Even when one end is
sending continuously, the response delay is affected by "delayed ACK"
strategies. So any measurement scheme has to include some kind of
"application classifier" to guess the behavior of the application.

I believe that if you do include an application classifier, then you can
obtain RTT information by passive observation of encrypted traffic. You
can explore single stream time correlations as explained in the INRIA
paper, and you may also isolate question/response patterns. Granted,
this is a bit of research issue. But flatly saying that this is
impossible seems wrong.

-- Christian Huitema

-- 
Christian Huitema

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 26 Oct 2017 00:17:38 +0400

> On 25 Oct 2017, at 21:23, Christian Huitema <[email-masked]> wrote:
> 
> 
> 

Very briefly, in transit: "running measurement" -> more than one sample per flow. Measurement of this remains impossible, though you can probably guess, and there might be work to do on the size of the error bars on that guess. Maybe we can use better wording for "running" but I believe the statement to be sound.

Cheers,

Brian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Oct 2017 07:52:34 +1100

> Very briefly, in transit: "running measurement" -> more than one sample per flow. Measurement of this remains impossible, though you can probably guess, and there might be work to do on the size of…

It sounds like there is an opportunity for improvement.  You could say
that it is possible to acquire round trip time measurements during the
initial connection setup, but (some measure of difficulty, maybe
impossible) to do that on an ongoing basis for an established
connection without significant additional information about the nature
of the application protocol and possibly the specific implementation
of endpoints.  Correct is necessary here, but not always sufficient.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 26 Oct 2017 01:13:57 +0400

Sent from my iPhone

> On 26 Oct 2017, at 00:52, Martin Thomson <[email-masked]> wrote:
> 
> of endpoints.  

That seems like a better phrasing. But there is a tradeoff here: the point of favoring explicit measurement over implicit is to keep something simple like basic performance measurement from having an otherwise unnecessary “classify traffic” or “characterize application” step. 

> Correct is necessary here, but not always sufficient.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Oct 2017 08:19:07 +1100

> That seems like a better phrasing. But there is a tradeoff here: the point of favoring explicit measurement over implicit is to keep something simple like basic performance measurement from having…

Hmm, reading this again it almost reads like an exhortation to traffic
analysis.  Maybe I could be uncharitable and say that that is what
people will do, but maybe also that doesn't need to be written down.
"It's hard" might be enough.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 26 Oct 2017 07:04:56 +0200

Agreed. after a flight to think about it: if after the DT comes back in Singapore we end up with no signal that facilitates other-than-handshake RTT, it’s probably just best to point out handshake RTT measurement, and  to note that QUIC has no facility equivalent to seq/tsopt full stop, without any further commentary.

Sent from my iPhone

> On 25 Oct 2017, at 23:19, Martin Thomson <[email-masked]> wrote:
>

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Thu, 26 Oct 2017 14:38:02 +0200

Hi,

I really like the listing of which information QUIC exposes.
I have just one little question about it: Should Section 3 also state which information is exposed my the integrated TLS handshake?
AFAIK, the TLS handshake exposes the application protocol and host name in clear.
I am not sure whether it also exposes the initial QUIC connection parameters in clear.
 
AVE!
  Philipp S. Tiesel / phils…

> On 25. Oct 2017, at 10:11, [email-masked] wrote:
> 
>