Hello Damien, Thank you for bringing this to our attention. I agree you have a point and have to admit that, at first, I was confused, because I thought we already defaulted to logging the wire image/unscaled value instead of the scaled one.
As such, I think your suggestion is a sensible one and I've created a PR for it here: https://github.com/quicwg/qlog/pull/337 Feel free to comment more on that issue as well. In absence of protest by others, this will be in the next draft versions. With best regards, Robin On Thu, Nov 9, 2023 at 10:44 PM Damien Neil <dneil= 40google....@dmarc.ietf.org> wrote: > The qlog AckFrame type includes the ack delay as a float32 number of > milliseconds: > > AckFrame = { > frame_type: "ack" > > ; in ms > ? ack_delay: float32 > ; ... > } > > > https://www.ietf.org/archive/id/draft-ietf-quic-qlog-quic-events-06.html#section-8.12.3 > > Given a serialized ack frame, determining the delay as a duration requires > knowing the ack_delay_exponent. In some cases, the logging endpoint may not > have this available (if receiving an ack before transport parameters have > been received). Even when available, it may not be easily accessible at the > point of logging. For example, in my own implementation, I'd like to be > able to convert a packet payload to a series of qlog event frames without > needing to reference persistent connection state. > > I think there should be an alternative to log the raw value of the ACK > Delay field: > > AckFrame = { > frame_type: "ack" > > ; in ms > ? ack_delay: float32 > > ; integer value of the ACK Delay field, not scaled by the > ack_delay_exponent > ? unscaled_ack_delay: uint64 > > ; ... > } > > - Damien > -- Marx Robin +32 (0)497 72 86 94
