Acknowledge receipt without promising retransmission
05A DATAGRAM is unreliable but still ack-eliciting: receiving its packet contributes to QUIC acknowledgments. Transport receipt and application success are different events.
A reordered packet 10 can later be handled and acknowledged. The optional sender notification changes from suspected loss to transport receipt, not to proof of application success.
Source for this drawing: RFC 9221 · Read RFC section 5.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Ack-eliciting
- A frame whose packet causes acknowledgment behavior under QUIC rules.
- Probe
- A packet sent by loss recovery to elicit feedback, not a DATAGRAM retransmission.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DATAGRAM frames are not retransmitted on loss detection, but they are ack-eliciting. An acknowledged DATAGRAM indicates receiver transport handling, not successful application processing.
- DATAGRAM frames are not retransmitted on loss detection, but they are ack-eliciting. An acknowledged DATAGRAM indicates receiver transport handling, not successful application processing.
- An implementation MAY notify the sender application about an acknowledged datagram or suspected loss. Reordering can later produce an acknowledgment for a datagram previously thought lost, so a loss signal is not a final delivery proof.
- Receivers SHOULD support delayed ACKs for DATAGRAM-only packets within max_ack_delay and other QUIC conditions. This does not mean acknowledgments can be omitted indefinitely.
- A sender suspecting loss of a DATAGRAM-only packet sends probe packets under QUIC loss recovery. A probe is not a retransmission of the lost DATAGRAM payload.
- If the application needs proof that an update was processed, it needs an appropriate application-layer signal. A transport ACK cannot replace that signal.
Packet numbers10 and11 and payload D are illustrative. One state shows a normally received packet; another shows a delayed/lost packet and a distinct probe; the last shows a late acknowledgment. Probe PING is a schematic choice with no copy of payload D. No actual packet trace or delivery measurement is claimed.
Read the RFC section ↗