Summary

  • QUIC DATAGRAM carries one application datagram unreliably and preserves its message boundary without retransmission or ordering relative to other DATAGRAM messages.
  • max_datagram_frame_size signals directional willingness to receive a frame, not capacity, delivery, or application processing.
  • A packet ACK is transport evidence: it cannot replace an application-layer confirmation or prove business completion.

The central mistake is to treat a successful local send as though it were a remote receipt. QUIC DATAGRAM deliberately narrows what the transport promises. One frame carries one application datagram. The receiver can distinguish that datagram from adjacent data, but the extension does not provide stream offsets, ordered byte delivery, or retransmission after loss detection. DATAGRAM messages are not ordered relative to other DATAGRAM messages. The message boundary survives; a delivery guarantee does not.

The QUIC DATAGRAM frame is not the same thing as the UDP datagram that carries a QUIC packet. A QUIC packet may be placed inside a UDP datagram, and that packet may contain a DATAGRAM frame. The application message is therefore separated from the outer carrier, the packet, and the transport evidence about that packet. Confusing those layers produces misleading operational records.

Support is negotiated directionally. A non-zero max_datagram_frame_size says that an endpoint is willing to receive conforming DATAGRAM frames in that direction. The default is zero. A sender must not send before the required handshake signal, or under the applicable retained 0-RTT conditions, and must not exceed the peer’s advertised value. None of those facts establishes available application memory, eventual delivery, or processing. The effective ceiling may be lower because of max_udp_payload_size and the path MTU. DATAGRAM frames cannot be fragmented by this extension, so the application must accommodate the smaller usable maximum.

The frame’s semantics also stop short of application identity. DATAGRAM frames belong to the QUIC connection as a whole and have no QUIC stream ID. The application protocol must define logical flow identifiers, payload interpretation, expiry, deduplication, ordering where needed, and completion signals. QUIC cannot infer whether two payloads are attempts at the same business action or unrelated messages.

Sending is conditional. After local submission, QUIC generates a new frame and seeks to send it in the first available packet, subject to congestion control and pacing. If congestion control does not permit transmission, the implementation must retain the frame until permitted or drop it without transmission. An application expiry can also authorize a pre-transmission drop. A successful API return must therefore be described according to that API’s actual contract; RFC 9221 does not make it a wire-transmission receipt, peer-receipt receipt, or application-completion receipt.

On the receiving side, a valid frame should be delivered to the application immediately only when the endpoint can process it and retain its contents in memory. DATAGRAM has no explicit flow control, and its data does not count toward stream or connection-wide data limits. That absence of blocking is not evidence of receiver capacity. A receiver may drop a frame it cannot process.

DATAGRAM frames are acknowledgment-eliciting. The containing packet can be acknowledged, and a sender can observe loss or receive a notification that the packet was acknowledged. A receiver may delay acknowledgment within ordinary bounds; because the frame is not retransmitted after loss detection, the absence of an immediate ACK does not create a retransmission of that message. Probe packets may seek a faster acknowledgment. Reordering can later reverse a provisional belief that the packet was lost.

What does an ACK prove? It proves receiver transport-layer processing of the frame’s packet. It does not prove successful receiver-application processing, durable storage, business acceptance, or completion. Those require application-defined evidence.

The clean ledger keeps application identity; local admission and API result; expiry or discard policy; negotiated support and effective size; congestion or pacing delay; any local pre-transmission drop; the containing packet number and packet-number space; ACK or loss observations, including reversals; receiver transport admission; receiver application processing; and durable or business completion separate.