idnits 2.17.1 draft-montenegro-httpbis-speed-mobility-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Mar 2012) is 4424 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: 'RFC2119' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 341, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Trace 3 Internet-Draft A. Foresti 4 Expires: September 2, 2012 S. Singhal 5 O. Mazahir 6 H. Nielsen 7 G. Montenegro 8 Microsoft 9 Mar 2012 11 HTTP Speed+Mobility 12 draft-montenegro-httpbis-speed-mobility-00 14 Abstract 16 The design of HTTP--how every application and service on the web 17 communicates today--can positively impact user experience, 18 operational and environmental costs, and even the battery life of the 19 devices you carry around. 21 Improving HTTP starts with speed. Apps--not just browsers--should 22 get faster too. More and more, apps are how people access web 23 services, in addition to their browser. Improving HTTP should also 24 make mobile better, particularly to ensure great battery life and low 25 network cost on constrained devices. People and their apps should 26 stay in control of network access. Finally, to achieve rapid 27 adoption, HTTP 2.0 needs to retain as much compatibility as possible 28 with the existing Web infrastructure. Done right, HTTP 2.0 can help 29 people connect their devices and applications to the Internet fast, 30 reliably, and securely over a number of diverse networks, with great 31 battery life and low cost. 33 This document describes "HTTP Speed+Mobility," a proposal for HTTP 34 2.0 that emphasizes performance improvements and security while at 35 the same time accounting for the important needs of mobile devices 36 and applications. The proposal starts from both the Google SPDY 37 protocol and the work the IETF has done around WebSockets. The 38 proposal is not a final product but rather is intended to form a 39 baseline for working group discussion. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 2, 2012. 58 Copyright Notice 60 Copyright (c) 2012 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1.1. Layered Architecture . . . . . . . . . . . . . . . . . 6 78 1.1.2. Existing standards . . . . . . . . . . . . . . . . . . 6 79 1.1.3. Network Cost and Power . . . . . . . . . . . . . . . . 7 80 1.1.4. Flexibility in deployment . . . . . . . . . . . . . . 8 81 1.1.5. Client is in control of content . . . . . . . . . . . 8 82 2. Technical Details . . . . . . . . . . . . . . . . . . . . . . 9 83 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 84 4. Normative References . . . . . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Over the course of its almost two decades of existence, the HTTP 90 protocol has enabled the web to experience phenomenal growth and 91 change the world in more ways than its creators might have imagined. 92 HTTP's designers got many design principles right, including 93 simplicity and robustness. These charateristics allow billions of 94 devices to support and use HTTP in a multitude of communication 95 scenarios. 97 Improving HTTP starts with speed. Web sites have become complex. A 98 single site could comprise of hundreds of different elements (from 99 images to videos to ads to news feeds and so on) that need to get 100 retrieved by the client before the page can be fully displayed. 101 Users expect all of this to happen securely and instantly across all 102 their devices and applications. In many scenarios, HTTP fails to 103 meet these expectations. Speed improvements need to apply not only 104 for browsers but also for apps. More and more, apps are how people 105 access web services, in addition to their browser. 107 The core of the speed problem is that HTTP only allows for a 108 unidirectional request / response model, and it relies on multiple 109 TCP connections for concurrency (pipelining is formally supported by 110 the protocol but is seldom implemented in practice). This leads to a 111 variety of issues, such as additional round trips for connection 112 setup, slow-start delays, and potentially connection rationing: the 113 client may not be able to dedicate too many connections to any single 114 server, and the server needs to protect itself from denial-of-service 115 attacks. As a result, users are often disappointed in the perceived 116 performance of websites. 118 Improving HTTP should also make mobile better. For example, people 119 want their mobile devices to have better battery life. HTTP 2.0 can 120 help decrease the power consumption of network access. Mobile 121 devices also give people a choice of networks with different costs 122 and bandwidth limits. Embedded sensors and clients face similar 123 issues. Mobile considerations require that HTTP be network efficient 124 while simultaneously being sensitive to the limited power, 125 computation, and connectivity capabilities of the client device. 127 1.1. Overview 129 This proposal describes a multiplexing solution to enable efficient 130 delivery of content across a broad variety of scenarios, including 131 mobile apps and devices. It is intended to serve as a baseline for 132 discussion within the HTTPbis working group. 134 This HTTP proposal adheres to the following principles: 136 Maintain the existing HTTP semantics. In particular, the meaning 137 of messages traversing a hybrid (1.1/2.0) request chain must be 138 preserved. Any deviation from this principle would represent an 139 extension to HTTP and should be treated as such. 141 Be as broadly applicable and flexible as the current protocol. As 142 part of that, it must enable servers and clients to select 143 security and compression depending on their own communication 144 needs. 146 Work with the current Web infrastructure including switches, 147 routers, proxies, load balancers, security systems, DNS servers 148 and NATs. 150 Account for the needs of modern mobile clients, including power 151 efficiency and connectivity through costed networks. 153 The proposal's intended outcome is a protocol that can be quickly and 154 widely adopted in the industry, and start delivering real value to 155 end users without imposing undue burden on hardware and software 156 vendors, as well as administrators of legacy equipment. Implementors 157 should also find it easy to understand due to the familiarity of some 158 of its key concepts, which are aligned with innovations that were 159 adopted in recent HTML5 specifications like WebSockets. 161 To achieve these goals, this proposal recommends to optimize HTTP 162 without changing its semantics by implementing a session layer 163 between TCP and HTTP that will support multiplexing of multiple HTTP 164 requests/responses. The session layer would have the following 165 properties: 167 It would maintain the integrity of the layered architecture. 169 It would use an upgrade mechanism similar to that of WebSockets. 170 This would enable compatibility with existing proxies and 171 connection models, without creating a mandatory dependency on TLS. 173 [Same as SPDY] The protocol would define two types of frames: data 174 and control. 176 [Same as SPDY] The session layer would enable negotiation of 177 multiple simultaneous streams for HTTP requests with minimal 178 overhead. 180 [Same as SPDY] The session layer would allow for prioritizing 181 delivery of content to ensure highest value traffic is delivered 182 first. 184 The session layer would enable future extensions to HTTP 2.0 for 185 new scenarios like server push (those extensions would be 186 documented separately). 188 These properties are described in more detail below. 190 1.1.1. Layered Architecture 192 HTTP relies on an in-order, reliable transport to ensure delivery of 193 application data. TCP has almost exclusively provided the reliable, 194 ordered delivery of HTTP messages from one computer to another since 195 its inception. TCP accounts for adverse network conditions such as 196 congestion, or other unpredictable network behavior. Any HTTP 2.0 197 proposal should leverage the reliable transport and not attempt to 198 replicate functions generally accepted as addressed by other layers. 200 Conversely, any proposals for enhancing functionality typically 201 provided by other layers of the networking stack (e.g. congestion 202 control provided by the transport layer) should be brought to the 203 attention of, and discussed in, proper IETF forums (e.g. TCPM WG). 205 During the charter proposal discussion, the security and applications 206 area directors suggested an additional paragraph on security work and 207 authentication. If new work is undertaken in this regard, it should 208 be done by existing IETF security groups in this area. 210 1.1.2. Existing standards 212 HTTP at its core is a simple request-response protocol. The working 213 group has clearly stated that it is a goal to preserve the semantics 214 of HTTP. Thus, we believe that the request-response nature of the 215 HTTP protocol must be preserved. The core HTTP 2.0 protocol should 216 focus on optimizing these HTTP semantics, while improving the 217 transport via a new session layer. Additional capabilities that 218 introduce new communication models like unrequested responses must be 219 treated as an extension to the core protocol, and explored separately 220 from the core protocol. 222 Additionally, HTTP 2.0 should prefer models that are compatible with 223 the existing Internet and, where possible, reuse existing protocol 224 mechanisms. One primary example is in protocol negotiation where the 225 WG should avoid a proliferation of methods, and instead consider 226 using the HTTP 1.1 Upgrade header as it is used in the WebSocket 227 protocol. This will help HTTP 2.0 to be readily deployed on the 228 existing internet, and maintain compatibility with existing web sites 229 and client environments (such as some educational networks). 231 1.1.3. Network Cost and Power 233 Any new protocol for transporting HTTP data on the Internet must also 234 take into account the types of systems and devices that use HTTP and 235 how they are connected to the Internet. The growth of the Internet 236 of the next decade (and longer) will be fueled by mobile apps and 237 mobile devices, as well as by the cheap, limited-capability devices 238 envisioned by the "Internet of Things." For all these devices, speed 239 is only one design tenet: considerations about battery life, 240 bandwidth limitations, processor and memory constraints, and various 241 policy mandates will also challenge designers and users. For 242 instance, the user of a device connected over mobile broadband may 243 need to minimize the amount of data sent in order to conserve 244 bandwidth, minimize power usage and monetary cost of communication. 245 Furthermore, transmitting the same amount of data may have radically 246 different power implications depending on how the transfer is 247 structured: for example, when operating over a mobile broadband 248 interface it is more efficient to use a single larger transfer than 249 to space out the transmission in multiple smaller transfers. 250 Multiple transfers may cause multiple radio transitions between low 251 and high powered states, causing additional battery drain. 253 In short, the choice among speed, cost, and power is not a simple 254 one. At times, speed may be the most important consideration. Other 255 times, bandwidth cost or battery life may be the deciding factor. 256 HTTP 2.0 must allow developers to optimize for the specific 257 constraints of their problem space (which might change over time) 258 rather than imposing a "one size fits all" solution to a generic 259 problem. For example, a server push extension could be a good 260 optimization for many scenarios where content updates to web pages 261 revisited over time are infrequent, and where the client has plenty 262 of bandwidth as well as the needed processing power to either handle 263 the updates instantly, or cache them for later processing. On the 264 other hand, it is not likely to be appropriate in situations where 265 content is being transmitted over a costed link. Neither it will be 266 when the client is running several applications that use network 267 bandwidth concurrently, and bursty, server-initiated content 268 transmissions would interfere with their smooth operation. Rather 269 than forcing developers to choose between using all the features of 270 HTTP 2.0 or sticking with HTTP 1.1, it would be better to provide 271 mechanisms for developers to fine tune the capabilities of HTTP 2.0 272 to a specific set of requirements. 274 In summary, the goals of higher speed, lower cost, lower power may 275 often be aligned. For instance, having less data sent on the wire 276 will allow pages to load faster, allow the radio to power down sooner 277 and consume less bandwidth. But given the variety of the scenarios 278 where HTTP 2.0 will be used, this will not always be the case. For 279 example, a device whose battery is about to run out, or whose cache 280 is near capacity can provide a better user experience by disabling 281 all (or most) server push updates while retaining the other 282 optimizations available in HTTP 2.0. Accordingly, the working group 283 should consider power and cost as well as speed in designing 284 extensions to HTTP 2.0. 286 1.1.4. Flexibility in deployment 288 HTTP is used in a vast array of scenarios and a variety of network 289 architectures. There is no "one size fits all" deployment of HTTP. 290 For example, at times it may not be optimal to use compression in 291 certain environments. For constrained sensors from the "Internet of 292 things" scenario, CPU resources may be at a premium. Having a high 293 performance but flexible HTTP 2.0 solution will enable 294 interoperability for a wider variety of scenarios. There also may be 295 aspects of security that are not appropriate for all implementations. 296 Encryption must be optional to allow HTTP 2.0 to meet certain 297 scenarios and regulations. HTTP 2.0 is a universal replacement for 298 HTTP 1.X, and there are some instances in which imposing TLS is not 299 required (or allowed). For example, a "random thought of the day" 300 web service has very little need for it, nor does a sensor spewing 301 out a temperature reading every few seconds. 303 1.1.5. Client is in control of content 305 Because of the variety of clients on the Internet and the number of 306 connection scenarios, clients must be able to define what content is 307 downloaded. The app or browser is in the best position to assess 308 what the user is currently doing and what data is already locally 309 available. For example, most of the browsers in use today have 310 powerful caches that should be leveraged to store web elements that 311 change infrequently. Clients need the ability to inform the server 312 about cached elements that do not need to be downloaded. In 313 addition, a particular client may have security and compatibility 314 needs with regard to the data being sent. HTTP 2.0 proposals should 315 not force the client to download content that has not been requested 316 and may already be cached. Furthermore, the client must have the 317 option to decline unwanted or uneeded content. Ideally this feedback 318 from the client to the server would allow for incremental approval of 319 content to enable an efficient "push" extension to deliver the right 320 content. 322 2. Technical Details 324 To be added within the next few days in version 01. 326 3. Acknowledgements 328 Thanks to the following individuals who have also contributed with 329 discussions and text: Brian Raymor, Ravi Rao, Dave Thaler, Ivan 330 Pashov, Jitu Padhye, Jean Paoli, Michael Champion, NK Srinivas, 331 Sharad Agarwal and Rob Mauceri. 333 This document incorporates materials from 334 http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00. 336 4. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 342 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 343 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 345 Authors' Addresses 347 Rob Trace 348 Microsoft 350 Email: Rob.Trace@microsoft.com 352 Adalberto Foresti 353 Microsoft 355 Email: aforesti@microsoft.com 357 Sandeep Singhal 358 Microsoft 360 Email: Sandeep.Singhal@microsoft.com 362 Osama Mazahir 363 Microsoft 365 Email: OsamaM@microsoft.com 367 Henrik Frystyk Nielsen 368 Microsoft 370 Email: HenrikN@microsoft.com 372 Gabriel Montenegro 373 Microsoft 375 Email: Gabriel.Montenegro@microsoft.com