HTTP Latency Metrics
draft-vinayak-http-latency-00

Abstract

This RFC will outline the different components of end-to-end HTTPS Latency Metrics. Each of these components is either a specific protocol or connection-oriented metrics. Taken together each of these components can reveal the characteristics of the application and the it's beaviour and interaction with the underlying protocol. This draft will however not cover the methodology or tools for measuring this and it is outside the scope of the current document.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on January 31, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  List of HTTP Latency Metrics
3.  Detailed definition of each component
    3.1.  DNS Query Time
    3.2.  Connection Setup Time
    3.3.  SSL Handshake Time
    3.4.  Request Time
    3.5.  First Byte Time
    3.6.  Content Download Time
4.  Explanation of components of HTTP Latency
    4.1.  DNS Query time
    4.2.  Connection Setup Time
    4.3.  SSL Handshake Time
    4.4.  Request Time
    4.5.  First Byte Time
    4.6.  Content Download Time
5.  Special Considerations
    5.1.  DNS Query time
    5.2.  Redirects
    5.3.  Embedded Content Download Time
    5.4.  Compression
6.  Acknowledgements
7.  IANA Considerations
8.  Security Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Additional Stuff
§  Author's Address

1.  Introduction

HTTP has become ubiquitous over the Internet powering several websites and even a small downtime can cause millions of dollars of losses. However most measurement tools and sites either us their own metrics or use different terminology. Some of these metrics are artificial and do not rflect the different stages in a download of an HTML page. In tis draft I will outline the different metrics that matter and their significance to the lifecycle of a html page download.

1.1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  List of HTTP Latency Metrics

The different components of HTTP Latency metrics are as follows.

1. DNS Query time
2. Connection Setup Time
3. SSL Handshake Time
4. Request Time
5. First Byte Time
6. Content Download Time
7. Embedded Content Download

The definition of each of these terms can be found in the following section.

3.  Detailed definition of each component

3.1.  DNS Query Time

DNS Query Time is the a measure of the time taken from the instant that an application starts writing the first byte of the request to the socket to the instant when the last byte of the resolved DNS response is received.

3.2.  Connection Setup Time

Once the IP address has been received by the application, it will try to setup a connection. The connection time is the difference between the instant from when the first SYN packet is sent to the destination host to the time when the final ACK is received by the sender host

3.3.  SSL Handshake Time

TBD

3.4.  Request Time

Sometime the sender host might take sometime to generate and send the HTTP Request that might be spread over several TCP segments. Request Time is the time difference between the time instant when the (secure) connection is setup and the time instant when the last byte is written to the socket.

3.5.  First Byte Time

Once the request has been sent to the destination host, the destination host will take some time to respond to the request and start writing a response to it. The first byte time is the time difference between time instant the last byte of the request is written to the socket and the time instant when the first byte of the response from the server is received.

3.6.  Content Download Time

The Content Download time is the time difference between the instant the first byte of response is recieved by the sending host and the time instant when the last byte of the response is received by the sending host.

4.  Explanation of components of HTTP Latency

4.1.  DNS Query time

DNS query time can reveal problems with the DNS infrastructure such as

1. Improper DNS server configuration.
2. Overloaded DNS server.
3. Too short TTL set for caching of DNS responses.
4. Too many levels of delegation before getting to the right DNS servers.
5. Too many CNAME to be resolved before getting an A record.

In the overall scheme of things, DNS resolution time is actually less except in the case when the content itself is very small and spread over several domain names. A common example of this is thumbnails distributed on many different subdomains.

4.2.  Connection Setup Time

The connection setup time can give an indication of how busy the server is (to be able to accept new connections) or even the packet loss on the network. A packet lost during the connection setup time is usually more costly as compared to those later in the data transfer period. Hence on a lossy network connection setup time can take gives an indication of packet loss.

4.3.  SSL Handshake Time

TBD

4.4.  Request Time

