Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt

[Mark Nottingham <[e-mail]>]

Hi Kazuho and Jana,

How does an intermediary understand when this request is directed at them? In particular, a CDN or reverse proxy, vs. the origin? Currently, the text says 'When a server receives a GET request at the Self-Trace Well-Known URI...' which includes intermediaries by definition...

>    To prevent this attack, servers SHOULD serve self-trace only when
>    HTTPS is being used.  The assumption here is that when HTTPS is being
>    used, end-clients are directly connected to the server.

I'm not sure that's a reasonable assumption; enterprise MITM proxies are pretty widely deployed. They may not currently implement h2 or h3, but that's not something we can rely upon.

Finally, just my .02 on naming - I think that 'connection tracing' is more evocative of what's going on, vs 'self tracing'. 'Self' implies a role (client, server, etc.), but that's not what's being traced.

Cheers,


> On 13 Aug 2021, at 4:14 pm, Kazuho Oku <[e-mail]> wrote:
> 
> Hello folks,
> 
> Today Jana and I have submitted a tiny I-D called draft-kazuho-httpbis-selftrace.
> 
> The draft specifies a well-known URI to be used for providing a trace of a particular HTTP/3 connection (e.g., qlog) on that same HTTP/3 connection.
> 
> One of the biggest hurdles in analyzing HTTP/3 performance issues is obtaining traces that show the symptoms. That is because clients being affected by issues have to coordinate with the server operators to collect the traces.
> 
> This PR solves the problem by defining a well-known URI for serving a trace to the client on the HTTP connection that the client is using. When a user sees an issue, they can collect the traces themselves and provide it to the server operator.
> 
> We have already implemented the feature in h2o, and doing so was easy, assuming that the underlying QUIC stack already defines callbacks for collecting trace events, see lib/handler/self_trace.c of https://github.com/h2o/h2o/pull/2765.
> 
> We also have a public endpoint; to try it out, first open https://ora1.kazuhooku.com/test/self-trace/video-only.html (which starts streaming a video), then open https://ora1.kazuhooku.com/.well-known/self-trace. While the video is being served, you would see the trace flowing through the well-known URI.
> 
> At the moment, we are using a custom JSON format for the trace, but when gzip compression is applied on-the-fly, the overhead of sending a trace alongside ordinary HTTP responses is less than 10%. Therefore, we tend to believe that this approach would work well in practice.
> 
> Please let us know what you think - your feedback is very welcome.
> 
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: 2021年8月13日(金) 14:53
> Subject: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
> To: Jana Iyengar <[e-mail]>, Kazuho Oku <[e-mail]>
> 
> 
> 
> A new version of I-D, draft-kazuho-httpbis-selftrace-00.txt
> has been successfully submitted by Kazuho Oku and posted to the
> IETF repository.
> 
> Name:           draft-kazuho-httpbis-selftrace
> Revision:       00
> Title:          Self-Tracing for HTTP
> Document date:  2021-08-13
> Group:          Individual Submission
> Pages:          5
> URL:            https://www.ietf.org/archive/id/draft-kazuho-httpbis-selftrace-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-kazuho-httpbis-selftrace/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-selftrace
> 
> 
> Abstract:
>    This document registers a "Well-Known URI" for exposing state of an
>    HTTP connection to the peer using formats such as qlog schema [QLOG].
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> -- 
> Kazuho Oku

--
Mark Nottingham   https://www.mnot.net/