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