Managing TCP connections under persistent HTTP

Cohen, Edith; Kaplan, Haim; Oldham, Jeffrey D.

doi:10.1016/s1389-1286(99)00018-3

Cited by 33 publications

(18 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The ubiquitous example of this is the Netscape browser, which uses an empirically determined value of four for the number of parallel TCP connections used by its clients [25]. The GridFTP project allows the user to select the number of parallel TCP connections to use for FTP data transfer [26].…”

Section: Current Workmentioning

confidence: 99%

The end-to-end performance effects of parallel TCP sockets on a lossy wide-area network

Hacker

Athey

Noble

2002

Proceedings 16th International Parallel and Distributed Processing Symposium

162

129

View full text Add to dashboard Cite

IntroductionThere are considerable efforts within the Grid and high performance computing communities to improve end-to-end network performance for applications that require substantial amounts of network bandwidth. The Atlas project [19], for example, must be able to reliably transfer over 2 Petabytes of data per year over transatlantic networks between Europe and the United States.Recent experience [1,2] has demonstrated that actual aggregate TCP throughput realized by high performance applications is persistently much less than the end-to-end structural and load characteristics a network indicates is available. One source of poor TCP throughput is a packet loss rate that is much greater than what would be reasonably expected [20]. Packet loss is interpreted by TCP as an indication of network congestion between a sender and receiver. However, packet loss may be due to factors other than network congestion, such as intermittent hardware faults [4].Current efforts to improve end-to-end performance take advantage of the empirically discovered mechanism of striping data transfers across a set of parallel TCP connections to substantially increase TCP throughput. As a result, application developers and network engineers must have a sound understanding of how parallel TCP connections improve aggregate throughput as well as their effects on a network. This paper addresses several questions concerning the use of parallel TCP connections. The first question is how the use of parallel TCP connections increases aggregate throughput. The second is how to determine the number of TCP connections needed to maximize throughput while avoiding network congestion. Finally, understanding how parallel TCP connections affect a network, and under what conditions they should not be used. This paper suggests some practical guidelines for the use of parallel sockets to maximize end-to-end performance for applications while simultaneously minimizing their network effects.The remainder of this paper is organized as follows. Section two discusses current work. Section three presents a parallel socket TCP bandwidth estimation model and the experimental results. Section four discusses the behavior of packet loss on the Internet and its effect on TCP throughput. Section five presents conclusions and guidelines for using parallel sockets, and discusses some possible avenues for future work. Current WorkApplications generally take two approaches to improve end-to-end network throughput that effectively defeats the congestion avoidance behavior of TCP. The first approach utilizes UDP, which puts responsibility for both error recovery and congestion control completely in the hands of the application. The second approach opens parallel TCP network connections and "stripes" the data (in a manner similar to RAID) across a parallel set of sockets. These two approaches are aggressive and do not permit the fair sharing of the network bandwidth available to applications [5].Recent work [1,2,6] has demonstrated that the parallel socket approach ...

show abstract

Section: Current Workmentioning

confidence: 99%

The end-to-end performance effects of parallel TCP sockets on a lossy wide-area network

Hacker

Athey

Noble

2002

Proceedings 16th International Parallel and Distributed Processing Symposium

162

129

View full text Add to dashboard Cite

show abstract

“…The fact that each Web page consists of many embedded images implies that Web browsing sessions typically consist of many HTTP [4] requests, each for a small size document. The practice with HTTP/1.0 was to use a separate TCP connection for each HTTP request and response [10].…”

Section: A Latencies Of Web Transfermentioning

confidence: 99%

Evaluating web user perceived latency using server side measurements

Marshak

Levy

2003

Computer Communications

View full text Add to dashboard Cite

--The central performance problem in the World Wide Web, in recent years, is user perceived latency. This is the time spent by a user while waiting for a Web page he/she requested. Impatience with poor performance is the most common reason visitors terminate their visit at Web sites. For e-commerce sites, such abandonment translates into lost revenue. For this reason, measuring the delay experienced by its customers is of high importance to a Web site. These measurements are critical for analyzing the site behavior and to size its components. As of today the main tool for conducting such measurements are external, client-side tools, whereby agents located on the net request pages from the site and measure its latency. In this paper we propose a novel solution that conducts the measurements of the user perceived delay at the Web site. The major advantage of this measurement approach, as opposed to client side approach, is that is can evaluate the latency experienced by each and every client (regardless of its network location). Further, this estimate can be conducted at real time, thus allowing the server to control its operation and prioritize the requests based on the actual performance observed by the clients. The solution does not require any agents to be placed at the net. Further, it does not sniff low-level protocols (that is, IP protocols) and is all based on implementation at the HTTP level. As such, it is very efficient and economical. The solution is based on a novel technique in which a special tiny HTTP object, called the sentry, assists in measuring the user perceived latency. The algorithm is implemented on the Apache server. The implementation was tested throughout an extensive array of tests and found to provide very accurate measures.

show abstract

“…Figure 5 illustrates the breakdown of latency components for our original traces without a proxy in place. 3 The latencies do not include the modem delays. Note that connection creation contributes a significant amount of time to the end-to-end latency.…”

Section: Latency Componentsmentioning

confidence: 99%

“…This includes answering questions as when to tear down a connection, which connection to tear down when the proxy runs out of connections, how many simultaneous connections should be maintained to a given content provider or client, when to wait for a persistent connection instead of opening a new connection, and so on [3].…”

Section: Number Of Connections In Modem Environmentmentioning

confidence: 99%

Performance of Web proxy caching in heterogeneous bandwidth environments

Feldmann

Cáceres

Douglis

et al. 1999

IEEE INFOCOM '99. Conference on Computer Communications. Proceedings. Eighteenth Annual Joint Conference of the IEEE Computer A

128

View full text Add to dashboard Cite

Abstract-Much work on the performance of Web proxy caching has focused on high-level metrics such as hit rates, but has ignored low-level details such as "cookies," aborted connections, and persistent connections between clients and proxies as well as between proxies and servers. These details have a strong impact on performance, particularly in heterogeneous bandwidth environments where network speeds between clients and proxies are significantly different than speeds between proxies and servers.We evaluate through detailed simulations the latency and bandwidth effects of Web proxy caching in such environments. We drive our simulations with packet traces from two scenarios: clients connected through slow dialup modems to a commercial ISP, and clients on a fast LAN in an industrial research lab. We present three main results. First, caching persistent connections at the proxy can improve latency much more than simply caching Web data. Second, aborted connections can waste more bandwidth than that saved by caching data. Third, cookies can dramatically reduce hit rates by making many documents effectively uncachable.

show abstract

Managing TCP connections under persistent HTTP

Cited by 33 publications

References 22 publications

The end-to-end performance effects of parallel TCP sockets on a lossy wide-area network

The end-to-end performance effects of parallel TCP sockets on a lossy wide-area network

Evaluating web user perceived latency using server side measurements

Performance of Web proxy caching in heterogeneous bandwidth environments

Contact Info

Product

Resources

About