W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

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

From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Sat, 14 Aug 2021 23:18:30 -0500
Message-ID: <CAKKJt-dYxmkzqO-XSkG+-k-5bywzBjnkdAQWNZeO7ZfdgfFYYg@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Jana Iyengar <jri.ietf@gmail.com>
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.



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
Received on Sunday, 15 August 2021 04:19:10 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 15 August 2021 04:19:12 UTC