As Damien says, delays can be considered. A PTO can result in non-trivial delays being reported during a handshake.
Now, the extent to which you trust any reported delays at this point is up to you. At this point, your minimum RTT is probably either excellent (because you haven't started to fill queues on the path) or wildly inaccurate (for a range of reasons). Either way, that's a cap on the amount that delays can affect your estimate. So it seems like the worst case is where the reported delay is doubled or halved (or other powers of two) within that narrow envelope. Because that only happens when there is loss (otherwise the ACK is sent with a delay of 0), the effect of a loss is worsened, but I just can't see an issue. An ACK that is a retransmission after PTO has a worse effect on RTT estimate if it sets the minimum RTT. A misreported delay cannot have that effect. In all cases, a few round trips with improved estimates will quickly erase any error. On Fri, Jun 30, 2023, at 17:39, Kazuho Oku 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
