Summary

  • PTO expiry authorizes one or two acknowledgment-eliciting probe datagrams and increases the backoff period.
  • It does not by itself declare a packet lost, identify a missing ACK, or prove congestion.
  • Timer state, packet-number space, probe contents, later ACKs, loss declarations, and application outcomes must remain separate evidence.

QUIC recovery is easy to misread when a monitoring pipeline compresses several events into one label. A PTO expiry is first a timer event in one packet number space. It means that acknowledgment-eliciting packets have not produced the expected acknowledgment progress within the calculated period, or that a server may be probing before client address validation. The protocol response is to seek progress: the endpoint sends at least one and may send up to two full-sized acknowledgment-eliciting probe datagrams, then increases the PTO backoff. The event is not a finding that a named packet disappeared.

PTO is maintained per packet-number space. Initial, Handshake, and Application Data traffic therefore cannot be treated as one undifferentiated queue. In ordinary computation, the period is smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay. Initial and Handshake use zero for the max_ack_delay term. Application Data PTO is not armed before handshake confirmation. A sender restarts PTO when suitable acknowledgment-eliciting packets are sent or acknowledged, and when Initial or Handshake keys are discarded. After expiry, the next period is twice the current one; consecutive periods grow exponentially across packet-number spaces until the separate idle timeout bounds them.

The order of recovery decisions matters. A time-threshold loss-detection timer takes precedence, so PTO must not be armed while that timer is set. Later ACK ranges can support packet-threshold or time-threshold loss detection under RFC 9002. That later declaration is different evidence from the earlier timer expiry. A pipeline that marks every outstanding packet lost at PTO expiry has therefore invented a conclusion before the relevant threshold or acknowledgment evidence exists.

Probe construction also resists the word “retransmission.” New data should be used when available. If no new data can be sent, previously sent information may be carried again in a new frame. If there is no data, PING or another acknowledgment-eliciting frame can be used. RFC 9000 says lost QUIC packets are not retransmitted whole: information needing repair is carried again in new frames and new packets. Sending old information again is not replaying the same packet, and a PING or PADDING frame carries no retransmittable information.

Address validation adds a material constraint. Before validation, server probe packets count against the anti-amplification limit. If the server cannot send more within that budget, it must not arm its PTO until another client datagram increases the budget. The client may still need to probe to unblock the server. This is a budget and state fact, not proof that a packet or acknowledgment was lost.

RFC 9002 permits an implementation strategy that marks remaining in-flight packets lost instead of sending a probe. That choice is not the semantic meaning of PTO expiry and risks an unnecessarily aggressive congestion-controller rate reduction. Nor does any PTO event prove that congestion caused the missing acknowledgment, that the receiver processed application data, that a service replied, or that a business operation completed. Even a later ACK supplies transport evidence, not a receipt of durable application completion.