On 6/14/2023 8:13 AM, Damien Neil wrote:
On Wed, Jun 14, 2023 at 6:59 AM Lars Eggert <[email protected]> wrote:
I had assumed - and IIRC that is what quant implements - that if
ack_delay_exponent is unknown, the default of 3 (per
https://datatracker.ietf.org/doc/html/rfc9000#section-18.2) should be
used.
Using a default of 3 prior to receiving transport parameters will lead to
misinterpretation if the peer is using a different value.
RFC 9000 Section 18.2 says to use 3 "if this value is absent", but I
believe in context that means if the value is absent from the transport
parameters. It doesn't address what to do prior to receiving transport
parameters.
The correctness of the ACK delay is a second order problem. In my
experience, the RTT measurements collected before the handshake is
complete are rather unreliable. They tend to incorporate delays due to
crypto operation, be affected by anti-DDOS policies, or in the case of
0-RTT be delayed until completion of handshake.
I would rather keep things simple and ignore that parameter for Initial
and Handshake packets.
-- Christian Huitema
