Summary

  • ACK Delay describes intentional receiver waiting between receipt of the largest acknowledged packet and transmission of the ACK.
  • The raw latest_rtt sample is formed before any ACK Delay adjustment and remains a local elapsed send-to-ACK observation.
  • Correct interpretation requires ack_delay_exponent, handshake phase, max_ack_delay and the min_rtt floor.

A tempting observability shortcut is to receive an ACK, decode its ACK Delay, subtract that value from the elapsed interval, and publish the remainder as network latency. That pipeline looks tidy because the protocol exposes a named delay field. It is nevertheless an evidentiary error. QUIC’s ACK Delay is a report about intentional waiting controlled by the receiver. It is not a direct reading of propagation, queueing, one-way delay, or all time spent on a host.

The scope is deliberately narrow. The receiver reports the intentional interval between receiving the packet with the largest acknowledged packet number and sending the ACK. The field does not describe every packet in the ACK ranges. It also excludes delay outside receiver control, such as time a packet spends waiting in an operating-system path before the endpoint processes it. A key-availability delay can be included under the protocol’s rules, but that still does not make the field a universal host-processing timer.

The sender first forms latest_rtt from the local send time of the largest newly acknowledged ack-eliciting packet and the local arrival of the ACK. The raw sample therefore contains the full observed acknowledgment interval. ACK Delay is decoded and applied later, when smoothed_rtt and rttvar are calculated. The encoded value is not meaningful without ack_delay_exponent and the relevant transport parameters. The default exponent is 3; max_ack_delay is expressed in milliseconds and has a default of 25 ms, but defaults do not erase negotiated context.

min_rtt follows a separate discipline. It is computed from local observations and is not reduced by peer-reported ACK Delay. That makes it a lower bound against an erroneous report, not a measurement of one-way or network-only latency. After handshake confirmation, the sender uses the lesser of decoded ACK Delay and peer max_ack_delay. It must also refuse to adjust a sample below min_rtt. Before confirmation, max_ack_delay is not used as a cap: larger values may reflect key availability or other permitted early-phase conditions.

This distinction matters because excess delay has no single proven cause. After confirmation, delay beyond max_ack_delay is treated in the estimator as effectively part of path delay, but the observation alone does not identify peer scheduler latency, earlier lost acknowledgments, or a noncompliant receiver. Authentication protects the packet; it does not prove that the peer’s report is accurate. Nor does an adjusted RTT prove application processing, service response, durable completion, or a business outcome.

The useful record is therefore a ledger, not a single latency number: connection and path identity, packet-number space, largest newly acknowledged packet and send time, ACK arrival and processing time, raw latest_rtt, raw and decoded ACK Delay, ack_delay_exponent, peer max_ack_delay, handshake-confirmation state, min_rtt, applied cap and floor, adjusted sample, smoothed_rtt, rttvar and PTO. Keep ACK ranges, key-availability evidence, local processing, previous-ACK loss and separate application timing distinct. The protocol correction and the estimator output should never be relabeled as a physical measurement.