As I see it, the problem we're discussing here is *not* a qlog problem. It's a general problem with the ACK delay on ACKs received in Initial and Handshake packets, both of which might be received before processing the transport parameters.
We discussed this in https://mailarchive.ietf.org/arch/msg/quic/s1rTtXWMqni6-uQlPBkKG1Wf8XY/. As I (and others) have argued there, this is probably not a problem that matters in practice, and one could read RFC 9000 such that it mandates setting / interpreting the field as 0. Irrespective of the concrete outcome of that discussion, I think that the problem (as small as it might be in practice) should be solved in QUIC, and not in qlog. On Tue, 14 Nov 2023 at 20:19, Damien Neil <[email protected]> wrote: > On Tue, Nov 14, 2023 at 12:01 PM Lucas Pardue <[email protected]> > 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. > > >> 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. > > - Damien > >>
