On Tue, 14 Nov 2023, 20:19 Damien Neil, <dn...@google.com> wrote: > On Tue, Nov 14, 2023 at 12:01 PM Lucas Pardue <lucaspardue.2...@gmail.com> > wrote: > >> Why not? >> > > I think what I wanted to say is that you don't want to require every qlog > consumer to have both a QUIC wire protocol frame parser and a qlog event > Frame parser. Frames in qlog should be either structured objects (in > practice, JSON objects) or QUIC wire bytes, but not a mix of both. >
Thats a clean design but it doesn't fly when a logger can read a wire format type it doesn't understand at all and can't interpret it's payload, such as the example of operating on a packet trace. QUIC is extensible, we should support people adding things to logs in advance of tooling catching up. Application protocols like HTTP/3 have even more flexibility and already require connection state tracking. Logging the bytes allows post-processing to fill gaps. Even if that means a human digging through with a hex editor. > >> It would help to better understand the use case. How can debugging use >> the value? Do we expect all tools to offer this and hence standardizing >> something has value. If not, logging endpoints can always insert custom >> fields into any element. And custom tooling can consume it. >> > > From my perspective as an event producer, it's odd to have a frame which I > can't log without inserting custom fields. > > Perhaps that's okay, but if so, I think qlog should define the expected > behavior for producers logging uninterpretable ACK Delay fields. > This is a good suggestion. Per Marten's email, this is a facet of the QUIC and we can provide some text to describe how to deal with it if it occurs. Cheers Lucas > > - Damien > >>
