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

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

hi Kazuho,

Many thanks for the draft. I've had a quick look at it. I like the architecture it proposes -- hey, since the endpoints have full access to all of these parameters, why not just ask them? -- but I'm afraid I agree with the chorus of negative voices here that this raises too many new issues to really be workable.

We looked at something like this for PLUS -- a generic path-request mechanism allowing a middlebox to ask an endpoint for a value -- and decided to drop it from the proposal because the trust and DoS issues were just too hairy.

First, the mechanism adds up to 1RTT of delay, depending on the relative position of the requesting device and the endpoint it wants to request information from. Second, the reported metrics only have the resolution available from the queried endpoint -- as we've seen in our work with the spin bit, completely exposed signals don't suffer from this issue. But most importantly, adding a hook for on path devices to query endpoints adds significant complexity and attack surface, and seems extremely difficult to secure against collaborating malicious devices on-and-off-path.

One nice thing about purely passive signals is that we know what the information content is, we have a pretty good handle on how to restrict their design to reduce the risk of additional endpoint fingerprinting, and if we find the right tradeoff in endpoint complexity and measurement fidelity, can get a lot of win for minimal implementation effort and very little if any attack surface.

I certainly think measurement and debugging approaches where both servers and clients use existing mechanisms or extensions thereof (IPFIX or something like Prometheus on the server side; extensions to JS APIs for browsers or some other instrumentation on the client side) are a useful part of diagnosing issues with QUIC traffic; indeed, standardizing one or two of these would be a useful side project to reduce the shock widespread QUIC deployment represents to the hosting and web development communities. But neither scales very well to getting information to other-than-client and other-than-server entities.

Thanks, chsser,

Brian


> On 11 Feb 2018, at 17:51, 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
>