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

Jana Iyengar <jri.ietf@gmail.com> Sat, 14 August 2021 02:13 UTC

Return-Path: <jri.ietf@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 9EC673A30E4 for <quic@ietfa.amsl.com>; Fri, 13 Aug 2021 19:13:03 -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 rfoKQzny8eMg for <quic@ietfa.amsl.com>; Fri, 13 Aug 2021 19:12:58 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 AF8C83A30E3 for <quic@ietf.org>; Fri, 13 Aug 2021 19:12:57 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id go31so21609534ejc.6 for <quic@ietf.org>; Fri, 13 Aug 2021 19:12:57 -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=DySy2q6do115689O18rBEoIIF0myuGptYa3MpuzRM8I=; b=WvpXff2g85suBaxWLJV+fvMohogoJcRzXbyeaJGhvgyUBwIw2Ff1XM40Kq9IxhWxrq jii5E5max3KXJhlgDoheejttiXRUvy7Qj7Vob1Y4PYBsy7GQbFmWOrEnDZrlNFDXN/PC kyCBRFql5r2Yno24p5nJgQBLj1hiz2+Nw8Mn0QjGZRz1r2PhJH/zqClGSLg/EtGGwxsp K+/34zNL/1r+hld4HksrKsvmAfvRCRYHvyJY+515+DKN9fUg5kxlXu0AZWu3Hz4d2O/q j/OcKOM6B59apITz+GBMMkWxKvTejL8aJ7bN6FWtJpjP9tnPtMjYEO0G8NlhMmmh1hft NWYQ==
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=DySy2q6do115689O18rBEoIIF0myuGptYa3MpuzRM8I=; b=EkfCGU7DG2eWOhVjNu1Hi9jJm4P6elixT0oELwIadhb6c4NcYR8AWUo3dwlbSUj5vm j7NM7Cr5YrlaOR1WuOrw24fhmfg7ge9M8c22UM+J/e36C1HsTJxoPmrJzKlU5URB1mzu B9fuJ4kKRKtdxlVfjjCzaceAdJza8Qx73n8Bija3s/kUc48oekox9LM+BSjArjcxgaMq k3EU9EUN2hdLc13dvC+JSLGoTJNskfZV5X7q38pXJLPCr9akf7LTYD+WK4X1mfphZax/ bc6C0Q87/9tbQV6oMcJSblWuCZ7Hup0GbdqvMvwnKuSSQeiiyDyYyoi6kNQah6FZtqI9 n/yg==
X-Gm-Message-State: AOAM533OO4hl7y8BadC4EnUV8+fvchiJjU3YXgdivRnubW48tSya8Nxj 4Ie36jP2ie3ES5CAm4PP9rx7Sc4kIBw5H0wlHqM=
X-Google-Smtp-Source: ABdhPJzfzp17h5kDq+fq38E4OsBKvG9asqQwK1hu8WaH/DMFioRaDd6Uo0cuSBZGshLosYQ/if6L3H8K40VULef8P4U=
X-Received: by 2002:a17:907:7faa:: with SMTP id qk42mr5358688ejc.291.1628907175177; Fri, 13 Aug 2021 19:12:55 -0700 (PDT)
MIME-Version: 1.0
References: <162883401993.25302.7275724432785172464@ietfa.amsl.com> <CANatvzxWrg+rciDpOZqsnDWq_oW_cr-Do2SjUzGgPy_vyAUs=Q@mail.gmail.com> <CADdTf+gG83d5n3X2SxwxdV5o2H_z66EK7JdbafiPfaETh3tSxw@mail.gmail.com>
In-Reply-To: <CADdTf+gG83d5n3X2SxwxdV5o2H_z66EK7JdbafiPfaETh3tSxw@mail.gmail.com>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Fri, 13 Aug 2021 19:12:44 -0700
Message-ID: <CACpbDcdDQ5KnaKZ1V3-BdZEJ3QbecL1iEtRfeKXBGEpMxtUWyA@mail.gmail.com>
Subject: Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
To: Matt Joras <matt.joras@gmail.com>
Cc: Kazuho Oku <kazuhooku@gmail.com>, IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000008c718e05c97b8194"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Ef-YbfvDb62wKHlwEMVKGG0j0fw>
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:13:04 -0000

Robin,

On the privacy question -- indeed the user doesn't know what info is being
shared but note that this is a server-side log that is being streamed to
the client. This is no different than the server logging it directly. The
primary value here is for a user to log a "problematic" connection, where
otherwise servers in general do log random connections for perf analysis.

This solves a real problem right now for us which is to be able to grab
server-side traces for specific repeatable performance problems on certain
connections. A client can tell us there's a perf issue with a particular
domain, but without much else, we have to try and repro it, and without the
client's setup, we are often unable to easily do this.

With this mechanism, we can ask the reporter to send us a self-trace for
the repeatable issue. This is quite similar to Chrome netlogs (which are
requested from users who report issues,
https://support.google.com/chrome/a/answer/6271171), except that it is
server side logs.

So, we don't stream qlog; the current format is based on what was easiest
for us to do. Importantly, this doc isn't about the format, it's about a
mechanism to spit out logs that are local to a server. We might even want
to send some server infra specific info that we can send as an encrypted
blob in this stream.

I don't think this should be in the qlog doc. Of course there is value in
emitting qlog -- one can build and use standard tools and such around this
if it were to be emitted in qlog format. But I don't see this as a reason
to limit this mechanism to emit only qlog.

- jana

On Fri, Aug 13, 2021 at 9:50 AM Matt Joras <matt.joras@gmail.com> 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 <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
>>
>