I think I'm late to respond, but my understanding is that endpoints are expected to ignore ack delays being reported in Initial and Handshake packets, and therefore it does not matter whatever value the endpoint would be using as ack delay exponent.
This is because endpoints "MUST acknowledge all ack-eliciting Initial and Handshake packets immediately" (section 13.2.1) and ack delay is "the delays intentionally introduced between the time the packet with the largest packet number is received and the time an acknowledgment is sent" (section 13.2.5). I might even argue that it is an error to send ACK frames with non-zero ack delays using Initial or Handshake packets; the peer can error-close the connection with PROTOCOL_VIOLATION. 2023年6月15日(木) 0:36 Christian Huitema <[email protected]>: > > > 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 > > -- Kazuho Oku
