Re: The future of qlog
Robin MARX <robin.marx@uhasselt.be> Mon, 23 November 2020 19:05 UTC
Return-Path: <robin.marx@uhasselt.be>
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 DADDA3A0C36 for <quic@ietfa.amsl.com>; Mon, 23 Nov 2020 11:05:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=uhasselt.be
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 ifMeit1NWRU4 for <quic@ietfa.amsl.com>; Mon, 23 Nov 2020 11:05:25 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 5517B3A0C35 for <quic@ietf.org>; Mon, 23 Nov 2020 11:05:25 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id a186so222458wme.1 for <quic@ietf.org>; Mon, 23 Nov 2020 11:05:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z1X/U4ADaZjKLzN2CAtKzXTT1uyl4gFhBX5h6Dt0hps=; b=dggZrDl4SLlBR9etOyJiM7tzmICgQwnBnqjMjACM6902mAtMkkKAvhc8Yupz7D9EPj kDjrTI0jWcgj5UlS7Vs8Tb1MoDhuxGHRAeUp7xx0DL3VBYB4G3R2sZn2L1XHvAEl9gIQ h0wI4Yi94zIU7aMJ9Iomvn2WgbbTcu5ggYq7M=
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=Z1X/U4ADaZjKLzN2CAtKzXTT1uyl4gFhBX5h6Dt0hps=; b=h3/w3DnXj5hp7awViIPa2wqNI14pOZ8HEmHaDzqQhQWnbG5G/B4bLFI1x3nYahmn44 XdEhu8vO+s13hNF2hKpcp6TqtAe6qkqL9FGJlT4p+q0A29JAhTzQm+mb+ZIbHGEuKyD/ 5JV8ztUZnALdy/6stQDiPQ/fy+JGCpdOlWdIsUIYa8KxzHaJHTZKI6TNuW+FFTq56cYP ck9I/bLiuu5pCF4FWuPbKT84x1enXwraQcPtOGz+yuykpz0i6gY7aZpZ88IncuIDD5pw YjGIoMtaej8LoBrkGOUMgkqKFVYEh22zbQ7B0BujR6AJp9eyYZYibg1Rax/DqqDBo7hy aP8g==
X-Gm-Message-State: AOAM532AiAnrs56q5soHr5jflOPKHZW9j5iDPGtXj+dhc4kyXmGkQQ4Q EsPHts9DsxOKuLt9nKieIK5TpLdv31emgxQtIZbGL8dRcrf05g==
X-Google-Smtp-Source: ABdhPJxIr1Pi63tRXeVCjCvhhwzKV5mNv+Haqz4BlYyQiHjR+81xFttxD25GDSpkQF1Os6T6ZABUtceN616rgi5P/DI=
X-Received: by 2002:a1c:2001:: with SMTP id g1mr296907wmg.179.1606158322950; Mon, 23 Nov 2020 11:05:22 -0800 (PST)
MIME-Version: 1.0
References: <CAC7UV9bZiuw7a9j2A2uMGB+kh+aP00+Ud5y0XqjRRcCh4MGE=A@mail.gmail.com>
In-Reply-To: <CAC7UV9bZiuw7a9j2A2uMGB+kh+aP00+Ud5y0XqjRRcCh4MGE=A@mail.gmail.com>
From: Robin MARX <robin.marx@uhasselt.be>
Date: Mon, 23 Nov 2020 20:05:10 +0100
Message-ID: <CAC7UV9bYMqsNfb=Hm1Ma-3yqRY7wXwVQKhogi7zpxPtpREoy3w@mail.gmail.com>
Subject: Re: The future of qlog
To: IETF QUIC WG <quic@ietf.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000004aff6205b4cae03e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HxffVwoxbSeefWpibPKtGn3x1D0>
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: Mon, 23 Nov 2020 19:05:28 -0000
Hello everyone, I was happy to see a large amount of support from you all for qlog at the QUIC wg meeting last week [0]! While it seemed there was consensus that it would benefit from a more formal adoption, it wasn't entirely clear if this should be in the QUIC wg. (I am also CC'ing the HTTP wg via Lucas Pardue, who thought this would somewhat concern them as well) To recap, qlog consists of two parts: 1) the main schema, which is protocol agnostic and mostly defines the serialization and container format [1] 2) the QUIC and HTTP/3 specific events [2] In theory, we could have other documents similar to [2], defining events for TCP, TLS, HTTP/2, DNS, BGP, etc. all using the same qlog main schema as a basis. This is how qlog was originally intended and hopefully someday will evolve to. For now it has focused mainly on QUIC and H3 as they were optimal experimental targets. While adopting both documents in the QUIC is possible and probably the most practical in the short term, it's not entirely clear this is the optimal path. For example, what would be the approach for defining e.g., HTTP/2 events down the line? Do this in the HTTP wg in collaboration? Or do it in QUIC as it's probably mostly the same people doing the work anyway? Even for more QUIC specific things there can be problems. For example, Ian and Matt expressed the need for broader congestion control events, yet the QUIC wg isn't chartered to really work on anything other than Reno atm. I'm not saying these are necessarily (major) issues, but I'm not experienced enough in IETF processes to know the best way forward or if these are actually problems. I can see roughly 3 main options and would like additional feedback on which people want: A) Adopt both in QUIC wg for now, bring them to ~full maturity for QUIC and H3, and then see if/how to generalize later (it seemed to me most were leaning to this side last week) B) Adopt document [2] in QUIC wg and find another place for [1], either in an existing wg or a new one via BOF by IETF 110 (what happens if that fails though?) C) Find an existing wg or do a BOF for both [1] and [2] together by IETF 110 (not sure this has enough traction outside of QUIC wg?) I'm also hoping people here can give some practical hints on how to move this forward (e.g., what do I have to do to get a document adopted etc.) A final important aspect was aptly summarized by Jana as "qvis/tooling is what people love, qlog is what people need". For those that don't know, qvis [3] is an open source set of tools that I and my team have been maintaining to visualize qlogs and other formats (such as pcaps and netlogs). The codebase is of (ahem) dubious quality and I definitely wouldn't mind extra people joining the project both for maintenance and new tool development. Another aspect is that we're currently hosting this on a university server, but will have to move to something else in 2 months. I'd prefer to not keep this tied to me personally. I'm not sure how much this can/should be tied to the IETF or QUIC wg proper, so I'd be interested in other people's opinions on how to organise qvis as well. Thanks in advance for your valuable feedback, Robin [0]: https://github.com/quicwg/wg-materials/blob/master/ietf109/minutes.md [1]: https://tools.ietf.org/html/draft-marx-qlog-main-schema-02 [2]: https://tools.ietf.org/html/draft-marx-qlog -event-definitions-quic-h3-02 [3]: https://github.com/quiclog/qvis On Thu, 5 Nov 2020 at 17:51, Robin MARX <robin.marx@uhasselt.be> wrote: > Hello everyone, > > As you might have seen, I submitted draft-02 of the qlog format just > before the > IETF 109 cutoff [1][2]. The main change from -01 is the move back to a > simpler > default JSON serialization and explicit support for streaming logs using > NDJSON. > > A year in the making, this update reflects feedback from a considerable > adoption > and deployment experience of the format by the IETF QUIC community. Over > 60% of > active implementations currently (partially) support the format [3] and > many of > you have actively contributed to improving this project, for which I am > eternally > grateful. > > Still, with this email, I am once again asking for your support. With > draft-02, I > feel we have reached the limits of what the current team can accomplish on > its > own. There are several issues of scope and approach that would benefit > greatly > from broader discussion. The main ones are: > > 1. Should qlog focus on reflecting internal implementation events (for > example a > "packet_acked" event) or provide ways to log the protocols' wire image > (for > example the ACK frame). Or both? [4] > 2. Should qlog feature a wide range of events, each reflecting a specific > small > aspect, or rather fewer, consolidated events? How much should the qlog > events > reflect the exact protocol mechanics/internal details? [5] > 3. What are the privacy and security best practices for this kind of > endpoint > logging and how can/should they be enforced? > 4. Is qlog as a concept more widely applicable to other protocols than just > QUIC/H3? If yes: what does that mean exactly? > > The answers to these and other questions will follow largely from concrete > future > applications and use cases people have in mind. This in turn will > influence if, > how and where we continue work on qlog. > > Early on, we already discussed wider applications for the qlog concept in > tsvarea > [6]. However it was decided to first get qlog implementation experience for > QUIC/H3, which I believe has now happened. However, this also means qlog > now has > the most direct value for QUIC/H3 and it feels natural to me to first hear > the > perspective of the QUIC wg on its future. > > I can see many possible ways forward, including: adopting this within the > QUIC wg, > adopting this in another wg, doing a BoF to try and form a new wg, create > a design > team, organize a single interim session to decide the main points, switch > to > maintenance mode and use qlog as-is, etc. > > I have requested an "if time permits" slot for the IETF 109 QUIC meeting > in two > weeks to get a feel for what people think. This email is to have a backup > in case > we don't have time then and so people can prepare (or already share) their > opinion > (if any). > > Thanks again to everyone who has already contributed to qlog and with best > regards, > Robin > > > [1]: https://tools.ietf.org/html/draft-marx-qlog-main-schema-02 > [2]: > https://tools.ietf.org/html/draft-marx-qlog-event-definitions-quic-h3-02 > [3]: > https://qlog.edm.uhasselt.be/anrw/files/DebuggingQUICWithQlog_Marx_final_21jun2020.pdf > [4]: https://github.com/quiclog/internet-drafts/issues/53 > [5]: https://github.com/quiclog/internet-drafts/issues/85 > [6]: https://www.youtube.com/watch?v=LiNLz1QuT0s&t=3233 > > -- > > Robin Marx > PhD researcher - web performance > Expertise centre for Digital Media > > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > > > -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
- The future of qlog Robin MARX
- Re: The future of qlog Robin MARX
- Re: The future of qlog Lucas Pardue
- Re: The future of qlog Martin Duke
- Re: The future of qlog Jana Iyengar
- Re: The future of qlog Robin MARX
- Re: The future of qlog Martin Duke