Re: qlog, AckFrame, and ack_delay

[Marten Seemann <[e-mail]>]

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 <dneil=[e-mail]>
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
>