RFC 9221

An Unreliable Datagram Extension to QUIC

📅 published March 2022, from ietf

RFC 9221: An Unreliable Datagram Extension to QUIC 🦋

Okay bestie, here's the tea 🫖. This is RFC 9221, titled An Unreliable Datagram Extension to QUIC, and it's a Standards Track document from March 2022 (ISSN 2070-1721). The authors are T. Pauly and E. Kinnear from Apple Inc., plus D. Schinazi from Google LLC. The header doesn't list anything it obsoletes or updates, so it's a clean slate ✨.

Abstract

Okay so the abstract is giving elevator pitch 💅. This doc adds an extension to the QUIC transport protocol so you can send and receive unreliable datagrams over a QUIC connection. That's it, that's the whole vibe 🦋.

Status of This Memo

This is an Internet Standards Track document 👑.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🧚.

For the current status, any errata, and how to give feedback, head to https://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 read these carefully, bestie, because they spell out your rights and restrictions for 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 they come without warranty as described in the Revised BSD License 🫶.

Table of Contents 🧚

1.  Introduction
  1.1.  Specification of Requirements
2.  Motivation
3.  Transport Parameter
4.  Datagram Frame Types
5.  Behavior and Usage
  5.1.  Multiplexing Datagrams
  5.2.  Acknowledgement Handling
  5.3.  Flow Control
  5.4.  Congestion Control
6.  Security Considerations
7.  IANA Considerations
  7.1.  QUIC Transport Parameter
  7.2.  QUIC Frame Types
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction ✨

Okay so the QUIC transport protocol [RFC9000] gives you a secure, multiplexed connection for sending reliable streams of application data 🔐. QUIC uses different frame types to carry data inside packets, and each frame type decides whether its data gets retransmitted. Reliable application data travels in STREAM frames 💖.

Some apps, especially real-time ones, would rather send data unreliably 🎮. Back in the day, these apps built straight on top of UDP [RFC0768] and often bolted on security with DTLS [RFC6347]. Extending QUIC to carry unreliable application data gives them another option for secure datagrams, and the bonus is they get to share the cryptographic and authentication context that reliable streams already use 🦋.

This document defines two new DATAGRAM QUIC frame types that carry application data without requiring retransmissions 🌸.

1.1. Specification of Requirements

Here's the rule book for the key words. 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 🎀.

2. Motivation 💅

Sending unreliable data over QUIC has some perks compared to existing solutions:

  • Apps that want a reliable stream and an unreliable flow to the same peer can share a single handshake and authentication context between a reliable QUIC stream and a flow of unreliable QUIC datagrams 🤝. That can cut the handshake latency you'd get from opening both a TLS connection and a DTLS connection.
  • QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake 🔁. That can let loss recovery happen more quickly for QUIC data ⚡.
  • QUIC datagrams are subject to QUIC congestion control 🚦. Having one congestion control for both reliable and unreliable data can be more effective and efficient 💜.

These features can be super useful for optimizing audio/video streaming apps, gaming apps, and other real-time network apps 🎧🎮.

Unreliable QUIC datagrams can also be used to build an IP packet tunnel over QUIC, like for a Virtual Private Network (VPN) 🔒. Internet-layer tunneling protocols usually need a reliable and authenticated handshake, followed by unreliable secure transmission of IP packets. For example, that could mean a TLS connection for the control data and DTLS for tunneling IP packets. A single QUIC connection could support both parts by using unreliable datagrams alongside reliable streams 🧚.

3. Transport Parameter 🎀

Support for receiving DATAGRAM frame types gets advertised with a QUIC transport parameter (name=max_datagram_frame_size, value=0x20) 📣. The max_datagram_frame_size transport parameter is an integer value (represented as a variable-length integer). It represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) that the endpoint is willing to receive, in bytes 📏.

The default for this parameter is 0, which means the endpoint does not support DATAGRAM frames 🙅‍♀️. A value greater than 0 means the endpoint supports the DATAGRAM frame types and is willing to receive such frames on this connection 🥳.

Okay, rule number one: 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) 🚫. Rule number two: an endpoint MUST NOT send DATAGRAM frames that are larger than the max_datagram_frame_size value it received from its peer 📐. An endpoint that receives a DATAGRAM frame when it hasn't indicated support via the transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint that receives a DATAGRAM frame larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION 💀.

