RFC 9221 / START HERE
QUIC DATAGRAM, before the details
QUIC DATAGRAM is the name of an extension for unreliable messages within a QUIC connection. QUIC is a protocol name, not expanded as an acronym here.
It lets an application send separate messages called datagrams over the same protected connection as reliable streams. Lost datagrams are not retransmitted by the transport. The receiver advertises whether it accepts them and a maximum encoded frame size.
The idea in one picture
Advertise receive limit
Send protected message
Handle loss + processing
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Some real-time updates lose value if retransmitted late. RFC 9221 adds two frame types, receive-limit negotiation and datagram behavior while retaining QUIC security and congestion control. It complements RFC 9000 instead of replacing it. Current RFC Editor metadata lists Proposed Standard, April 2022, with no formal updates or obsoletions.
A familiar example
A fictional application uses a reliable stream for configuration and datagrams for short position updates. If an update is lost, a newer update may be more useful than resending the old one. A transport ACK still does not prove the receiving application processed an update, and an application that needs that proof must define its own signal.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Advertise a receive limit for each directionQUIC peers negotiate support for receiving DATAGRAM frames with a transport parameter called max_datagram_frame_size. Each endpoint’s value describes what that endpoint can receive, not what it can send.→
- Read the two DATAGRAM frame layoutsA DATAGRAM frame has a type and application bytes. The least-significant bit of its type decides whether an explicit Length field is present. Length counts only the Datagram Data bytes.→
- Fit the whole frame without fragmentationA large peer receive limit does not guarantee that much payload fits on a path. The sender also has to fit the frame inside a QUIC packet subject to UDP size, path MTU and other packet contents.→
- Keep datagrams connection-wide and application-definedReliable streams and unreliable datagrams can share one QUIC connection and its security context. A DATAGRAM has no QUIC stream ID; the application defines any identifiers inside the data.→
- Acknowledge receipt without promising retransmissionA DATAGRAM is unreliable but still ack-eliciting: receiving its packet contributes to QUIC acknowledgments. Transport receipt and application success are different events.→
- Share congestion control and discard stale sendsNo DATAGRAM flow-control credits does not mean unlimited sending. Reliable and unreliable traffic use the QUIC connection’s congestion controller, which regulates load on the network.→
- Protect application data and validate remembered 0-RTT limitsDATAGRAM application data uses QUIC’s protected application-data keys. Early data can use a remembered server receive limit, but resumption must preserve the relevant limit checks and application replay policy.→
This introduction explains RFC 9221 (2022). Read the original RFC ↗