idnits 2.17.1 draft-ietf-quic-datagram-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 February 2022) is 812 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC T. Pauly 3 Internet-Draft E. Kinnear 4 Intended status: Standards Track Apple Inc. 5 Expires: 8 August 2022 D. Schinazi 6 Google LLC 7 4 February 2022 9 An Unreliable Datagram Extension to QUIC 10 draft-ietf-quic-datagram-10 12 Abstract 14 This document defines an extension to the QUIC transport protocol to 15 add support for sending and receiving unreliable datagrams over a 16 QUIC connection. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Discussion of this document takes place on the QUIC Working Group 23 mailing list (mailto:quic@ietf.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/quic/. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/quicwg/datagram. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 8 August 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 64 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 4 66 4. Datagram Frame Types . . . . . . . . . . . . . . . . . . . . 5 67 5. Behavior and Usage . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Multiplexing Datagrams . . . . . . . . . . . . . . . . . 6 69 5.2. Acknowledgement Handling . . . . . . . . . . . . . . . . 7 70 5.3. Flow Control . . . . . . . . . . . . . . . . . . . . . . 7 71 5.4. Congestion Control . . . . . . . . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 7.1. QUIC Transport Parameter . . . . . . . . . . . . . . . . 8 75 7.2. QUIC Frame Types . . . . . . . . . . . . . . . . . . . . 9 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 9.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 The QUIC Transport Protocol [RFC9000] provides a secure, multiplexed 85 connection for transmitting reliable streams of application data. 86 QUIC uses various frame types to transmit data within packets, and 87 each frame type defines whether the data it contains will be 88 retransmitted. Streams of reliable application data are sent using 89 STREAM frames. 91 Some applications, particularly those that need to transmit real-time 92 data, prefer to transmit data unreliably. In the past, these 93 applications have built directly upon UDP [RFC0768] as a transport 94 and have often added security with DTLS [RFC6347]. Extending QUIC to 95 support transmitting unreliable application data provides another 96 option for secure datagrams with the added benefit of sharing the 97 cryptographic and authentication context used for reliable streams. 99 This document defines two new DATAGRAM QUIC frame types which carry 100 application data without requiring retransmissions. 102 1.1. Specification of Requirements 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 2. Motivation 112 Transmitting unreliable data over QUIC provides benefits over 113 existing solutions: 115 * Applications that want to use both a reliable stream and an 116 unreliable flow to the same peer can benefit by sharing a single 117 handshake and authentication context between a reliable QUIC 118 stream and a flow of unreliable QUIC datagrams. This can reduce 119 the latency required for handshakes compared to opening both a TLS 120 connection and a DTLS connection. 122 * QUIC uses a more nuanced loss recovery mechanism than the DTLS 123 handshake. This can allow loss recovery to occur more quickly for 124 QUIC data. 126 * QUIC datagrams are subject to QUIC congestion control. Providing 127 a single congestion control for both reliable and unreliable data 128 can be more effective and efficient. 130 These features can be useful for optimizing audio/video streaming 131 applications, gaming applications, and other real-time network 132 applications. 134 Unreliable QUIC datagrams can also be used to implement an IP packet 135 tunnel over QUIC, such as for a Virtual Private Network (VPN). 136 Internet-layer tunneling protocols generally require a reliable and 137 authenticated handshake followed by unreliable secure transmission of 138 IP packets. This can, for example, require a TLS connection for the 139 control data and DTLS for tunneling IP packets. A single QUIC 140 connection could support both parts with the use of unreliable 141 datagrams in addition to reliable streams. 143 3. Transport Parameter 145 Support for receiving the DATAGRAM frame types is advertised by means 146 of a QUIC Transport Parameter (name=max_datagram_frame_size, 147 value=0x20). The max_datagram_frame_size transport parameter is an 148 integer value (represented as a variable-length integer) that 149 represents the maximum size of a DATAGRAM frame (including the frame 150 type, length, and payload) the endpoint is willing to receive, in 151 bytes. 153 The default for this parameter is 0, which indicates that the 154 endpoint does not support DATAGRAM frames. A value greater than 0 155 indicates that the endpoint supports the DATAGRAM frame types and is 156 willing to receive such frames on this connection. 158 An endpoint MUST NOT send DATAGRAM frames until it has received the 159 max_datagram_frame_size transport parameter with a non-zero value 160 during the handshake (or during a previous handshake if 0-RTT is 161 used). An endpoint MUST NOT send DATAGRAM frames that are larger 162 than the max_datagram_frame_size value it has received from its peer. 163 An endpoint that receives a DATAGRAM frame when it has not indicated 164 support via the transport parameter MUST terminate the connection 165 with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint 166 that receives a DATAGRAM frame that is larger than the value it sent 167 in its max_datagram_frame_size transport parameter MUST terminate the 168 connection with an error of type PROTOCOL_VIOLATION. 170 For most uses of DATAGRAM frames, it is RECOMMENDED to send a value 171 of 65535 in the max_datagram_frame_size transport parameter to 172 indicate that this endpoint will accept any DATAGRAM frame that fits 173 inside a QUIC packet. 175 The max_datagram_frame_size transport parameter is a unidirectional 176 limit and indication of support of DATAGRAM frames. Application 177 protocols that use DATAGRAM frames MAY choose to only negotiate and 178 use them in a single direction. 180 When clients use 0-RTT, they MAY store the value of the server's 181 max_datagram_frame_size transport parameter. Doing so allows the 182 client to send DATAGRAM frames in 0-RTT packets. When servers decide 183 to accept 0-RTT data, they MUST send a max_datagram_frame_size 184 transport parameter greater than or equal to the value they sent to 185 the client in the connection where they sent them the 186 NewSessionTicket message. If a client stores the value of the 187 max_datagram_frame_size transport parameter with their 0-RTT state, 188 they MUST validate that the new value of the max_datagram_frame_size 189 transport parameter sent by the server in the handshake is greater 190 than or equal to the stored value; if not, the client MUST terminate 191 the connection with error PROTOCOL_VIOLATION. 193 Application protocols that use datagrams MUST define how they react 194 to the absence of the max_datagram_frame_size transport parameter. 195 If datagram support is integral to the application, the application 196 protocol can fail the handshake if the max_datagram_frame_size 197 transport parameter is not present. 199 4. Datagram Frame Types 201 DATAGRAM frames are used to transmit application data in an 202 unreliable manner. The Type field in the DATAGRAM frame takes the 203 form 0b0011000X (or the values 0x30 and 0x31). The least significant 204 bit of the Type field in the DATAGRAM frame is the LEN bit (0x01), 205 which indicates whether there is a Length field present: if this bit 206 is set to 0, the Length field is absent and the Datagram Data field 207 extends to the end of the packet; if this bit is set to 1, the Length 208 field is present. 210 DATAGRAM frames are structured as follows: 212 DATAGRAM Frame { 213 Type (i) = 0x30..0x31, 214 [Length (i)], 215 Datagram Data (..), 216 } 218 Figure 1: DATAGRAM Frame Format 220 DATAGRAM frames contain the following fields: 222 Length: A variable-length integer specifying the length of the 223 Datagram Data field in bytes. This field is present only when the 224 LEN bit is set to 1. When the LEN bit is set to 0, the Datagram 225 Data field extends to the end of the QUIC packet. Note that empty 226 (i.e., zero-length) datagrams are allowed. 228 Datagram Data: The bytes of the datagram to be delivered. 230 5. Behavior and Usage 232 When an application sends a datagram over a QUIC connection, QUIC 233 will generate a new DATAGRAM frame and send it in the first available 234 packet. This frame SHOULD be sent as soon as possible (as determined 235 by factors like congestion control, described below) and MAY be 236 coalesced with other frames. 238 When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD 239 deliver the data to the application immediately, as long as it is 240 able to process the frame and can store the contents in memory. 242 Like STREAM frames, DATAGRAM frames contain application data and MUST 243 be protected with either 0-RTT or 1-RTT keys. 245 Note that while the max_datagram_frame_size transport parameter 246 places a limit on the maximum size of DATAGRAM frames, that limit can 247 be further reduced by the max_udp_payload_size transport parameter 248 and the Maximum Transmission Unit (MTU) of the path between 249 endpoints. DATAGRAM frames cannot be fragmented; therefore, 250 application protocols need to handle cases where the maximum datagram 251 size is limited by other factors. 253 5.1. Multiplexing Datagrams 255 DATAGRAM frames belong to a QUIC connection as a whole, and are not 256 associated with any stream ID at the QUIC layer. However, it is 257 expected that applications will want to differentiate between 258 specific DATAGRAM frames by using identifiers, such as for logical 259 flows of datagrams or to distinguish between different kinds of 260 datagrams. 262 Identifiers used to multiplex different kinds of datagrams, or flows 263 of datagrams, are the responsibility of the application protocol 264 running over QUIC to define. The application defines the semantics 265 of the Datagram Data field and how it is parsed. 267 If the application needs to support the coexistence of multiple flows 268 of datagrams, one recommended pattern is to use a variable-length 269 integer at the beginning of the Datagram Data field. This is a 270 simple approach that allows a large number of flows to be encoded 271 using minimal space. 273 QUIC implementations SHOULD present an API to applications to assign 274 relative priorities to DATAGRAM frames with respect to each other and 275 to QUIC streams. 277 5.2. Acknowledgement Handling 279 Although DATAGRAM frames are not retransmitted upon loss detection, 280 they are ack-eliciting ([RFC9002]). Receivers SHOULD support 281 delaying ACK frames (within the limits specified by max_ack_delay) in 282 response to receiving packets that only contain DATAGRAM frames, 283 since the sender takes no action if these packets are temporarily 284 unacknowledged. Receivers will continue to send ACK frames when 285 conditions indicate a packet might be lost, since the packet's 286 payload is unknown to the receiver, and when dictated by 287 max_ack_delay or other protocol components. 289 As with any ack-eliciting frame, when a sender suspects that a packet 290 containing only DATAGRAM frames has been lost, it sends probe packets 291 to elicit a faster acknowledgement as described in Section 6.2.4 of 292 [RFC9002]. 294 If a sender detects that a packet containing a specific DATAGRAM 295 frame might have been lost, the implementation MAY notify the 296 application that it believes the datagram was lost. 298 Similarly, if a packet containing a DATAGRAM frame is acknowledged, 299 the implementation MAY notify the sender application that the 300 datagram was successfully transmitted and received. Due to 301 reordering, this can include a DATAGRAM frame that was thought to be 302 lost, but which at a later point was received and acknowledged. It 303 is important to note that acknowledgement of a DATAGRAM frame only 304 indicates that the transport-layer handling on the receiver processed 305 the frame, and does not guarantee that the application on the 306 receiver successfully processed the data. Thus, this signal cannot 307 replace application-layer signals that indicate successful 308 processing. 310 5.3. Flow Control 312 DATAGRAM frames do not provide any explicit flow control signaling, 313 and do not contribute to any per-flow or connection-wide data limit. 315 The risk associated with not providing flow control for DATAGRAM 316 frames is that a receiver might not be able to commit the necessary 317 resources to process the frames. For example, it might not be able 318 to store the frame contents in memory. However, since DATAGRAM 319 frames are inherently unreliable, they MAY be dropped by the receiver 320 if the receiver cannot process them. 322 5.4. Congestion Control 324 DATAGRAM frames employ the QUIC connection's congestion controller. 325 As a result, a connection might be unable to send a DATAGRAM frame 326 generated by the application until the congestion controller allows 327 it [RFC9002]. The sender MUST either delay sending the frame until 328 the controller allows it or drop the frame without sending it (at 329 which point it MAY notify the application). Implementations that use 330 packet pacing (Section 7.7 of [RFC9002]) can also delay the sending 331 of DATAGRAM frames to maintain consistent packet pacing. 333 Implementations can optionally support allowing the application to 334 specify a sending expiration time beyond which a congestion- 335 controlled DATAGRAM frame ought to be dropped without transmission. 337 6. Security Considerations 339 The DATAGRAM frame shares the same security properties as the rest of 340 the data transmitted within a QUIC connection, and the security 341 considerations of [RFC9000] apply accordingly. All application data 342 transmitted with the DATAGRAM frame, like the STREAM frame, MUST be 343 protected either by 0-RTT or 1-RTT keys. 345 Application protocols that allow DATAGRAM frames to be sent in 0-RTT 346 require a profile that defines acceptable use of 0-RTT; see 347 Section 5.6 of [RFC9001]. 349 The use of DATAGRAM frames might be detectable by an adversary on 350 path that is capable of dropping packets. Since DATAGRAM frames do 351 not use transport-level retransmission, connections that use DATAGRAM 352 frames might be distinguished from other connections due to their 353 different response to packet loss. 355 7. IANA Considerations 357 7.1. QUIC Transport Parameter 359 This document registers a new value in the QUIC Transport Parameter 360 Registry maintained at https://www.iana.org/assignments/quic/ 361 quic.xhtml#quic-transport. 363 Value: 0x20 365 Parameter Name: max_datagram_frame_size 367 Status: permanent 369 Specification: This document 371 7.2. QUIC Frame Types 373 This document registers two new values in the QUIC Frame Type 374 registry maintained at https://www.iana.org/assignments/quic/ 375 quic.xhtml#quic-frame-types. 377 Value: 0x30 and 0x31 (if this document is approved) 379 Frame Name: DATAGRAM 381 Status: permanent 383 Specification: This document 385 8. Acknowledgments 387 The original proposal for this work came from Ian Swett. 389 This document had reviews and input from many contributors in the 390 IETF QUIC Working Group, with substantive input from Nick Banks, 391 Lucas Pardue, Rui Paulo, Martin Thomson, Victor Vasiliev, and Chris 392 Wood. 394 9. References 396 9.1. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 404 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 405 May 2017, . 407 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 408 Multiplexed and Secure Transport", RFC 9000, 409 DOI 10.17487/RFC9000, May 2021, 410 . 412 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 413 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 414 . 416 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 417 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 418 May 2021, . 420 9.2. Informative References 422 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 423 DOI 10.17487/RFC0768, August 1980, 424 . 426 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 427 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 428 January 2012, . 430 Authors' Addresses 432 Tommy Pauly 433 Apple Inc. 434 One Apple Park Way 435 Cupertino, California 95014, 436 United States of America 438 Email: tpauly@apple.com 440 Eric Kinnear 441 Apple Inc. 442 One Apple Park Way 443 Cupertino, California 95014, 444 United States of America 446 Email: ekinnear@apple.com 448 David Schinazi 449 Google LLC 450 1600 Amphitheatre Parkway 451 Mountain View, California 94043, 452 United States of America 454 Email: dschinazi.ietf@gmail.com