idnits 2.17.1 draft-pauly-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 (December 17, 2018) is 1958 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-transport-16 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 2 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: June 20, 2019 D. Schinazi 6 Google LLC 7 December 17, 2018 9 An Unreliable Datagram Extension to QUIC 10 draft-pauly-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 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 20, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Specification of Requirements . . . . . . . . . . . . . . 2 54 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 3 56 4. Datagram Frame Type . . . . . . . . . . . . . . . . . . . . . 3 57 5. Behavior and Usage . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Datagram Identifiers . . . . . . . . . . . . . . . . . . 5 59 5.2. Flow Control and Acknowledgements . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 63 9. Informative References . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a 69 secure, multiplexed connection for transmitting reliable streams of 70 application data. Reliability within QUIC is performed on a per- 71 stream basis, so some frame types are not eligible for 72 retransmission. 74 Some applications, particularly those that need to transmit real-time 75 data, prefer to transmit data unreliably. These applications can 76 build directly upon UDP [RFC0768] as a transport, and can add 77 security with DTLS [RFC6347]. Extending QUIC to support transmitting 78 unreliable application data would provide another option for secure 79 datagrams, with the added benefit of sharing a cryptographic and 80 authentication context used for reliable streams. 82 This document defines four new DATAGRAM QUIC frame types, which carry 83 application data without requiring retransmissions. 85 1.1. Specification of Requirements 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 2. Motivation 95 Transmitting unreliable data over QUIC provides benefits over 96 existing solutions: 98 o Applications that open both a reliable TLS stream and an 99 unreliable DTLS flow to the same peer can benefit by sharing a 100 single handshake and authentication context between a reliable 101 QUIC stream and flow of unreliable QUIC datagrams. This can 102 reduce the latency required for handshakes. 104 o QUIC uses a more nuanced loss recovery mechanism than the DTLS 105 handshake, which has a basic packet loss retransmission timer. 106 This may allow loss recovery to occur more quickly for QUIC data. 108 o QUIC datagrams, while unreliable, can support acknowledgements, 109 allowing applications to be aware of whether a datagram was 110 successfully received. 112 These reductions in connection latency, and application insight into 113 the delivery of datagrams, can be useful for optimizing audio/video 114 streaming applications, gaming applications, and other real-time 115 network applications. 117 Unreliable QUIC datagrams can also be used to implement an IP packet 118 tunnel over QUIC, such as for a Virtual Private Network (VPN). 119 Internet-layer tunneling protocols generally require a reliable and 120 authenticated handshake, followed by unreliable secure transmission 121 of IP packets. This can, for example, require a TLS connection for 122 the control data, and DTLS for tunneling IP packets. A single QUIC 123 connection could support both parts with the use of unreliable 124 datagrams. 126 3. Transport Parameter 128 Support for receiving the DATAGRAM frame types is advertised by means 129 of a QUIC Transport Parameter (name=accepts_datagrams, value=12). An 130 endpoint that includes this parameter supports the DATAGRAM frame 131 types and is willing to receive such frames on this connection. 132 Endpoints MUST NOT send DATAGRAM frames until they have sent and 133 received the accepts_datagrams transport parameter. An endpoint that 134 receives a DATAGRAM frame when it has not sent the accepts_datagrams 135 transport parameter MUST terminate the connection with error 136 PROTOCOL_VIOLATION. 138 4. Datagram Frame Type 140 DATAGRAM frames are used to transmit application data in an 141 unreliable manner. The DATAGRAM frame type takes the form 0b001000XX 142 (or the set of values from 0x20 to 0x23). The least significant bit 143 of the DATAGRAM frame type is the LEN bit (0x01). It indicates that 144 there is a Length field present. If this bit is set to 0, the Length 145 field is absent and the Datagram Data field extends to the end of the 146 packet. If this bit is set to 1, the Length field is present. The 147 second least significant bit of the DATAGRAM frame type is the 148 DATAGRAM_ID bit (0x02). It indicates that there is a Datagram ID 149 field present. If this bit is set to 0, the Datagram ID field is 150 absent and the Datagram ID is assumed to be zero. If this bit is set 151 to 1, the Datagram ID field is present. 153 A DATAGRAM frame is shown below. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | [Datagram ID (i)] ... 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | [Length (i)] ... 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Datagram Data (*) ... 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1: DATAGRAM Frame Format 167 The fields of a DATAGRAM frame are as follows: 169 Datagram ID: A variable-length integer indicating the datagram ID of 170 the datagram (see Section 5.1). 172 Length: A variable-length integer specifying the length of the 173 datagram in bytes. If the length is zero, the data extends to the 174 end of the QUIC packet. 176 Datagram Data: The bytes of the datagram to be delivered. 178 5. Behavior and Usage 180 When an application sends an unreliable datagram over a QUIC 181 connection, QUIC will generate a new DATAGRAM frame and send it in 182 the first available packet. This frame SHOULD NOT be delayed, but 183 MAY be coalesced with other STREAM or DATAGRAM frames. 185 When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD 186 deliver the data to the application immediately. 188 DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. 190 5.1. Datagram Identifiers 192 Since several applications relying on datagrams have the need to 193 identify which application-level flow a given datagram is a part of, 194 DATAGRAM frames carry a datagram identifier. Applications that do 195 not have a need for the identifier can use the value zero on their 196 DATAGRAM frames and use the DATAGRAM_ID bit to omit sending the 197 identifier over the wire. If an application uses a mixture of 198 DATAGRAM frames with and without the DATAGRAM_ID bit set, the frames 199 without it are assumed to be part of the application-level flow with 200 Datagram ID zero. 202 5.2. Flow Control and Acknowledgements 204 Although the DATAGRAM frame is not retransmitted upon loss detection, 205 it does contribute to the maximum data for the overall connection. 206 Packets that contain only DATAGRAM frames do need to be acknowledged, 207 but implementations SHOULD defer and batch acknowledgements since the 208 timing of these acknowledgements is not used for loss recovery. 210 The DATAGRAM frame does not provide any explicit flow control 211 signaling apart from the connection-level flow control. DATAGRAM 212 frames are flow controlled only when the maximum data for the 213 connection is hit, at which point the BLOCKED frame is sent. 215 In cases in which a DATAGRAM frame is blocked due to connection-level 216 flow control or congestion control, an implementation MAY drop the 217 frame without sending it. 219 6. Security Considerations 221 The DATAGRAM frame shares the same security properties as the rest of 222 the data transmitted within a QUIC connection. All application data 223 transmitted with the DATAGRAM frame, like the STREAM frame, MUST be 224 protected either by 0-RTT or 1-RTT keys. 226 7. IANA Considerations 228 This document registers a new value in the QUIC Transport Parameters: 230 Value: 12 (if this document is approved) 232 Parameter Name: accepts_datagrams 234 Specification: Indicates that the connection should enable support 235 for unreliable DATAGRAM frames. An endpoint that advertises this 236 transport parameter can receive datagrams frames from the other 237 endpoint. 239 This document also registers a new value in the QUIC Frame Type 240 registry: 242 Value: 0x1c - 0x1d (if this document is approved) 244 Frame Name: DATAGRAM 246 Specification: Unreliable application data 248 8. Acknowledgments 250 Thanks to Ian Swett, who inspired this proposal. 252 9. Informative References 254 [I-D.ietf-quic-transport] 255 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 256 and Secure Transport", draft-ietf-quic-transport-16 (work 257 in progress), October 2018. 259 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 260 DOI 10.17487/RFC0768, August 1980, 261 . 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 269 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 270 January 2012, . 272 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 273 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 274 May 2017, . 276 Authors' Addresses 278 Tommy Pauly 279 Apple Inc. 280 One Apple Park Way 281 Cupertino, California 95014 282 United States of America 284 Email: tpauly@apple.com 285 Eric Kinnear 286 Apple Inc. 287 One Apple Park Way 288 Cupertino, California 95014 289 United States of America 291 Email: ekinnear@apple.com 293 David Schinazi 294 Google LLC 295 1600 Amphitheatre Parkway 296 Mountain View, California 94043 297 United States of America 299 Email: dschinazi.ietf@gmail.com