idnits 2.17.1 draft-ietf-quic-datagram-04.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 (8 September 2021) is 961 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: 12 March 2022 D. Schinazi 6 Google LLC 7 8 September 2021 9 An Unreliable Datagram Extension to QUIC 10 draft-ietf-quic-datagram-04 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 of this work is encouraged to happen on the QUIC IETF 19 mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub 20 repository which contains the draft: https://github.com/quicwg/ 21 datagram (https://github.com/quicwg/datagram). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 12 March 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 58 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 4 60 4. Datagram Frame Type . . . . . . . . . . . . . . . . . . . . . 5 61 5. Behavior and Usage . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Multiplexing Datagrams . . . . . . . . . . . . . . . . . 6 63 5.2. Acknowledgement Handling . . . . . . . . . . . . . . . . 6 64 5.3. Flow Control . . . . . . . . . . . . . . . . . . . . . . 7 65 5.4. Congestion Control . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The QUIC Transport Protocol [RFC9000] provides a secure, multiplexed 77 connection for transmitting reliable streams of application data. 78 Reliability within QUIC is performed on a per-stream basis, so some 79 frame types are not eligible for retransmission. 81 Some applications, particularly those that need to transmit real-time 82 data, prefer to transmit data unreliably. In the past, these 83 applications have built directly upon UDP [RFC0768] as a transport, 84 and have often added security with DTLS [RFC6347]. Extending QUIC to 85 support transmitting unreliable application data provides another 86 option for secure datagrams, with the added benefit of sharing the 87 cryptographic and authentication context used for reliable streams. 89 This document defines two new DATAGRAM QUIC frame types, which carry 90 application data without requiring retransmissions. 92 Note that DATAGRAM frames are only meant for unreliable 93 transmissions. Reliable transmission is already supported by QUIC 94 via STREAM frames. 96 Discussion of this work is encouraged to happen on the QUIC IETF 97 mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub 98 repository which contains the draft: https://github.com/quicwg/ 99 datagram (https://github.com/quicwg/datagram). 101 1.1. Specification of Requirements 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. Motivation 111 Transmitting unreliable data over QUIC provides benefits over 112 existing solutions: 114 * Applications that open both a reliable TLS stream and an 115 unreliable DTLS flow to the same peer can benefit by sharing a 116 single handshake and authentication context between a reliable 117 QUIC stream and flow of unreliable QUIC datagrams. This can 118 reduce the latency required for handshakes. 120 * QUIC uses a more nuanced loss recovery mechanism than the DTLS 121 handshake, which has a basic packet loss retransmission timer. 122 This can allow loss recovery to occur more quickly for QUIC data. 124 * QUIC datagrams are subject to QUIC congestion control. Providing 125 a single congestion control for both reliable and unreliable data 126 can be more effective and efficient. 128 These features can be useful for optimizing audio/video streaming 129 applications, gaming applications, and other real-time network 130 applications. 132 Unreliable QUIC datagrams can also be used to implement an IP packet 133 tunnel over QUIC, such as for a Virtual Private Network (VPN). 134 Internet-layer tunneling protocols generally require a reliable and 135 authenticated handshake, followed by unreliable secure transmission 136 of IP packets. This can, for example, require a TLS connection for 137 the control data, and DTLS for tunneling IP packets. A single QUIC 138 connection could support both parts with the use of unreliable 139 datagrams. 141 3. Transport Parameter 143 Support for receiving the DATAGRAM frame types is advertised by means 144 of a QUIC Transport Parameter (name=max_datagram_frame_size, 145 value=0x0020). The max_datagram_frame_size transport parameter is an 146 integer value (represented as a variable-length integer) that 147 represents the maximum size of a DATAGRAM frame (including the frame 148 type, length, and payload) the endpoint is willing to receive, in 149 bytes. 151 The default for this parameter is 0, which indicates that the 152 endpoint does not support DATAGRAM frames. A value greater than 0 153 indicates that the endpoint supports the DATAGRAM frame types and is 154 willing to receive such frames on this connection. 156 An endpoint MUST NOT send DATAGRAM frames until it has received the 157 max_datagram_frame_size transport parameter with a non-zero value. 158 An endpoint MUST NOT send DATAGRAM frames that are larger than the 159 max_datagram_frame_size value it has received from its peer. An 160 endpoint that receives a DATAGRAM frame when it has not indicated 161 support via the transport parameter MUST terminate the connection 162 with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint 163 that receives a DATAGRAM frame that is larger than the value it sent 164 in its max_datagram_frame_size transport parameter MUST terminate the 165 connection with an error of type PROTOCOL_VIOLATION. 167 For most uses of DATAGRAM frames, it is RECOMMENDED to send a value 168 of 65535 in the max_datagram_frame_size transport parameter to 169 indicate that this endpoint will accept any DATAGRAM frame that fits 170 inside a QUIC packet. 172 The max_datagram_frame_size transport parameter is a unidirectional 173 limit and indication of support of DATAGRAM frames. Application 174 protocols that use DATAGRAM frames MAY choose to only negotiate and 175 use them in a single direction. 177 When clients use 0-RTT, they MAY store the value of the server's 178 max_datagram_frame_size transport parameter. Doing so allows the 179 client to send DATAGRAM frames in 0-RTT packets. When servers decide 180 to accept 0-RTT data, they MUST send a max_datagram_frame_size 181 transport parameter greater or equal to the value they sent to the 182 client in the connection where they sent them the NewSessionTicket 183 message. If a client stores the value of the max_datagram_frame_size 184 transport parameter with their 0-RTT state, they MUST validate that 185 the new value of the max_datagram_frame_size transport parameter sent 186 by the server in the handshake is greater or equal to the stored 187 value; if not, the client MUST terminate the connection with error 188 PROTOCOL_VIOLATION. 190 Application protocols that use datagrams MUST define how they react 191 to the max_datagram_frame_size transport parameter being missing. If 192 datagram support is integral to the application, the application 193 protocol can fail the handshake if the max_datagram_frame_size 194 transport parameter is not present. 196 4. Datagram Frame Type 198 DATAGRAM frames are used to transmit application data in an 199 unreliable manner. The DATAGRAM frame type takes the form 0b0011000X 200 (or the values 0x30 and 0x31). The least significant bit of the 201 DATAGRAM frame type is the LEN bit (0x01). It indicates that there 202 is a Length field present. If this bit is set to 0, the Length field 203 is absent and the Datagram Data field extends to the end of the 204 packet. If this bit is set to 1, the Length field is present. 206 The DATAGRAM frame is structured as follows: 208 DATAGRAM Frame { 209 Type (i) = 0x30..0x31, 210 [Length (i)], 211 Datagram Data (..), 212 } 214 Figure 1: DATAGRAM Frame Format 216 DATAGRAM frames contain the following fields: 218 Length: A variable-length integer specifying the length of the 219 Datagram Data field in bytes. This field is present only when the 220 LEN bit is set to 1. When the LEN bit is set to 0, the Datagram 221 Data field extends to the end of the QUIC packet. Note that empty 222 (i.e., zero-length) datagrams are allowed. 224 Datagram Data: The bytes of the datagram to be delivered. 226 5. Behavior and Usage 228 When an application sends an unreliable datagram over a QUIC 229 connection, QUIC will generate a new DATAGRAM frame and send it in 230 the first available packet. This frame SHOULD be sent as soon as 231 possible, and MAY be coalesced with other frames. 233 When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD 234 deliver the data to the application immediately, as long as it is 235 able to process the frame and can store the contents in memory. 237 DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. 239 Note that while the max_datagram_frame_size transport parameter 240 places a limit on the maximum size of DATAGRAM frames, that limit can 241 be further reduced by the max_packet_size transport parameter and the 242 Maximum Transmission Unit (MTU) of the path between endpoints. 243 DATAGRAM frames cannot be fragmented, therefore application protocols 244 need to handle cases where the maximum datagram size is limited by 245 other factors. 247 5.1. Multiplexing Datagrams 249 DATAGRAM frames belong to a QUIC connection as a whole, and are not 250 strongly associated with any stream ID at the QUIC layer. However, 251 it is expected that applications will want to differentiate between 252 specific DATAGRAM frames by using identifiers, such as for logical 253 flows of datagrams or to distinguish between different kinds of 254 datagrams. 256 Identifiers used to multiplex different kinds of datagrams, or flows 257 of datagrams, are the responsibility of the application protocol 258 running over QUIC to define. The application defines the semantics 259 of the Datagram Data field and how it is parsed. 261 If the application needs to support the coexistence of multiple flows 262 of datagrams, one recommended pattern is to use a variable-length 263 integer at the beginning of the Datagram Data field. 265 QUIC implementations SHOULD present an API to applications to assign 266 relative priorities to DATAGRAM frames with respect to each other and 267 to QUIC streams. 269 5.2. Acknowledgement Handling 271 Although DATAGRAM frames are not retransmitted upon loss detection, 272 they are ack-eliciting ([RFC9002]). Receivers SHOULD support 273 delaying ACK frames (within the limits specified by max_ack_delay) in 274 response to receiving packets that only contain DATAGRAM frames, 275 since the sender takes no action if these packets are temporarily 276 unacknowledged. Receivers will continue to send ACK frames when 277 conditions indicate a packet might be lost, since the packet's 278 payload is unknown to the receiver, and when dictated by 279 max_ack_delay or other protocol components. 281 As with any ack-eliciting frame, when a sender suspects that a packet 282 containing only DATAGRAM frames has been lost, it sends probe packets 283 to elicit a faster acknowledgement as described in Section 6.2.4 of 284 [RFC9002]. 286 If a sender detects that a packet containing a specific DATAGRAM 287 frame might have been lost, the implementation MAY notify the 288 application that it believes the datagram was lost. 290 Similarly, if a packet containing a DATAGRAM frame is acknowledged, 291 the implementation MAY notify the sender application that the 292 datagram was successfully transmitted and received. Due to 293 reordering, this can include a DATAGRAM frame that was thought to be 294 lost, but which at a later point was received and acknowledged. It 295 is important to note that acknowledgement of a DATAGRAM frame only 296 indicates that the transport-layer handling on the receiver processed 297 the frame, and does not guarantee that the application on the 298 receiver successfully processed the data. Thus, this signal cannot 299 replace application-layer signals that indicate successful 300 processing. 302 5.3. Flow Control 304 DATAGRAM frames do not provide any explicit flow control signaling, 305 and do not contribute to any per-flow or connection-wide data limit. 307 The risk associated with not providing flow control for DATAGRAM 308 frames is that a receiver might not be able to commit the necessary 309 resources to process the frames. For example, it might not be able 310 to store the frame contents in memory. However, since DATAGRAM 311 frames are inherently unreliable, they MAY be dropped by the receiver 312 if the receiver cannot process them. 314 5.4. Congestion Control 316 DATAGRAM frames employ the QUIC connection's congestion controller. 317 As a result, a connection might be unable to send a DATAGRAM frame 318 generated by the application until the congestion controller allows 319 it [RFC9002]. The sender implementation MUST either delay sending 320 the frame until the controller allows it or drop the frame without 321 sending it (at which point it MAY notify the application). 322 Implementations that use packet pacing (Section 7.7 of [RFC9002]) can 323 also delay the sending of DATAGRAM frames to maintain consistent 324 packet pacing. 326 Implementations can optionally support allowing the application to 327 specify a sending expiration time, beyond which a congestion- 328 controlled DATAGRAM frame ought to be dropped without transmission. 330 6. Security Considerations 332 The DATAGRAM frame shares the same security properties as the rest of 333 the data transmitted within a QUIC connection. All application data 334 transmitted with the DATAGRAM frame, like the STREAM frame, MUST be 335 protected either by 0-RTT or 1-RTT keys. 337 Application protocols that allow DATAGRAM frames to be sent in 0-RTT 338 require a profile that defines acceptable use of 0-RTT; see 339 Section 5.6 of [RFC9001]. 341 The use of DATAGRAM frames might be detectable by an adversary on 342 path that is capable of dropping packets. Since DATAGRAM frames do 343 not use transport-level retransmission, connections that use DATAGRAM 344 frames might be distinguished from other frames using the different 345 response to loss. 347 7. IANA Considerations 349 This document registers a new value in the QUIC Transport Parameter 350 Registry: 352 Value: 0x0020 (if this document is approved) 354 Parameter Name: max_datagram_frame_size 356 Specification: A non-zero value indicates that the endpoint supports 357 receiving unreliable DATAGRAM frames. An endpoint that advertises 358 this transport parameter can receive DATAGRAM frames from the 359 other endpoint, up to and including the length in bytes provided 360 in the transport parameter. The default value is 0. 362 This document also registers a new value in the QUIC Frame Type 363 registry: 365 Value: 0x30 and 0x31 (if this document is approved) 367 Frame Name: DATAGRAM 369 Specification: Unreliable application data 371 8. Acknowledgments 373 The original proposal for this work came from Ian Swett. 375 This document had reviews and input from many contributors in the 376 IETF QUIC Working Group, with substantive input from Nick Banks, 377 Lucas Pardue, Rui Paulo, Martin Thomson, Victor Vasiliev, and Chris 378 Wood. 380 9. References 382 9.1. Normative References 384 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 385 Multiplexed and Secure Transport", RFC 9000, 386 DOI 10.17487/RFC9000, May 2021, 387 . 389 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 390 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 391 . 393 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 394 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 395 May 2021, . 397 9.2. Informative References 399 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 400 DOI 10.17487/RFC0768, August 1980, 401 . 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 409 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 410 January 2012, . 412 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 413 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 414 May 2017, . 416 Authors' Addresses 417 Tommy Pauly 418 Apple Inc. 419 One Apple Park Way 420 Cupertino, California 95014, 421 United States of America 423 Email: tpauly@apple.com 425 Eric Kinnear 426 Apple Inc. 427 One Apple Park Way 428 Cupertino, California 95014, 429 United States of America 431 Email: ekinnear@apple.com 433 David Schinazi 434 Google LLC 435 1600 Amphitheatre Parkway 436 Mountain View, California 94043, 437 United States of America 439 Email: dschinazi.ietf@gmail.com