When an application sends a datagram over a QUIC connection, QUIC will generate a new DATAGRAM frame and send it in the first available packet. This frame SHOULD
be sent as soon as possible (as determined by factors like congestion control, described below) and MAY
be coalesced with other frames.
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.
Like STREAM frames, DATAGRAM frames contain application data and MUST
be protected with either 0-RTT or 1-RTT keys.
Note that while the max_datagram_frame_size transport parameter places a limit on the maximum size of DATAGRAM frames, that limit can be further reduced by the max_udp_payload_size transport parameter and the Maximum Transmission Unit (MTU) of the path between endpoints. DATAGRAM frames cannot be fragmented; therefore, application protocols need to handle cases where the maximum datagram size is limited by other factors.
DATAGRAM frames belong to a QUIC connection as a whole and are not associated with any stream ID at the QUIC layer. However, it is expected that applications will want to differentiate between specific DATAGRAM frames by using identifiers, such as for logical flows of datagrams or to distinguish between different kinds of datagrams.
Defining the identifiers used to multiplex different kinds of datagrams or flows of datagrams is the responsibility of the application protocol running over QUIC. The application defines the semantics of the Datagram Data field and how it is parsed.
If the application needs to support the coexistence of multiple flows of datagrams, one recommended pattern is to use a variable-length integer at the beginning of the Datagram Data field. This is a simple approach that allows a large number of flows to be encoded using minimal space.
QUIC implementations SHOULD
present an API to applications to assign relative priorities to DATAGRAM frames with respect to each other and to QUIC streams.
Although DATAGRAM frames are not retransmitted upon loss detection, they are ack-eliciting ([RFC 9002
]). Receivers SHOULD
support delaying ACK frames (within the limits specified by max_ack_delay) in response to receiving packets that only contain DATAGRAM frames, since the sender takes no action if these packets are temporarily unacknowledged. Receivers will continue to send ACK frames when conditions indicate a packet might be lost, since the packet's payload is unknown to the receiver, and when dictated by max_ack_delay or other protocol components.
As with any ack-eliciting frame, when a sender suspects that a packet containing only DATAGRAM frames has been lost, it sends probe packets to elicit a faster acknowledgement as described in Section 6.2.4
of RFC 9002
If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY
notify the application that it believes the datagram was lost.
Similarly, if a packet containing a DATAGRAM frame is acknowledged, the implementation MAY
notify the sender application that the datagram was successfully transmitted and received. Due to reordering, this can include a DATAGRAM frame that was thought to be lost but, at a later point, was received and acknowledged. It is important to note that acknowledgement of a DATAGRAM frame only indicates that the transport-layer handling on the receiver processed the frame and does not guarantee that the application on the receiver successfully processed the data. Thus, this signal cannot replace application-layer signals that indicate successful processing.
DATAGRAM frames do not provide any explicit flow control signaling and do not contribute to any per-flow or connection-wide data limit.
The risk associated with not providing flow control for DATAGRAM frames is that a receiver might not be able to commit the necessary resources to process the frames. For example, it might not be able to store the frame contents in memory. However, since DATAGRAM frames are inherently unreliable, they MAY
be dropped by the receiver if the receiver cannot process them.
DATAGRAM frames employ the QUIC connection's congestion controller. As a result, a connection might be unable to send a DATAGRAM frame generated by the application until the congestion controller allows it [RFC 9002
]. The sender MUST
either delay sending the frame until the controller allows it or drop the frame without sending it (at which point it MAY
notify the application). Implementations that use packet pacing (Section 7.7
of RFC 9002
) can also delay the sending of DATAGRAM frames to maintain consistent packet pacing.
Implementations can optionally support allowing the application to specify a sending expiration time beyond which a congestion-controlled DATAGRAM frame ought to be dropped without transmission.