Bestie, these two terminate rules are serious. Get the size and the support flag right, or the connection is toast 🍞.

For most uses of DATAGRAM frames, it is RECOMMENDED to send a value of 65535 in the max_datagram_frame_size transport parameter 🌟. That tells the peer this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet 🎁.

The max_datagram_frame_size transport parameter is a unidirectional limit and also an indication of support for DATAGRAM frames 🧭. Application protocols that use DATAGRAM frames MAY choose to only negotiate and use them in a single direction 👉.

Now for 0-RTT. When clients use 0-RTT, they MAY store the value of the server's max_datagram_frame_size transport parameter 🗂️. Doing so lets the client send DATAGRAM frames in 0-RTT packets 🚀. When servers decide to accept 0-RTT data, they MUST send a max_datagram_frame_size transport parameter greater than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message 🎫. If a client stores the value of the max_datagram_frame_size transport parameter with its 0-RTT state, it MUST validate that the new value sent by the server in the handshake is greater than or equal to the stored value. If not, the client MUST terminate the connection with error PROTOCOL_VIOLATION 😱.

Application protocols that use datagrams MUST define how they react to the absence of the max_datagram_frame_size transport parameter 🧐. If datagram support is integral to the application, the application protocol can fail the handshake when the max_datagram_frame_size transport parameter isn't present 🙅.

4. Datagram Frame Types 🧚‍♀️

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 values 0x30 and 0x31). The least significant bit of the Type field is the LEN bit (0x01), and it tells you whether a Length field is present. If this bit is set to 0, the Length field is absent and the Datagram Data field extends to the end of the packet. If this bit is set to 1, the Length field is present 🔍.

DATAGRAM frames are structured like this 👇:

DATAGRAM Frame {
  Type (i) = 0x30..0x31,
  [Length (i)],
  Datagram Data (..),
}
                  Figure 1: DATAGRAM Frame Format

DATAGRAM frames contain the following fields 🍓:

  • Length: A variable-length integer specifying the length of the Datagram Data field in bytes. This field is present only when the LEN bit is set to 1. When the LEN bit is set to 0, the Datagram Data field extends to the end of the QUIC packet. Also, empty (i.e., zero-length) datagrams are allowed 🫧.
  • Datagram Data: The bytes of the datagram to be delivered 📦.

5. Behavior and Usage 🌈

When an application sends a datagram over a QUIC connection, QUIC generates a new DATAGRAM frame and sends it in the first available packet 📨. This frame SHOULD be sent as soon as possible (as determined by factors like congestion control, described below) 🏃‍♀️. It MAY be coalesced with other frames too 🧩.

When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD deliver the data to the application immediately, as long as it can process the frame and 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 🔐.

Here's a lowkey important note 👀. The max_datagram_frame_size transport parameter places a limit on the maximum size of DATAGRAM frames, but that limit can be reduced even further by the max_udp_payload_size transport parameter and by the Maximum Transmission Unit (MTU) of the path between endpoints 📉. DATAGRAM frames cannot be fragmented, so application protocols need to handle cases where the maximum datagram size is limited by other factors 🧃.

5.1. Multiplexing Datagrams 🦋

DATAGRAM frames belong to a QUIC connection as a whole, and they aren't associated with any stream ID at the QUIC layer 🌊. Still, applications will probably want to tell specific DATAGRAM frames apart using identifiers, like 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 gets parsed 📖.

If the application needs to support multiple flows of datagrams at once, one recommended pattern is to use a variable-length integer at the beginning of the Datagram Data field 🔢. It's a simple approach that lets a large number of flows be encoded using minimal space 🤏.

QUIC implementations SHOULD present an API to applications so they can assign relative priorities to DATAGRAM frames with respect to each other and to QUIC streams 🎛️✨.

Part 1 ends here, and part 2 is coming with the rest of the goodies 🫶🌸.

5.2. Acknowledgement Handling 💌

