Skip to main content

RFC 9221 - An Unreliable Datagram Extension to QUIC

Abstract​

This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.

Status of This Memo​

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 at 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 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.

Table of Contents​

    1. Introduction
    1. Motivation
    1. Transport Parameter
    1. Datagram Frame Types
    1. Behavior and Usage
    1. Security Considerations
    1. IANA Considerations
    1. References
  • Acknowledgments
  • Authors' Addresses

1. Introduction​

The QUIC transport protocol [RFC9000] provides a secure, multiplexed connection for transmitting reliable streams of application data. QUIC uses various frame types to transmit data within packets, and each frame type defines whether the data it contains will be retransmitted. Streams of reliable application 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 built directly upon UDP [RFC0768] as a transport and have often added security with DTLS [RFC6347]. Extending QUIC to support transmitting unreliable application data provides another option for secure datagrams with the added benefit of sharing the cryptographic and authentication context used for reliable streams.

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

1.1. Specification of Requirements​

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​

Transmitting unreliable data over QUIC provides benefits over existing solutions:

  • Applications that want to use both a reliable stream and an unreliable flow to the same peer can benefit by sharing a single handshake and authentication context between a reliable QUIC stream and a flow of unreliable QUIC datagrams. This can reduce the latency required for handshakes compared to opening both a TLS connection and a DTLS connection.
  • QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake. This can allow loss recovery to occur more quickly for QUIC data.
  • QUIC datagrams are subject to QUIC congestion control. Providing a single congestion control for both reliable and unreliable data can be more effective and efficient.

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 tunneling protocols generally require a reliable and authenticated handshake followed by unreliable secure communication.

3. Transport Parameter​

This document defines a new transport parameter, max_datagram_frame_size (value 0x20). This parameter represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) that the endpoint is willing to receive, in bytes.

4. Datagram Frame Types​

This document defines two new frame types:

  • DATAGRAM (0x30): A DATAGRAM frame containing application data. The frame does not contain a length field; the data extends to the end of the packet.
  • DATAGRAM_WITH_LEN (0x31): A DATAGRAM frame containing application data. The frame contains a length field.

5. Behavior and Usage​

5.1. Multiplexing Datagrams​

DATAGRAM frames are multiplexed with other QUIC frames within QUIC packets.

5.2. Acknowledgement Handling​

Although DATAGRAM frames are not retransmitted upon loss, they are acknowledged. This allows the sender to maintain congestion control state and potentially gather statistics about delivery.

5.3. Flow Control​

DATAGRAM frames are not subject to flow control. The max_datagram_frame_size transport parameter limits the size of individual frames, but there is no limit on the total number of bytes or frames.

5.4. Congestion Control​

DATAGRAM frames are congestion controlled. The sender MUST respect the congestion controller's limits when sending DATAGRAM frames.

6. Security Considerations​

The security considerations for this document are similar to those for QUIC [RFC9000]. The use of unreliable datagrams introduces some additional considerations, such as the potential for amplification attacks if the datagrams are used to reflect traffic.

7. IANA Considerations​

7.1. QUIC Transport Parameter​

This document registers a new value in the "QUIC Transport Parameters" registry:

  • 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:

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

8. References​

8.1. Normative References​

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

8.2. Informative References​

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-editor.org/info/rfc0768.

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, https://www.rfc-editor.org/info/rfc6347.

Acknowledgments​

The authors would like to thank...

Authors' Addresses​

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]

Last updated on