idnits 2.17.1 draft-mccall-httpbis-timing-measurements-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 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 (June 16, 2012) is 4325 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 361, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. McCall 3 Internet-Draft Akamai 4 Intended status: Standards Track June 16, 2012 5 Expires: December 18, 2012 7 HTTP Extension to provide timing data for performance measurement 8 draft-mccall-httpbis-timing-measurements-00 10 Abstract 12 This memo presents a method for allowing an HTTP server to gather 13 relevant performace data from compliant user-agents. Though the HTML 14 5 standard supplies Nav-Timings there is no standard way for that 15 data to be communicated back to an origin. The intention of this 16 document is to describe a method in which that can be done cleanly 17 and scalably. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 18, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Supported Client Measurements . . . . . . . . . . . . . . . . 5 55 3. Delivering Measurement Data . . . . . . . . . . . . . . . . . 6 56 4. Illustrative Use Case . . . . . . . . . . . . . . . . . . . . 7 57 5. Proposed HTTP protocol extension . . . . . . . . . . . . . . . 9 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 60 8. Closing Thoughts . . . . . . . . . . . . . . . . . . . . . . . 12 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 1. Overview 68 One of the primary goals of the HTTP 2.0 is to improve performance of 69 web pages. While there have been many performance improvements in 70 the entire web stack since the first iteration of HTTP - from server, 71 to network, to browser - there are now important efforts being made 72 to improve the protocol which delivers much of the world's content 73 every day. Indeed, it's no surprise that having a faster website has 74 shown to improve customer conversion rates and user engagement, and 75 with richer websites becoming more prevalent, improving performance 76 is a natural next step in the evolution of the protocol. While there 77 are many different proposals on how best to speed up HTTP, this 78 document focuses on quantifying the performance of an HTTP session. 80 In its current state, HTTP has no means to expose performance metrics 81 for an HTTP session. Because of this, today, most web page 82 performance measurement is done one of two ways: 84 Synthetic transactions 86 Real-user Measurement 88 Synthetic transactions tend to rely on a instrumented browser that 89 has the ability measure DNS resolution time, first byte time, object 90 download time, DOM processing time, and other browser events. There 91 are many synthetic transaction options currently available, ranging 92 from 3rd-party solutions provided by companies like Keynote [Keynote] 93 and Gomez [Gomez] , to open-source projects like WebPageTest [WPT] . 94 While these solutions are valuable, they do have limitations. In 95 particular, most these measurements are performed in controlled, 96 "clean room" environment. These "clean rooms" often have better- 97 performing networks, browsers, and computers than a real user might 98 have, and thus, tend to provide a best-case measurement of a site's 99 performance. 101 Real-user measurement is normally performed by instrumenting the 102 target webpage with JavaScript to capture measurements similar to 103 those available in synthetic transactions. Recently, the W3C has 104 submitted a few specification drafts [Nav-Timing] which provide an 105 interface for browsers to expose performance timing data, and most 106 modern browsers support the Navigation Timing interface. While the 107 measurements available using browser-side RUM are extremely valuable 108 in quantifying an end-user experience, this solution also comes with 109 limitations. In particular, running JavaScript on the client does 110 not come without some performance impact. In addition, instrumenting 111 the webpage with timing measurements can potentially be non-trivial 112 and add to development time for web page designers. 114 This document outlines an alternative to both synthetic measurements 115 and real-user measurements in their current forms by adding new 116 request and response headers to the HTTP protocol. By coupling 117 client-side metrics into the HTTP session, end-user web page 118 performance can be easily quantified without the need and overhead of 119 JavaScript running in the client's browser, and without having to 120 rely on third parties to provide performance data. Additionally, 121 since the server is privy to the performance of the session, it is 122 possible for it to modify the content delivered accordingly. 124 At a high level, the HTTP Timing Measures Extension would work in a 125 manner similar to the following: 127 A new client request header, X-Accept-Measurement, is sent at the 128 initiation of an HTTP request. 130 A negotiation takes place between the server and the client to 131 determine which measurements will be sent by the client and a 132 timing interval for the measurements. The server requests 133 measurements by sending an X-Send-Measurement response header. 135 Assuming the negotiation is successful, the client sends 136 measurements after the timing interval has expired to the server 137 in an HTTP POST request with an X-Timing-Measures header. 139 We believe that adding this functionality to HTTP is important for a 140 variety of reasons. CDNs, in particular, compete through performance 141 attributes. However, there are a number of issues that make showing 142 value through performance data difficult: Web site owners tend to be 143 hesitant to add new JavaScript to their sites out of fear of slowing 144 the site down, and synthetic measurements don't truly show what real 145 users are experiencing. Even if a CDN were to transparently insert 146 measurement code into a web page, there are risks involved. By 147 adding measurements directly into HTTP, the playing field is leveled 148 by having the protocol itself provide the de-facto method of 149 measuring web site performance. 151 2. Supported Client Measurements 153 The W3C spec for Navigation Timing provides an excellent interface 154 for collecting base page metrics. However, it is limited to network 155 and browser events, and in those cases only for the base page as it 156 is served. AJAX-initiated events and object timings are not exposed. 157 The draft W3C spec for Resource Timing goes further, but to date has 158 no browser support. 160 In addition to the base measurements outlined in Navigation Timing, 161 the client should optionally support providing measurements for all 162 resources required to render the page within the timing interval 163 specified by the server. Having this level of measurement 164 granularity would allow one to collect measurements for objects that 165 are delivered outside of the base page measurement, and be useful in 166 illustrating end user experience. 168 At a minimum, clients should support the measurements outlined in the 169 Navigation Timing spec. Supporting other resource timings should be 170 optional, since it could conceivably generate a large number of 171 performance metrics to be sent back to the server. 173 3. Delivering Measurement Data 175 Once the client and server have negotiated the collection of the 176 measurements, data should be sent back to the collecting server via 177 an empty HTTP POST request, and encapsulated in an X-Timing-Measures 178 header. 180 However, there may be a case in which the amount of data to be sent 181 back to the server is too much to encapsulate in an HTTP header. An 182 HTTP POST also may not be desirable in cases when POSTs interfere 183 with application logic. In this case, an optional HTTP header, 184 X-Timing-Measures-Collector can be specified in the initial response 185 to indicate to the client where to send the data. If the X-Timing- 186 Measures-Collector header exists, data will be sent in the body of 187 the POST request, in the format previously described. 189 In some cases, it may be necessary to specify a Timing Measures 190 Collector on a per-page basis, in which case an optional meta element 191 can be added to an HTML page. Such a meta element might look like: 193 196 By default, the X-Timing-Measures-Collector attribute is null, and 197 data is POSTed back to the page as described earlier. 199 4. Illustrative Use Case 201 This use case demonstrates a successful performance measurement 202 negotiation and data posting. In it, we show how a user agent and 203 site (www.example.com) would negotiate and transfer measurement data. 205 Request1: 206 UA --> Server (www.example.com) 208 GET /index.html HTTP/2.0 209 Host: www.example.com 210 X-Accept-Measurement: allowed 211 Response1: 212 Server (www.example.com) --> UA 214 HTTP/2.0 200 OK 215 X-Send-Measurement: 216 dns;firstByte;domReady;domLoaded;onLoad;resources:TI:300000 218 We see that the first UA request has indicated that it is willing to 219 provide HTTP performance measurements (X-Accept-Measurement: 220 allowed), and that the server has replied with the measurements it is 221 requesting (X-Send-Measurement: 222 dns;firstByte;domReady;domLoaded;onLoad;resources:TI:300000). The 223 X-Send-Measurement response header sent by the server is followed 224 with a semicolon-delimited list of desired measurements, followed by 225 'TI', which is the timing interval of the desired measurement data 226 expressed as milliseconds. 228 Request2: 229 UA --> Server (www.example.com) 231 POST /index.html HTTP/2.0 232 Host: www.example.com 233 X-Timing-Measures: 234 dns:23;firstByte:120;domReady:1200; 235 domLoaded:1300;onLoad:1331;resources:1400 237 Response2: 238 Server (www.example.com) --> UA 240 HTTP/2.0 200 OK 242 We now see the UA sending back data to the initial server via an 243 empty HTTP POST request, including the X-Timing-Measures header 244 containing measurements that happened in the timing interval 245 requested by the server in the initial handshake. The header 246 contains key-value pairs of the requested measurements, where the 247 values are represented as milliseconds of the measurement's duration. 248 Depending on which measurements are supported by the browser, all or 249 some of the measurements requested by the server are returned. 251 5. Proposed HTTP protocol extension 253 To implement Timing Measures, additions of new HTTP headers are 254 required. The details of the request and response headers are 255 included as an initial starting point for discussions, rather than as 256 a final proposal. 258 Pseudo-BNF grammar for these headers might look like: 260 X-Accept-Measurement = "Accept-Measurement:" measure-resp 261 measure-resp = "accept|not-accepted" 263 X-Send-Measurement = "Send-Measurement:" measure-type:TI 264 measure-type = measurement 265 TI = timing-interval 267 X-Timing-Measures = "Timing-Measures:" measure-type:value 268 measure-type = measurement 269 value = value 271 X-Timing-Measures-Collector = "Timing-Measures-Collector:" collector-url 272 collector-url = collector 274 The Accept-Measurement, Send-Measurement headers are optional. If a 275 negotiation is successful, the Timing-Measures header is required. 276 The Timing-Measures-Collector header is optional. All measurement 277 values, as well as TI, are 32-bit integers expressed as milliseconds. 278 The collector-url is a string representing the URI data should be 279 sent back to. 281 Measurements are submitted via an HTTP POST request and must contain 282 the Timing-Measures header, and should not contain any data in the 283 body of the request. Measurements are sent as key-value pairs in the 284 form of measurement:value delimited by semicolons. If the Timing- 285 Measures-Collector header is sent or the relevant HTML meta tag 286 exists, the client must send its data to the specified collector-url 287 in the body of a POST request, using the data format specified above. 289 The user agent must discard the measurements after the Timing 290 Interval for the requested metrics expires. 292 6. Security Considerations 294 User-agent MUST follow 'same origin' considerations when sending 295 timing data 297 7. IANA Considerations 299 The new header fields 301 Accept-Measurement 303 Send-Measurement 305 Timing-Measures 307 Timing-Measures-Collector 309 should require IANA assignment 311 8. Closing Thoughts 313 Outside of adoption, the goal of this document is to get the 314 community thinking about measuring HTTP performance. While many of 315 the current HTTP 2.0 proposals have been designed to improve 316 performance, to date, none discuss quantifying the intended 317 improvements. 319 It is well known by the author that there are shortcomings and 320 unanswered questions in this document. In particular, there is a 321 lingering question about whether or not the timing measurements 322 should exist within the context of a server connection, or whether 323 they are best viewed within the scope of a user session. Another 324 question arises as to what should happen if the user agent closes the 325 connection before the timing interval has expired. With the optional 326 X-Timing-Measures-Collector header that can be used to send the 327 measurement results to another host, it is the belief of the author 328 that measurements should exist as part of a user session, and not 329 necessarily tied to a particular connection. Community consensus on 330 this matter is encouraged. 332 Another concern is that some of the measurements outlined in the 333 "Supported Client Measurements" section are more browser-specific 334 than some may be comfortable with. However, while network timing is 335 most obviously relevant for HTTP, it is also possible to infer 336 browser and hardware performance by looking at the time elapsed 337 processing and rendering the document. If a server had a full 338 performance profile of the user agent it was communicating with, it 339 could potentially serve different content or make other decisions 340 based on the UA's performance characteristics. 342 One glaring omission is the security of the proposed extension. 343 While performance data would seem to be of low value to malicious 344 users, at the very least the security of the extension should be 345 considered. 347 Finally, the grammar for the new headers needs to be properly 348 defined. The grammar outlined in the "Proposed HTTP Protocol 349 Extension" section is woefully incomplete and syntactically 350 incorrect, and is included only for illustrative purposes. 352 In closing, the intention is that these, as well as other 353 shortcomings in this document, are fleshed out by the community. The 354 more people thinking about these issues, the faster and better the 355 web will be. 357 9. References 359 9.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 9.2. Informative References 366 [Keynote] "Keynote Systems", . 368 [Gomez] "Gomez Networks", . 370 [WPT] "WebPageTest", . 372 [Nav-Timing] 373 "Nav-Timing Spec", 374 . 376 Author's Address 378 Mike McCall 379 Akamai Technologies