idnits 2.17.1 draft-yang-alto-http2-transport-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2021) is 1019 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) == Unused Reference: 'RFC7971' is defined on line 358, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group Y. Yang 3 Internet-Draft Yale University 4 Intended status: Standards Track July 12, 2021 5 Expires: January 13, 2022 7 ALTO Transport using HTTP/2 8 draft-yang-alto-http2-transport-00 10 Abstract 12 The ALTO base protocol and ALTO/SSE are based on HTTP/1.x, and they 13 introduce complexities to address limitations of HTTP/1.x. The 14 deployment of HTTP/2 allows this document to design ALTO/H2, which 15 benefits from the additional capabilities of HTTP/2 to provide 16 services for ALTO. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 22 "OPTIONAL" in this document are to be interpreted as described in BCP 23 14 [RFC2119][RFC8174] when, and only when, they appear in all 24 capitals, as shown here. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 13, 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. ALTO/H2 Design Overview . . . . . . . . . . . . . . . . . . . 3 62 3. ALTO/H2 Information Resource Directory (IRD) . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 5. ALTO based on HTTP/3 Considerations . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Application-Layer Traffic Optimization (ALTO) provides a means for 75 network applications to obtain network status information. The ALTO 76 base protocol [RFC7285] is based on the sequential request and 77 response model of HTTP/1.1 [RFC7230]; hence, in the base protocol, an 78 ALTO client only can issue a sequence of requests on network 79 information resources, and the ALTO server sends the information 80 resources one-by-one, in the order of the request sequence. To 81 address the use cases where an ALTO client may need to efficiently 82 monitor changes to a set of network information resources and the 83 protocol is still based on the HTTP/1.1 model, the ALTO Working Group 84 introduces ALTO/SSE (ALTO Incremental Update based on Server-Sent- 85 Event) [RFC8895], so that an ALTO client can manage (i.e., add and 86 remove) a set of requests maintained at an ALTO server, and the 87 server can continuously, concurrently, and incrementally push updates 88 whenever a monitored network information resource changes. ALTO/SSE 89 can be considered a more general protocol of the ALTO base protocol 90 to transport network information. Figure 1. shows the architecture 91 and message flow of ALTO/SSE. 93 ------------------------------------------------------------------ 94 | | 95 | +-------+ +-------+ 1. init request +------+ | 96 | | | | | <------------- | | | 97 | | | | | -------------> | | | 98 | 3.add/ | | | | 1'. control uri | | | 99 | remove | | | | | | | 100 | resource |Stream | |Update | | | | 101 -------->|Control| private |Stream | 2a. data update |Client| -- 102 |Server |<------->|Server | messages | | 103 -------- | | | | --------------> | | <- 104 | response | | | | --------------> | | | 105 | | | | | 2b.control update| | | 106 | +-------+ +-------+ messages +------+ | 107 | | 108 ------------------------------------------------------------------ 110 Figure 1: ALTO SSE Architecture and Message Flow. 112 With the wide deployment of newer HTTP (e.g., HTTP/2 [RFC7540]), this 113 document specifies ALTO transport based on HTTP/2, referred to as 114 ALTO/H2. The newer transport can provide multiple benefits: 116 o ALTO based on HTTP/2 natively supports multiple concurrent 117 requests pending at the server, realizing a main design goal of 118 ALTO SSE. At the same time, instead of using two TCP connections 119 (a control channel and a data channel) as ALTO/SSE does, ALTO 120 based on HTTP/2 can use a single TCP connection, achieving a 121 design with only one connection. 123 o ALTO based on HTTP/2 can take advantage of the benefit provided by 124 HTTP/2 to avoid head-of-line blocking in the data channel, 125 reducing latency. 127 o ALTO based on HTTP/2 can take advantage of other benefits of 128 HTTP/2, including potentially higher encoding efficiency and 129 stronger enforcement of security (i.e., using https). 131 2. ALTO/H2 Design Overview 133 There are multiple design points. 135 o First, how to transport incremental update messages to a monitored 136 resource (e.g., in a single HTTP/2 stream or each update uses a 137 unique HTTP/2 stream)? Since there is sequential dependency among 138 the incremental updates to a single information resource, there is 139 no concurrency gain in separating them into different streams. 141 Creating multiple streams, on the other hand, has overhead. 142 Hence, ALTO/H2 uses a single HTTP/2 stream to carry the 143 incremental updates to each monitored request. An implication of 144 the preceding design is that to allow flexibility, ALTO/SSE allows 145 different types of incremental update encodings (e.g., merge patch 146 vs JSON patch), and hence ALTO/H2 needs to solve the same problem: 147 it needs a header layer above HTTP/2 to indicate the media type of 148 each incremental update. 150 o Second, how to distinguish between an ALTO service that sends a 151 one-shot response and one that sends incremental updates. Instead 152 of introducing ALTO/H2 to completely replace the ALTO base 153 protocol [RFC7285] and ALTO/SSE [RFC8895], ALTO/H2 can run in 154 parallel with them, to support incremental deployment. A single 155 ALTO server can provide multiple resources in its IRD, and an 156 ALTO/H2 resource is indicated in the ALTO IRD, consistent with 157 ALTO base protocol and ALTO/SSE. 159 3. ALTO/H2 Information Resource Directory (IRD) 161 Extending the IRD example in Section 8.1 of [RFC8895], Figure 2 is 162 the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, 163 and ALTO/H2. 165 In particular, 167 "my-network-map": { 168 "uri": "https://alto.example.com/networkmap", 169 "media-type": "application/alto-networkmap+json", 170 }, 171 "my-routingcost-map": { 172 "uri": "https://alto.example.com/costmap/routingcost", 173 "media-type": "application/alto-costmap+json", 174 "uses": ["my-networkmap"], 175 "capabilities": { 176 "cost-type-names": ["num-routingcost"] 177 } 178 }, 179 "my-hopcount-map": { 180 "uri": "https://alto.example.com/costmap/hopcount", 181 "media-type": "application/alto-costmap+json", 182 "uses": ["my-networkmap"], 183 "capabilities": { 184 "cost-type-names": ["num-hopcount"] 185 } 186 }, 187 "my-filtered-cost-map": { 188 "uri": "https://alto.example.com/costmap/filtered/constraints", 189 "media-type": "application/alto-costmap+json", 190 "accepts": "application/alto-costmapfilter+json", 191 "uses": ["my-networkmap"], 192 "capabilities": { 193 "cost-type-names": ["num-routingcost", "num-hopcount"], 194 "cost-constraints": true 195 } 196 }, 197 "my-simple-filtered-cost-map": { 198 "uri": "https://alto.example.com/costmap/filtered/simple", 199 "media-type": "application/alto-costmap+json", 200 "accepts": "application/alto-costmapfilter+json", 201 "uses": ["my-networkmap"], 202 "capabilities": { 203 "cost-type-names": ["num-routingcost", "num-hopcount"], 204 "cost-constraints": false 205 } 206 }, 207 "my-props": { 208 "uri": "https://alto.example.com/properties", 209 "media-type": "application/alto-endpointprops+json", 210 "accepts": "application/alto-endpointpropparams+json", 211 "capabilities": { 212 "prop-types": ["priv:ietf-bandwidth"] 213 } 214 }, 215 "my-pv": { 216 "uri": "https://alto.example.com/endpointcost/pv", 217 "media-type": "multipart/related; 218 type=application/alto-endpointcost+json", 219 "accepts": "application/alto-endpointcostparams+json", 220 "capabilities": { 221 "cost-type-names": [ "path-vector" ], 222 "ane-properties": [ "maxresbw", "persistent-entities" ] 223 } 224 }, 225 "update-my-costs": { 226 "uri": "https://alto.example.com/updates/costs", 227 "media-type": "text/event-stream", 228 "accepts": "application/alto-updatestreamparams+json", 229 "uses": [ 230 "my-network-map", 231 "my-routingcost-map", 232 "my-hopcount-map", 233 "my-simple-filtered-cost-map" 234 ], 235 "capabilities": { 236 "incremental-change-media-types": { 237 "my-network-map": "application/json-patch+json", 238 "my-routingcost-map": "application/merge-patch+json", 239 "my-hopcount-map": "application/merge-patch+json" 240 }, 241 "support-stream-control": true 242 } 243 }, 244 "update-my-costs-h2": { 245 "uri": "https://alto.example.com/updates-h2/costs", 246 "media-type": "application/alto-h2", 247 "accepts": "application/alto-updatestreamparams+json", 248 "uses": [ 249 "my-network-map", 250 "my-routingcost-map", 251 "my-hopcount-map", 252 "my-simple-filtered-cost-map" 253 ], 254 "capabilities": { 255 "incremental-change-media-types": { 256 "my-network-map": "application/json-patch+json", 257 "my-routingcost-map": "application/merge-patch+json", 258 "my-hopcount-map": "application/merge-patch+json" 259 }, 260 "support-stream-control": true 261 } 262 }, 264 "update-my-props": { 265 "uri": "https://alto.example.com/updates/properties", 266 "media-type": "text/event-stream", 267 "uses": [ "my-props" ], 268 "accepts": "application/alto-updatestreamparams+json", 269 "capabilities": { 270 "incremental-change-media-types": { 271 "my-props": "application/merge-patch+json" 272 }, 273 "support-stream-control": true 274 } 275 }, 276 "update-my-pv": { 277 "uri": "https://alto.example.com/updates/pv", 278 "media-type": "text/event-stream", 279 "uses": [ "my-pv" ], 280 "accepts": "application/alto-updatestreamparams+json", 281 "capabilities": { 282 "incremental-change-media-types": { 283 "my-pv": "application/merge-patch+json" 284 }, 285 "support-stream-control": true 286 } 287 } 289 Note that it is straightforward for an ALTO sever to run HTTP/2 and 290 support concurrent retrieval of multiple resources such as "my- 291 network-map" and "my-routingcost-map" using multiple HTTP/2 streams 292 with the need to introducing ALTO/H2. 294 The resource "update-my-costs-h2" provides an ALTO/H2 based 295 connection, and this is indicated by the media-type "application/ 296 alto-h2". For an ALTO/H2 connection, the client can send in a 297 sequence of control requests using media type application/alto- 298 updatestreamparams+json. The server creates HTTP/2 streams and 299 pushes updates to the client. 301 4. Security Considerations 303 The properties defined in this document present no security 304 considerations beyond those in Section 15 of the base ALTO 305 specification [RFC7285]. 307 5. ALTO based on HTTP/3 Considerations 309 One consideration of the ALTO/H2 design is the pending deployment of 310 HTTP3. 312 6. IANA Considerations 314 IANA will need to register the alto-h2 media type under ALTO registry 315 as defined in [RFC7285]. 317 7. Acknowledgments 319 The authors of this document would also like to thank many for the 320 reviews and comments. 322 8. References 324 8.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 328 RFC2119, March 1997, . 331 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 332 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 333 7230, DOI 10.17487/RFC7230, June 2014, . 336 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 337 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 338 "Application-Layer Traffic Optimization (ALTO) Protocol", 339 RFC 7285, DOI 10.17487/RFC7285, September 2014, 340 . 342 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 343 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 344 10.17487/RFC7540, May 2015, . 347 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 348 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 349 May 2017, . 351 [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic 352 Optimization (ALTO) Incremental Updates Using Server-Sent 353 Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 354 2020, . 356 8.2. Informative References 358 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 359 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 360 Deployment Considerations", RFC 7971, DOI 10.17487/ 361 RFC7971, October 2016, . 364 Author's Address 366 Y. Richard Yang 367 Yale University 368 51 Prospect St 369 New Haven, CT 06520 370 USA 372 Email: yry@cs.yale.edu