There's a tradeoff here: Giving writers of qlog files more flexibility comes at a cost to consumers of qlog files, who now need to support multiple representations. There's a lot of value in having only a single way to log something.
I'm not sure the proposal for unscaled_ack_delay strikes the right balance here. For a consumer of a qlog file, I can't think of a single scenario where the unscaled_ack_delay would provide any advantage over the actual value, so introducing this option would purely to make the writer's life easier. And I'm struggling to see why logging the ack_delay would place a big burden on the writer, since a QUIC stack will need to decode this field at some point anyway. On Thu, 9 Nov 2023 at 22:44, Damien Neil <[email protected]> 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 >
