| RFC 9221 | QUIC Datagrams | March 2022 |
| Pauly, et al. | Standards Track | [Page] |
This document defines an extension to the QUIC transport protocol to add supportfor sending and receiving unreliable datagrams over a QUIC connection.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9221.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The QUIC transport protocol[RFC9000] provides a secure, multiplexedconnection for transmitting reliable streams of application data. QUIC usesvarious frame types to transmit data within packets, and each frame typedefines whether the data it contains will be retransmitted. Streams of reliableapplication data are sent using STREAM frames.¶
Some applications, particularly those that need to transmit real-time data,prefer to transmit data unreliably. In the past, these applications have builtdirectly upon UDP[RFC0768] as a transport and have often added securitywith DTLS[RFC6347]. Extending QUIC to support transmitting unreliableapplication data provides another option for secure datagrams with the addedbenefit of sharing the cryptographic and authentication context used forreliable streams.¶
This document defines two new DATAGRAM QUIC frame types that carry applicationdata without requiring retransmissions.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Transmitting unreliable data over QUIC provides benefits over existing solutions:¶
These features can be useful for optimizing audio/video streaming applications,gaming applications, and other real-time network applications.¶
Unreliable QUIC datagrams can also be used to implement an IP packet tunnel over QUIC, such as for a Virtual Private Network (VPN). Internet-layer tunnelingprotocols generally require a reliable and authenticated handshake followed byunreliable secure transmission of IP packets. This can, for example, require aTLS connection for the control data and DTLS for tunneling IP packets. A singleQUIC connection could support both parts with the use of unreliable datagrams in addition to reliable streams.¶
Support for receiving the DATAGRAM frame types is advertised by means of a QUICtransport parameter (name=max_datagram_frame_size, value=0x20). Themax_datagram_frame_size transport parameter is an integer value (represented asa variable-length integer) that represents the maximum size of a DATAGRAM frame(including the frame type, length, and payload) the endpoint is willing toreceive, in bytes.¶
The default for this parameter is 0, which indicates that the endpoint does notsupport DATAGRAM frames. A value greater than 0 indicates that the endpointsupports the DATAGRAM frame types and is willing to receive such frames on thisconnection.¶
An endpointMUST NOT send DATAGRAM frames until it has received themax_datagram_frame_size transport parameter with a non-zero value during thehandshake (or during a previous handshake if 0-RTT is used). An endpointMUST NOT send DATAGRAM frames that are larger than the max_datagram_frame_size valueit has received from its peer. An endpoint that receives a DATAGRAM frame whenit has not indicated support via the transport parameterMUST terminate theconnection with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint thatreceives a DATAGRAM frame that is larger than the value it sent in itsmax_datagram_frame_size transport parameterMUST terminate the connection withan error of type PROTOCOL_VIOLATION.¶
For most uses of DATAGRAM frames, it isRECOMMENDED to send a value of 65535 inthe max_datagram_frame_size transport parameter to indicate that this endpointwill accept any DATAGRAM frame that fits inside a QUIC packet.¶
The max_datagram_frame_size transport parameter is a unidirectional limit andindication of support of DATAGRAM frames. Application protocols that useDATAGRAM framesMAY choose to only negotiate and use them in a single direction.¶
When clients use 0-RTT, theyMAY store the value of the server'smax_datagram_frame_size transport parameter. Doing so allows the client to sendDATAGRAM frames in 0-RTT packets. When servers decide to accept 0-RTT data,theyMUST send a max_datagram_frame_size transport parameter greater than orequal to the value they sent to the client in the connection where they sentthem the NewSessionTicket message. If a client stores the value of themax_datagram_frame_size transport parameter with their 0-RTT state, theyMUSTvalidate that the new value of the max_datagram_frame_size transport parametersent by the server in the handshake is greater than or equal to the storedvalue; if not, the clientMUST terminate the connection with errorPROTOCOL_VIOLATION.¶
Application protocols that use datagramsMUST define how they react to theabsence of the max_datagram_frame_size transport parameter. If datagram supportis integral to the application, the application protocol can fail the handshakeif the max_datagram_frame_size transport parameter is not present.¶
DATAGRAM frames are used to transmit application data in an unreliable manner.The Type field in the DATAGRAM frame takes the form 0b0011000X (or the values0x30 and 0x31). The least significant bit of the Type field in the DATAGRAMframe is the LEN bit (0x01), which indicates whether there is a Length fieldpresent: if this bit is set to 0, the Length field is absent and the DatagramData field extends to the end of the packet; if this bit is set to 1, theLength field is present.¶
DATAGRAM frames are structured as follows:¶
DATAGRAM Frame { Type (i) = 0x30..0x31, [Length (i)], Datagram Data (..),}DATAGRAM frames contain the following fields:¶
A variable-length integer specifying the length of the Datagram Data field inbytes. This field is present only when the LEN bit is set to 1. When the LEN bitis set to 0, the Datagram Data field extends to the end of the QUIC packet. Notethat empty (i.e., zero-length) datagrams are allowed.¶
The bytes of the datagram to be delivered.¶
When an application sends a datagram over a QUIC connection, QUIC will generatea new DATAGRAM frame and send it in the first available packet. This frameSHOULD be sent as soon as possible (as determined by factors like congestioncontrol, described below) andMAY be coalesced with other frames.¶
When a QUIC endpoint receives a valid DATAGRAM frame, itSHOULD deliver the datato the application immediately, as long as it is able to process the frame andcan store the contents in memory.¶
Like STREAM frames, DATAGRAM frames contain application data andMUST beprotected with either 0-RTT or 1-RTT keys.¶
Note that while the max_datagram_frame_size transport parameter places a limiton the maximum size of DATAGRAM frames, that limit can be further reduced by themax_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 maximumdatagram size is limited by other factors.¶
DATAGRAM frames belong to a QUIC connection as a whole and are not associatedwith any stream ID at the QUIC layer. However, it is expected that applicationswill want to differentiate between specific DATAGRAM frames by usingidentifiers, such as for logical flows of datagrams or to distinguish betweendifferent 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 andhow it is parsed.¶
If the application needs to support the coexistence of multiple flows ofdatagrams, one recommended pattern is to use a variable-length integer at thebeginning of the Datagram Data field. This is a simple approach that allows alarge number of flows to be encoded using minimal space.¶
QUIC implementationsSHOULD present an API to applications to assign relativepriorities to DATAGRAM frames with respect to each other and to QUIC streams.¶
Although DATAGRAM frames are not retransmitted upon loss detection, they areack-eliciting ([RFC9002]). ReceiversSHOULD support delaying ACK frames(within the limits specified by max_ack_delay) in response to receiving packetsthat only contain DATAGRAM frames, since the sender takes no action if thesepackets are temporarily unacknowledged. Receivers will continue to send ACKframes when conditions indicate a packet might be lost, since the packet'spayload is unknown to the receiver, and when dictated by max_ack_delay or otherprotocol components.¶
As with any ack-eliciting frame, when a sender suspects that a packet containingonly DATAGRAM frames has been lost, it sends probe packets to elicit a fasteracknowledgement as described inSection 6.2.4 of [RFC9002].¶
If a sender detects that a packet containing a specific DATAGRAM frame mighthave been lost, the implementationMAY notify the application that it believesthe datagram was lost.¶
Similarly, if a packet containing a DATAGRAM frame is acknowledged, theimplementationMAY notify the sender application that the datagram wassuccessfully transmitted and received. Due to reordering, this can include aDATAGRAM frame that was thought to be lost but, at a later point, wasreceived and acknowledged. It is important to note that acknowledgement of aDATAGRAM frame only indicates that the transport-layer handling on the receiverprocessed the frame and does not guarantee that the application on the receiversuccessfully processed the data. Thus, this signal cannot replaceapplication-layer signals that indicate successful processing.¶
DATAGRAM frames do not provide any explicit flow control signaling and do notcontribute to any per-flow or connection-wide data limit.¶
The risk associated with not providing flow control for DATAGRAM frames is thata receiver might not be able to commit the necessary resources to process theframes. For example, it might not be able to store the frame contents in memory.However, since DATAGRAM frames are inherently unreliable, theyMAY be dropped bythe 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 theapplication until the congestion controller allows it[RFC9002]. The senderMUST either delay sending the frame until the controller allows it or drop theframe without sending it (at which point itMAY notify the application).Implementations that use packet pacing (Section 7.7 of [RFC9002]) can also delay the sending of DATAGRAM frames to maintain consistent packet pacing.¶
Implementations can optionally support allowing the application to specify asending expiration time beyond which a congestion-controlled DATAGRAM frameought to be dropped without transmission.¶
The DATAGRAM frame shares the same security properties as the rest of the datatransmitted within a QUIC connection, and the security considerations of[RFC9000] apply accordingly. All application data transmitted with theDATAGRAM frame, like the STREAM frame,MUST be protected either by 0-RTT or1-RTT keys.¶
Application protocols that allow DATAGRAM frames to be sent in 0-RTT require aprofile that defines acceptable use of 0-RTT; seeSection 5.6 of [RFC9001].¶
The use of DATAGRAM frames might be detectable by an adversary on path that iscapable of dropping packets. Since DATAGRAM frames do not use transport-levelretransmission, connections that use DATAGRAM frames might be distinguished fromother connections due to their different response to packet loss.¶
This document registers a new value in the "QUIC Transport Parameters" registrymaintained at<https://www.iana.org/assignments/quic>.¶
This document registers two new values in the "QUIC Frame Types" registrymaintained at<https://www.iana.org/assignments/quic>.¶
The original proposal for this work came fromIan Swett.¶
This document had reviews and input from many contributors in the IETF QUICWorking Group, with substantive input fromNick Banks,Lucas Pardue,Rui Paulo,Martin Thomson,Victor Vasiliev, andChris Wood.¶