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

Jana Iyengar <> Sat, 14 August 2021 02:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5AB83A314E for <>; Fri, 13 Aug 2021 19:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ac2ir1DfzTqM for <>; Fri, 13 Aug 2021 19:23:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 764E13A314D for <>; Fri, 13 Aug 2021 19:23:39 -0700 (PDT)
Received: by with SMTP id d6so18120750edt.7 for <>; Fri, 13 Aug 2021 19:23:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7zoNdVF9CDWRI3w8YmE9Xg2UrhQt1Q0zSy6rgOfnQ1A=; b=Rw1Ls1oHPvPLgTjoDEHToor9NaRkpMpKW/lTqNr5uKqe4EknLKlyfeashYwtNtqu1K Q4DR1udUpkVUd4buOWK6O6SkByvM42zTOnjRLVxUlBmLYEvbMGJRxrjDgPAJ9EuzTQYZ IWjGhfBoA8hv7nnMbNtpktQkrWzvT7FIPSAcjIRPPCYiKtRI7IUTmronEhqyjgOnAPVg kuvg4ju/gZY2MNutOyHM1n6qv8IcnkcLqSh2aGl7WTV7tskrPO3HzXHx1qaClXcMLOlQ UbM8R36HUjLb1P29EBI9u505mIuDXsXwjTL5d10+WMQIOnQOr5VPpv3QcLkgBHczYAWQ /5lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7zoNdVF9CDWRI3w8YmE9Xg2UrhQt1Q0zSy6rgOfnQ1A=; b=JnXUTkYvbH/S454u6fpFk68dyv00yIkH8KFAwHpum0usi9jTiTwOK88lMw4uUxf5bc N3Ey/SrHpVBIzf8gnULocHTSWvg5GmCoLRcsCCXDmOt3U05fRok+icXydLKFt1xmTm9b Su1R6zNdVbRhK/y0ZdrEL/s33SaV3GVozb3LeB598zEevCxMYIT84vFBormPN/u5LTta 4OcUWyAqHYAz6C9ld8vPw9VOOMKD50e8wvSwlt2gLoXIDWlMB+xcLelbhGHGB0ViSjSS YIllw9U7h0SjrVvYFDfzywKqNPPZD4Ov2V2nwoGHnmxaa7ZVxneT1XsaQenmQWW5DVuY bBtw==
X-Gm-Message-State: AOAM531w4X1zk7qXJpwPuyTsD4w/zM076bos0gOrlt8vx81M+lin0IKo mhSydB0utpco2FW7HYj0aCTnaYJOzJcd9Vvf12g=
X-Google-Smtp-Source: ABdhPJxitcId3L1++7Io7LSFlMu+fQk2zqWH/XZm86to0vyJHglSnaaQiSw1ddE7AixobrjFgMleqhFatv8nek4h1jg=
X-Received: by 2002:aa7:d3cf:: with SMTP id o15mr6680040edr.98.1628907816727; Fri, 13 Aug 2021 19:23:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Jana Iyengar <>
Date: Fri, 13 Aug 2021 19:23:25 -0700
Message-ID: <>
Subject: Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
To: Matt Joras <>
Cc: Kazuho Oku <>, IETF QUIC WG <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000c9b8cc05c97ba7a2"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Aug 2021 02:23:46 -0000


Both good points. These are limitations of this approach (and can be noted
in the document), but I don't know how you can get around these issues
using this mechanism.

For the HS issue, Robin suggested using a TP, and while specifying the
mechanism is easy, I'm not sure how useful it will be given that there's no
easy way to trigger that on a browser or web clients.

For CC/FC issues, you could ignore CC for specifically sending a message
that says "my available cwnd is 0", but you can't get around FC, since you
violate FC at the receiver and risk getting the connection closed. While
these  signals are useful, you can also infer them in 2 other ways:
(i) you stopped receiving data and traces. Presumably a client-side trace
can be gathered which should show BLOCKED frames being received.
(ii) it isn't too difficult to see a diminishing cwnd or rwnd in the trace
that has been received prior to getting blocked.

- jana

On Fri, Aug 13, 2021 at 9:50 AM Matt Joras <> wrote:

> 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 <> 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
>> We also have a public endpoint; to try it out, first open
>> (which starts
>> streaming a video), then open
>> 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: <>
>> Date: 2021年8月13日(金) 14:53
>> Subject: New Version Notification for
>> draft-kazuho-httpbis-selftrace-00.txt
>> To: Jana Iyengar <>, Kazuho Oku <>
>> 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:
>> Status:
>> Htmlized:
>> 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