datatracker.ietf.org
Sign in
Version 5.6.2.p6, 2014-09-03
Report a bug

Analysis of SPDY and TCP Initcwnd
draft-white-httpbis-spdy-analysis-00

Document type: Expired Internet-Draft (individual)
Document stream: No stream defined
Last updated: 2013-01-07 (latest revision 2012-07-06)
Intended RFC status: Unknown
Other versions: (expired, archived): plain text, pdf, html

Stream State:No stream defined
Document shepherd: No shepherd assigned

IESG State: Expired
Responsible AD: (None)
Send notices to: No addresses provided

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found here:
http://www.ietf.org/archive/id/draft-white-httpbis-spdy-analysis-00.txt

Abstract

Making the Internet faster is the goal of many product and service companies. Many strategies exist, from data caching to packet switching, performance improvements in Internet browser clients and server software, without forgetting the transport network scaling from the fiber core to the access edges. This report investigates two proposed protocol enhancements aimed at making the web browsing user experience better by optimizing the transport of web objects and thereby reducing the page load time. The two enhancements are SPDY, a replacement of the HyperText Transfer Protocol (HTTP) requiring client and server changes, and a TCP tune-up, an increase in the TCP initial congestion window accomplished by a setting change on the web servers. Both show promise, but there are some caveats, particularly with SPDY. SPDY is a candidate for standardization as HTTP/2.0. In addition to a discussion of the two enhancements, this report provides the results of laboratory testing on SPDY version 2 and the proposed increase in the TCP initial congestion window in a variety of simulated conditions, comparing the page load time when using the proposed enhancement to the page load time for the default case of HTTPS and current initial congestion window settings. The proposed enhancements generate mixed results: web page load times were reduced in some scenarios but increased significantly in others. The performance improvement (or degradation) varied depending on the number of servers, configuration of the initial TCP congestion window, and especially any network packet loss. The following results were obtained across all scenarios comparing SPDY and congestion window enhancements to standard HTTPS. o Average reduction in page load time was 29% o Best improvement was over 78% reduction in page load time o Worst cases showed a negative impact, resulting in a 3.3x increase in page load time These results lead us to the following conclusions: o The SPDY protocol is currently a moving target, and thus it would be challenging to realize a return on investment for general- purpose usage in web servers. o Protocol improvements, standardization in the IETF and wider adoption by the client/server software may warrant a second look at SPDY. o Some applications in controlled environments may gain by leveraging SPDY. SPDY might be a valuable tool where the a single entity provides the servers, the client software, and the web content. o If SPDY were adopted very widely it may have some secondary benefits for network operators through improved infrastructure scalability due to a significant reduction in concurrent TCP sessions, as well as a reduction in Packets Per Second. o The proposed increase in the TCP initial congestion window is straightforward, requires no client modifications, and on its own provides consistent (albeit modest) performance gains. This report is available in a somewhat more detailed form in [SPDY-ANALYSIS].

Authors

Greg White <g.white@cablelabs.com>
Dan Rice <d.rice@cablelabs.com>

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid)