Re: qlog, AckFrame, and ack_delay

[Damien Neil <[e-mail]>]

Consider an endpoint processing an ACK frame in an Initial packet received
before transport parameters have been received. This can happen when, for
example, a client's Initial CRYPTO flight is too large to fit in a single
datagram; the server will send an ACK for the first Initial packet before
it has the ability to send transport parameters in the Handshake flight. Or
even in the case where the client Initial CRYPTO flight fits in one
datagram, the server may respond with an ACK in an Initial packet prior to
sending a Handshake packet.

In this case, the client is processing an ACK frame that may contain a
non-zero ACK Delay value, but has no ability to interpret it because it
doesn't know the peer's ack_delay_exponent. I forget whether it's permitted
for an endpoint to send a non-zero ACK Delay in an Initial packet, but even
if it isn't, the recipient may want to log the value.

Or one could imagine a tool which converts a pcap packet capture to a qlog
file; in this case, the tool may have access to a key log to permit it to
decrypt packets, but may be processing a section of the log that does not
include the handshake.

On Fri, Nov 10, 2023 at 12:48 AM Marten Seemann <[e-mail]>
wrote:

> 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
>>
>