Re: The future of qlog

Thanks Robin!

I have some responses in line.

On Mon, Nov 23, 2020 at 7:05 PM Robin MARX <robin.marx@uhasselt.be> wrote:

> 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]
>

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.


> 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?)
>
>
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