As written, RFC 9000 and 9002 indicate that ack delays in Handshake packets may be used.
"[...] endpoints SHOULD include buffering delays caused by unavailability of decryption keys, since these delays can be large and are likely to be non-repeating." https://www.rfc-editor.org/rfc/rfc9000#section-13.2.5-2 "The peer might report acknowledgment delays that are larger than the peer's max_ack_delay during the handshake (Section 13.2.1 of [QUIC-TRANSPORT]). To account for this, the endpoint SHOULD ignore max_ack_delay until the handshake is confirmed, as defined in Section 4.1.2 of [QUIC-TLS]. When they occur, these large acknowledgment delays are likely to be non-repeating and limited to the handshake. The endpoint can therefore use them without limiting them to the max_ack_delay, avoiding unnecessary inflation of the RTT estimate." https://www.rfc-editor.org/rfc/rfc9002#section-5.3-3 RFC 9001 implies that ack delays may appear in Initial packets, and indicates that implementations "should use caution" but not necessarily ignore this data: "For example, an attacker could inject [an Initial] packet containing an ACK frame to make it appear that a packet had not been received or to create a false impression of the state of the connection (e.g., by modifying the ACK Delay). [...] Implementations SHOULD use caution in relying on any data that is contained in Initial packets that is not otherwise authenticated." https://www.rfc-editor.org/rfc/rfc9001#section-7-2 So if the intent is that ack delays are neither reported nor consulted during the handshake, I believe those sections at the least should be updated. On Fri, Jun 30, 2023 at 12:40 AM Kazuho Oku <[email protected]> wrote: > 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 >
