Predicting short-transfer latency from TCP arcana

14 Pages·2005·1.19 MB·English

Predicting short-transfer latency from TCP arcana:
A trace-based validation
MartinArlitt BalachanderKrishnamurthy JeffreyC.Mogul
HPLabs/UniversityofCalgary AT&TLabs–Research HPLabs
PaloAlto,CA94304 FlorhamPark,NJ07932 PaloAlto,CA94304
[email protected] [email protected] [email protected]
Abstract effectiveuseofthatopportunity.
Insomecontextsitmaybeusefultopredictthelatencyfor There are several possible ways to define “short” TCP
shortTCPtransfers.Forexample,aWebservercouldauto- transfers. Models for TCP performance typically distin-
maticallytailorits contentdependingonthe networkpath guishbetweenlongflowswhichhaveachievedsteadystate,
toeachclient,oran“opportunisticnetworking”application and short flows which do not last long enough to leave
couldimproveitsschedulingofdatatransfers. theinitialslow-startphase. Alternatively,onecoulddefine
Several techniques have been proposed to predict the short in termsofanarbitrary threshold ontransferlength.
latency of short TCP transfers based on online measure- While defining “short” in terms of slow-start behavior is
mentsofcharacteristicsofthe currentTCPconnection, or lessarbitrary, it is also less predictable (because the dura-
ofrecentconnectionsfromthesameclient. Weanalyzethe tionofslow-startdependsonunpredictablefactorssuchas
predictiveabilitiesofthesetechniquesusingtracesfroma crosstrafficandpacketloss),andsoforthispaperweusea
varietyofWebservers,andshowthattheycanachieveuse- definitionbasedontransferlength. Similarly, whiletrans-
fulaccuracyinmany,butnotall,cases. Wealsoshowthat ferlengthcouldbedefinedintermsofthenumberofdata
a previously-described model forpredicting short-transfer packets sent, this also depends on unpredictable factors
TCPlatencycan be improvedwith asimplemodification. such as MTU discovery and the interactions between ap-
Ours is the first trace-based analysis that evaluates these plicationbufferingandsocket-levelbuffering. So,forsim-
predictiontechniquesacrossdiverseusercommunities. plicity,inthispaperwedefine“short”intermsofthenum-
berofbytestransferred.
1 Introduction Several techniques have previously been proposed for
Itisoftenusefultopredictthelatency(i.e.,duration)of automated prediction of the transfer time for a short TCP
a short TCP transfer before deciding when or whether to transfer. Some of thesetechniques glean their input para-
initiate it. Network bandwidths, round-trip times (RTTs), meters from characteristics of TCP connections, such as
andlossratesvaryovermanyordersofmagnitude,andso round-trip time(RTT) or congestion window size (cwnd),
thetransferlatencyforagivendataitemcanvarysimilarly. thatarenotnormallyexposedtotheserverapplication. We
Examples where such predictions might be useful in- callthese characteristics TCP arcana. Thesecharacterist-
clude: ics can then be used in a previously-described model for
(cid:0) aWebservercouldautomaticallyselectbetween“low- predictingshort-transferlatency[2]. Othertechniquesuse
bandwidth”and“high-bandwidth”versionsofcontent, observations of the actual latency for past transfers to the
with the aim of keeping the user's download latency sameclient(ortosimilarlylocatedclients),andassumethat
belowathreshold[9,16]. pastperformanceisagoodpredictoroffutureperformance.
(cid:0)
A Web server using shortest-remaining-processing- Inthispaper,weusepacket-leveltracescapturedneara
time(SRPT)scheduling[19]couldbetterpredictover- variety of realWebserversto evaluatethe ability of tech-
all response times if it can predict network transfer niques based on both TCP arcana and historical observa-
latency, which in many cases is the primary contrib- tion to predict short transfer latencies. We show that the
utortoresponsetime. previously-describedmodeldoesnotquitefitthe observa-
(cid:0)
An application using opportunistic networking [20] tions, but that a simple modification to the model greatly
mightchoosetoschedulewhichdatatosendbasedon improves the fit. We also describe an experiment sug-
an estimate of the duration of a transfer opportunity gesting (based on a limited data set) that RTT observa-
andpredictionsofwhichdataitemscanmakethemost tionscouldbeusedtodiscriminate,withmodestaccuracy,
betweendialupandnon-dialuppaths. Client Server
Thisworkcomplementspreviousworkonpredictingthe SYN (P1)
throughput obtained by long TCP transfers. He et al. [7]
SYN|ACK (P2)
characterized these techniques as either formula-based or
1 RTT
ACK (P3)
history-based;ourTCParcanaapproachisformula-based.
HTTP GET (P4)
2 Latencypredictiontechniques
ACK (P5)
Westartwiththeassumptionthatanapplicationwishing
topredictthelatencyofashorttransfermustdosoasearly HTTP REPLY (P6)
aaaapssscppuoromonsanseceihbcthelteiaso,tncbpoetrufheloaddrtiecbwteaionaensyxtidiensanittbdaieaehitdneadgtsobbdceyoleinenaenttcar-lastiinetdhsnefete;prsrraeeelrdtdvhi.ecortWuioegennh,datwlhsooeef HTTFPI ANRC E(PKP8L ()PY9 ()P7) Transfer latency
havenodatatoevaluatethatscenario.
Weexaminetwopredictionapproachesinthispaper:
(cid:1)
Theinitial-RTTapproach: Theserver'sfirstpossible Figure1: Timeline: typicalHTTPconnection
measurement of the connection RTT is provided by
(cid:2)
the interval between its initial SYNACK packet and Why might this RTT be a useful predictor of transfer
the client's subsequent ACK. For short transfers, this latency?
(cid:1)
RTT measurement is often sufficient to predict sub- Manylast-hopnetworktechnologiesimposebothhigh
sequent data transfer latency to this client. This ap- delay and low bandwidth. For example, dialup mo-
proachwasfirstproposedbyMogulandBrakmo[15] demsalmostalwaysaddabout100mstotheRTT[4,5]
and discussed in [16]. We describe it further in Sec- and usually limit bandwidth to under 56Kb/s. If we
tion2.1. observe an RTT much lower than 100ms, we can in-
(cid:1)
The recent-transfers approach: A server can predict ferthatthepathdoesnotinvolveamodem. (SeeSec-
thedatatransferbandwidthtoagivenrequestbasedon tion 5 for quantitative evidence.) A similar inference
recentlymeasuredtransferbandwidthstothesamecli- might be made about some (perhaps not all) popular
ent. Thisapproach,inthecontextofWebservers,was low-bandwidthwirelessmedia.
(cid:1)
proposedin[9];wedescribeitfurtherinSection2.2. Evenwhentheend-to-endbandwidthislarge,thetotal
transfer time for short responses depends mostly on
2.1 PredictionfrominitialRTTs
the RTT.(Therefore,anHTTPrequestheaderindicat-
Suppose one wants to predict the transfer latency, for a
ingclientconnectionspeedwouldnotreliablypredict
response of a given length over a specific HTTP connec-
latencyforsuchtransfers.)
tion,withnopriorinformationabouttheclientandthenet-
Cardwelletal.[2]showedthatfortransferssmallerthan
workpath,andbeforehavingtomaketheveryfirstdecision
the limiting window size, the expected latency to transfer
aboutwhatcontenttosendtotheclient. Letusassumethat (cid:9)
segments via TCP, when there are no packet losses, is
wedonotwanttheservertogenerateextranetworktraffic
approximatedby
or cause extra delays. What information could one glean
(cid:9) )(cid:15)+-,/.’0
fromtheTCPconnectionbeforeitistoolate?
(cid:10)(cid:12)(cid:11)(cid:13)(cid:15)(cid:14)(cid:17)(cid:16)(cid:19)(cid:18)(cid:21)(cid:20)(cid:23)(cid:22)(cid:25)(cid:24)(cid:27)(cid:26)(cid:23)(cid:28)(cid:30)(cid:29) (cid:31)!(cid:31)#"$(cid:13)(cid:15)%’&(cid:21)(*) .50
Figure 1 shows a timeline for the packets sent over a 132 4 (1)
typicalnon-persistentHTTPconnection. (Weassumethat
the client TCP implementation does not allow the client where
(cid:1) +
application to send data until after the 3-way handshake; dependsontheclient'sdelayed-ACKpolicy;reason-
this is true of most commonstacks.) In this timeline, the ablevaluesare1.5or2(see [2]fordetails).
(cid:1)61 2
server has to make its decision immediately after seeing dependsontheserver'sinitialvalueforcwnd;reas-
theGET-bearingpacket((cid:3)(cid:5)(cid:4) )fromtheclient. onablevaluesare2,3,or4(see [2]fordetails).
Itmightbepossibletoinfernetworkpathcharacteristics (cid:1) (cid:9) (cid:28)87:?(cid:12)9<;>@A= @(cid:5)B
(cid:1) (cid:13)(cid:15)(cid:18)(cid:21)(cid:20)
fromtherelativetimingoftheclient'sfirstACK-only((cid:3)(cid:5)(cid:6) ) isthenumberofbytessent.
(cid:1)DCFEGE
and GET ((cid:3) (cid:4) ) packets, using a packet-pair method [11]. istheTCPmaximumsegmentsizeforthecon-
However, the initial-RTTpredictor insteaduses the path's nection.
(cid:2)
RTT, as measured betweenthe server's SYNACK packet NotethatmedianWebresponsesizes(weusethedefinition
((cid:3)(cid:8)(cid:7) ) and the client's subsequent ACK-only packet ((cid:3) (cid:6) ). of “response”from the HTTPspecification [6]) are typic-
Since these two packets are both near-minimum length, allysmallerthanthelimitingwindowsize;seeSection3.4.
theyprovideadirectmeasurementofRTT,in theabsence End-to-endbandwidthlimitsandpacketlossescanonly
ofpacketloss. increasethislatency. Inotherwords, if weknow the RTT
and response size, then we can predict a lower bound for 2.3 Definingtransferlatency
thHetransferlatency. We have so far been vague about defining “transfer
We would like to use the RTT to predict the transfer latency.”Onemightdefinethisasthetimebetweenthede-
latency as soon as possible. Therefore, the first time a parture of the first response byte from the server and the
server sees a request from a given client, it has only one arrival of the last response byte at the client. However,
RTTmeasurementtouseforthispurpose. Butiftheclient without perfect clock synchronization and packet traces
returns again, which RTT measurement should the server madeateveryhostinvolved,thisdurationisimpossibleto
use for its prediction? It could use the most recent meas- measure.
urement(thatis,fromthecurrentconnection),asthisisthe For this paper, we define transfer latency as the time
freshest;itcouldusethemeanofallmeasurements,todeal between the departure of the first response byte from the
with noise; it could useanexponentially smoothed mean, serverandthearrivalattheserveroftheacknowledgment
toreducenoisewhilefavoringfreshvalues;itcouldusethe of the last response byte. (Figure 1 depicts this interval
minimum measurement, to account for variable queueing forthecaseof anon-persistentconnection.) Thistendsto
delays; or it could use the maximum measurement, to be inflateour latency measurementby approximatelyRTT/2,
conservative. but becausepath delays can be asymmetric we do not at-
“Mostrecent,” whichrequires no per-client state, is the tempttocorrectforthatinflation. Weareeffectivelymeas-
simplesttoimplement,andthisistheonlyvariantwehave uringanupperboundonthetransferlatency.
evaluated.
3 Methodology
2.2 Predictionfromprevioustransfers Wefollowedthisoverallmethodology:
I
Step 1: collect packet traces near a variety of Web
KrishnamurthyandWillsoriginallydescribedthenotion
serverswithdifferentanddiverseuserpopulations.
of using measurements from previous transfers to estim-
I
Step 2: extract the necessary connection parameters,
ate the connectivity of clients [9]. A prime motivation of
including client IDs, from these raw traces to create
thisworkwastoretainpoorlyconnectedclients,whomight
intermediatetraces.
avoidaWebsiteifitspagestaketoolongtodownload.Bet-
I
Step 3: evaluate the predictors using simple simu-
terconnectedclientscouldbepresentedenhancedversions
lator(s)drivenfromtheintermediatetraces.
ofthepages.
Although the prediction mechanisms analyzed in this
This approach is largely passive: it examines server
paper are not necessarily specific to Web traffic, we lim-
logsto measuretheinter-arrivaltimebetweenbase-object
ited our trace-basedstudy to Web trafficbecausewe have
(HTML)requestsandtherequestsforthefirstandlastem-
not obtained significant and diverse traces of other short-
beddedobjects,typicallyimages. Exponentiallysmoothed
transfer traffic. It might be useful to capture traffic near
meansofthesemeasurementsarethenusedtoclassifycli-
busy e-mail servers to get another relevant data set, since
ents. Anetwork-aware clustering scheme[8]wasused as
e-mailtransfersalsotendtobeshort[13].
aninitialclassificationmechanism,ifaclienthadnotbeen
Giventhatwearedefining“short”TCPtransfersinterms
seen before but another client from the same cluster had
ofthenumberofdatabytessent,weanalyzedthreeplaus-
alreadyused the site. KrishnamurthyandWills used adi-
ible thresholds: 8K bytes, 16Kbytes, and32Kbytes; this
versecollectionofserverlogsfrommultiplesitestoevalu-
paper focuses on the 32K byte threshold. (The response-
atethedesign, andKrishnamurthyetal. presentedanim-
sizedistributionsinFigure2supportthischoice.)
plementation[10],usingamodifiedversionoftheApache
server,totesttheimpactofvariousserveractionsonclients 3.1 Tracesets
withdifferentconnectivity. We collected trace sets from several different environ-
Therecent-transfersapproachthatwestudyinthispaper ments,allinNorthAmerica.Forreasonsofconfidentiality,
isasimplificationoftheKrishnamurthyandWills design. weidentifythesesetsusingshortnames:
I
BecausetheirmeasurementsuseWebserverlogs,thisgave C2:Collectedonacorporatenetwork
I
themenoughinformationaboutpagestructuretoinvestig- U2,U3,U4: CollectedataUniversity
I
atethealgorithm'sabilitytopredictthedownloadtimefor R2:Collectedatacorporateresearchlab
an entire page, including embedded objects. Wehavenot In all cases, the traces were collected on the public Inter-
extracted object-relationship information from our packet net(not on an Intranet) and were collected relatively near
traces, so we only evaluated per-response latency, rather exactlyonepublicly-accessibleWebserver.
thanper-pagelatency. Ontheotherhand,mostserverlogs Wecollectedfull-packettraces,usingtcpdump,andlim-
provide timing information with one-second resolution, itedthetracestoincludeonlyTCPconnectionstoorfrom
whichmeansthatalog-basedevaluationcannotprovidethe thelocalWebserver.
fine-grainedtimingresolutionthatwegotfromourpacket While we wanted to collect traces covering an entire
traces. week at each site, storage limits and other restrictions
meant that we had to collect aseries of shorter traces. In Whentheclient'sSYNpacketisreceived, adatastructure
orJder to cover representative periods over the course of a is created to retain information on the connection, which
week(May3–9,2004),wechosetogathertracesfortwoto startsinthenot establishedstate.Whenthecorresponding
fourhourseachday:9:00AM-11:00AMMonday,Wednes- SYNKACKpacketisreceivedfromtheserver,themodeled
day, andFriday; 2:00PM-4:00PM TuesdayandThursday; connection enters the timing SYN ACK state, and then
and10:00AM-2:00PMSaturdayandSunday(allarelocal to the establishedstate whenthe client acknowledges the
timeswithrespecttothetracesite: MSTforC2,MDTfor SYNKACK.
U2, and PDT for R2). We additionally gathered two 24- Wethenwaitforhttp request()eventstooccuronthat
hour (midnight to midnight) traces at the University: U3 connection. When a request is received, a data struc-
onThursday,Aug. 26,2004,andU4onTuesday,Aug. 31, ture is created to retain information on that HTTP trans-
2004. action, which starts in the waiting for reply transaction
state. On an http reply() event, that state becomes wait-
3.2 Arethesetracesrepresentative?
ing for end of reply. Once the server has finished send-
Wecertainly wouldprefertohavetracesfromadiverse
ing the response, the transaction state is set to wait-
sample of servers, clients, and network paths, but this is
ing for ack of reply. OncetheentireHTTPresponsehas
not necessaryto validateourapproach. Our goalis not to
beenacknowledgedbytheclient,thatstateissettotrans-
predict the latencies seen by all client-server pairs in the
action complete. Thisdesignallowsourscripttoproperly
Internet, but tofindamethodforagivenserverto predict
handlepersistentandpipelinedHTTPconnections.
thelatenciesthatititself(andonlyitself)willencounterin
Our analysis uses an additional state, er-
thenearfuture.
ror has occurred, which is used, for example, when
It is true that some servers or client populations might
a TCP connection is reset, or when a packet is missing,
differ so much from the ones in our traces that our res-
causingagapin the TCPdata. Allsubsequentpacketson
ults do not apply. Although logistical and privacy con-
a connection in an error has occurred state are ignored,
straints prevent us from exploring a wider set of traces,
although RTT and bandwidth estimates are still recorded
our analysis tools are available at http://bro-ids.org/bro-
forallHTTPtransactionsthatcompletedontheconnection
contrib/network-analysis/akm-imc05/ so that others can
beforetheerroroccurred.
testouranalysesontheirowntraces.
Foreachsuccessfullycompletedandsuccessfullytraced
TheresultsinSection4.6implythatourequation-based
HTTPrequest/responseexchange,thescriptgeneratesone
predictorworkswellforsomesitesandnotsowellforoth-
tuplethatincludesthetimestampofthearrivaltimeofthe
ers. One could use our trace-based methodology to dis-
client'sacknowledgementofalloutstandingresponsedata;
cover if a server's response latencies are sufficiently pre-
theclient'sIPaddress;theresponse'slength,content-type,
dictablebeforedecidingtoimplementprediction-basedad-
andstatuscode;thepositionoftheresponseinapersistent
aptationatthatserver.
connection (if any); and estimates of the initial RTT, the
3.3 Traceanalysistools MSS,theresponsetransferlatency,andtheresponsetrans-
Westartbyprocessingtheraw(full-packetbinary)traces fer bandwidth. The latency is estimated as described in
togenerateonetupleperHTTPrequest/responseexchange. Section 2.3, andthe bandwidth estimateis then computed
Ratherthanwriteanewprogramtoprocesstherawtraces, fromthelatencyestimateandthelength.
wetookadvantageofBro,apowerfultooloriginallymeant Thesetuplesform anintermediatetrace, convenientfor
fornetworkintrusiondetection[17]. Broincludesapolicy further analysis and several orders of magnitude smaller
scriptinterpreterforscriptswritteninBro'scustomscript- than the original raw packet trace. For almost all of our
inglanguage,whichallowedustodothisprocessingwitha subsequentanalysis,weexamineonlyresponseswithstatus
relativelysimplepolicyscript–about800lines,including code LNM(cid:27)O(cid:21)O , since theseare the only ones that should al-
comments. Wecurrentlyuseversion0.8a74ofBro. wayscarryfull-lengthbodies.
Bro reduces the network stream into a series of higher
levelevents. Ourpolicyscriptdefineshandlersfortherel-
3.3.1 Proxiesandrobots
evant events. We identify four analysis states for a TCP
connection: not established, timing SYN ACK, estab- MostWebserversreceiverequestsfrommulti-clientproxy
lished, and error has occurred. We also use four ana- servers, and from robots such as search-engine crawlers;
lysisstatesforeachHTTPtransaction: waiting for reply, both kinds ofclientstend to makemore frequentrequests
waiting for end of reply, waiting for ack of reply, and than single-human clients. Requests from proxies and ro-
transaction complete. (Our script follows existing Bro botsskewthereferencestreamtomaketheaverageconnec-
practiceofusingtheterm“reply”inlieuof“response”for tion's bandwidth more predictable, which could bias our
statenames.) resultsinfavorofourpredictionmechanisms.
Progression through these states occurs as follows. We therefore “pruned” our traces to remove apparent
proxiesandrobots(identifiedusingaseparateBroscript); total response bytes, response count, and mean response
P
wethenanalyzedboththeprunedandunprunedtraces. size for just the status-200 responses on which most sub-
In order to avoid tedious, error-prone, and privacy- sequentanalysesarebased.
disrupting techniques for distinguishing robots and prox- We add “p” to the names of trace sets that have been
ies,wetestedafewheuristicstoautomaticallydetectsuch pruned (e.g., apruned version of trace set “C2” is named
cliQents: “C2p”). Pruningreducesthenumberofclientsby5%(for
Any HTTP request including a Via header probably traceC2)to13%(forR2);thenumberofHTTPresponses
comes from a proxy. The converse is not true; some by7%(forC2)to23%(forR2,U3,andU4);andthepeak
Q proxiesdonotinsertViaheaders. requestrateby6%(forC2)to11%(forR2).
AnyrequestincludingaFromheaderprobablycomes
Q fromarobot. NotallrobotsinsertFromheaders. 1 1460
0.9
IfagivenclientIPaddressgeneratesrequestswithsev-
n 0.8
eraldifferentUser-Agentheadersduringashortin- ctio 0.7
terval, it is probably a proxy server with multiple cli- ve fraR 00..56 32768
ents that use more than one browser. It could also ulati 0.4 TTrraaccee sseett CR22
be a dynamic IP address that has been reassigned to um 0.3 16384 Trace set U2
C 0.2 Trace set C2p
adifferentclient,sothetimescaleaffectstheaccuracy Trace set R2p
0.1 8192 Trace set U2p
of this heuristic. Weignore User-Agent: con- 0
type headers, since this is an artifact of a particular 100 1000 10000 100000 1e+06 1e+07 1e+08
HTTP response size (bytes)
browser[12,14].
TheresultsofthesetestsrevealedthattheFromheader Figure2: CDFofstatus-200responsesizes
isnotwidelyused,butitisareasonablemethodforidenti-
fying robots in our traces. Our test results also indic-
1
atedthatsimply excluding allclientsthatissuedaViaor
0.9
User-Agentheaderwouldresultinexcessivepruning. n 0.8
AnanalysisoftheViaheaderssuggestedthatcompon- ctio 0.7
entssuchaspersonalfirewallsalsoaddthisheadertoHTTP ve fraS 00..56
requests. Asaresult,wedecidedtoonlypruneclientsthat ulati 0.4
includeaViaheaderthatcanbeautomaticallyidentifiedas um 0.3 Trace set C2
C 0.2 Trace set R2
amulti-clientproxy: forexample,thoseaddedbyaSquid, Trace set R2p
0.1 Trace set U2
NetAppNetCache,orInktomiTraffic-Serverproxy. 0
0.001 0.01 0.1 1 10 100 1000 10000
We adopted a similar approach for pruning clients that
Response latency (seconds)
sentmultipledifferentUser-Agentheaders.First,were-
Figure3: CDFofstatus-200responselatencies
quirethattheUser-Agentheadersbe fromwell-known
browsers (e.g., IE or Mozilla). These browsers typically The mean values in Table 1 do not convey the whole
formtheUser-Agentheaderinaverystructuredformat. story. InFigures2and3, respectively,weplotcumulative
Ifwecannotidentifythetypeofbrowser,thebrowserver- distributions for response size and latency for status-200
sion,andtheclientOS,wedonotusetheheaderintheana- responses(TheseplotsexcludetheU3andU4traces,since
lysis. Ifwethenseerequestsfromtwodifferentbrowsers, these CDFs are nearly identical to thosefor the U2 trace;
browserversions, or client OSs coming from the same IP Figure3alsoexcludesC2pandU2p,sincetheseCDFsare
addressinthelimiteddurationofthetrace,weconsiderthis nearlyidenticaltothosefortheunprunedtraces.)
tobeaproxy,andexcludethatclientfromtheprunetrace. The three traces in Figure 2 show quite different re-
Weoptedtoerr(slightly)onthesideofexcessiveprun- sponse sizedistributions. Theresponsesin traceC2seem
ing,ratherthanstrivingforaccuracy,inordertoreducethe somewhatsmallerthanhastypicallybeenreportedforWeb
chancesofbiasingourresultsinfavorofourpredictors. traces;theresponsesintraceR2arealotlarger. (Thesedif-
ferencesalsoappearinthemeanresponsesizesinTable1.)
3.4 Overalltracecharacteristics TraceR2isunusual,inpart,becausemanyusersofthesite
Table1showsvariousaggregatestatisticsforeachtrace download entire technical reports, which tend to be much
set,toprovidesomecontextfortherestoftheresults. For largerthanindividualHTMLorembedded-imagefiles.
reasonsofspace,weomitday-by-daystatisticsforC2,R2, Figure 2 includes three vertical lines indicating the 8K
and U2; these show the usual daily variations in load, al- byte, 16K byte, and32Kbyte thresholds. Note that8K is
though C2 and R2 peak on the weekend, while U2 peaks below the median size for R2, but above the median size
duringtheworkweek. Thetable alsoshows totalsforthe forC2andU2, but themedianforalltracesis wellbelow
prunedversions ofeachtraceset. Finally, thetableshows 32Kbytes.
AllHTTPstatuscodes statuscodeT 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
Table1: Overalltracecharacteristics
Figure3showsthatresponsedurations aresignificantly Thiscancausepacketstoappearinthetraceinadiffer-
longerinthe R2tracethanin theothers,possiblybecause entorderthantheyarrivedonthemonitoredlink.Such
ofthelongerresponsesizesinR2. reorderingtypicallyaffectspacketsthatoccurredclose
together in time. For example, in the U2 trace, 10%
0.06 ofconnectionshadtheSYNandSYNWACKpacketsin
Trace set C2
0.05 TTrraaccee sseett RU22 V reverseorder. OurBroscriptcorrectsforthis.
clientsU 0.04 Pmoorntitmorierrdorliinnkgutnemtilptohreayriclyanbbueffseernstpoavcekretthsefmroimrrortehde
n of 0.03 link. This buffer can overflow, causing packets to be
o
Fracti 0.02 V dSreovpepraeld.of our environments have multiple network
0.01
links that transfer packets to or from the Web server.
0 Since wecould not monitor allof these links, wedid
10 100 1000 10000 100000 1e+06 1e+07
not capture all of the HTTP request/response transac-
Mean bandwidth per client (bits/sec)
tions. Insomecaseswecaptureonlyhalfofthetrans-
Figure4: PDFofmeanbandwidthperclient
action (about 48% of the connections are affected by
Wecalculated,foreachdistinctclient,ameanbandwidth thisinonetrace).
V
acrossalltransfersforthatclient. Figure4showsthedis- Ideally, a traced packet would be timestamped at the
tributions; the pruned traces had similar distributions and precise instant it arrives. However, trace-collection
arenotshown. TraceC2hasamuchlargerfractionoflow- systems buffer packets at least briefly (often in sev-
bandwidthusersthanR2orU2. Theapparentslightexcess eralplaces)beforeattachingatimestamp,andpackets
ofhigh-bandwidthclientsinR2mightresultfromthelarger are often collected at several nearby points (e.g., two
responsesin R2; largertransfersgenerallyincreaseTCP's packetmonitorsonbothmembersofapairofsimplex
efficiencyatusingavailablebandwidth. links), which introduces timestamp errors due to im-
WealsolookedatthedistributionoftheTCPMaximum perfect clock synchronization. Erroneous timestamps
SegmentSize(MSS)valuesinourtraces. IntraceR2,vir- couldcauseerrorsinouranalysisbyaffectingeitheror
tually allof the MSS valueswereatorcloseto the stand- bothofourRTTestimatesandourlatencyestimates.
ardEthernetlimit(about1460bytes);intracesC2andU2,
We estimated the number of packets lost within our
about 95% of the MSS values were near the limit, with
measurement system by watching for gaps in the TCP
the rest mostly close to 512 bytes. Figure 2 shows a ver-
sequence numbers. This could overestimate losses (e.g.,
ticallineat1460bytes,indicatingapproximatelywherethe
due to reorderedpackets) but theestimates,asreportedin
dominantMSSvalueliesontheresponse-sizedistribution.
Table2,arequitelow.
3.5 Traceanomalies Table 2 also shows our estimates (based on a separ-
ate Bro script) for packet retransmission rates on the path
The monitoring architectures available to us differed at
between client and server, implied by packets that cover
eachofthecollectionsites.Forexample,atoneofthesites
part of the TCP sequence space we have already seen.
portmirroringwasusedtocopypacketsfromamonitored
Retransmissions normally reflect packet losses in the In-
link to the mirrored link. At another site, separate links
ternet, which would invalidate the model used in equa-
weretapped,oneforpacketsboundfortheWebserver,the
tion 1. Knowing these rates could help understand where
secondforpacketssentbytheserver. Thesemonitoringin-
theinitial-RTTapproachisapplicable.
frastructuresaresubjecttoavarietyofmeasurementerrors:
V
Port mirroring multiplexes bidirectional traffic from NotethatTable1onlyincludesconnectionswithatleast
themonitoredlinkontotheunidirectionalmirrorlink. one complete HTTP response, while Table 2 includes all
Total Total Measurement Retransmitted Conns.w/ Conns.w/nopkts
Tracename packets Conns. systemlostpkts. packets retransmittedpackets inonedirection
C2 40474900 1182499 17017(0.04%) 114911(0.3%) 53906(4.6%) 572052(48.4%)
R2 2824548 43023 1238(0.04%) 27140(1.0%) 4478(10.4%) 460(1.1%)
U2 11335406 313462 5611(0.05%) 104318(0.9%) 26815(8.6%) 17107(5.5%)
U3 11924978 328038 2093(0.02%) 89178(0.7%) 26371(8.0%) 14975(4.6%)
U4 14393790 384558 5265(0.04%) 110541(0.8%) 30638(8.0%) 18602(4.8%)
Table2: Packetlossrates
oconnlyneacbtlieontos,uinsecl2u7d%ingotfhtohseectohnanteecntdioinnselirsrtoerds.inWTeabwleer2e bits/sec) 1e+07
forC2,partlybecauseweonlysawpacketsinonedirection dth ( 1e+06
wi
for48%oftheconnections. Ouranalysisscriptflaggedan- Ynd
poothsesribXly20d%ueotoftuhnekCno2wconnpnreocbtlieomnssaisnethrreomrohnaitsoroicncguirnrferad-, nsfer ba 100000
structure. ured tra 10000 Sampling ratio = 0.01
4 Predictions basedoninitial RTT:results Meas 100 00.001 0.01 0.1 1 10
Measured RTT (sec)
In this section, we summarize the results of our exper-
Figure6: BWvs.RTT,traceC2,1MSSZ lengthZ 32KB
iments on techniques to predict transfer latency using the
initialRTT.Weaddressthesequestions: ratios are shown in the figures.) The graph shows an ap-
1. DoesRTTpersecorrelatewellwithlatency? parent weak correlation between initial RTT and transfer
2. Howwelldoesequation1predictlatency? bandwidth. Corresponding scatter plots for R2, U2, U3,
3. Canweimproveonequation1? andU4showevenweakercorrelations.
4. Whatistheeffectofmodemcompression? Wefoundastrongercorrelationifwefocusedontransfer
5. How sensitive are the predictions to parameter lengthsaboveoneMSSandbelow32Kbytes,asshownin
choices? Figure6. Ourtechniqueformeasuringlatencyisprobably
Thereisnosinglewaytodefinewhatitmeansforalatency leastaccurateforresponsesbelowoneMSS(i.e.,thosesent
predictor to provide“good” predictions. Weevaluatepre- injustonepacket). Also,single-packetresponsesmaysuf-
diction methods using several criteria, including the cor- ferexcessapparentdelay(asmeasuredbywhentheserver
relationbetweenpredictedandmeasuredlatencies,andthe receives the final ACK) because of delayed acknowledg-
meanandmedianofthedifferencebetweentheactualand mentattheclient. Inoursubsequentanalyses,weexclude
predictedlatencies. responseswithlengthsofoneMSSorlessbecauseofthese
measurement difficulties. The 32KB threshold represents
4.1 DoesRTTitselfcorrelatewithlatency?
oneplausiblechoicefordefininga“short”transfer.
h (bits/sec) 11ee++0067 TnCar2amcee 140234iS(n2ac4mlu.3pd%leeds) wC/boarnrde-wl0a.it3di5otn2h Cwor/rleal0tae.t5nio1cn1y
widt C2p 129661(24.3%) -0.370 0.508
Ynd 100000 R2 7500(18.7%) -0.112 0.364
ba R2p 5519(17.6%) -0.054 0.418
nsfer 10000 UU22p 211881218800((3377..68%%)) --00..116738 00..444588
d tra 1000 Sampling ratio = 0.01 U3 234591(36.8%) -0.181 0.421
ure U3p 181276(36.9%) -0.228 0.427
Meas 10 00.001 0.01 0.1 1 10 UU44p 228139949732((3377..23%%)) --00..127393 00..346114
Measured RTT (sec) (a)1MSS[ length[ 8KB
Figure5: Scatterplotofbandwidthvs.RTT,traceC2
Trace Samples Correlation Correlation
name included w/bandwidth w/latency
C2 261931(45.4%) -0.325 0.426
Perhaps it is unnecessary to invoke the full complexity C2p 238948(44.8%) -0.339 0.426
of equation 1 to predict latency from RTT. To investigate R2 20546(51.4%) -0.154 0.348
R2p 15407(49.0%) -0.080 0.340
this,weexaminedthecorrelationbetweenRTTperseand U2 312090(53.7%) -0.165 0.392
eitherbandwidthorlatency. U2p 258049(53.8%) -0.179 0.401
U3 336443(52.8%) -0.162 0.263
Forexample,Figure5showsascatterplotofbandwidth U3p 259028(52.7%) -0.215 0.276
vs. initial RTT, for all status-200 responses in trace C2. U4 414209(54.2%) -0.167 0.287
U4p 320613(54.4%) -0.215 0.343
(Inordertoavoidoversaturatingourscatterplots, weran-
(b)1MSS[ length[ 32KB
domly sampled the actualdata in each plot; the sampling
Table3: Correlations:RTTvs.eitherbandwidthorlatency
For a more quantified evaluation of this simplistic ap- 100
pprr\oogacrahm, w. eThdiedreassutlattsisatriecaslhaonwanlysinisTuasbinleg3a(as)imanpdle(Rb),[1f8o]r y (sec) 10 Sy a=m xp l+in 1g. 0ratio = 0.01
lenTghthestalibmleistesdhtoow8rKowansdfo3r2bKotbhypterus,nreedspaencdtiuvneplyr.unedver- ured latencb 0. 11
sionsofthefivebasictraces. Weincludedonlystatus-200 Meas 0.01
responseswhoselengthwasatleastoneMSS;the“samples y = x
included”columnshowsthatcountforeachtrace.Thelast 0.001
0.001 0.01 0.1 1 10
two columns show the computed correlation between ini-
Predicted latency per response (sec)
tialRTT andeither transferbandwidth ortransfer latency. c
^/dfehg ,i3jk^/l
(The bandwidth correlations are negative, because this is
Figure7: Realvs.predictedlatency,traceC2
aninverserelationship.)
For the data set including response lengths up to 32K
predictionoflatency;underpredictionsaregenerallyworse
bytes,noneofthesecorrelationsexceeds0.426,andmany
thanoverpredictions,if(forexample)wewanttoavoidex-
are much lower. If we limit the response lengths to 8K
posing Web users to unexpectedly long downloads. Most
bytes, the correlations improve, but this also eliminates
of the points in the plot are above that line, but most are
mostofthesamples.
belowthecurve](cid:12)^/‘:mon(cid:21)ehg(cid:21)p’q’r ,implyingthatmostofthe
We tried excluding samples with an initial RTT value overpredictions(inthisexample)arelessthan1secinex-
abovesomequantile, onthetheorythathighRTTscorrel-
cess. However,asignificantnumberaremanysecondstoo
ate with lossy network paths; this slightly improves RTT
high.
vs.bandwidthcorrelations(forexample,excludingrecords
WeextendedourRprogramtocomputestatisticsforthe
withanRTTabove281msecreducesthenumberof32K-
predictive ability ofequation 1. For eachstatus-200 trace
or-shortersamples for R2 by10%, andimprovesthatcor-
record with a length between one MSS and 32K bytes,
relation from -0.154to -0.302) but itactually worsens the
we used the equation to predict a latency, and then com-
latencycorrelations (for the sameexample,from 0.348 to
pared this to the latency recorded in the tracerecord. We
0.214).
thencomputedthecorrelationbetweentheactualandpre-
Notethat,contrarytoourexpectationthattracespruned dictedlatencies. Wealsocomputedaresidualerrorvalue,
ofproxiesandrobotswouldbelesspredictable,inTable3 as the difference between the actual and predicted laten-
this seems true only for the R2 trace; in general, prun- cies. Table 4 shows the results from this analysis, using
ingseemstoslightlyimprovepredictability. Infact,while c ^sntehu and i jv^sn ,aparameterassignmentthatworked
we present results for both pruned and unpruned traces fairlywellacrossallfivetraces.
throughout the paper, we see no consistent difference in
predictability. Trace Samples Correlation Median Mean
name included w/latency residual residual
4.2 Doesequation1predictlatency? C2 261931(45.4%) 0.581 -0.017 0.164
C2p 238948(44.8%) 0.584 -0.015 0.176
Although wedid not expectRTTto correlatewell with R2 20546(51.4%) 0.416 -0.058 0.261
latency, we might expect better results from the sophist- R2p 15407(49.0%) 0.421 -0.078 0.272
U2 312090(53.7%) 0.502 -0.022 0.110
icated model derived by Cardwell et al. [2]. They valid- U2p 258049(53.8%) 0.519 -0.024 0.124
atedtheirmodel(equation 1is asimplifiedversion) using U3 336443(52.8%) 0.334 -0.018 0.152
U3p 259028(52.7%) 0.353 -0.016 0.156
HTTPtransfersovertheInternet,butapparentlyusedonly U4 414209(54.2%) 0.354 -0.013 0.141
“well-connected”clientsandsodidnotprobeitsutilityfor U4p 320613(54.4%) 0.425 -0.010 0.136
Residualvaluesaremeasuredinseconds;1MSSw lengthw 32KB
poorly-connected clients. They also used RTT estimates
Table4: Qualityofpredictionsbasedonequation1
thatincludedmoresamplesthanjusteachconnection'sini-
tialRTT. InTable4,themedianresidualsarealwaysnegative,im-
We therefore analyzed the ability of equation 1 to pre- plying that equation 1 overestimates the transfer latency
dict transfer bandwidths and latencies using only the ini- more often than it underestimates it. However, the mean
tial RTT, and with the belief that our traces include some residuals are always positive, because the equation's un-
poorly-connectedclients. derestimates are more wrong (in absolute terms) than its
Figure 7 shows an example scatter plot of measured overestimates. ThesamplesinFigure7generallyfollowa
latencyvs. predicted latency, for traceC2. Again, wein- linewithasteeperslopethan]-^(cid:30)‘ ,suggestingthatequa-
cludeonlystatus-200responsesatleastoneMSSinlength. tion1especiallyunderestimateshigherlatencies.
Wehavesuperimposedtwocurvesontheplot. (Sincethis One possible reason is that, for lower-bandwidth links,
is a log-log plot, most linear equations result in curved RTT depends on packet size. For a typical 56Kb/s mo-
lines.)Anypointabovetheline]_^a‘ representsanunder- demlink, aSYNpacketwillseeanRTTsomewhatabove
100 msec, while a1500 bytedatapacketwill see an RTT Trace Samples Correlation Median Mean
x name included w/latency residual residual
severaltimeslarger. Thiseffectcouldcauseequation1to
C2 261931(45.4%) 0.417 0.086 -0.002
underestimatetransferlatencies. C2p 238948(44.8%) 0.423 0.092 -0.006
R2 20546(51.4%) 0.278 0.015 0.002
4.3 Canweimproveonequation1? R2p 15407(49.0%) 0.311 0.019 0.013
U2 312090(53.7%) 0.386 0.053 0.010
Given that equation 1 seems to systematically underes-
U2p 258049(53.8%) 0.402 0.056 0.001
timate higher latencies, exactly the error that we want to U3 336443(52.8%) 0.271 0.034 0.011
U3p 259028(52.7%) 0.302 0.036 -0.020
avoid, we realized that we could modify the equation to
U4 414209(54.2%) 0.279 0.035 0.003
reducetheseerrors. U4p 320613(54.4%) 0.337 0.038 -0.033
We experimented with several modifications, including Residualvaluesaremeasuredinseconds;1MSS⁄ length⁄ 32KB
alinearmultiplier,butonesimpleapproachis: Table5: Predictionsbasedonmodifiedequation1
functionModifiedEqnOne(RTT,MSS,Length,ykz , 4.4 Textcontentandmodemcompression
{
,CompWeight)
Many people still use dialup modems. It has been ob-
{
temp=EquationOne(RTT,MSS,Length,y z , );
served thatto accuratelymodelpath bandwidth, one must
return(temp+(temp*temp*CompWeight));
accountforthecompressiontypicallydonebymodems[3].
That is, we “overpredict” by a term proportional to the However, most image Content-Types are already com-
squareoftheoriginalprediction. Thisisaheuristic,notthe pressed, so this correction should only be done for text
resultofrigoroustheory. content-types.
We found by trial and error that a proportionality con- HTTPresponsesnormallycarryaMIME Content-Type
stant, or “compensation weight,” | }(cid:21)~(cid:12)(cid:127)(cid:129)(cid:128)a(cid:130)’(cid:131)(cid:15)(cid:132)(cid:129)(cid:133)(cid:17)(cid:134)(cid:136)(cid:135)(cid:138)(cid:137)(cid:17)(cid:139)(cid:140)(cid:137)(cid:17)(cid:141) label,whichallowedustoanalyzetracesubsetsfor“text/*”
worked best for C2, but | }(cid:21)~(cid:142)(cid:127)*(cid:128)a(cid:130)$(cid:131)(cid:143)(cid:132)(cid:129)(cid:133)(cid:17)(cid:134)(cid:144)(cid:135)(cid:146)(cid:145)’(cid:139)(cid:140)(cid:147)(cid:17)(cid:141) worked and “image/*” subsets. Table 6 shows the distribution of
betterforR2U2, and |3}(cid:21)~_(cid:127)*(cid:128)a(cid:130)$(cid:131)(cid:148)(cid:132)(cid:149)(cid:133)f(cid:134)v(cid:135)8(cid:145)’(cid:139)(cid:140)(cid:137)(cid:17)(cid:141) workedbest thesecoarseContent-Typedistinctionsforthetraces.
for U3andU4. For alltraces, (cid:150)(cid:151)(cid:135)(cid:152)(cid:137) got the best results, Wespeculatedthatthelatency-predictionmodelofequa-
andweset(cid:153)3(cid:154)k(cid:135)o(cid:155) forC2andU2,and(cid:153)3(cid:154)k(cid:135)a(cid:156) forR2,U3, tion 1, which incorporates the response length, could be
and U4. We discuss the sensitivity to these parametersin furtherimprovedbyreducingthislengthvaluewhencom-
Section4.5. pressionmight beexpected. (Aservermakingpredictions
knowstheContent-Typesoftheresponsesitplanstosend.
100
Some servers might use a compressed content-coding for
y (sec) 10 Sampling ratio = 0.01 dteixcttiroensspofonrsetsh,owsehircehspwoonusledsofbovrimateodtheemneceodmtporecossriroenct.pWree-
ncb 1 y = x + 0.5
ured late 0.1 fouWndencoansnuocthdreirsepcotnlysepsriendoicutretritahceers.t)he compression ra-
Meas 0.01 tio (which varies among responses and among modems)
y = x
nor can we reliably determine which clients in our traces
0.001
0.001 0.01 0.1 1 10 used modems. Therefore, for feasibility of analysis our
Predicted latency per response (sec) model assumes a constant compressibility factor for text
(cid:150)(cid:157)(cid:135)(cid:30)(cid:137)(cid:158)(cid:139)(cid:159) ,(cid:153) (cid:154) (cid:135)o(cid:155) ,|3}(cid:21)~(cid:160)(cid:127)(cid:129)(cid:128)a(cid:130)’(cid:131)(cid:148)(cid:132)(cid:158)(cid:133)(cid:158)(cid:134)¡(cid:135)a(cid:137)f(cid:139)h(cid:137)(cid:21)(cid:141) responses, and we tested several plausible values for this
Figure8: Modifiedpredictionresults,traceC2 factor. Also,weassumedthatanRTTbelow100msecim-
pliedanon-modemconnection,andRTTsabove100msec
Figure 8 shows how the modified prediction algorithm implied the possible use of a modem. In a real system,
systematically overpredicts at higher latencies, while not informationderivedfromtheclientaddressmightidentify
significantly changing the accuracy for lower latencies. modem-usersmorereliably. (InSection 5weclassifycli-
(For example, in this figure, | }(cid:21)~(cid:12)(cid:127)(cid:129)(cid:128)a(cid:130)’(cid:131)(cid:15)(cid:132)(cid:129)(cid:133)(cid:158)(cid:134)¢(cid:135)£(cid:137)(cid:17)(cid:139)h(cid:137)(cid:17)(cid:141) ; if ents using hostnames; but this might add too much DNS-
equation 1 predicts a latency of 0.100 seconds, the mod- lookupdelaytobeeffectiveforlatencyprediction.)
ified prediction will be 0.1225 seconds). However, even Table 7 shows results for text content-types only, using
the modified algorithm significantly underpredicts a few themodifiedpredictionalgorithmbasedonequation1,but
samples; we do not believe we can avoid this, especially without correcting for possible modem compression. We
forconnectionsthatsufferpacketloss(seeTable2). set(cid:150)(cid:151)(cid:135)¥(cid:137)f(cid:139)(cid:159) for C2and U2, and (cid:150)¢(cid:135)8(cid:145)(cid:21)(cid:139)h(cid:141) forR2, U3, and
Table5showsthatthemodificationstoequation1gener- U4; (cid:153) (cid:154) (cid:135)(cid:152)(cid:137) for C2 and (cid:153) (cid:154) (cid:135)ƒ(cid:156) for the other traces; and
allyworsenthecorrelations,comparedtothoseinTable4, | }(cid:21)~(cid:12)(cid:127)(cid:129)(cid:128)a(cid:130)’(cid:131)(cid:15)(cid:132)(cid:149)(cid:133)f(cid:134)-(cid:135)§(cid:145) for all traces. (We have not tested a
but definitely improvestheresiduals –the median erroris widerangeof |3}(cid:21)~(cid:160)(cid:127)(cid:129)(cid:128)a(cid:130)’(cid:131)(cid:148)(cid:132)(cid:158)(cid:133)(cid:158)(cid:134) valuestoseeiftextcontent-
alwayslessthan100msec,andthemeanerrorislessthan typeswouldbenefitfromadifferent| }(cid:21)~(cid:12)(cid:127)(cid:129)(cid:128)a(cid:130)’(cid:131)(cid:15)(cid:132)(cid:129)(cid:133)(cid:158)(cid:134) .)Com-
15 msec, except for traces U3p and U4p (our parameter paredto theresults forallcontent types (seeTable 5), the
choicesweretunedfortheunprunedtraces). residualsfortext-onlysamplesaregenerallyhigher.
Content-type C2 R2 U2 U3 U4
Unknown 3(0.00%) 26(0.06%) 178(0.03%) 157(0.02%) 144(0.02%)
TEXT/* 122426(21.22%) 23139(57.83%) 85180(14.67%) 92108(14.45%) 107958(14.14%)
IMAGE/* 454458(78.78%) 13424(33.55%) 465160(80.10%) 507330(79.60%) 607520(79.57%)
APPLICATION/* 0(0.00%) 3410(8.52%) 29733(5.12%) 37581(5.90%) 47765(6.26%)
VIDEO/* 0(0.00%) 4(0.01%) 17(0.00%) 10(0.00%) 5(0.00%)
AUDIO/* 0(0.00%) 8(0.02%) 446(0.08%) 194(0.03%) 140(0.02%)
Table6: Countsandfrequencyofcontent-types(excludingsomerarely-seentypes)
Trace Samples Correlation Median Mean designersaremorelikelytohavechoicesbetweenrichand
name included w/latency residual residual
simplecontentforimagetypesthanfortexttypes.(Design-
C2 118217(96.6%) 0.442 0.142 0.002
C2p 106120(96.4%) 0.449 0.152 -0.003 ersoftenincludeoptional“Flash”animations,butwefound
R2 12558(54.3%) 0.288 0.010 0.066
almostnoFlashcontentinC2andR2,andrelativelylittle
R2p 8760(50.2%) 0.353 0.017 0.105
U2 70924(83.3%) 0.292 0.100 0.073 inU2,U3,andU4.) Wethereforecomparedthepredictab-
U2p 56661(83.0%) 0.302 0.110 0.066
ilityoftransferlatenciesforimagecontent-types,butfound
U3 76714(83.3%) 0.207 0.063 -0.021
U3p 56070(83.2%) 0.198 0.072 -0.099 no clear differencecomparedto the results for allcontent
U4 90416(83.8%) 0.281 0.065 -0.034
ingeneral.
U4p 65708(83.8%) 0.359 0.078 -0.122
Residualvaluesaremeasuredinseconds;1MSS¤ length¤ 32KB
4.5 Sensitivitytoparameters
Table7: Predictionsfortextcontent-typesonly
How sensitive is prediction performance to the para-
Trace Samples Compression Correlation Median Mean meters ' , – † , and · (cid:181)(cid:27)¶_•*‚a„$”(cid:148)»(cid:149)…f‰ ? That question can be
name included factor w/latency residual residual framedin several ways: how dothe results for one server
C2 118217 1.0 0.442 0.142 0.002
varywithparametervalues?Ifparametersarechosenbased
C2p 106120 1.0 0.449 0.152 -0.003
R2 12558 4.0 0.281 0.013 0.002 on traces from server X, do they work well for server
R2p 8760 4.0 0.345 0.021 0.044
Y? Are the optimal values constant over time, client sub-
U2 70924 3.0 0.295 0.083 0.008
U2p 56661 3.0 0.306 0.096 -0.004 population, content-type, or response length? Do optimal
U3 76714 4.0 0.208 -0.002 0.001
parameter values depend on the performance metric? For
U3p 56070 4.0 0.201 0.003 -0.063
U4 90416 4.0 0.277 -0.000 -0.011 reasonsof space, wefocus on the first two of these ques-
U4p 65708 4.0 0.353 0.007 -0.083
Residualvaluesaremeasuredinseconds;1MSS¤ length¤ 32KB tions.
Table8: Predictionsfortextwithcompression Figure 9 shows how the absolute values of the mean
andmedianresidualsvarywith' ,–3† , and ·(cid:192)(cid:181)(cid:21)¶(cid:12)•*‚a„$”(cid:143)»(cid:129)…f‰
for traces C2, R2, andU2. Theoptimalparameterchoice
Table8showsresultsfortextcontent-typeswhenweas-
depends on whether one wants to minimize the mean or
sumed that modems compress these by the factor shown
the median; for example, for R2, '(cid:30)“`«ffi(cid:176)¿ , – † “`´ , and
in the third column. Note that for C2 and C2p, we got
· (cid:181)(cid:21)¶(cid:12)•(cid:129)‚a„’”(cid:15)»(cid:149)…f‰k“›‹’fihˆ(cid:27)fl yieldsanoptimalmeanof1.5msec
thebestresultsusingacompressionfactorof1.0–thatis,
(andamedianof15msec). Themediancanbefurtherre-
without correcting for compression. For the other traces,
ducedto0.2msec,butatthecostofincreasingthemeanto
correctingforcompressiondidgivebetterresults.Herewe
overhalfasecond.
settheotherparametersas: '(cid:144)“F« (exceptforU3andU4,
Figure 9 also shows how the optimal parameters vary
where'(cid:157)“›‹(cid:21)fi(cid:176)fl workedbest),–3†k“‡‹ (exceptforC2,where
across several traces. (Results for traces U3 and U4 are
– † “N« worked best), and · (cid:181)(cid:21)¶(cid:142)•*‚a„$”(cid:143)»(cid:158)…(cid:158)‰-“(cid:190)‹(cid:21)fi¿ (except
similar to those for U2, and are omitted to reduce clut-
for R2, where ·3(cid:181)(cid:21)¶_•*‚a„$”(cid:148)»(cid:149)…f‰(cid:157)“(cid:190)«(cid:158)fi(cid:140)«(cid:21)fl worked best). We
ter.) It appears that no single choice is optimal across all
experimentedwithassumingthatthepathdidnotinvolvea
traces, although some choices yield relatively small mean
modem(andthusshouldnotbecorrectedforcompression)
andmediansformanytraces.Forexample,'(cid:157)“a« ,– † “/´ ,
iftheinitialRTTwasunder 100msec, but for R2andU2
and ·3(cid:181)(cid:21)¶(cid:12)•(cid:149)‚a„(cid:21)”(cid:15)»(cid:149)…f‰v“¥‹(cid:21)fi«(cid:17)fl yieldsoptimalornear-optimal
itturnedoutthatwegotthebestresultswhenweassumed
meanresidualsforU2, U3, andU4, anddecentresultsfor
thatalltextresponsesshouldbecorrectedforcompression.
C2.
Table 8 shows that, except for trace C2, correcting for
modem compression improves the mean residuals over 4.6 Trainingandtestingondifferentdata
those in Table 7. We have not evaluated the use of com-
The results we have presented so far used parameter
pression factors other than integers between 1 and 4, and
choices“trained”onthesamedatasetsasourresultswere
we did not evaluate a full range of ·3(cid:181)(cid:21)¶(cid:12)•(cid:129)‚o„(cid:21)”(cid:15)»(cid:149)…f‰ values
tested on. Since any real prediction system requires ad-
forthissection.
vancetraining,wealsoevaluatedpredictionswithtraining
andtestingondifferentdatasets.
Imagecontent AsshowninTable6,imagecontent-types Our trace collection was not carefully designed in this
dominatemostofthetraces,exceptforR2. Also,Website regard; we have no pairs of data sets that are completely