An Unreliable Datagram Extension to QUIC
Extracted elements (24)
Applications sharing a QUIC connection can use both reliable STREAM frames and unreliable DATAGRAM frames over a single handshake and authentication context, reducing latency compared to maintaining separate TLS and DTLS connections. QUIC datagrams also share a single congestion controller, which is more efficient than separate controllers.
DATAGRAM frames have no stream ID at the QUIC layer; multiplexing of datagram flows is the responsibility of the application protocol. A recommended pattern is to use a variable-length integer at the start of the Datagram Data field to distinguish flows, allowing many flows with minimal overhead.
DATAGRAM frames provide no explicit flow control and do not contribute to per-flow or connection-wide data limits. The rationale is that datagrams are inherently unreliable and MAY be dropped by the receiver if it cannot process them, making explicit flow control unnecessary.
Unreliable QUIC datagrams can implement IP packet tunnels (e.g., VPNs) over a single QUIC connection, replacing the pattern of a TLS connection for control data and DTLS for tunneling IP packets.
The maximum datagram size usable in practice may be further constrained beyond max_datagram_frame_size by the max_udp_payload_size transport parameter and the path MTU between endpoints. DATAGRAM frames cannot be fragmented, so application protocols must handle cases where the effective maximum datagram size is smaller than max_datagram_frame_size.
An endpoint MUST NOT send DATAGRAM frames larger than the max_datagram_frame_size value received from its peer. An endpoint that receives an oversized DATAGRAM frame or one received when support was not indicated MUST terminate the connection with PROTOCOL_VIOLATION.
An endpoint MUST NOT send DATAGRAM frames until it has received the max_datagram_frame_size transport parameter with a non-zero value during the handshake (or during a previous handshake if 0-RTT is used).
Application protocols that use datagrams MUST define how they react to the absence of the max_datagram_frame_size transport parameter, and may fail the handshake if datagram support is integral.
DATAGRAM frames contain application data and MUST be protected with either 0-RTT or 1-RTT keys, the same as STREAM frames.
DATAGRAM frames use the QUIC connection's congestion controller. The sender MUST either delay sending the frame until the controller allows it, or drop the frame without sending it (and MAY notify the application of the drop).
For most uses of DATAGRAM frames, it is RECOMMENDED to send a value of 65535 in the max_datagram_frame_size transport parameter to indicate acceptance of any DATAGRAM frame that fits inside a QUIC packet.
QUIC implementations SHOULD present an API to applications to assign relative priorities to DATAGRAM frames with respect to each other and to QUIC streams.
When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD deliver the data to the application immediately, as long as it is able to process the frame and can store the contents in memory.
When an application sends a datagram, the resulting DATAGRAM frame SHOULD be sent as soon as possible (subject to congestion control) and MAY be coalesced with other frames.
When servers accept 0-RTT data, they MUST send a max_datagram_frame_size transport parameter greater than or equal to the value sent in the connection where the NewSessionTicket message was sent. Clients using stored 0-RTT state MUST validate the new parameter is >= the stored value, or terminate with PROTOCOL_VIOLATION.
Acknowledgement of a DATAGRAM frame only indicates that the transport-layer receiver processed the frame; it does not guarantee that the application successfully processed the data. Application-layer signals are needed for confirmed end-to-end delivery.
Although DATAGRAM frames are not retransmitted upon loss, they are ack-eliciting. Receivers SHOULD support delaying ACK frames (within max_ack_delay limits) for packets containing only DATAGRAM frames, since the sender takes no action on temporary non-acknowledgement.
The Length field in a DATAGRAM frame is a variable-length integer specifying the length of the Datagram Data field in bytes, present only when the LEN bit is set to 1. When LEN=0, Datagram Data extends to the end of the QUIC packet. Zero-length datagrams are allowed.
The max_datagram_frame_size transport parameter (value=0x20) advertises support for receiving DATAGRAM frames. It is a variable-length integer representing the maximum size (in bytes) of a DATAGRAM frame the endpoint is willing to receive, including frame type, length, and payload. Default is 0, meaning no support.
This document registers the DATAGRAM frame type (values 0x30-0x31, status permanent) in the IANA QUIC Frame Types registry.
This document registers the max_datagram_frame_size transport parameter (value 0x20, status permanent) in the IANA QUIC Transport Parameters registry.
DATAGRAM frames share the same security properties as all other QUIC connection data; all application data in DATAGRAM frames MUST be protected by 0-RTT or 1-RTT keys. Application protocols allowing DATAGRAM frames in 0-RTT require a profile defining acceptable 0-RTT use per RFC 9001 Section 5.6.
The use of DATAGRAM frames may be detectable by an on-path adversary capable of dropping packets. Because DATAGRAM frames are not retransmitted, connections using them may be distinguished from other connections by their different response to packet loss.
DATAGRAM frames use Type field values 0x30 (no Length field) and 0x31 (Length field present). The LEN bit (0x01, least significant bit) controls presence of the Length field. Format: Type (i) = 0x30..0x31, optional Length (variable-length integer), Datagram Data (..).