Okay so DATAGRAM frames are not retransmitted when they get lost 😭, but they are still ack-eliciting ([RFC9002]), which means the other side still has to reply with an ACK. 🦋 Receivers SHOULD support delaying ACK frames (within the limits specified by max_ack_delay) when they get packets that only contain DATAGRAM frames, because the sender doesn't do anything if those packets stay unacknowledged for a bit. ✨ Receivers will still send ACK frames when things look like a packet might be lost, since the receiver can't see what's inside the payload, and whenever max_ack_delay or other protocol components say so. 💅

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 get a faster acknowledgement, as described in Section 6.2.4 of [RFC9002]. 🚀

If a sender detects that a packet with a specific DATAGRAM frame might have been lost, the implementation MAY tell the application that it believes the datagram was lost. 🌸

It works the other way too! If a packet containing a DATAGRAM frame gets acknowledged, the implementation MAY tell the sender's application that the datagram was successfully sent and received. 🎀 Because of reordering, this can include a DATAGRAM frame that was thought to be lost but later turned up and got acknowledged. 🙈

⚠️ Bestie, this next part is important: an acknowledgement of a DATAGRAM frame only means the transport layer on the receiver handled the frame. It does NOT guarantee the receiver's application actually processed the data. So this signal can't replace application-layer signals that show the data was processed successfully. 💀

5.3. Flow Control 🌊

DATAGRAM frames don't give any explicit flow control signaling, and they don't count toward any per-flow or connection-wide data limit. 🙅‍♀️

The risk of not having flow control for DATAGRAM frames is that a receiver might not be able to set aside the resources it needs to process them. For example, it might not be able to store the frame contents in memory. 😬 But since DATAGRAM frames are inherently unreliable, they MAY be dropped by the receiver if it can't process them. 🫶

5.4. Congestion Control 🚦

DATAGRAM frames use the QUIC connection's congestion controller. 🧠 That means a connection might not be able to send a DATAGRAM frame the application generated until the congestion controller allows it [RFC9002]. The sender MUST either delay sending the frame until the controller allows it, or drop the frame without sending it (and at that point it MAY tell the application). 👑 Implementations that use packet pacing (Section 7.7 of [RFC9002]) can also delay sending DATAGRAM frames to keep packet pacing consistent. ✨

Implementations can optionally support letting the application specify a sending expiration time. After that time, a congestion-controlled DATAGRAM frame ought to be dropped without being transmitted. ⏰

6. Security Considerations 🔐

The DATAGRAM frame has the same security properties as the rest of the data sent within a QUIC connection, so the security considerations of [RFC9000] apply to it too. 🛡️ All application data sent with the DATAGRAM frame, just like the STREAM frame, MUST be protected by either 0-RTT or 1-RTT keys. 🔑

Application protocols that let DATAGRAM frames be sent in 0-RTT require a profile that defines acceptable use of 0-RTT. Check Section 5.6 of [RFC9001] for that. 📜

The use of DATAGRAM frames might be detectable by an adversary on the path who is able to drop packets. 👀 Since DATAGRAM frames don't use transport-level retransmission, connections that use them might be told apart from other connections because they respond to packet loss differently. 🕵️‍♀️ Be careful out there, bestie!! 😭💜

7. IANA Considerations 📋

7.1. QUIC Transport Parameter 🎀

This document registers a new value in the "QUIC Transport Parameters" registry, which is maintained at https://www.iana.org/assignments/quic. 🌈

Value:  0x20
Parameter Name:  max_datagram_frame_size
Status:  permanent
Specification:  RFC 9221

7.2. QUIC Frame Types 🦋

This document registers two new values in the "QUIC Frame Types" registry, which is also maintained at https://www.iana.org/assignments/quic. 🍓

Value:  0x30-0x31
Frame Name:  DATAGRAM
Status:  permanent
Specification:  RFC 9221

8. References 📚

8.1. Normative References 💖

8.2. Informative References 🧚

Acknowledgments 🫶

The original proposal for this work came from Ian Swett. 👑

This document had reviews and input from many contributors in the IETF QUIC Working Group, with substantive input from Nick Banks, Lucas Pardue, Rui Paulo, Martin Thomson, Victor Vasiliev, and Chris Wood. 💕

Authors' Addresses 💌

Tommy Pauly
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Email: tpauly@apple.com

Eric Kinnear
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Email: ekinnear@apple.com

David Schinazi
Google LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: dschinazi.ietf@gmail.com
📦 where this page comes from