The request time can give an indication of how much time was taken in creating the queries and sending it across the wire to the destination. This time can be significantly large in the case of the large HTTP POST (which browsers use sometimes to upload objects such as photos and videos files). Even normally, web browsers are seen to send small form requests that should usually fit into one TCP segment over two TCP segments - one TCP segment for headers and another for the actual form data adding overhead to the request time. In the overall scheme of things, request time should be insignificant except in the case of testing HTTP end-to-end latency for uploads.

4.5.  First Byte Time

Once the request has been sent, the destionation host takes some time to process it. The processing may involve amongst other things generating a page based on a template, connecting to the database to get data, adding inline style tags and javascript. The time taken for doing all this is typicall seen in first byte time (the idle time at the sender after sending the request). Howver some webservers can be configured to flush data as soon as a request is received. An example of this is flushing out initial lines of the header which could be common to the whole website and the server. In this case the processing time taken by the server can be hidden as the webserver starts pushing data out while parsing the temple and inserting data at appropriate placs in the template.

4.6.  Content Download Time

The content download time can be affected by a whole lot of factors including congestion algorithms, packet loss and whether the sender and receiver support compression or not.

5.  Special Considerations

5.1.  DNS Query time

The application is generally oblivious to the underlying API that does the DNS query. In effect, the process of DNS resolution might involve both UDP and TCP and several sequential lookups (in the case of non-recursive DNS servers). Also DNS servers cache their replies so there might be the problem of spiky behavior when doing continuous end-to-end tests. This effect cannot be completely removed from most measurements as the reply to DNS query can be cached at any level of the DNS heirarchy and depends on the configuration of each client.

Several CDNs also set the TTLs of their replies very small (as small as ~5 seconds). This can have an effect on the end-to-end measurement as the DNS caching layer might not be able to handle small TTLs. Some webbrowsers are alsoo know to have their own internal cache to cache replies from the most recent queries while overllooking the TTLs in the response.

5.2.  Redirects

In the real world, the response to an DNS query or an HTTP request may not be immediate. Examples of both:

• DNS CNAME : Some CDNs and several large websites have a bunch of CNAMEs that need to be followed and resolved before getting the A record with an IP address as an answer. Example TBD
• HTTP 3xx Redirects : HTTP redirects are often used (and abused) by websites. This should be avoided except in rare cases as they will add time delay of atleast one RTT to every HTTP response.
• HTML Redirect : Though this does not fall under the purview of the protocol, HTML META Refresh tags can also be used to reload a page or redirect it to another website. This happens though after the HTTP response has been recived and interpreted by the sending hosti. Example TBD

5.3.  Embedded Content Download Time

The Embedded Content download time is the time difference from which the first DNS request is sent for the embedded content of the page to the time instant of the receipt of the last byte of the page. This does not take care of pages which have continuously flowing data such as stock tickers or pages in which some external or user event trigger another HTTP Request without refreshing the page. Embedded Content Download time is an measure of the time taken to download all the embedded components of the page when the HTML page was first recieved by the sending host.

5.4.  Compression

If both the sender and the receiver support compression then the content download time can be signifiantly reduced. However there are resources and time required at both the sender and receiver for compression and decompression. Also some content compresses better than other. e.g Test can be significantly compressed on-the-fly as compared to video and images (which are generally compressed beforehand using more efficient codecs). But for this to be done the right HTTP headers have to be send by both the sender and receiver

6.  Acknowledgements

I acknowledge Al Morton for his help in creating this draft and his constant encouragement. ISOC also helped me by funding my travel to the IETF.

7.  IANA Considerations

This memo includes no request to IANA.

All drafts are required to have an IANA considerations section (see the update of RFC 2434 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” March 2008.) [I‑D.narten‑iana‑considerations‑rfc2434bis] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.

8.  Security Considerations

All drafts are required to have a security considerations section. See RFC 3552 (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) [RFC3552] for a guide.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  Additional Stuff

This becomes an Appendix.

Author's Address