The future of qlog

[Robin MARX <[e-mail]>]

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 [phone] - GSM [phone]

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05