idnits 2.17.1 draft-thomson-webtrans-hwtq-00.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 (12 July 2021) is 990 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-02 == Outdated reference: A later version (-08) exists of draft-ietf-webtrans-http2-00 == Outdated reference: A later version (-09) exists of draft-ietf-webtrans-http3-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBTRANS M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational 12 July 2021 5 Expires: 13 January 2022 7 Generic HTTP Binding for WebTransport using QUIC 8 draft-thomson-webtrans-hwtq-00 10 Abstract 12 The WebTransport API provides an interface to HTTP resources that 13 provides transport-layer capabilities. This document describes how a 14 subset of the QUIC protocol can be used to provide these transport 15 capabilities. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the WebTransport Working 22 Group mailing list (webtransport@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/browse/webtransport/. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/martinthomson/webtransport-hwtq. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 13 January 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Open Design Questions . . . . . . . . . . . . . . . . . . 4 65 4. Comparison to an HTTP/2-Only Design . . . . . . . . . . . . . 4 66 4.1. Session Control and Resource Management . . . . . . . . . 4 67 4.2. Stream States . . . . . . . . . . . . . . . . . . . . . . 5 68 4.3. HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.4. Additional Framing . . . . . . . . . . . . . . . . . . . 5 70 4.5. RESET_STREAM Redundancies . . . . . . . . . . . . . . . . 6 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 This document is input to discussion of the design of [WTH2] and -- 80 to a lesser extent -- [WTH3]. The author has no intent of pursuing 81 publication of this document, it exists only to provide a more 82 complete exploration of an alternative design. 84 This document describes a means of providing a WebTransport-capable 85 mapping to any HTTP version, with a specific goal of providing a TCP- 86 based design that fulfills all of the basic WebTransport 87 requirements. 89 The proposed design transplants the design of QUIC streams [QUIC] 90 almost directly, saving specification effort. This might also save 91 implementation and validation effort through reuse. 93 2. Conventions and Definitions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. Overview 103 The WebTransport API depends on three basic functions: bidirectional 104 and unidirectional streams, plus datagrams. When using a QUIC 105 transport, using native QUIC support for these capabilities ([QUIC], 106 [QD]) provides the best performance. However, the need to provide a 107 TCP-based protocol means finding a protocol that works with -- at a 108 minimum -- HTTP/2. 110 This document proposes that an extended CONNECT [EXT-CONNECT] be used 111 to establish a new connection using a new protocol identifier (with 112 an identifier to be decided). Using CONNECT results in a 113 bidirectional communications medium with stream characteristics 114 between client and server. 116 Once established, this document proposes using a subset of QUIC 117 frames to carry the control messages, stream data, and datagrams. 118 The following frames would be permitted: 120 * PADDING 122 * RESET_STREAM 124 * STOP_SENDING 126 * STREAM (with the 0x02 bit set only) 128 * MAX_DATA 130 * MAX_STREAM_DATA 132 * MAX_STREAMS 134 * DATA_BLOCKED 136 * STREAM_DATA_BLOCKED 138 * STREAMS_BLOCKED 140 * DATAGRAM (0x31 only; from [QD]) 141 This set of frames is sufficient to carry data for streams of the 142 necessary types. It also provides a complete set of resource 143 management functions that operate within the scope of the 144 bidirectional WebTransport communication. 146 This would use a subset of the stream states in [QUIC]. This ensures 147 that the API is able to present a very similar interface to streams 148 as that provided in QUIC. Implementations might be simplified 149 slightly as some state transitions are not possible in a context 150 where ordered delivery can be guaranteed. 152 Endpoints MUST NOT send stream data that is not contiguous or out of 153 order. The underlying transport provides reliable, ordered delivery. 154 Implementations will still need to buffer stream data, but the 155 implementation of that buffering does not need to handle gaps in 156 incoming flow. 158 3.1. Open Design Questions 160 It is not clear whether "connection"-level flow control (the QUIC 161 MAX_DATA frame) is necessary in the context of this integration. TCP 162 or HTTP/2 flow control mechanisms already exist to control the flow 163 of information on the request and response, which makes the control 164 redundant in some circumstances. The inclusion is justified by the 165 potential for DATAGRAM frames and other control frames to be 166 exchanged independent of this limit. 168 A connection close signal at the level of the WebTransport is 169 possible. The QUIC application CONNECTION_CLOSE (0x1d) might be used 170 for this purpose. 172 4. Comparison to an HTTP/2-Only Design 174 The main claim made here is that this design is comparatively simpler 175 than the design in [WTH2]. However, there are other consequences 176 that are worth consideration. This section attempts to document 177 these more fully. 179 4.1. Session Control and Resource Management 181 The QUIC binding in [WTH3] is complicated by the need to manage the 182 total number of WebTransport sessions on the one connection. 183 Furthermore, the use of shared resources at the level of the 184 connection (streams especially) means that it is necessary to 185 carefully manage the commitment of resources to a 187 [WTH2] has similar constraints on operation. This proposal avoids 188 using a shared resource for its functions, avoiding that problem. 189 The cost is that sessions are exposed to additional head-of-line 190 blocking performance costs. As the goal of the protocol is to 191 support TCP-based HTTP versions, the marginal impact of head-of-line 192 blocking is expected to be minimal. 194 4.2. Stream States 196 [WTH2] describes a design that integrates with the HTTP/2 stream 197 state machine. This is challenging as it results in the details of 198 the HTTP/2 stream state machine being visible in the API. In 199 particular, the closing of send and receive parts of HTTP/2 streams 200 are coupled, where they are independent in QUIC. 202 As a protocol extension, this difference could be addressed with 203 adjustments to the state machine, but this results in the 204 implementation of an entirely new state management logic, which 205 increases implementation complexity. 207 The other way to resolve this discrepancy is to require the same sort 208 of close-state coupling when QUIC is used so that behavior is 209 consistent across different protocol versions. 211 4.3. HTTP/1.1 213 Though not a hard requirement of the design, the ability to support 214 HTTP/1.1 is an advantage of this design. 216 It is also possible to use this design with HTTP/3, albeit with worse 217 performance characteristics than the more complete design of [WTH3]. 218 This is offered merely as an observation. 220 4.4. Additional Framing 222 This proposal adds an additional layer of framing, which increases 223 overheads in HTTP/2. This is less efficient in terms of overheads 224 than native use of HTTP/2 layer constructs. This is partially 225 mitigated by the relatively good efficiency of QUIC framing and the 226 potential to send larger frames with the HTTP/2 stream. The QUIC- 227 derived frames this uses do not need to be limited in size in the 228 same way as those at the HTTP/2 layer. 230 4.5. RESET_STREAM Redundancies 232 There is a small bit of redundancy in the RESET_STREAM frame. With a 233 reliable substrate, there is no need to signal the number of bytes 234 that were consumed by the stream in a RESET_STREAM frame. This field 235 could be safely removed, if reuse of the QUIC encodings was deemed to 236 be unimportant. 238 In the current design, endpoints are required to provide an accurate 239 value for the Final Size field of RESET_STREAM frames they send and 240 to validate the value they received. 242 5. Security Considerations 244 Relatively few of the security considerations of QUIC apply, though a 245 small few are relevant, such as Section 21.6 of [QUIC]. 247 6. IANA Considerations 249 This document has no IANA actions. Currently. It might be necessary 250 to work out how the framing layer might be extended in a way that can 251 avoid collisions between frames used in QUIC and this design. A few 252 options seem plausible: 254 * Register WebTransport extensions in the QUIC registry. After all, 255 there is tons of space over there. The main cost there is 256 recording what context each frame type applies to. 258 * Make a clone of the registry for WebTransport that only contains 259 WebTransport frames. This is relatively simple, but might result 260 in collisions as both protocols independently evolve. 262 * Forego extensibility, at least in the short term, and require a 263 revision or update to the protocol to define new frames or to add 264 the use of a registry. 266 7. Normative References 268 [EXT-CONNECT] 269 McManus, P., "Bootstrapping WebSockets with HTTP/2", 270 RFC 8441, DOI 10.17487/RFC8441, September 2018, 271 . 273 [QD] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 274 Datagram Extension to QUIC", Work in Progress, Internet- 275 Draft, draft-ietf-quic-datagram-02, 16 February 2021, 276 . 279 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 280 Multiplexed and Secure Transport", RFC 9000, 281 DOI 10.17487/RFC9000, May 2021, 282 . 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 290 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 291 May 2017, . 293 [WTH2] Frindell, A., Kinnear, E., Pauly, T., Vasiliev, V., and G. 294 Xie, "WebTransport using HTTP/2", Work in Progress, 295 Internet-Draft, draft-ietf-webtrans-http2-00, 3 July 2021, 296 . 299 [WTH3] Vasiliev, V., "WebTransport over HTTP/3", Work in 300 Progress, Internet-Draft, draft-ietf-webtrans-http3-01, 19 301 May 2021, . 304 Acknowledgments 306 Alan Frindell probably doesn't like this proposal all that much, but 307 he at a minimum deserves some credit for it being written down. 309 Author's Address 311 Martin Thomson 312 Mozilla 314 Email: mt@lowentropy.net