idnits 2.17.1 draft-xie-bidirectional-messaging-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (4 April 2019) is 1848 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 normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpbis Working Group G. Xie 3 Internet-Draft F. Frindell 4 Intended status: Standards Track Facebook Inc. 5 Expires: 6 October 2019 4 April 2019 7 An HTTP/2 extension for bidirectional messaging communication 8 draft-xie-bidirectional-messaging-01 10 Abstract 12 This draft proposes a http2 protocol extension, which enables 13 bidirectional messaging communication between client and server. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 6 October 2019. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 50 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Routing Stream and ExStream . . . . . . . . . . . . . . 3 52 3.2. Bidirectional Messaging Communication . . . . . . . . . 3 53 3.3. States of RStream and ExStream . . . . . . . . . . . . 4 54 3.4. Negotiate the Extension through SETTINGS frame . . . . 5 55 3.5. Interaction with standard http2 features . . . . . . . 5 56 4. HTTP2 EX_HEADERS Frame . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. FRAME TYPE Registry . . . . . . . . . . . . . . . . . . 6 59 5.2. Settings Registry . . . . . . . . . . . . . . . . . . . 6 60 5.3. Error Code Registry . . . . . . . . . . . . . . . . . . 7 61 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 HTTP/2 is the de facto application protocol in Internet. The 67 optimizations developed in HTTP/2, like stream multiplexing, header 68 compression, and binary message framing are very generic. They can 69 be useful in non web browsing applications, for example, Publish/ 70 Subscribe, RPC. However, the request/response from client to server 71 communication pattern limits HTTP/2 from wider use in these 72 applications. This draft proposes a HTTP/2 protocol extension, which 73 enables bidirectional messaging between client and server. 75 The only mechanism HTTP/2 provides for server to client communication 76 is PUSH_PROMISE. While this satisfies some use-cases, it is 77 unidirectional, i.g. the client cannot respond. In this draft, a new 78 frame is introduced which has the routing properties of PUSH_PROMISE 79 and the bi-directionality of HEADERS. Further, clients are also able 80 group streams together for routing purposes, such that each 81 individual stream does not need to carry additional routing 82 information. 84 2. Conventions and Terminology 86 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 87 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 88 document, are to be interpreted as described in [RFC2119]. 90 All the terms defined in the Conventions and Terminology section in 91 [RFC7540] apply to this document. 93 3. Solution Overview 95 3.1. Routing Stream and ExStream 97 A routing stream (RStream) is a long lived HTTP/2 stream in nature. 98 RStreams are initiated by clients, and can be routed independently by 99 any intermediaries. Though an RStream is effectively a regular 100 HTTP/2 stream, RStreams are recommended for exchanging metadata, but 101 not user data. 103 A new HTTP/2 stream called ExStream is introduced for exchanging user 104 data. ExStreams are recommended for short lived transactions, so 105 intermediaries and servers can gracefully shutdown ExStreams within a 106 short time. The typical use case can be a subscription or publish 107 request/response in Publish/Subscribe use case, or an RPC call 108 between two endpoints. 110 An ExStream is opened by an EX_HEADERS frame, and continued by 111 CONTINUATION and DATA frames. An ExStream MUST be associated with an 112 open RStream, and MUST NOT be associated with any other ExStream. 113 ExStreams are routed according to their RStreams by intermediaries 114 and servers. Effectively, all ExStreams with the same RStream form a 115 logical stream group, and are routed to the same endpoint. 117 3.2. Bidirectional Messaging Communication 119 With RStreams and ExStreams, HTTP/2 can be used for bidirectional 120 messaging communication. As shown in the follow diagrams, after an 121 RStream is open from client to server, either endpoint can initiate 122 an ExStreams to its peer. 124 +--------+ RStream (5) +---------+ RStream (1) +--------+ 125 | client |>--------------->| proxy |>---------------->| server | 126 +--------+ +---------+ +--------+ 127 v ^ v ^ 128 | ExStream(7, RS=5) | | ExStream(3, RS=1) | 129 +------------------------+ +------------------------+ 131 Figure 1: Client initiates the ExStream to server, after an 132 RStream is open. 134 +--------+ RStream (5) +---------+ RStream (1) +--------+ 135 | client |>--------------->| proxy |>---------------->| server | 136 +--------+ +---------+ +--------+ 137 ^ v ^ v 138 | ExStream(4, RS=5) | | ExStream(2, RS=1) | 139 +------------------------+ +------------------------+ 140 Figure 2: Server initiates the ExStream to client, after an 141 RStream is open. 143 Beyond that, clients can multiplex RStreams, ExStreams and regular 144 HTTP/2 streams into one HTTP/2 connection. This enables clients to 145 access different services without initiating new TCP connections. 146 This avoids the latency cost of setting up new connections. This is 147 more desirable for mobile devices because they usually have longer 148 RTT and battery constraints. Multiplexing these services also allows 149 them to share a single TCP connection congestion control context. 151 As shown in the following diagram, the client can exchange data with 152 PubSub, RPC and CDN three different services with one TCP connection. 154 +--------+ RStream (5) +---------+ RStream (1) +----------+ 155 | client |>--------------->| proxy |>---------------->| PUBSUB | 156 +--------+ +---------+ +----------+ 157 v v ^ ^ v v 158 | | RStream (7) / | | \ RStream (5) +----------+ 159 | +-------------------+ | | +---------------->| RPC | 160 | | | +----------+ 161 | | | 162 | Stream (9) | | Stream (7) +----------+ 163 +---------------------------+ +--------------------->| CDN | 164 +----------+ 166 Figure 3: Client opens multiple RStreams and a HTTP/2 stream 167 within one HTTP/2 connection. 169 3.3. States of RStream and ExStream 171 RStreams are regular HTTP/2 streams that follow the stream lifecycle 172 in [RFC7540], section 5.1. ExStreams use the same lifecycle as 173 regular HTTP/2 streams, but also depend on their RStreams. If a 174 RStream is reset, endpoints MUST reset the ExStreams associated with 175 that RStream. If the RStream is closed, endpoints SHOULD allow 176 existing ExStreams complete normally. The RStream SHOULD remain open 177 while communication is ongoing. Endpoints SHOULD refresh any 178 timeouts on the RStream while associated ExStreams are open. 180 A sender MUST NOT initiate new ExStreams if on an RStream that is in 181 the open or half closed (remote) state. 183 Endpoints process new ExStreams only when the RStream is open or half 184 closed (local) state. If an endpoint receives an EX_HEADERS frame 185 specifying an RStream in the closed or haf closed (remote) state, it 186 MUST respond with a connection error of type ROUTING_STREAM_ERROR. 188 3.4. Negotiate the Extension through SETTINGS frame 190 The extension SHOULD be disabled by default. Endpoints can negotiate 191 the use of the extension through the SETTINGS frame. If an 192 implementation supports the extension, it is RECOMMENDED to include 193 the ENABLE_EX_HEADERS setting in the initial SETTINGS frame. HTTP/2 194 compliant implementations will ignore the setting if it is unknown. 195 An endpoint can send EX_HEADERS frames immediately upon receiving a 196 SETTINGS frame with ENABLE_EX_HEADERS=1. 198 Endpoints MUST NOT send out EX_HEADERS before receiving a SETTINGS 199 frame with the ENABLE_EX_HEADERS=1. If a remote endpoint does not 200 support this extension, the EX_HEADERS will be ignored, making the 201 header compression contexts inconsistent between sender and receiver. 203 If an endpoint supports this extension, but receives EX_HEADERS 204 before ENABLE_EX_HEADERS, it MUST respond with a connection error 205 EX_HEADER_NOT_ENABLED_ERROR. 207 Intermediaries SHOULD send the ENABLE_EX_HEADERS setting to clients, 208 only if intermediaries and their upstream servers can support this 209 extension. If an intermediary receives an ExStream but discovers the 210 destination endpoint does not support the extension, it MUST reset 211 the stream with EX_HEADER_NOT_ENABLED_ERROR. 213 3.5. Interaction with standard http2 features 215 The extension implementation should apply stream and connection level 216 flow control, maximum concurrent streams limit, GOAWAY logic to both 217 RStreams and ExStreams. 219 4. HTTP2 EX_HEADERS Frame 221 The EX_HEADERS frame (type=0xfb) has all the fields and frame header 222 flags defined by HEADERS frame in HEADERS [RFC7540]. Moreover, 223 EX_HEADERS has one extra field, RStream ID. It is used to open an 224 ExStream, and additionally carries a header block fragment. 225 EX_HEADERS frames can be sent on a stream in the "idle", "open", or 226 "half-closed (remote)" state. 228 Like HEADERS, the CONTINUATION frame (type=0x9) is used to continue a 229 sequence of header block fragments, if the headers do not fit into 230 one EX_HEADERS frame. 232 +---------------+ 233 |Pad Length? (8)| 234 +-+-------------+-----------------------------------------------+ 235 |E| Stream Dependency? (31) | 236 +-+-------------+-----------------------------------------------+ 237 | Weight? (8) | 238 +-+-------------+-----------------------------------------------+ 239 |R| Routing Stream ID (31) | 240 +-+-------------+-----------------------------------------------+ 241 | Header Block Fragment (*) ... 242 +---------------------------------------------------------------+ 243 | Padding (*) ... 244 +---------------------------------------------------------------+ 246 Figure 4: EX_HEADERS Frame Payload 248 The RStream specified in EX_HEADERS frames MUST be an open stream. 249 The recipient MUST respond with a connection error 250 ROUTING_STREAM_ERROR PROTOCOL_ERROR, if the specified RStream is 251 missing; or is an ExStream rather than a stream; or is closed or 252 half-closed (remote). Otherwise, the states maintained for header 253 compression or flow control) may be out of sync. 255 5. IANA Considerations 257 This document establishes a registry for a new frame type, setting, 258 and error code. 260 5.1. FRAME TYPE Registry 262 The entry in the following table are registered by this document. 264 +---------------+------+--------------+ 265 | Frame Type | Code | Section | 266 +---------------+------+--------------+ 267 | EX_HEADERS | 0xfb | | 268 +---------------+------+--------------+ 270 5.2. Settings Registry 272 The entry in the following table are registered by this document. 274 +------------------------+--------+---------------+---------------+ 275 | Name | Code | Initial Value | Specification | 276 +------------------------+--------+---------------+---------------+ 277 | ENABLE_EX_HEADERS | 0xfbfb | 0 | | 278 +------------------------+--------+---------------+---------------+ 280 5.3. Error Code Registry 282 The entry in the following table are registered by this document. 284 +----------------------+------+-------------------+---------------+ 285 | Name | Code | Description | Specification | 286 +----------------------+------+-------------------+---------------+ 287 | ROUTING_STREAM_ERROR | 0xfb | Routing stream is | | 288 | | | not open | | 289 | EX_HEADERS_NOT_ | 0xfc | EX_HEADERS is not | | 290 | ENABLED_ERROR | | enabled yet | | 291 +----------------------+------+-------------------+---------------+ 293 6. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, 298 . 300 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 301 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 302 DOI 10.17487/RFC7540, May 2015, 303 . 305 Authors' Addresses 307 Guowu Xie 308 Facebook Inc. 309 1 Hacker Way 310 Menlo Park 312 Email: woo@fb.com 314 Alan Frindell 315 Facebook Inc. 317 Email: afrind@fb.com