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

Mark Nottingham <mnot@mnot.net> Sat, 14 August 2021 02:44 UTC

Return-Path: <mnot@mnot.net>
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 8E9693A3202 for <quic@ietfa.amsl.com>; Fri, 13 Aug 2021 19:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Rcsdv3t1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GW0iZ/j2
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 R-OSywrFDAQO for <quic@ietfa.amsl.com>; Fri, 13 Aug 2021 19:44:04 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9E53A3169 for <quic@ietf.org>; Fri, 13 Aug 2021 19:44:04 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6E93A5C004F; Fri, 13 Aug 2021 22:43:58 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 13 Aug 2021 22:43:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; 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= messagingengine.com; 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 mail.messagingengine.com (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.120.0.1.13\))
Subject: Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CANatvzxWrg+rciDpOZqsnDWq_oW_cr-Do2SjUzGgPy_vyAUs=Q@mail.gmail.com>
Date: Sat, 14 Aug 2021 12:43:52 +1000
Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Jana Iyengar <jri.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FC98EA2-7DCB-41E0-9C4F-58088C5DD89E@mnot.net>
References: <162883401993.25302.7275724432785172464@ietfa.amsl.com> <CANatvzxWrg+rciDpOZqsnDWq_oW_cr-Do2SjUzGgPy_vyAUs=Q@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1Dh5mpvrRMDNeHsCDZ6uhk_jVow>
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: 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.

Cheers,


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

--
Mark Nottingham   https://www.mnot.net/