Subject: The future of qlog

From: Robin MARX <[email-masked]>
Date: Thu, 5 Nov 2020 17:51:03 +0100

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

---

From: Robin MARX <[email-masked]>
Date: Mon, 23 Nov 2020 20:05:10 +0100

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 <[email-masked]> wrote:

> Hello everyone,
>
> As you might have seen, I submitted draft-02 of the qlog format just
> before the
> applications and use cases people have in mind. This in turn will
> influence if,
> adopting this in another wg, doing a BoF to try and form a new wg, create
> a design
> I have requested an "if time permits" slot for the IETF 109 QUIC meeting
> in two

-- 

Robin Marx

www.uhasselt.be

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Nov 2020 20:07:47 +0000

Thanks Robin!

I have some responses in line.

> 2) the QUIC and HTTP/3 specific events [2]

Yes sorry HTTP folks blame me for your additional email traffic. The reason
I thought the discussion on qlog was pertinent to the HTTP WG is because
one of the major places I've found benefit is in analyzing stream
multiplexing using qvis. This has particularly been useful for developing
an implementation of Extensible Priorities in an HTTP/3 stack. The most
mature way to get qlog for HTTP/2 stacks would be to define qlog schemas
for TCP, TLS and HTTP/2.

There are potentially other application mappings. As was discussed at the
IETF 109 session, I think congestion control is going to be something that
benefits from logging and tooling. Is there an interest in making qlog work
the same for a CCA across TCP and QUIC? I suspect that might drive some
opinion of what to do here.

> 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
Option A seems the most pragmatic given where we are. But the more I think
about things, the more concerned I get that a focus on QUIC stifles the
innovation of other qlog use cases simply because they fall out of the
scope of permitted discussion. So far, the main schema discussion has
rightly focused on more operational concerns like serialization format, we
should also let people with interest and expertise in this area flourish if
possible. Finally, I also have a concern that the combined QUIC & HTTP/3
schema becomes difficult to manage once we hand the reigns of HTTP/3 back.

So I don't have a personal strong decision yet. But I'd like to consider an
Option D that splits the QUIC & HTTP/3 schema, with each WG getting first
refusal for adoption. Meanwhile, we continue to discuss the main schema.

Cheers
Lucas

---

From: Martin Duke <[email-masked]>
Date: Wed, 25 Nov 2020 16:00:09 -0800

Splitting HTTP/3 and QUIC into separate documents, so they can evolve
separately makes, sense, though I would be comfortable with them both
remaining in QUICWG for now.

As an AD, I will facilitate a discussion with other areas about the main
schema. Robin, it might be useful for you to go on a roadshow at IETF 110
to pitch it to other areas to see if there's wider IETF energy to pursue
qlog extensions. If so, the case for putting the main schema outside quicwg
is pretty strong.

On Mon, Nov 23, 2020 at 12:14 PM Lucas Pardue <[email-masked]>
wrote:

> Yes sorry HTTP folks blame me for your additional email traffic. The
> reason I thought the discussion on qlog was pertinent to the HTTP WG is
> because one of the major places I've found benefit is in analyzing stream
>> 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?)
> So I don't have a personal strong decision yet. But I'd like to consider
> an Option D that splits the QUIC & HTTP/3 schema, with each WG getting
> first refusal for adoption. Meanwhile, we continue to discuss the main
> schema.
>
> Cheers
> Lucas
>
>