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

Mark Nottingham <> Sat, 14 August 2021 02:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E9693A3202 for <>; Fri, 13 Aug 2021 19:44:10 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Rcsdv3t1; dkim=pass (2048-bit key) header.b=GW0iZ/j2
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R-OSywrFDAQO for <>; Fri, 13 Aug 2021 19:44:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C9E53A3169 for <>; Fri, 13 Aug 2021 19:44:04 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 6E93A5C004F; Fri, 13 Aug 2021 22:43:58 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute3.internal (MEProxy); Fri, 13 Aug 2021 22:43:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=U gl5YWsr7j/vwc//MF47b7A16UqGAcMmUwK7tM+hVgQ=; b=Rcsdv3t1Q88GU9kJj M1va/dtl5UVPmxueejlFOQY4h3RwCBjXKXRgjJq/3ysSeUBHB+Dcu5mfBLX6Mm2i eVsOD1ja9WnrETbhiBLdPL3F1NZRDGC1AJua/4L+D+fjb0puGTJs7oEGucLIjv/9 f0P6Dc2v+ulu1OkkstCG7ollvGgj3JSqFB4jNlQ7LTbNNmJ+hvQYMnzQKc1S1wUz 6EPRwKKupbxpSujExKSTM5hUIMbuxidJyFcsEwBgytSpBNvL90DDJD0jA/CuOtNC dihhOqBHnx/5g2YN0ft5eQYKzGLM8NFVeRudlyRFf9SnmNuXa/ztl/ed9jxTWtgC /IKAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Ugl5YWsr7j/vwc//MF47b7A16UqGAcMmUwK7tM+hV gQ=; b=GW0iZ/j27+GTR09oYSacLDexkeOduS0PRIxoYvytux+iKZcUY66tOWsIo aDfHdyzfnLcU+hXiFd9yIQ76unbHZ1tchgZtb5bpUuvjfl0xaBzuOjYzbyrItZnH IHjRm2X0k1Xyf0JKZ3fevNWHXediHFSu2adiNJXDwP4d5aK0OWtSjoG2pmml3hvl LT/PgeeiEFIfi1AKjJ9W5icEMUi8nJwckLdMTzJdf5Ez7k36saYJitdtOWk8nmv9 Fi/KY2r/JGqA3n8WV72cDzBjVua0sKzQOVFGG0JDrgtPsB7RKj2v7NsYAlOAJPqJ qSsmxYLbG+osPbr4uuYOpuIv+/Ybw==
X-ME-Sender: <xms:7C0XYeMUNJXV9UbbqkCrwTXTNbD_A8SG_BrYMf4D0SnP1Snzotzuiw> <xme:7C0XYc_yKrXke9kcLaa8ySwDDtDyMqNmZwuzjc_KiuxIPnHcTKP9_x9-39eP5nrPe oATfMgIENtq9hP5lA>
X-ME-Received: <xmr:7C0XYVS0owl-IQMARIC7wEhXX03-NkSaOaRnUcImYNh6M3_gJGdX3jw6Aj7FkNilgI_YeotwqM7IaVDPs1FDmwuC2qtMR8iqO5YSBL9pWO3F2sI-A5rKnCDw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrkeeigdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepiedvjeeugffhffeghfeugedtkeffveehjeejtefghfefudejjeetffevheehjeff necuffhomhgrihhnpehhthhtphhsihhssggvihhnghhushgvuggvnhguqdgtlhhivghnth hsrghrvgguihhrvggtthhlhigtohhnnhgvtghtvgguthhothhhvghsvghrvhgvrhdrihhm pdhhthhtpheftghonhhnvggtthhiohhnrdhonhgvpdhgihhthhhusgdrtghomhdpkhgrii huhhhoohhkuhdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:7C0XYeurComqzYJqIFygJfnrlCjW65tbrHXQtLzVehxhx0OrOgX8GA> <xmx:7C0XYWcZ6HKWe-dtwXgr1CB15B9WCcfC9beB2JgjWeqyNQuMS5b0iQ> <xmx:7C0XYS33f7F0txGQTY97NLP3YuWERpHFlJ9bDPguysM55Qdem4aVJQ> <xmx:7i0XYTFJueMc8bPIriZybWlJ7lu1F26DEtQVh4rEt0_QYlkM7SObCg>
Received: by (Postfix) with ESMTPA; Fri, 13 Aug 2021 22:43:54 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Subject: Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
From: Mark Nottingham <>
In-Reply-To: <>
Date: Sat, 14 Aug 2021 12:43:52 +1000
Cc: IETF QUIC WG <>, HTTP Working Group <>, Jana Iyengar <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Kazuho Oku <>
X-Mailer: Apple Mail (2.3654.
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:44:11 -0000

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.


> On 13 Aug 2021, at 4:14 pm, 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

Mark Nottingham