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

Matt Joras <matt.joras@gmail.com> Fri, 13 August 2021 16:51 UTC

Return-Path: <matt.joras@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50093A1F07 for <quic@ietfa.amsl.com>; Fri, 13 Aug 2021 09:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5mWgT-fmwy0 for <quic@ietfa.amsl.com>; Fri, 13 Aug 2021 09:50:59 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A339B3A188F for <quic@ietf.org>; Fri, 13 Aug 2021 09:50:58 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id y7so16531730ljp.3 for <quic@ietf.org>; Fri, 13 Aug 2021 09:50:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GbZdwGgN9mC1fluztswTyGeeETW0yOV/yhyBWDpMkBU=; b=aiM7+xsONoFROSS1JoVzVPw6vUDcUDi9hp2QAQA8AfzuYBAHLhlqeO654yPYjZBJIY XJQACDN6eoyqXWM2zDyti1gtZpxugaXUhmYcFjp538k9dvVKkuiZtRzS2MagPak2kzwi LYrRtadVr5TNELER9R/0jjkWbplMK+I1q4sIpq3eoSufON1csg67OWM9TgtbPuhFq5Zl LCL7iav5uw4IAN5VmpxL15JgKYosug89y+KklZStSDMI2M3OGyofVqW0tRuIhgJqdLk9 sX81i6LaoXgvvdUobcw4/LStUbY0qDzTLzSY5skfaaXTizrl0qEY0zT8nWdgjFVXFKdl qZCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GbZdwGgN9mC1fluztswTyGeeETW0yOV/yhyBWDpMkBU=; b=RvIYZDUXTCUqr93FynmB3+tANGTVf1EZb0B5ek8NiSEIZSStDg4SE81SZiBZ2LEZde 1+IEoTQpCb89IwNesKlJXl3REKTPaSJs1u97RLD3eVX7KbbzI70cQjKcDJt1+OL21XXE BMwyA+iprq5c9GBcHo1D9fCVTUq0dXc/Z7MJIK3rNLeTeq4Wywh5/KtHw+7y+8paERI8 7evg0d53F5Uq8haIOAl6aPPngrFs4h1+zOsvXD8HYswJdBzvA1hMCCsL4oxc0FTugVfr V02J9bld3LtjU2+qTiRLKkZ9GK12VL7slVphnfsd5RXjS5pDYzCZ3zriWSn3iJGZ4uLO H3+g==
X-Gm-Message-State: AOAM5304xcRZGqUd7JlACYHj0edJ9rAbv2JMVmiDK6IyhtaCk4uGVknb N5BZd+02TAe5Q/p9AVZ0u9JD0j/8QsxVUqCoGio=
X-Google-Smtp-Source: ABdhPJzFmrlSouPyENge1n1kaGjmgYZuni/HdSuLq0FygHaF0I+PnSAnwuFB2cCWVk69ah16FIdMtTZtC2hyr8F61Ok=
X-Received: by 2002:a2e:9a03:: with SMTP id o3mr2557037lji.428.1628873453836; Fri, 13 Aug 2021 09:50:53 -0700 (PDT)
MIME-Version: 1.0
References: <162883401993.25302.7275724432785172464@ietfa.amsl.com> <CANatvzxWrg+rciDpOZqsnDWq_oW_cr-Do2SjUzGgPy_vyAUs=Q@mail.gmail.com>
In-Reply-To: <CANatvzxWrg+rciDpOZqsnDWq_oW_cr-Do2SjUzGgPy_vyAUs=Q@mail.gmail.com>
From: Matt Joras <matt.joras@gmail.com>
Date: Fri, 13 Aug 2021 10:50:42 -0600
Message-ID: <CADdTf+gG83d5n3X2SxwxdV5o2H_z66EK7JdbafiPfaETh3tSxw@mail.gmail.com>
Subject: Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
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>
Content-Type: multipart/alternative; boundary="000000000000999bfb05c973a78b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ZBIbWsw_-aRq4_RLPv1RLKNhRMc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2021 16:51:12 -0000

Happy to see this work! Speaking as an individual:

One limitation of this sort of scheme (HTTP triggering and utilizing the
same connection) is that it won't be able to capture two classes of issues
that can be very problematic: handshake setup issues and mid-connection
"stalling" issues. The former I think it's pretty obvious why, as this
trace is triggered by an HTTP signal. As an example of the latter, consider
a bug where the server runs down its flow control or congestion control to
zero and can't recover. This ends up with the server being perpetually
blocked from sending anything, and both endpoints idle timing out. If a
client wants to trigger a trace and reproduce the issue then it will end up
not getting a trace at all, since the server is stuck. That's not to say
this kind of tracing isn't useful for other classes of issues, but these
are two serious ones we've had to diagnose with "out of band"
non-HTTP-triggered qlogs, and I wonder if we should also explore a
standardized mechanism for triggering those kind of traces.

Matt

On Fri, Aug 13, 2021 at 12: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
>