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

If I might top-post, I had thoughts about a couple of things people said at
various points in the thread ...

   - Kazuho, thank you for submitting this proposal.
   - I agree that this concept doesn't need to be tied to qlog, even if
   initial implementations use it with qlog.
   - I see that people have provided questions and concerns. It seems
   simpler to have those conversations if the well-known URI is described
   separately, and at a high level, and other specifications describe specific
   usages and how the concerns would be addressed in specific usages.
   - I would hope that it would be easier for operator types to engage in
   discussion about a general capability, and I can imagine that people
   looking at a description of the general capability might propose additional
   usages that we might not have thought of, because we're thinking about the
   qlog usage.

Best,

Spencer


On Fri, Aug 13, 2021 at 1:15 AM Kazuho Oku <kazuhooku@gmail.com> 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: <internet-drafts@ietf.org>
> Date: 2021年8月13日(金) 14:53
> Subject: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
> To: Jana Iyengar <jri.ietf@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
>
>
>
> 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
>