Predicting short-transfer latency from TCP arcana: extended

34 Pages·2005·1.27 MB·English

Predicting short-transfer latency from TCP arcana: extended version

Martin Arlitt, Balachander Krishnamurthy1, Jeffrey C. Mogul
Internet Systems and Storage Laboratory
HP Laboratories Palo Alto
HPL-2005-137
September 30, 2005*

TCP latency, In some contexts it may be useful to predict the latency for short TCP
network transfers. For example, a Web server could automatically tailor its
performance content depending on the network path to each client, or an "opportunistic
networking” application could improve its scheduling of data transfers.
Several techniques have been proposed to predict the latency of short
TCP transfers based on online measurements of characteristics of the
current TCP connection, or of recent connections from the same client.
We analyze the predictive abilities of these techniques using traces from
a variety of Web servers, and show that they can achieve useful accuracy
in many, but not all, cases. We also show that a previously-described
model for predicting short-transfer TCP latency can be improved with a
simple modification. Ours is the first trace-based analysis that evaluates
these prediction techniques across diverse user communities.

* Internal Accession Date Only
1 AT&T Labs – Research, Florham Park, NJ 07932
This is an extended version of a paper original published in the Proceedings of the Internet Measurement
Conference, 19-21 October 2005, Berkeley, CA, USA
Approved for External Publication
© Copyright 2005 Hewlett-Packard Development Company, L.P.
Predicting short-transfer latency from TCP arcana:
extended version
MartinArlitt BalachanderKrishnamurthy JeffreyC.Mogul
HPLabs/UniversityofCalgary AT&TLabs–Research HPLabs
PaloAlto,CA94304 FlorhamPark,NJ07932 PaloAlto,CA94304
[email protected] [email protected] [email protected]
Abstract
In some contexts it may be useful to predict the latency for short TCP transfers. For example, a
Web server could automatically tailor its content depending on the network path to each client, or an
“opportunisticnetworking”applicationcouldimproveitsschedulingofdatatransfers.
SeveraltechniqueshavebeenproposedtopredictthelatencyofshortTCPtransfersbasedononline
measurementsofcharacteristicsofthecurrentTCPconnection,orofrecentconnectionsfromthesame
client. We analyze the predictive abilities of these techniques using traces from a variety of Web
servers,andshowthattheycanachieveusefulaccuracyin many,butnot all,cases. Wealsoshowthat
apreviously-describedmodelforpredictingshort-transferTCPlatencycanbeimprovedwithasimple
modification. Ours is the first trace-based analysis that evaluates these prediction techniques across
diverseusercommunities.
1 Introduction
It is often useful to predict the latency (i.e., duration) of a short TCP transfer before deciding when or
whethertoinitiate it. Networkbandwidths,round-triptimes(RTTs),andlossratesvaryovermany orders
ofmagnitude,and sothe transferlatency fora givendataitemcanvary similarly.
Exampleswhere suchpredictionsmightbe usefulinclude:
(cid:0)
a Web server could automatically select between “low-bandwidth” and “high-bandwidth” versions
ofcontent,withthe aimofkeeping the user's downloadlatency below athreshold[11,20].
(cid:0)
AWebserverusingshortest-remaining-processing-time(SRPT)scheduling[23]couldbetterpredict
overallresponsetimesifitcanpredict network transferlatency,whichinmany casesis theprimary
contributortoresponsetime.
(cid:0)
An application using opportunistic networking [25] might choose to schedule which data to send
based on an estimate of the duration of a transfer opportunity and predictions of which data items
can makethe mosteffective useofthatopportunity.
Thereareseveralpossiblewaystodefine“short”TCPtransfers. ModelsforTCPperformancetypically
distinguish between long flows which have achieved steady state, and short flows which do not last long
enough to leave the initial slow-start phase. Alternatively, one could define short in terms of an arbitrary
threshold on transfer length. While defining “short” in terms of slow-start behavior is less arbitrary, it is
also less predictable (because the duration of slow-start depends on unpredictable factors such as cross
traffic and packet loss), and so for this paper we use a definition based on transfer length. Similarly,
while transfer length could be defined in terms of the number of data packets sent, this also depends
2
on unpredictable factors such as MTU discovery and the interactions between application buffering and
socket-level buffering. So, for simplicity, in this paper we define “short” in terms of the number of bytes
transferred.
Several techniques have previously been proposed for automated prediction of the transfer time for a
short TCP transfer. Some of these techniques glean their input parameters from characteristics of TCP
connections, such as round-trip time (RTT) or congestion window size (cwnd), that are not normally
exposed to the server application. We call these characteristics TCP arcana. These parameters can then
be used in a previously-described model for predicting short-transfer latency [2]. Other techniques use
observations ofthe actuallatency forpasttransfersto the sameclient (ortoclientsin asimilarlocation of
thenetwork), andassume thatpastperformanceis agoodpredictoroffuture performance.
Inthispaper,weusepacket-leveltracescapturednearavarietyofrealWebserverstoevaluatetheability
oftechniquesbasedonbothTCParcanaandhistoricalobservations topredictshorttransferlatencies. We
showthatthepreviously-describedmodeldoesnotquitefittheobservations,butthatasimplemodification
tothe modelgreatly improvesthe fit. We alsodescribe an experiment suggesting(basedona limited data
set) thatRTTobservations couldbe used to discriminate, withmodest accuracy, betweendialup and non-
dialuppaths.
1.1 Relatedwork
Our work complements previous work on predicting the throughput obtained by long TCP transfers.
He et al. [9] characterized these techniques as either formula-based or history-based; our TCP arcana
approachis formula-based.
Lakshminarayanan and Padmanabhan [14] briefly discussed the relationship between RTT and TCP
throughput, but for transfer lengths of 100KB, since their paper focuses on peer-to-peer systems. They
found a poorcorrelation betweenlatency and throughput, which is not surprising, becausefor long trans-
ferstheformula-basedmethodrequiresknowledgeofpacketlossrates,whichtheydidnotmeasure. They
didremarkthat“latencymayinfactbeagoodpredictorofthroughputwhendial-uphosts... areincluded,”
whichagreeswiththeresultswepresent in Section 5.
Hall et al. [8] studied the effect of early packet loss on Web page download times. As with our work,
they point out that download times are not always correlated with path bandwidth. They focused on
packetlossesoccurringearlyenoughintheTCPconnectionthat“neitherclientnorserverhasseenenough
packets to establish a usable round trip time estimation,” which leads to excessively long retransmission
timeouts.
2 Latency prediction techniques
We start with the assumption that an application wishing to predict the latency of a short transfer must
do so as early as possible, before any data has been transferred. We also assume that prediction is being
done at the server end of a connection that was initiated by a client; although the approaches could be
extended to client-side prediction,wehave nodata to evaluate thatscenario.
Weexamine two predictionapproachesin this paper:
(cid:1)
The initial-RTT approach: The server's first(cid:2) possible measurement of the connection RTT is
provided by the interval betweenits initialSYN ACK packetand the client's subsequentACK. For
short transfers, this RTT measurementis often sufficient to predict subsequentdata transfer latency
to this client. This approach was first proposed by Mogul and Brakmo [19] and discussed in [20].
We describe itfurtherinSection2.1.
(cid:1)
Therecent-transfersapproach: A server canpredict the data transfer bandwidth to a givenrequest
3
basedon recentlymeasuredtransferbandwidthstothesameclient. Thisapproach,inthecontext of
Webservers,wasproposedin[11]; wedescribe it further inSection2.2.
2.1 PredictionfrominitialRTTs
Supposeonewantstopredictthetransferlatency,foraresponseofagivenlengthoveraspecificHTTP
connection, with no prior information about the client and the network path, and before having to make
the very first decision about what content to send to the client. Let us assume that we do not want the
server to generate extra networktraffic orcauseextra delays. What information could one gleanfrom the
TCPconnection before it istoolate?
Client Server
SYN (P1)
SYN|ACK (P2)
1 RTT
ACK (P3)
HTTP GET (P4)
ACK (P5)
HTTP REPLY (P6)
T
HTTFPI NR E(PP8L)Y (P7) ransfer latency
ACK (P9)
Figure 1: Timeline: typicalHTTPconnection
Figure 1 shows a timeline for the packets sent over a typical non-persistent HTTP connection. (We
assumethattheclientTCPimplementationdoesnotallowtheclientapplicationtosenddatauntilafterthe
3-wayhandshake;thisistrueofmostcommonstacks.) Inthistimeline,theserverhastomakeitsdecision
immediately afterseeingtheGET-bearingpacket(P )fromtheclient.
4
It might be possible to infer network path characteristics from the relative timing of the client's first
ACK-only(P )andGET(P )packets,usingapacket-pairmethod[13]. However,theinitial-RTTpredictor
3 4
(cid:3)
instead uses the path's RTT, as measured between the server's SYN ACK packet (P ) and the client's
2
subsequentACK-onlypacket(P ). Sincethesetwopacketsarebothnear-minimumlength,theyprovidea
3
directmeasurementofRTT,inthe absenceofpacket loss.
Why might this RTTbe a usefulpredictoroftransferlatency?
(cid:4)
Many last-hop network technologies impose both high delay and low bandwidth. For example,
dialup modems almost always add about 100ms to the RTT [4, 5] and usually limit bandwidth to
under 56Kb/s. If we observe an RTT much lower than 100ms, we can infer that the path does not
involve a modem. (See Section 5 for quantitative evidence.) A similar inference might be made
aboutsome(perhapsnot all)popularlow-bandwidthwirelessmedia.
(cid:4)
Even when the end-to-end bandwidth is large, the total transfer time for short responses depends
mostly on the RTT. (Therefore, an HTTP request header indicating client connection speed would
notreliably predictlatencyfor suchtransfers.)
Cardwelletal.[2]showedthatfortransferssmallerthanthelimitingwindowsize,theexpectedlatency
4
totransferd segments viaTCP,whenthereare no packet losses,isapproximated by
d(cid:10) g (cid:11) 1(cid:12) (cid:13)
E(cid:5)latency(cid:6)(cid:8)(cid:7) RTT (cid:9) logg (cid:10) 1(cid:12) (1)
w
1
(cid:14)
where
(cid:14)
g dependson theclient's delayed-ACK policy; reasonablevaluesare 1.5or2(see [2] fordetails).
(cid:14)
(cid:15)(cid:17)(cid:16)(cid:19)(cid:18)(cid:21)(cid:20)
w dependsontheserver'sinitialvaluefor ;reasonablevaluesare2,3,or4(see [2]fordetails).
(cid:14) 1
d (cid:7)(cid:23)(cid:22) len (cid:24)
(cid:14) MSS
len isthe numberofbytessent.
MSSis theTCPmaximumsegment sizefor theconnection.
NotethatmedianWebresponsesizes(weusethedefinitionof“response”fromtheHTTPspecification[6])
aretypicallysmallerthanthe limitingwindow size;see Section3.4.
End-to-end bandwidth limits and packet losses can only increase this latency. In other words, if we
know theRTTandresponsesize,then we can predicta lowerbound forthetransferlatency.
We would like to use the RTT to predict the transfer latency as soon as possible. Therefore, the first
time a serverseesa requestfrom agiven client, it hasonly oneRTTmeasurementto use forthis purpose.
But if the client returns again, which RTT measurement should the server use for its prediction? It could
use the most recent measurement (that is, from the current connection), as this is the freshest; it could
use the mean of all measurements, to deal with noise; it could use an exponentially smoothed mean, to
reduce noisewhile favoring fresh values;it could usethe minimum measurement, to accountfor variable
queueingdelays;orit couldusethe maximum measurement,tobe conservative.
“Most recent,” which requires no per-client state, is the simplest to implement, and this is the only
variant wehave evaluated.
2.2 Predictionfromprevioustransfers
KrishnamurthyandWillsoriginallydescribedthenotionofusingmeasurementsfromprevioustransfers
toestimatetheconnectivityofclients[11]. Aprimemotivationofthisworkwastoretainpoorlyconnected
clients,whomightavoida Web siteifits pagestake toolongto download. Betterconnectedclients could
bepresented enhancedversions ofthepages.
This approach is largely passive: it examines server logs to measure the inter-arrival time between
base-object (HTML) requests and the requests for the first and last embedded objects, typically images.
Exponentiallysmoothedmeansofthesemeasurementsare thenusedto classifyclients. A network-aware
clusteringscheme[10]wasusedasaninitialclassificationmechanism,ifaclienthadnotbeenseenbefore
butanotherclientfromthesameclusterhadalreadyusedthesite. KrishnamurthyandWillsusedadiverse
collectionofserverlogs frommultiple sitestoevaluate thedesign,and Krishnamurthyetal. presentedan
implementation [12], using a modified version of the Apache server, to test the impact of various server
actionson clientswithdifferentconnectivity.
The recent-transfers approach that we study in this paper is a simplification of the Krishnamurthy and
Wills design. Becausetheir measurementsuseWeb serverlogs,this gave themenoughinformationabout
pagestructuretoinvestigatethealgorithm'sabilitytopredictthedownloadtimeforanentirepage,includ-
ing embedded objects. We have not extracted object-relationship information from our packet traces, so
we onlyevaluated per-responselatency,ratherthan per-page latency. On the otherhand,most server logs
provide timing information with one-second resolution, which means that a log-based evaluation cannot
provide thefine-grainedtimingresolution that wegotfrom ourpacket traces.
5
2.3 Definingtransferlatency
Wehave so farbeenvagueaboutdefining“transferlatency.” Onemight define this asthetimebetween
the departure of the first response byte from the server and the arrival of the last response byte at the
client. However,withoutperfectclocksynchronizationandpackettracesmadeateveryhostinvolved,this
durationis impossibleto measure.
For this paper, we define transfer latency as the time between the departure of the first response byte
from the server and the arrival at the server of the acknowledgment of the last response byte. (Figure 1
depictsthisintervalforthecaseofanon-persistentconnection.) Thistendstoinflateourlatencymeasure-
ment by approximately RTT/2, but because path delays can be asymmetric we do not attempt to correct
for that inflation. Weare effectively measuring anupperboundonthe transferlatency.
2.4 Predictingattheclient
Thispaperfocusesonmakinglatencypredictions attheserverendofaconnection. Webelievethatthe
techniques we describe should be usable at the client end. For example, Figure 1 shows how the server
(cid:25)
can obtain an RTT sample from the timestamps of the SYN ACK packet (P ) and the ACK-only packet
2
(P ). Butthe clientcanalsogetanearly RTTsample,fromthetimestamps oftheinitialSYN(P )andthe
3 1
(cid:25)
SYN ACK(P ).
2
Similarly, a client could maintain historical information to drive a recent-transfers predictor. While a
singleclientwouldnothavesufficienthistorywithrespecttomanyservers,a poolofclientsmightjointly
obtain enough history (as in the throughput-oriented SPAND system [24]). Such an approach would
probablyworkbestiftheclientsinthepoolwerelocatedneartoeachother,intermsofnetworktopology.
Unfortunately,ourserver-centrictracesdonotallowus toevaluateclient-basedlatency prediction.
3 Methodology
Wefollowed this overallmethodology:
(cid:26)
Step 1: collect packet traces near a variety of Web servers with different and diverse user popula-
tions.
(cid:26)
Step 2: extract the necessary connection parameters, including client IDs, from these raw traces to
createintermediate traces.
(cid:26)
Step3: evaluatethe predictorsusing simple simulator(s)drivenfromthe intermediate traces.
Although the prediction mechanisms analyzed in this paper are not necessarily specific to Web traffic,
welimitedourtrace-basedstudytoWebtrafficbecausewehavenotobtainedsignificantanddiversetraces
of other short-transfer traffic. It might be useful to capture traffic near busy e-mail servers to get another
relevantdata set,sincee-mail transfers alsotend to beshort[7, 17].
Giventhatwearedefining“short”TCPtransfersintermsofthenumberofdatabytessent,weanalyzed
three plausible thresholds: 8K bytes, 16K bytes, and 32K bytes; this paper focuses on the 32K byte
threshold. (The response-sizedistributions inFigure 3supportthis choice.)
3.1 Tracesets
We collected trace sets from several different environments, all in North America. For reasons of
confidentiality,we identifythesesetsusing shortnames:
(cid:26)
C2: Collectedona corporate network
(cid:26)
U2,U3,U4: Collectedata University
(cid:26)
R2: Collectedat acorporate researchlab
6
In all cases, the traces were collected on the public Internet (not on an Intranet) and were collected relat-
ivelynearexactly onepublicly-accessibleWebserver.
Wecollectedfull-packettraces,usingtcpdump,andlimitedthe tracestoincludeonlyTCPconnections
toorfromthe localWeb server.
While we wanted to collect traces covering an entire week at each site, storage limits and other re-
strictions meant that we had to collect a series of shorter traces. In order to cover representative peri-
ods over the course of a week (May 3–9, 2004), we chose to gather traces for two to four hours each
day: 9:00AM-11:00AM Monday, Wednesday, and Friday; 2:00PM-4:00PM Tuesday and Thursday; and
10:00AM-2:00PM Saturday and Sunday (all are local times with respect to the trace site: MST for C2,
MDTforU2,andPDTforR2). Weadditionallygatheredtwo24-hour(midnighttomidnight)tracesatthe
University: U3onThursday,Aug. 26,2004,andU4 onTuesday,Aug. 31,2004.
3.2 Arethesetracesrepresentative?
We certainly would prefer to have traces from a diverse sample of servers, clients, and network paths,
butthisisnotnecessarytovalidateourapproach. Ourgoalisnottopredictthelatenciesseenbyallclient-
serverpairs intheInternet,buttofindamethodfora givenservertopredictthelatenciesthatititself(and
onlyitself)will encounter in the nearfuture.
It is true that some servers or client populations might differ so much from the ones in our traces that
ourresults donotapply. Althoughlogisticalandprivacyconstraintspreventusfromexploringawiderset
oftraces,ouranalysistoolsareavailableathttp://bro-ids.org/bro-contrib/network-analysis/akm-imc05/ so
thatotherscantest ouranalysesontheirown traces.
Theresultsin Section4.6imply thatourequation-basedpredictorworks wellfor somesitesandnot so
wellforothers. Onecoulduseourtrace-basedmethodologytodiscoverifaserver'sresponselatenciesare
sufficientlypredictablebefore deciding toimplement prediction-basedadaptationatthat server.
3.3 Traceanalysistools
Westartbyprocessingtheraw(full-packetbinary)tracestogenerateonetupleperHTTPrequest/response
exchange. Ratherthanwriteanewprogramtoprocesstherawtraces,wetookadvantageofBro,apower-
ful tool originally meant for network intrusion detection [21]. Bro includes a policy script interpreter for
scriptswritteninBro'scustomscriptinglanguage,whichallowedustodothisprocessingwitharelatively
simplepolicy script –about800lines,includingcomments. Wecurrently useversion 0.8a74ofBro.
Bro reduces the network stream into a series of higher level events. Our policy script defines hand-
lers for the relevant events. We identify four analysis states for a TCP connection: not established,
timing SYN ACK, established, and error has occurred. We also use four analysis states for each
HTTP transaction: waiting for reply, waiting for end of reply, waiting for ack of reply, and trans-
action complete. (OurscriptfollowsexistingBropractice ofusingtheterm“reply”inlieuof“response”
for statenames.)
Progression through these states occurs as follows. When the client's SYN packet is received, a data
structure is created to retain information on the connection, which starts in the not established state.
(cid:27)
WhenthecorrespondingSYN ACKpacketis receivedfromtheserver,themodeledconnectionentersthe
(cid:27)
timing SYN ACKstate,andthentothe establishedstatewhenthe clientacknowledgesthe SYN ACK.
We then wait for http request() eventsto occur on that connection. When a request is received, a data
structure is created to retain information on that HTTP transaction, which starts in the waiting for reply
transactionstate. Onanhttp reply()event,thatstatebecomeswaiting for end of reply. Oncetheserver
hasfinishedsendingtheresponse,thetransactionstateissettowaiting for ack of reply. Oncetheentire
HTTP response has been acknowledged by the client, that state is set to transaction complete. This
7
designallowsourscript toproperlyhandlepersistentandpipelinedHTTPconnections.
Our analysis uses an additional state, error has occurred, which is used, for example, when a TCP
connectionisreset,orwhenapacketismissing,causingagapintheTCPdata. Allsubsequentpacketson
a connection in anerror has occurredstate are ignored, althoughRTTand bandwidth estimatesare still
recorded forallHTTPtransactions thatcompletedonthe connection beforethe error occurred.
For each successfully completed and successfully traced HTTP request/response exchange, the script
generatesone tuple that includes the timestamp of the arrival time of the client's acknowledgement of all
outstandingresponsedata;theclient'sIPaddress;theresponse'slength,content-type,andstatuscode;the
position of the responsein a persistentconnection(if any); and estimates ofthe initial RTT,the MSS,the
response transfer latency, and the response transfer bandwidth. The latency is estimated as described in
Section2.3,andthe bandwidth estimate is thencomputed fromthelatencyestimateandthelength.
Thesetuplesformanintermediatetrace,convenientforfurtheranalysisandseveralordersofmagnitude
smaller than the original raw packet trace. For almost all of our subsequent analysis, we examine only
(cid:28)
responseswithstatuscode 200,sincethesearetheonlyonesthatshouldalwayscarryfull-lengthbodies.
3.3.1 Proxiesandrobots
MostWebserversreceiverequestsfrommulti-clientproxyservers,andfromrobotssuchassearch-engine
crawlers; both kinds of clients tend to make more frequent requests than single-human clients. Requests
from proxies and robots skew the reference stream to make the average connection's bandwidth more
predictable,whichcould biasourresultsin favorofourpredictionmechanisms.
Wetherefore“pruned”ourtracestoremoveapparentproxiesandrobots(identifiedusingaseparateBro
script); wethenanalyzedboth theprunedandunprunedtraces.
In order to avoid tedious, error-prone, and privacy-disrupting techniques for distinguishing robots and
proxies,wetestedafewheuristicsto automaticallydetectsuchclients:
(cid:29)
(cid:30)(cid:8)(cid:31)!
Any HTTP request including a header probably comes from a proxy. The converseis not true;
(cid:30)(cid:21)(cid:31)(cid:17)
someproxies donotinsert headers.
(cid:29)
"$#&%(’ "$#(cid:8)%)’
Any request including a header probably comes from a robot. Not all robots insert
headers.
(cid:29)
*,+$-.#0/(cid:17)1$2(cid:21)-(3&4
If a given client IP address generates requests with several different headers during a
short interval, it is probably a proxy serverwith multiple clientsthat use more than one browser. It
could also be a dynamic IP address that has been reassigned to a different client, so the time scale
*5+(cid:19)-(cid:17)#(cid:21)/.162(cid:8)-.3(cid:8)487 9$%(cid:19)3&46:(cid:19);,-
affects the accuracy of this heuristic. We ignore headers, since this is an
artifactofaparticularbrowser[16, 18].
"<#&%.’
Theresultsofthesetests revealedthatthe headeris notwidelyused,butitisa reasonable method
for identifying robots in our traces. Our test results also indicated that simply excluding all clients that
(cid:30)(cid:8)(cid:31)! *,+$-(cid:19)#(cid:8)/(cid:17)162(cid:8)-.3=4
issueda or headerwouldresultin excessivepruning.
(cid:30)0(cid:31)(cid:17)
An analysis of the headers suggested that components such as personal firewalls also add this
(cid:30)(cid:21)(cid:31)(cid:17)
header to HTTP requests. As a result, we decided to only prune clients that include a header that
can be automatically identified as a multi-client proxy: for example, those added by a Squid, NetApp
NetCache,orInktomiTraffic-Serverproxy.
*5+$-.#0/(cid:17)1$2(cid:21)-(3&4
We adopted a similar approach for pruning clients that sent multiple different headers.
*>+$-.#0/.1&20-)3=4
First, we require that the headers be from well-known browsers (e.g., IE or Mozilla). These
*>+(cid:19)-(cid:19)#(cid:21)/.162(cid:8)-.3=4
browserstypicallyformthe headerinaverystructuredformat. Ifwecannotidentifythetype
8
Table1: Overall trace characteristics
?
AllHTTPstatuscodes statuscode 200
Total Total Total Total meanresp. mean peak Total Total meanresp.
Tracename Conns. Clients Resp.bytes Resps. size(bytes) req.rate req.rate Resp.bytes Resps. size(bytes)
C2 323141 17627 3502M 1221961 3005 2.3/sec 193/sec 3376M 576887 6136
C2p(pruned) 281375 16671 3169M 1132030 2935 2.1/sec 181/sec 3053M 533582 5999
R2 33286 7730 1679M 50067 35154 0.1/sec 35/sec 1359M 40011 35616
R2p(pruned) 23296 6732 1319M 38454 35960 0.1/sec 31/sec 1042M 31413 34766
U2 261531 36170 5154M 909442 5942 1.7/sec 169/sec 4632M 580715 8363
U2p(pruned) 203055 33705 4191M 744181 5904 1.4/sec 152/sec 3754M 479892 8202
U3 278617 29843 5724M 987787 6076 11.4/sec 125/sec 5261M 637380 8655
U3p(pruned) 197820 26697 4288M 756994 5939 8.8/sec 117/sec 3940M 491497 8405
U4 326345 32047 6800M 1182049 6032 13.7/sec 139/sec 6255M 763545 8589
U4p(pruned) 230589 28628 5104M 902996 5926 10.5/sec 139/sec 4689M 588954 8347
ofbrowser,thebrowserversion,andtheclientOS,wedonotusetheheaderintheanalysis. Ifwethensee
requestsfromtwodifferentbrowsers,browserversions,orclientOSscomingfromthesameIPaddressin
the limited duration of the trace, we consider this to be a proxy, and exclude that client from the pruned
trace.
We opted to err (slightly) on the side of excessive pruning, rather than striving for accuracy, in order
to reduce the chances of biasing our results in favor of our predictors. In Section 7.1, we discuss how an
actual server implementation might detect proxies and robots, since the criteria could be different in that
setting.
3.4 Overalltracecharacteristics
Table 1 shows various aggregate statisticsfor each trace set,to provide somecontext for the rest ofthe
results. Forreasonsofspace,weomitday-by-daystatisticsforC2,R2,andU2;theseshowtheusualdaily
variations in load,although C2 and R2 peak on the weekend, while U2 peaksduring the work week. The
table also shows totals for the pruned versions of each trace set. Finally, the table shows total response
bytes,responsecount,andmeanresponsesizeforjustthestatus-200responsesonwhichmostsubsequent
analysesarebased.
We add“p” to thenames of tracesetsthathave beenpruned(e.g.,a pruned version oftrace set“C2”is
named “C2p”). Pruning reduces the number of clients by 5% (for trace C2) to 13% (for R2); the number
ofHTTPresponsesby7%(forC2)to23%(forR2,U3,andU4);andthepeakrequestrateby6%(forC2)
to11%(forR2).
Themean values inTable 1 donot convey the whole story. InFigures 2,3,and 4, respectively, we plot
cumulative distributions for request rate, response size, and latency for status-200responses (These plots
exclude the U3 and U4 traces, since these CDFs are nearly identical to those for the U2 trace; Figure 4
alsoexcludesC2pand U2p,sincetheseCDFsare nearly identicaltothoseforthe unprunedtraces.)
Figure 5 shows a histogram of request counts per client address. One might expect that our pruning
wouldchangethesedistributions,ifthe proxiesand robotsremovedbypruningdoindeedgeneratean un-
usuallyhighnumberofrequests. However,theresultsinFigure5donotstronglysupportthisexpectation.
We are not sure if this reflects a flaw in our pruning approach, or simply that most proxies and robots do
notvisitthe tracedsitesveryoften.
Thethree tracesin Figure 3 show quite different response sizedistributions. The responsesin trace C2
seem somewhat smaller than has typically been reported for Web traces; the responses in trace R2 are a
lot larger. (These differences also appear in the mean response sizes in Table 1.) Trace R2 is unusual, in
9
1
0.9
0.8
n
o 0.7
cti
a 0.6
r@
f
ve 0.5
ulati 0.4 Trace set C2
m 0.3 Trace set R2
u
C Trace set U2
0.2 Trace set C2p
Trace set R2p
0.1
Trace set U2p
0
1 10 100 1000
HTTP request rate per second
Figure2: CDFofrequestrates
1 1460
0.9
0.8
n
o
cti 0.7
raA 0.6
f
ve 0.5 32768
ati 0.4 Trace set C2
ul Trace set R2
m 0.3 16384
Trace set U2
u
C 0.2 Trace set C2p
Trace set R2p
0.1 8192
Trace set U2p
0
100 1000 10000 100000 1e+06 1e+07 1e+08
HTTP response size (bytes)
Figure3: CDFofstatus-200responsesizes
part, because many users ofthe site download entire technicalreports, which tend to be much larger than
individualHTMLorembedded-imagefiles.
Figure 3 includes three vertical lines indicating the 8K byte, 16K byte, and 32K byte thresholds. Note
that 8K is below the median size for R2, but above the median size for C2 and U2, but the median for all
tracesis well below32K bytes.
Figure4showsthatresponsedurationsaresignificantlylongerintheR2tracethanintheothers,possibly
becauseofthelongerresponsesizesinR2.
We calculated, for each distinct client, a mean bandwidth across all transfers for that client. Figure 6
showsthedistributions;theprunedtraceshadsimilardistributionsandarenotshown. TraceC2hasamuch
largerfractionoflow-bandwidthusersthanR2orU2. Theapparentslightexcessofhigh-bandwidthclients
in R2 might result from the larger responsesin R2; larger transfers generally increase TCP's efficiency at
usingavailablebandwidth.