Re: The future of qlog

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