Summary

  • A QUIC receiver cannot acknowledge a packet until it has removed packet protection and processed every frame in it.
  • For STREAM data, processing reaches the receiver’s queue for application receipt; the application need not have received or consumed those bytes.
  • Delivery and completion claims require an application-defined receipt joined to packet, frame, stream-offset and retransmission evidence.

The delivery dashboard turns green when the packet carrying a request enters an ACK range. If it is the newly acknowledged ack-eliciting packet selected for measurement, it can yield an RTT sample; acknowledgment also stops retransmission of the acknowledged information it carried. Yet the receiving process is paused before its read callback. Nothing has been parsed, committed or acted upon. The dashboard has promoted a transport receipt into an application result.

RFC 9000 §13.1 sets the exact boundary. A receiver must not acknowledge a packet until packet protection has been successfully removed and every frame in that packet has been processed. For a STREAM frame, processing means that the data has been enqueued in preparation for receipt by the application protocol. It does not require that the application has received or consumed the data. An ACK is therefore strong evidence about the peer’s QUIC processing, but it stops before application consumption.

The object being acknowledged matters. RFC 9000 §19.3 defines ACK ranges as packet numbers for packets the receiver has received and processed, within the same packet-number space. Packet numbers identify protected transport packets, not business messages. One packet can contain several frame types, while one application message can span multiple STREAM frames and packets.

The stream model makes that mismatch explicit. RFC 9000 §2.2 provides an ordered byte stream and says STREAM frame boundaries are not preserved through transmission, retransmission or delivery. RFC 9000 §3.2 separately names Data Recvd, when all stream data has arrived, and Data Read, reached after the application has read all of it. Even complete transport receipt and completed application reading are distinct states; application receipt begins between those endpoints and is not the same as either one.

ACK visibility is not a one-packet-one-receipt ledger. Under RFC 9000 §13.2, ack-eliciting packets force acknowledgment within the peer’s advertised maximum delay, subject to the protocol’s rules. Non-ack-eliciting packets can wait for other traffic. ACK frames can themselves be lost, and older ranges can eventually be omitted. A sender might never see an ACK for every packet that the receiver processed. Silence is therefore not immediate proof that processing failed.

Nor does a retransmission preserve packet identity. RFC 9000 §13.3 retransmits information rather than whole packets. The same STREAM offsets can reappear in a new frame inside a new packet number. Once a packet carrying that information is acknowledged, the sender generally stops retransmitting the acknowledged information. To reason about data delivery, operators must join ACK ranges to the frames originally carried, then to stream ID, offset, length and retransmission lineage. That joined record still proves only arrival at the transport queue.

The recovery algorithms use ACKs within the same limited scope. RFC 9002 §5.1 derives an RTT sample from the largest newly acknowledged ack-eliciting packet, with ACK Delay handling. That measures a transport feedback path, not application service time. RFC 9002 §6.1 uses later acknowledgments plus packet and time thresholds to infer loss while allowing for reordering. A missing ACK is not instant loss proof; a received ACK is not application-success proof.

The useful evidence is a ladder. First, preserve the connection and packet-number space, packet number, send time, receive-side processing time where available, ACK range and timestamp, ACK Delay, and the frames carried. Second, preserve STREAM ID, offsets, lengths, FIN state and every retransmission that carried the same bytes. Third, preserve the receiving stack’s enqueue event and the application’s read or callback event. Fourth, attach an application message or transaction ID, durable commit receipt, side-effect receipt and response.

Each rung answers a different question. The ACK can support “the peer processed this protected packet”. A stream-offset ledger can support “these bytes reached the peer’s transport receive queue”. An application callback can support “the process received these bytes”. A parser or protocol acknowledgment can support “the remote application accepted this message”. Only a durable transaction or externally observed effect can support “the requested action completed”.

This distinction is especially important when a success metric drives retries. Treating an ACK as application completion suppresses recovery while work is still queued or a process is deadlocked. Treating absent ACK visibility as immediate failure can duplicate a request that the peer already processed. Correct retry authority belongs to the layer that can identify the operation and state whether it is safe to repeat.

The strongest receipt is not the one closest to the wire. It is the narrowest chain that reaches the operational claim. QUIC supplies a precise transport fact. Applications must supply the rest.