Re: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not)

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I need to read it more closely to understand the finer details, but my
immediate reaction is that I do not like this at all.

It appears to add unnecessary complication and there could be a host of
hidden security issues. The basic fact that someone other than the
endpoints can affect the traffic can lead to all sorts of issues and the
information transmitted might be abused in a number of ways, for example to
learn about the kind of traffic being sent, the internal layout of a
subnetwork by leaking presence of other middleware, the OS and applications
in use etc.

I much prefer a simple no-nonsense solution over trying to handle protocol
lifetime variations. The QUIC protocol could fix issues in new versions and
until then a simple predictable signal should suffice, even if it isn’t
perfect. This also makes middleware simpler, since a signal is always
present in a predictable manner.

We could have some fractal square waves to deal by having a short repeating
signal that periodically changes at different wave lengths, e.g. a a
repeating 8 bit pattern where each bit is flipped at the period of the wave
length it represents. That ought to be enough. The pattern repeats every 8
packets. The wave lengths could be 16, 32, 64, 128,  256, 512, 1024, 2048
so that same 8 bits are always transmitted twice before a bit changes which
should help synchronise it. It might not be perfect, but it ought to be
sufficient.

I’m also starting to think that just exposing a sequential counter per path
is much simpler even if it leads to ossification - see segment packet
number proposal https://github.com/quicwg/base-drafts/issues/1105



Kind Regards,
Mikkel Fahnøe Jørgensen


On 11 February 2018 at 17.51.37, Kazuho Oku ([e-mail]) wrote:

2018-02-11 2:34 GMT+09:00 <[e-mail]>:
> Then Kazuho's square signal and Mikkel's Pi (or any other consensual
> self-synchronizing sequence) ramification came up. They are both
appealing
> for their elegance and low complexity on QUIC endpoints. Beyond their
quirks
> acknowledged here, here are a few considerations for troubleshooting:
> (snip)
> Given these, a benevolent, troubleshooting-minded passive midpoint will
> clearly vote for the square. Now the obvious question is: is this
> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see
> upstream losses and benevolently wreak havoc by delaying packets ?

Thank you for raising the question.

While I think that using square wave is a neat idea, I am not so sure
if the wavelength is correct, or if it would continue to be correct
for the lifetime of the transport protocol. I assume that other
patterns that have been proposed (e.g., PI, random) share the same
weakness.

Therefore, I have written a proposal of a very different approach,
which is the following I-D.

Performance Metrics Subprotocol for QUIC
https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/

The I-D proposes to add a subprotocol that is used between an on-path
observer and the QUIC server to obtain the performance metrics. At the
latency of 1 RTT, the subprotocol can observe accurate upstream
loss/reorder rate, as well as SRTT / RTTVAR.

I believe that it is not difficult to implement on the server-side
(please refer to section 4). Client needs no change.

Since the proposed approach does not hard-code any information for
observation on the wire, the hard part of the design issue goes away.
We can adjust what (and how) to observe independently from the QUIC
transport. I think that this is not only a win in terms of design but
also might have positive effect on moving the standardization process
forward, since we would no longer be constrained by the discussion of
what should be observable "on-the-wire."

Privacy concern regarding observation becomes minor, since observation
becomes "observable" and deniable by an endpoint.

Although SRTT / RTTVAR is observable, I am not sure if it can be used
to replace the Spin Bit proposal. It depends on how often and how fast
an observer needs to see the metrics. Primary target of my proposal is
to help diagnosing issues.

Please let me know what you think.

---------- Forwarded message ----------
From: <[e-mail]>
Date: 2018-02-12 1:43 GMT+09:00
Subject: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt
To: Kazuho Oku <[e-mail]>



A new version of I-D, draft-kazuho-quic-perf-metrics-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name: draft-kazuho-quic-perf-metrics
Revision: 00
Title: Performance Metrics Subprotocol for QUIC
Document date: 2018-02-12
Group: Individual Submission
Pages: 8
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-quic-perf-metrics-00.txt
Status: https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/
Htmlized: https://tools.ietf.org/html/draft-kazuho-quic-perf-metrics-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-quic-perf-metrics-00


Abstract:
This memo proposes a subprotocol that can be used to query the
performance metrics of a QUIC path.




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.

The IETF Secretariat



-- 
Kazuho Oku