idnits 2.17.1 draft-pauly-quic-datagram-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1629 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) -- Looks like a reference, but probably isn't: '1' on line 369 -- Looks like a reference, but probably isn't: '2' on line 371 -- Looks like a reference, but probably isn't: '3' on line 373 -- Looks like a reference, but probably isn't: '4' on line 375 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-23 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 == Outdated reference: A later version (-05) exists of draft-schinazi-quic-h3-datagram-01 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 6 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: May 7, 2020 D. Schinazi 6 Google LLC 7 November 04, 2019 9 An Unreliable Datagram Extension to QUIC 10 draft-pauly-quic-datagram-05 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 [1] or on the GitHub repository which 20 contains the draft: https://github.com/tfpauly/draft-pauly-quic- 21 datagram [2]. 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 May 7, 2020. 40 Copyright Notice 42 Copyright (c) 2019 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 4 61 4. Datagram Frame Type . . . . . . . . . . . . . . . . . . . . . 5 62 5. Behavior and Usage . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Acknowledgement Handling . . . . . . . . . . . . . . . . 6 64 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6 65 5.3. Congestion Control . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . 8 72 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a 78 secure, multiplexed connection for transmitting reliable streams of 79 application data. Reliability within QUIC is performed on a per- 80 stream basis, so some frame types are not eligible for 81 retransmission. 83 Some applications, particularly those that need to transmit real-time 84 data, prefer to transmit data unreliably. These applications can 85 build directly upon UDP [RFC0768] as a transport, and can add 86 security with DTLS [RFC6347]. Extending QUIC to support transmitting 87 unreliable application data would provide another option for secure 88 datagrams, with the added benefit of sharing a cryptographic and 89 authentication context used for reliable streams. 91 This document defines four new DATAGRAM QUIC frame types, which carry 92 application data without requiring retransmissions. 94 Discussion of this work is encouraged to happen on the QUIC IETF 95 mailing list quic@ietf.org [3] or on the GitHub repository which 96 contains the draft: https://github.com/tfpauly/draft-pauly-quic- 97 datagram [4]. 99 1.1. Specification of Requirements 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. Motivation 109 Transmitting unreliable data over QUIC provides benefits over 110 existing solutions: 112 o Applications that open both a reliable TLS stream and an 113 unreliable DTLS flow to the same peer can benefit by sharing a 114 single handshake and authentication context between a reliable 115 QUIC stream and flow of unreliable QUIC datagrams. This can 116 reduce the latency required for handshakes. 118 o QUIC uses a more nuanced loss recovery mechanism than the DTLS 119 handshake, which has a basic packet loss retransmission timer. 120 This may allow loss recovery to occur more quickly for QUIC data. 122 o QUIC datagrams, while unreliable, can support acknowledgements, 123 allowing applications to be aware of whether a datagram was 124 successfully received. 126 o QUIC datagrams are subject to QUIC congestion control, allowing 127 applications to avoid implementing their own. 129 These reductions in connection latency, and application insight into 130 the delivery of datagrams, can be useful for optimizing audio/video 131 streaming applications, gaming applications, and other real-time 132 network 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 138 of IP packets. This can, for example, require a TLS connection for 139 the control data, and DTLS for tunneling IP packets. A single QUIC 140 connection could support both parts with the use of unreliable 141 datagrams. 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=0x0020). 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. An endpoint that includes this parameter supports the 152 DATAGRAM frame types and is willing to receive such frames on this 153 connection. Endpoints MUST NOT send DATAGRAM frames until they have 154 sent and received the max_datagram_frame_size transport parameter. 155 Endpoints MUST NOT send DATAGRAM frames of size strictly larger than 156 the value of max_datagram_frame_size the endpoint has received from 157 its peer. An endpoint that receives a DATAGRAM frame when it has not 158 sent the max_datagram_frame_size transport parameter MUST terminate 159 the connection with error PROTOCOL_VIOLATION. An endpoint that 160 receives a DATAGRAM frame that is strictly larger than the value it 161 sent in its max_datagram_frame_size transport parameter MUST 162 terminate the connection with error PROTOCOL_VIOLATION. Endpoints 163 that wish to use DATAGRAM frames need to ensure they send a 164 max_datagram_frame_size value sufficient to allow their peer to use 165 them. It is RECOMMENDED to send the value 65536 in the 166 max_datagram_frame_size transport parameter as that indicates to the 167 peer that this endpoint will accept any DATAGRAM frame that fits 168 inside a QUIC packet. 170 When clients use 0-RTT, they MAY store the value of the server's 171 max_datagram_frame_size transport parameter. Doing so allows the 172 client to send DATAGRAM frames in 0-RTT packets. When servers decide 173 to accept 0-RTT data, they MUST send a max_datagram_frame_size 174 transport parameter greater or equal to the value they sent to the 175 client in the connection where they sent them the NewSessionTicket 176 message. If a client stores the value of the max_datagram_frame_size 177 transport parameter with their 0-RTT state, they MUST validate that 178 the new value of the max_datagram_frame_size transport parameter sent 179 by the server in the handshake is greater or equal to the stored 180 value; if not, the client MUST terminate the connection with error 181 PROTOCOL_VIOLATION. 183 Application protocols that use datagrams MUST define how they react 184 to the max_datagram_frame_size transport parameter being missing. If 185 datagram support is integral to the application, the application 186 protocol can fail the handshake if the max_datagram_frame_size 187 transport parameter is not present. 189 4. Datagram Frame Type 191 DATAGRAM frames are used to transmit application data in an 192 unreliable manner. The DATAGRAM frame type takes the form 0b0011000X 193 (or the values 0x30 and 0x31). The least significant bit of the 194 DATAGRAM frame type is the LEN bit (0x01). It indicates that there 195 is a Length field present. If this bit is set to 0, the Length field 196 is absent and the Datagram Data field extends to the end of the 197 packet. If this bit is set to 1, the Length field is present. 199 The DATAGRAM frame is structured as follows: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | [Length (i)] ... 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Datagram Data (*) ... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 1: DATAGRAM Frame Format 211 DATAGRAM frames contain the following fields: 213 Length: A variable-length integer specifying the length of the 214 datagram in bytes. This field is present only when the LEN bit is 215 set. If the LEN bit is not set, the datagram data extends to the 216 end of the QUIC packet. Note that empty (i.e., zero-length) 217 datagrams are allowed. 219 Datagram Data: The bytes of the datagram to be delivered. 221 5. Behavior and Usage 223 When an application sends an unreliable datagram over a QUIC 224 connection, QUIC will generate a new DATAGRAM frame and send it in 225 the first available packet. This frame SHOULD be sent as soon as 226 possible, and MAY be coalesced with other frames. 228 When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD 229 deliver the data to the application immediately, as long as it is 230 able to process the frame and can store the contents in memory. 232 DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. 234 Application protocols using datagrams are responsible for defining 235 the semantics of the Datagram Data field, and how it is parsed. If 236 the application protocol supports the coexistence of multiple 237 entities using datagrams inside a single QUIC connection, it may need 238 a mechanism to allow demultiplexing between them. For example, using 239 datagrams with HTTP/3 involves prepending a flow identifier to all 240 datagrams, see [I-D.schinazi-quic-h3-datagram]. 242 Note that while the max_datagram_frame_size transport parameter 243 places a limit on the maximum size of DATAGRAM frames, that limit can 244 be further reduced by the max_packet_size transport parameter, and by 245 the Maximum Transmission Unit (MTU) of the path between endpoints. 246 DATAGRAM frames cannot be fragmented, therefore application protocols 247 need to handle cases where the maximum datagram size is limited by 248 other factors. 250 5.1. Acknowledgement Handling 252 Although DATAGRAM frames are not retransmitted upon loss detection, 253 they are ack-eliciting ([I-D.ietf-quic-recovery]). Receivers SHOULD 254 support delaying ACK frames (within the limits specified by 255 max_ack_delay) in reponse to receiving packets that only contain 256 DATAGRAM frames, since the timing of these acknowledgements is not 257 used for loss recovery. 259 If a sender detects that a packet containing a specific DATAGRAM 260 frame might have been lost, the implementation MAY notify the 261 application that it believes the datagram was lost. Similarly, if a 262 packet containing a DATAGRAM frame is acknowledged, the 263 implementation MAY notify the application that the datagram was 264 successfully transmitted and received. Note that, due to reordering, 265 a DATAGRAM frame that was thought to be lost could at a later point 266 be received and acknowledged. 268 5.2. Flow Control 270 DATAGRAM frames do not provide any explicit flow control signaling, 271 and do not contribute to any per-flow or connection-wide data limit. 273 The risk associated with not providing flow control for DATAGRAM 274 frames is that a receiver may not be able to commit the necessary 275 resources to process the frames. For example, it may not be able to 276 store the frame contents in memory. However, since DATAGRAM frames 277 are inherently unreliable, they MAY be dropped by the receiver if the 278 receiver cannot process them. 280 5.3. Congestion Control 282 DATAGRAM frames employ the QUIC connection's congestion controller. 283 As a result, a connection may be unable to send a DATAGRAM frame 284 generated by the application until the congestion controller allows 285 it [I-D.ietf-quic-recovery]. The sender implementation MUST 286 either delay sending the frame until the controller allows it or drop 287 the frame without sending it (at which point it MAY notify the 288 application). 290 Implementations can optionally support allowing the application to 291 specify a sending expiration time, beyond which a congestion- 292 controlled DATAGRAM frame ought to be dropped without transmission. 294 6. Security Considerations 296 The DATAGRAM frame shares the same security properties as the rest of 297 the data transmitted within a QUIC connection. All application data 298 transmitted with the DATAGRAM frame, like the STREAM frame, MUST be 299 protected either by 0-RTT or 1-RTT keys. 301 7. IANA Considerations 303 This document registers a new value in the QUIC Transport Parameter 304 Registry: 306 Value: 0x0020 (if this document is approved) 308 Parameter Name: max_datagram_frame_size 310 Specification: Indicates that the connection should enable support 311 for unreliable DATAGRAM frames. An endpoint that advertises this 312 transport parameter can receive datagrams frames from the other 313 endpoint, up to and including the length in bytes provided in the 314 transport parameter. 316 This document also registers a new value in the QUIC Frame Type 317 registry: 319 Value: 0x30 and 0x31 (if this document is approved) 321 Frame Name: DATAGRAM 323 Specification: Unreliable application data 325 8. Acknowledgments 327 Thanks to Ian Swett, who inspired this proposal. 329 9. References 331 9.1. Normative References 333 [I-D.ietf-quic-recovery] 334 Iyengar, J. and I. Swett, "QUIC Loss Detection and 335 Congestion Control", draft-ietf-quic-recovery-23 (work in 336 progress), September 2019. 338 [I-D.ietf-quic-transport] 339 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 340 and Secure Transport", draft-ietf-quic-transport-23 (work 341 in progress), September 2019. 343 9.2. Informative References 345 [I-D.schinazi-quic-h3-datagram] 346 Schinazi, D., "Using QUIC Datagrams with HTTP/3", draft- 347 schinazi-quic-h3-datagram-01 (work in progress), October 348 2019. 350 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 351 DOI 10.17487/RFC0768, August 1980, 352 . 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 360 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 361 January 2012, . 363 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 364 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 365 May 2017, . 367 9.3. URIs 369 [1] mailto:quic@ietf.org 371 [2] https://github.com/tfpauly/draft-pauly-quic-datagram 373 [3] mailto:quic@ietf.org 375 [4] https://github.com/tfpauly/draft-pauly-quic-datagram 377 Authors' Addresses 379 Tommy Pauly 380 Apple Inc. 381 One Apple Park Way 382 Cupertino, California 95014 383 United States of America 385 Email: tpauly@apple.com 387 Eric Kinnear 388 Apple Inc. 389 One Apple Park Way 390 Cupertino, California 95014 391 United States of America 393 Email: ekinnear@apple.com 395 David Schinazi 396 Google LLC 397 1600 Amphitheatre Parkway 398 Mountain View, California 94043 399 United States of America 401 Email: dschinazi.ietf@gmail.com