Subject: QUIC standardized logging and tooling

From: Robin MARX <[email-masked]>
Date: Tue, 11 Dec 2018 16:44:57 +0100

Hello everyone,

Last week, we presented the paper "Towards QUIC Debuggability" at the EPIQ
workshop.
In it, we argue the need for a (de-facto) standardized QUIC logging format
and default ways of accessing those logs through (.well-known) URLs.
This enables easy processing of results from a variety of sources,
but mainly also the creation of easily shareable and reusable (visual)
tools.
The paper and examples of such tools can be found at
https://quic.edm.uhasselt.be

The logging format in the paper, termed "qlog", is currently an incomplete
strawman proposal.
We do think its underlying principles are a good starting point for a wider
discussion:
- Logging of individual events, allowing full endpoint state to be
reconstructed from the log
   (as opposed to logging full state at discrete intervals)
- Inclusion of an explicit trigger/reason field with each logged event
   (e.g., when retransmitting a packet, is it because of early retransmit,
RTO, TLP or gaps in received ACKs?)
- Flexible format allowing for partial logging and filtering
   (e.g., not logging the "HTTP/3" category when debugging congestion
control)
- Easy to parse
   (qlog is currently JSON-based for use in web-based tools)
- Standard methods of access and encryption/protection
   (e.g., webserver exposes example.com/.well-known/h3/state, browser
exposes about:networking/h3/state/list)

Several of these points overlap with a previous similar proposal
from Google at https://github.com/google/quic-trace.
There was a small discussion on the mailing list on this in September,
which sadly fizzled.
As several EPIQ workshop attendees showed interest in our work and asked me
to extend
it to the IETF, I am hoping to restart the standardized logging
conversation here.

Next to the logging schema itself, there are several remaining open
questions
that require further discussion, for example:
- Need for scalability (e.g., files with many thousands of events)
- Which format(s) to use (e.g., protocolbuffers gained some pushback before)
- Implementation and runtime overhead (e.g., "reason" field requires
additional state keeping)
- Interest from developers and practical approach (e.g., need to provide
library VS implementer will use custom code)

We plan to start a new draft document with an initial proposal, based on
both qlog and quic-trace,
which can be used as the basis for further discussion.
In the mean time, we are open to collaboration and welcome any and all
feedback,
both here and in the quicdev slack group.
We will be actively developing the tools and format proposals in the coming
months
and hope to be present at IETF 104 in Prague to discuss early results.

With best regards,
Robin

-- 

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: Mirja Kühlewind <[email-masked]>
Date: Tue, 11 Dec 2018 16:49:49 +0100

Hi Robin,

thanks for this work and the pointers. I agree that this is an interesting topic and I would like to further discuss it in the IETF. Also I think this discussion should not be constraint to QUIC only. Yes, QUIC is the current most important use case but this can also be applied to other protocols and as we see even more encryption in future, this because a general requirement.

Mirja

> Am 11.12.2018 um 16:44 schrieb Robin MARX <[email-masked]>:
> 
> Hello everyone,
> 
> Last week, we presented the paper "Towards QUIC Debuggability" at the EPIQ workshop.
> but mainly also the creation of easily shareable and reusable (visual) tools. 
> The paper and examples of such tools can be found at https://quic.edm.uhasselt.be
> 
> The logging format in the paper, termed "qlog", is currently an incomplete strawman proposal.
> We do think its underlying principles are a good starting point for a wider discussion:
> - Logging of individual events, allowing full endpoint state to be reconstructed from the log 
>    (e.g., when retransmitting a packet, is it because of early retransmit, RTO, TLP or gaps in received ACKs?)
>    (e.g., not logging the "HTTP/3" category when debugging congestion control)
> - Easy to parse 
>    (e.g., webserver exposes example.com/.well-known/h3/state, browser exposes about:networking/h3/state/list)
> 
> There was a small discussion on the mailing list on this in September, which sadly fizzled. 
> As several EPIQ workshop attendees showed interest in our work and asked me to extend 
> it to the IETF, I am hoping to restart the standardized logging conversation here.
> 
> Next to the logging schema itself, there are several remaining open questions 
> - Implementation and runtime overhead (e.g., "reason" field requires additional state keeping)
> - Interest from developers and practical approach (e.g., need to provide library VS implementer will use custom code)
> 
> We plan to start a new draft document with an initial proposal, based on both qlog and quic-trace, 
> In the mean time, we are open to collaboration and welcome any and all feedback,
> We will be actively developing the tools and format proposals in the coming months