idnits 2.17.1 draft-ietf-quic-datagram-01.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 (24 August 2020) is 1339 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) == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-29 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 == Outdated reference: A later version (-05) exists of draft-schinazi-quic-h3-datagram-04 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Pauly 3 Internet-Draft E. Kinnear 4 Intended status: Standards Track Apple Inc. 5 Expires: 25 February 2021 D. Schinazi 6 Google LLC 7 24 August 2020 9 An Unreliable Datagram Extension to QUIC 10 draft-ietf-quic-datagram-01 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 25 February 2021. 40 Copyright Notice 42 Copyright (c) 2020 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. Acknowledgement Handling . . . . . . . . . . . . . . . . 6 63 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6 64 5.3. Congestion Control . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a 76 secure, multiplexed connection for transmitting reliable streams of 77 application data. Reliability within QUIC is performed on a per- 78 stream basis, so some frame types are not eligible for 79 retransmission. 81 Some applications, particularly those that need to transmit real-time 82 data, prefer to transmit data unreliably. These applications can 83 build directly upon UDP [RFC0768] as a transport, and can add 84 security with DTLS [RFC6347]. Extending QUIC to support transmitting 85 unreliable application data would provide another option for secure 86 datagrams, with the added benefit of sharing a cryptographic and 87 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 Discussion of this work is encouraged to happen on the QUIC IETF 93 mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub 94 repository which contains the draft: https://github.com/quicwg/ 95 datagram (https://github.com/quicwg/datagram). 97 1.1. Specification of Requirements 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 2. Motivation 107 Transmitting unreliable data over QUIC provides benefits over 108 existing solutions: 110 * Applications that open both a reliable TLS stream and an 111 unreliable DTLS flow to the same peer can benefit by sharing a 112 single handshake and authentication context between a reliable 113 QUIC stream and flow of unreliable QUIC datagrams. This can 114 reduce the latency required for handshakes. 116 * QUIC uses a more nuanced loss recovery mechanism than the DTLS 117 handshake, which has a basic packet loss retransmission timer. 118 This may allow loss recovery to occur more quickly for QUIC data. 120 * QUIC datagrams, while unreliable, can support acknowledgements, 121 allowing applications to be aware of whether a datagram was 122 successfully received. 124 * QUIC datagrams are subject to QUIC congestion control, allowing 125 applications to avoid implementing their own. 127 These reductions in connection latency, and application insight into 128 the delivery of datagrams, can be useful for optimizing audio/video 129 streaming applications, gaming applications, and other real-time 130 network 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. An endpoint that includes this parameter supports the 150 DATAGRAM frame types and is willing to receive such frames on this 151 connection. Endpoints MUST NOT send DATAGRAM frames until they have 152 received the max_datagram_frame_size transport parameter. Endpoints 153 MUST NOT send DATAGRAM frames of size strictly larger than the value 154 of max_datagram_frame_size the endpoint has received from its peer. 155 An endpoint that receives a DATAGRAM frame when it has not sent the 156 max_datagram_frame_size transport parameter MUST terminate the 157 connection with error PROTOCOL_VIOLATION. An endpoint that receives 158 a DATAGRAM frame that is strictly larger than the value it sent in 159 its max_datagram_frame_size transport parameter MUST terminate the 160 connection with error PROTOCOL_VIOLATION. Endpoints that wish to use 161 DATAGRAM frames need to ensure they send a max_datagram_frame_size 162 value sufficient to allow their peer to use them. It is RECOMMENDED 163 to send the value 65536 in the max_datagram_frame_size transport 164 parameter as that indicates to the peer that this endpoint will 165 accept any DATAGRAM frame that fits inside a QUIC packet. 167 The max_datagram_frame_size transport parameter is a unidirectional 168 limit and indication of support of DATAGRAM frames. Application 169 protocols that use DATAGRAM frames MAY choose to only negotiate and 170 use them in a single direction. 172 When clients use 0-RTT, they MAY store the value of the server's 173 max_datagram_frame_size transport parameter. Doing so allows the 174 client to send DATAGRAM frames in 0-RTT packets. When servers decide 175 to accept 0-RTT data, they MUST send a max_datagram_frame_size 176 transport parameter greater or equal to the value they sent to the 177 client in the connection where they sent them the NewSessionTicket 178 message. If a client stores the value of the max_datagram_frame_size 179 transport parameter with their 0-RTT state, they MUST validate that 180 the new value of the max_datagram_frame_size transport parameter sent 181 by the server in the handshake is greater or equal to the stored 182 value; if not, the client MUST terminate the connection with error 183 PROTOCOL_VIOLATION. 185 Application protocols that use datagrams MUST define how they react 186 to the max_datagram_frame_size transport parameter being missing. If 187 datagram support is integral to the application, the application 188 protocol can fail the handshake if the max_datagram_frame_size 189 transport parameter is not present. 191 4. Datagram Frame Type 193 DATAGRAM frames are used to transmit application data in an 194 unreliable manner. The DATAGRAM frame type takes the form 0b0011000X 195 (or the values 0x30 and 0x31). The least significant bit of the 196 DATAGRAM frame type is the LEN bit (0x01). It indicates that there 197 is a Length field present. If this bit is set to 0, the Length field 198 is absent and the Datagram Data field extends to the end of the 199 packet. If this bit is set to 1, the Length field is present. 201 The DATAGRAM frame is structured as follows: 203 0 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | [Length (i)] ... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Datagram Data (*) ... 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 1: DATAGRAM Frame Format 213 DATAGRAM frames contain the following fields: 215 Length: A variable-length integer specifying the length of the 216 datagram in bytes. This field is present only when the LEN bit is 217 set. If the LEN bit is not set, the datagram data extends to the 218 end of the QUIC packet. Note that empty (i.e., zero-length) 219 datagrams are allowed. 221 Datagram Data: The bytes of the datagram to be delivered. 223 5. Behavior and Usage 225 When an application sends an unreliable datagram over a QUIC 226 connection, QUIC will generate a new DATAGRAM frame and send it in 227 the first available packet. This frame SHOULD be sent as soon as 228 possible, and MAY be coalesced with other frames. 230 When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD 231 deliver the data to the application immediately, as long as it is 232 able to process the frame and can store the contents in memory. 234 DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. 236 Application protocols using datagrams are responsible for defining 237 the semantics of the Datagram Data field, and how it is parsed. If 238 the application protocol supports the coexistence of multiple 239 entities using datagrams inside a single QUIC connection, it may need 240 a mechanism to allow demultiplexing between them. For example, using 241 datagrams with HTTP/3 involves prepending a flow identifier to all 242 datagrams, see [I-D.schinazi-quic-h3-datagram]. 244 Note that while the max_datagram_frame_size transport parameter 245 places a limit on the maximum size of DATAGRAM frames, that limit can 246 be further reduced by the max_packet_size transport parameter, and by 247 the Maximum Transmission Unit (MTU) of the path between endpoints. 248 DATAGRAM frames cannot be fragmented, therefore application protocols 249 need to handle cases where the maximum datagram size is limited by 250 other factors. 252 5.1. Acknowledgement Handling 254 Although DATAGRAM frames are not retransmitted upon loss detection, 255 they are ack-eliciting ([I-D.ietf-quic-recovery]). Receivers SHOULD 256 support delaying ACK frames (within the limits specified by 257 max_ack_delay) in reponse to receiving packets that only contain 258 DATAGRAM frames, since the timing of these acknowledgements is not 259 used for loss recovery. 261 If a sender detects that a packet containing a specific DATAGRAM 262 frame might have been lost, the implementation MAY notify the 263 application that it believes the datagram was lost. Similarly, if a 264 packet containing a DATAGRAM frame is acknowledged, the 265 implementation MAY notify the application that the datagram was 266 successfully transmitted and received. Note that, due to reordering, 267 a DATAGRAM frame that was thought to be lost could at a later point 268 be received and acknowledged. 270 5.2. Flow Control 272 DATAGRAM frames do not provide any explicit flow control signaling, 273 and do not contribute to any per-flow or connection-wide data limit. 275 The risk associated with not providing flow control for DATAGRAM 276 frames is that a receiver may not be able to commit the necessary 277 resources to process the frames. For example, it may not be able to 278 store the frame contents in memory. However, since DATAGRAM frames 279 are inherently unreliable, they MAY be dropped by the receiver if the 280 receiver cannot process them. 282 5.3. Congestion Control 284 DATAGRAM frames employ the QUIC connection's congestion controller. 285 As a result, a connection may be unable to send a DATAGRAM frame 286 generated by the application until the congestion controller allows 287 it [I-D.ietf-quic-recovery]. The sender implementation MUST 288 either delay sending the frame until the controller allows it or drop 289 the frame without sending it (at which point it MAY notify the 290 application). 292 Implementations can optionally support allowing the application to 293 specify a sending expiration time, beyond which a congestion- 294 controlled DATAGRAM frame ought to be dropped without transmission. 296 6. Security Considerations 298 The DATAGRAM frame shares the same security properties as the rest of 299 the data transmitted within a QUIC connection. All application data 300 transmitted with the DATAGRAM frame, like the STREAM frame, MUST be 301 protected either by 0-RTT or 1-RTT keys. 303 7. IANA Considerations 305 This document registers a new value in the QUIC Transport Parameter 306 Registry: 308 Value: 0x0020 (if this document is approved) 310 Parameter Name: max_datagram_frame_size 312 Specification: Indicates that the connection should enable support 313 for unreliable DATAGRAM frames. An endpoint that advertises this 314 transport parameter can receive datagrams frames from the other 315 endpoint, up to and including the length in bytes provided in the 316 transport parameter. 318 This document also registers a new value in the QUIC Frame Type 319 registry: 321 Value: 0x30 and 0x31 (if this document is approved) 323 Frame Name: DATAGRAM 325 Specification: Unreliable application data 327 8. Acknowledgments 329 Thanks to Ian Swett, who inspired this proposal. 331 9. References 333 9.1. Normative References 335 [I-D.ietf-quic-recovery] 336 Iyengar, J. and I. Swett, "QUIC Loss Detection and 337 Congestion Control", Work in Progress, Internet-Draft, 338 draft-ietf-quic-recovery-29, 9 June 2020, 339 . 342 [I-D.ietf-quic-transport] 343 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 344 and Secure Transport", Work in Progress, Internet-Draft, 345 draft-ietf-quic-transport-29, 9 June 2020, 346 . 349 9.2. Informative References 351 [I-D.schinazi-quic-h3-datagram] 352 Schinazi, D., "Using QUIC Datagrams with HTTP/3", Work in 353 Progress, Internet-Draft, draft-schinazi-quic-h3-datagram- 354 04, 16 April 2020, . 357 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 358 DOI 10.17487/RFC0768, August 1980, 359 . 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 367 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 368 January 2012, . 370 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 371 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 372 May 2017, . 374 Authors' Addresses 376 Tommy Pauly 377 Apple Inc. 378 One Apple Park Way 379 Cupertino, California 95014, 380 United States of America 382 Email: tpauly@apple.com 384 Eric Kinnear 385 Apple Inc. 386 One Apple Park Way 387 Cupertino, California 95014, 388 United States of America 390 Email: ekinnear@apple.com 392 David Schinazi 393 Google LLC 394 1600 Amphitheatre Parkway 395 Mountain View, California 94043, 396 United States of America 398 Email: dschinazi.ietf@gmail.com