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

[Kazuho Oku <[e-mail]>]

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