The future of qlog

Robin MARX <robin.marx@uhasselt.be> Thu, 05 November 2020 16:51 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 B8A133A17FF for <quic@ietfa.amsl.com>; Thu, 5 Nov 2020 08:51:19 -0800 (PST)
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, 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 z6l_VHCMW8Yx for <quic@ietfa.amsl.com>; Thu, 5 Nov 2020 08:51:16 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 918D13A17F7 for <quic@ietf.org>; Thu, 5 Nov 2020 08:51:16 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id n15so2578244wrq.2 for <quic@ietf.org>; Thu, 05 Nov 2020 08:51:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:from:date:message-id:subject:to; bh=2vE1vmyP0VmI6vytsI/K0a8OQ34y20riOczpK76N3ts=; b=jEQ3TLrXr2OLmYSYutaGgeuLADY3kmU/m0IUkqxNRQO5AjDmLlfCrfljhxi4CiGBgG dXuuOmtCbfS26wZdrgo3x9R2t55WMsSd57plAm6YhgklS2vOwxIx/DTwNcfJK890vkYg Y+bsS0Qky+RKikzlUaIDUW+newPnVK2xx0Mng=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2vE1vmyP0VmI6vytsI/K0a8OQ34y20riOczpK76N3ts=; b=MWDqLIJKsexGRkZDELdeDHmB5EKJdE2fhrpvkUr7OEoEPmVn2qMLp2DYXwgDEmlwDC UuIVeeVYtiMbA8P36fDsLO16iu/nyFD1eCfNSYjYhP6emo8QAkyOfRMZKICmLvJpwwgb Nfb/0I5Buhio0FgAWFb23EIf2EqRozHR1D3KGmyrz6H78uWFBn6eDam04ip3/5GuJ1h3 dIvg0PtkaHAdUrsa+aVm98FXom1c3CXlG4DE9q35Wq9eZJIoQcjTamHnHzRUdHi7Dvai +JC++7lrgx+X9H2Cw2tQ/YOgvR+CPTm+eufUYbnZzaf8xeEwR4LRr9j4NZf8K9FKyBjw BEYw==
X-Gm-Message-State: AOAM530vY0wOS6VvqtVO4UEL78mpGbVqs4lX8cit7Gpd5z4dlkK5kVjX rINajGXNl7ki/8Bz0upOq2PXMROXUVGixmVeJB1kXPh0/U08Og==
X-Google-Smtp-Source: ABdhPJzRxWpHchu4PUr35PYJAZZyuth/1YCzz0f4aPZLYcfdmVY/2cBfmCo7W41Mww8wfOY7DbKMH9g1s21CQ5g12oc=
X-Received: by 2002:a5d:56d0:: with SMTP id m16mr3988646wrw.120.1604595074010; Thu, 05 Nov 2020 08:51:14 -0800 (PST)
MIME-Version: 1.0
From: Robin MARX <robin.marx@uhasselt.be>
Date: Thu, 5 Nov 2020 17:51:03 +0100
Message-ID: <CAC7UV9bZiuw7a9j2A2uMGB+kh+aP00+Ud5y0XqjRRcCh4MGE=A@mail.gmail.com>
Subject: The future of qlog
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000065349c05b35ee75b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/yv9FFyXItsKK6m-5I5eRE6jnqR8>
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: Thu, 05 Nov 2020 16:51:20 -0000

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