Evaluating Quick-Start for TCP

Pasi SarolahtiNokia Research Center

pasi.sarolahti@iki.fi

Mark Allman, Sally FloydICSI/ICIR

{mallman,floyd}@icir.org

ABSTRACTThis paper explores the Quick-Start mechanism, designedto allow transport protocols to explicitly request permis-sion from the routers along a network path to send at ahigher rate than normally allowed by traditional congestioncontrol mechanisms. If the routers are underutilized, theymay approve the sender’s request for a higher sending rate;otherwise the sender uses the default congestion control al-gorithms. This paper discusses some of the design issuesof Quick-Start, and evaluates the potential benefits, costsand implications of Quick-Start in different networking en-vironments. Using simulations, we evaluate several differ-ent algorithms that routers could use to process a Quick-Start Request. This evaluation explores tradeoffs betweenthe fraction of Quick-Start requests that are approved andthe fraction of approved Quick-Start requests that result inincreasing network congestion. In addition, the paper dis-cusses the security implications of using Quick-Start andsome possible mitigations for the vulnerabilities.

1. INTRODUCTIONA fundamental aspect of communication in general-purpose,

best-effort packet-switched networks is determining an ap-propriate sending rate. The appropriate sending rate de-pends on the characteristics of the network path betweenthe two peers (bandwidth, propagation delay, etc.), as wellas the amount of load being placed on the network by oth-ers at the given time. Traditionally, TCP [20] has used a setof congestion control algorithms for determining this rate[11]. The problem we tackle in this paper is how a partic-ular connection that is under-utilizing (or, even not using)a network path can rapidly increase its transmission rate totake advantage of the available capacity more rapidly thanallowed by TCP’s traditional congestion control algorithms.

The first place the issue of determining an appropriatesending rate occurs is when choosing an initial rate. Thecurrent method for choosing an initial sending rate in theInternet is to use TCP’s slow-start algorithm [11, 5]. TCPcontrols the sending rate using a congestion window (cwnd),which bounds the amount of data that can be transmit-ted into the network before receiving an acknowledgment(ACK). Slow start initializes cwnd to a small value (1–4 segments, per [5, 4]) that is assumed to be an appro-priate starting point for the vast majority of situations.In each subsequent congestion-free round-trip time (RTT),cwnd is increased exponentially by 50–100% (depending on

whether the receiver uses delayed acknowledgments [8, 5]and whether the sender uses packet or byte counting [3]to increase cwnd). After slow-start has probed for an ap-propriate operating point, additive-increase, multiplicative-decrease (AIMD) congestion control governs the remainingtransmission [11, 5].

In many environments, slow-start can require a significantnumber of RTTs and require a large amount of data to opencwnd sufficiently to fully use the available bandwidth. Evenin the best case with byte-counting and an initial window offour packets, slow-start takes log2N−2 round-trip times andrequires sending N − 3 packets before reaching a congestionwindow of N packets.

Probing for the available bandwidth makes sense whenthere is general contention for the resources at a congestedpoint in the network path. In this paper we examine analternative – Quick-Start, a mechanism for end nodes to re-quest permission from routers along the path to circumventthe probing and use a higher sending rate [12]. Quick-Starthas the potential to alleviate the delay of slow-start for con-nections in under-utilized environments.

Although Quick-Start could be used with a number oftransport protocols, in this paper we mainly consider its usewith TCP. Quick-Start is described in detail in Section 3,but the process is generally that a TCP connection sendsa packet that includes a Quick-Start Request in an IP op-tion containing the requested sending rate, say X bytes/sec.Each router along the path either indicates agreement withthe request, lowers the requested sending rate or implicitlysignals that the Quick-Start option was not processed (and,hence, the request will not be approved). The data receiverreports the information received in the Quick-Start Requestback to the sender using a Quick-Start Response in a TCPoption, and the data sender determines if all of the routersalong the path have agreed to the request and sets the send-ing rate appropriately.

The assumption behind Quick-Start is that routers willonly approve Quick-Start requests when they are under-utilized. Thus, Quick-Start should be generally safe to de-ploy in general purpose networks, with a negligible risk ofcausing network congestion. However, because Quick-Startrequires support from all routers along the path, this couldpresent a high bar to deployment in the general Internet.Possible initial deployments could come in (i) those Intranetsand operator networks with large amounts of under-utilizedbandwidth1 and (ii) cellular wireless networks (such as GPRS

1For instance, [18] shows that a large enterprise network isgenerally significantly underutilized.

/ EDGE [23]) with bandwidth of up to 384 Kbps, but withlong round-trip delays. Based on the investigation presentedin this paper, Quick-Start is expected to be of benefit in boththese cases.

Quick-Start could potentially be useful not just at thestart of a connection, but any time a connection is signif-icantly under-utilizing the network path or has no under-standing of the path’s characteristics and has the data re-quired to considerably increase the transmission rate. Thus,Quick-Start could be used by a TCP sender after an explicitmessage informs a TCP connection of a change in networkattachment point (e.g., due to the use of Mobile IP). Inaddition, Quick-Start could be used after “idle” periods ina connection, when TCP’s understanding of the availablebandwidth is stale. The use of Quick-Start after idle peri-ods raises many questions about exactly when it would beappropriate for a sender to transmit Quick-Start requests,but we don’t address these questions in this paper. Instead,we concentrate on the first order question of Quick Start’sefficacy in the clear-cut case of determining an initial send-ing rate, leaving the thornier questions of precisely whenQuick-Start should be employed to future work.

While Quick-Start is a component of congestion control,Quick-Start is not a complete congestion control mechanism,and it is not intended as a replacement for TCP’s stan-dard congestion control. Quick-Start is also not a Qualityof Service (QoS) or resource reservation mechanism, thoughQuick-Start could be used by QoS-enabled traffic. As weshow in the paper, for best-effort traffic Quick-Start is in factmost effective in those under-utilized environments wherecongestion control is not the overriding issue, and whereQoS mechanisms are needed the least. Thus, Quick-Startis not expected to be of use in the case of a highly-utilizedpath. However, Quick-Start could be of significant use inthe case of a connection over an under-utilized path, wherethe use of Quick-Start might allow a connection to transferall its data in a single round-trip time.

The rest of this paper is organized as follows. Section 2discusses related work. Section 3 details the Quick-Startmechanism and discusses design issues while Section 4 tack-les deployment issues. Section 5 describes the simulationsetup used in our study. Section 6 illustrates the poten-tial advantages and disadvantages of Quick-Start. Section 7discusses the handling of Quick-Start Requests by routers.Section 8 outlines possible vulnerabilities of Quick-Start todenial-of-service attacks and potential coping techniques.Finally, Section 9 offers conclusions and future work.

2. RELATED WORKQuick-Start was first proposed in an internet-draft [12],

with the first version of the draft appearing in 2002 [2]. Thefirst study and ns-2 implementation of Quick-Start, by Sun-darrajan in 2002 [24], was based on the earlier internet-draft.

There have been a number of proposals for faster variantsof TCP slow-start that do not use explicit feedback fromrouters. For example, SwiftStart [19] would use the firstvolley of packets sent during slow-start to estimate the bot-tleneck bandwidth, and then use that estimate as the basisfor a rapid increase in the congestion window.

There are also proposals for sharing information aboutnetwork conditions between connections, ranging from TCPFast Start [17] to the Congestion Manager [6], that wouldallow new connections to start with a larger cwnd, based on

the assessment of the network path conducted by previousconnections.

Additional proposals call for other new mechanisms for ex-plicit congestion-related feedback from routers to end-nodes.In Explicit Congestion Notifications (ECN) [21], the onlycurrent mechanism in the IP protocol for explicit congestion-related feedback from routers to end-nodes, routers use theECN field in the IP header to indicate congestion explic-itly, instead of relying on packet drops. In contrast, theAnti-ECN proposal [15] would allow the sender to increaseas fast as slow-start over an uncongested path, even in themiddle of a transfer, with routers setting a bit in the packetheader to indicate an under-utilized link.

XCP (Explicit Control Protocol) [14] is a proposal fora new congestion control mechanism based on explicit andfine-grained per-packet feedback from the routers over thecourse of the entire transfer. XCP is similar to Quick-Startin that the routers are explicitly involved in feedback on thesenders’ allowed transmission rates, but the goals of the twoschemes are different. While XCP provides a full-fledgedcongestion control mechanism, Quick-Start, in some sense,provides just the opposite. Quick-Start provides for a briefcheck to determine whether the path is underutilized, allow-ing the sender to start or move to a high sending rate. Theappendix of [12] includes an extensive discussion of the rela-tionship between Quick-Start and proposals for fine-grainedper-packet feedback from routers to transport end-nodes.As discussed in [12], Quick-Start is complementary to manyof the proposals for new forms of per-packet feedback fromrouters. In addition, Quick-Start is relatively simple (com-pared to a possible new congestion control mechanism), andthe design and possible deployment of Quick-Start couldprovide useful data in the investigation of new, fine-grainedcongestion control mechanisms.

Measurement-based admission control research has inves-tigated various algorithms at network nodes for admitting orrejecting flows, when given some QoS requirements (see forexample [9]). Our Quick-Start work discusses a somewhatsimilar problem regarding router algorithms for approvingQuick-Start requests so that the network utilization stayswithin acceptable limits.

3. QUICK-STARTQuick-Start is a collaborative effort between end hosts and

routers. This section describes the details of Quick-Start,and discusses the Quick-Start requirements. [12] gives adetailed specification of Quick-Start.

3.1 Quick-Start Processing at the SenderThe Quick-Start Rate Request is initialized by the sender

to the desired sending rate in bytes per second (Bps). Thesender also initializes a Quick-Start TTL to a random valueand saves the difference between the initial Quick-Start TTLand the initial IP TTL as TTLDiff. As discussed in the nextsubsection, the routers along the network path between thesender and receiver alter the Request, as appropriate. Whenthe Quick-Start Request arrives at the transport receiver,the receiver echoes the rate request back to the sender alongwith the difference between the Quick-Start TTL and the IPTTL, TTLDiff ′, in an option in the transport header. Uponreception of an echoed Quick-Start Rate Request the senderverifies that all routers along the path have approved theQuick-Start Request by comparing TTLDiff and TTLDiff ′.

If these two values are the same then the request was ap-proved by all routers in the network path; otherwise, datatransmission will continue using TCP’s standard algorithms.

When TTLDiff and TTLDiff ′ match, the TCP senderthen calculates the appropriate cwnd based on the approvedsending rate and measured round-trip time as follows:

cwnd =Rate ∗ RTT

MSS + H(1)

where Rate is the approved rate request in Bps, RTT isthe recently measured round-trip time in seconds, MSS isthe maximum segment size for the TCP connection in bytesand H is the estimated header overhead for the connection inbytes. The TCP sender paces out the Quick-Start packets atthe approved sending rate over the next RTT2. Upon receiptof an acknowledgment for the first Quick-Start packet, theTCP sender returns to ACK-paced transmission.

One of the problems of Quick-Start is that unnecessary orunnecessarily-large Quick-Start Requests can “waste” po-tential Quick-Start bandwidth. Because routers must keeptrack of the aggregate bandwidth represented by recently-approved Quick-Start requests so that the router does notover-subscribe the available capacity, each approved requestreduces the chances of approval for subsequent requests. Ide-ally, a sender should not use Quick-Start for data streamsthat are not expected to benefit from it, such as those thathave only a few packets of data to send. The TCP sendershould, in theory, also avoid requesting an unnecessarily highsending rate. However, it can be difficult for the TCP senderto determine how much data will ultimately be transmittedand therefore to form a reasonable rate request. For ex-ample, in request-response protocols such as HTTP [7], theserver does not know the size of the requested object duringthe TCP handshake; it hasn’t yet received the data request.Once the web server does know the requested object, the ap-plication would need to determine the size of the object andthen inform TCP as to how many bytes will be sent, becausethe objects are rarely written to the TCP socket buffers in asingle atomic call. Even if the web server went to all of thistrouble, with persistent HTTP connections there may stillbe more data that the web server does not yet know about.Finally, sometimes the application cannot even obtain thesize of an object because the object is being read from apipe or some live source. In Section 6.2 we illustrate theproblems of not making a reasonably accurate rate requestand offer some strategies for coping.

3.2 Quick-Start Processing at RoutersA router that receives a packet with a Quick-Start Rate

Request has several options. Routers that do not under-stand the Quick-Start Request option simply leave the op-tion untouched, ultimately causing the Quick-Start Requestto be rejected because TTLDiff ′ will not match TTLDiff.Routers that do not approve the request can either leavethe Quick-Start Request option untouched, zero the RateRequest, or delete the option from the IP header. Routersthat approve the rate in the request decrement the Quick-Start TTL and forward the packet. Finally, a router canapprove a rate that is less than the rate in the request byreducing the rate, as well as decrementing the Quick-StartTTL.

2Note that TCPs are required to implement a timer forpaced transmission when using Quick-Start.

Routers should only approve a Quick-Start Request whenthe output link has been underutilized over some recent timeperiod. In order to approve a Quick-Start rate request, arouter generally should know the bandwidth of the outgoinglink and the utilization of the link over a recent period oftime. At a minimum, the router also must keep track ofthe aggregate bandwidth recently approved for Quick-StartRequests, to avoid approving too many requests when manyQuick-Start Requests arrive within a small window of time.Section 7 discusses in more detail the range of algorithmsthat could be used by routers in approving or denying aQuick-Start request.

Finally, we note that in this paper we discuss router algo-rithms in terms of “allocating” capacity, but that our notionof an “allocation” is quite informal. Quick-Start routers donot in fact reserve capacity for a particular flow and thenpolice the usage to ensure that the given flow is able to usethe granted capacity. Rather, the router simply tracks theaggregate amount of promised capacity (in the recent past)in an effort not to promise more than the output link canabsorb. If, however, a burst of unexpected traffic arrives theQuick-Start “allocations” may prove to be empty promiseswhen the end hosts attempt to use the granted bandwidthand detect congestion.

4. DEPLOYMENT ISSUESThis section discusses some of the deployment issues for

Quick-Start. These issues are discussed in more detail in[12].

Quick-Start is only of use when it is supported by bothend systems and all the routers along the path. This leadsto the “chicken-and-egg” deployment problem, that there islittle incentive to being the first node to deploy Quick-Start.Because of the incremental-deployment problems, we expectthat initial deployments of Quick-Start would happen withinnetworks or Intranets with centralized control, where hostsand routers both have an interest in aiding performance.

Unfortunately, there are middleboxes in the current net-work that drop packets containing known or unknown IPoptions [16]. This could result in significant delay for connec-tions using Quick-Start, as packets using Quick-Start wouldhave to be retransmitted without the Rate Request option.If the Quick-Start option is initially transmitted on a SYNsegment, the recommended initial retransmission timeoutof one second [12] determines the delay for retransmission.Again, one consequence is that initial deployments of Quick-Start may be in controlled environments, where it is knownthat packets with Quick-Start options would be forwarded.

A further deployment issue concerns the possibility of non-IP queues along a path. A router should not approve Quick-Start requests if it cannot reliably determine the link utiliza-tion all the way to the next IP hop. What this would mean,in practice, when there is an Ethernet switch, an ATM cloud,or some other non-IP queue between the IP router and thenext-hop IP router is left as future work.

The difficulties of incremental deployment and the prob-lems of middleboxes, coupled with the potential problem ofattacks on Quick-Start bandwidth discussed in Section 8,suggest that Quick-Start could remain in controlled net-works for quite some time, where the incremental-deploymentbarriers are reduced, the range of middleboxes is under morecontrol, and attack traffic can more easily be monitored andcontrolled. In addition, in such a controlled environment, it

is likely that all of the routers along a path would supportQuick-Start, reducing the problem of Quick-Start requeststhat are denied simply because of routers that are not Quick-Start capable. It is even possible that Quick-Start wouldremain a mechanism largely for use in controlled environ-ments, and would never see ubiquitous deployment in theglobal Internet.

5. SIMULATION SETUPIn the following sections we use the ns-2 simulator [1] to

explore various facets of Quick-Start. We use a networkcomprised of three routers, R1–R3, arranged in a chain.The two links between the routers have bandwidth of Lbw

and a one-way link delay of Ld. Unless otherwise noted,Lbw=10 Mbps and Ld=20 msec. The routers employ drop-tail queuing with a maximum queue size of 150 packets.

For most simulations, web clients and servers are con-nected to the ends of the network (to R1 and R3) with ded-icated 1000 Mbps links with a mean one-way link delay of12 msec and a maximum delay of 110 msec. The actuallink delays are chosen to give a range of round-trip timesthat roughly matches those from measurements, using theprocess from [10]. A varying number of web servers, N ,are connected to R1 with a corresponding number of webclients connected to R3. The measurements presented inthe subsequent sections all refer to the traffic from the webservers connected to R1. We also attach N

2web clients to

R1 and N

2web servers to R3 to provide background traf-

fic on the return path. When Quick-Start is enabled, alltraffic attempts to use Quick-Start. The standard web traf-fic generator included with ns-2 is used in our simulations,with the following parameter settings: an average of 30 webpages per session, an inter-page parameter of 0.8, an aver-age page size of 10 objects. The web object sizes are gener-ated using a ParetoII distribution with an average param-eter of 400 packets and shape parameter of 1.002. We useHTTP/1.0-like transactions, with one web object per TCPconnection. These parameters, particularly the average ob-ject size, are not picked to match realistic traffic distribu-tions, but rather to explore Quick-Start’s impact on a wideswatch of connection sizes, as Quick-Start is only effective onconnections that are larger than the size of the TCP’s initialwindow. We also ran simulations with other web traffic andnetwork parameters, and the observations were similar asdiscussed in Sections 6 and 7. Our web traffic simulationsare run for 150 seconds, and they were repeated 12 times(with means reported in this paper).

A few simulations make use of a single transfer at a time.These simulations use FTP to transfer a file of a given sizeover the network given above with no reverse traffic present.

Finally, all TCP connections use ns-2’s sack1 TCP variantwith an initial cwnd of 3 segments (per [4]), an MSS of1460 bytes, an advertised window of 10,000 segments3, andthe receiver acknowledging each segment.

All simulations presented in the remainder of the paperuse this setup unless otherwise noted. Simulation scriptswill be on-line on the Quick-Start web page [2].

6. CONNECTION PERFORMANCE

3This is high enough to make the advertised window a non-issue in our simulations.

In this section we explore when Quick-Start is and is not ofbenefit. In particular, we consider how to choose the Quick-Start request size and the implications of Quick-Start onaggregate network traffic.

6.1 Ideal BehaviorIn an ideal Quick-Start scenario over an under-utilized

network path, the TCP sender would be able to transmit asmuch of its data in the initial congestion window as the sparenetwork capacity can absorb. Figure 1 illustrates the idealQuick-Start behavior by displaying time-sequence plots oftwo connections4. The first connection is a standard TCPconnection that uses slow-start to begin transmission (withan initial cwnd of 3 segments). The second connection on theplot shows a case where an approved Quick-Start Requestallows the sender to transmit 25 of its 30-packet transfer inthe initial window. When the first acknowledgment for dataarrives at the TCP sender, the data transmission continuesin slow-start, sending two packets for each acknowledgment.The connection using Quick-Start completes in just over halfthe time required by the non-Quick-Start connection.

0 2 4 6 8 10

05

1015

2025

30

Time (s)

Seq

uenc

e N

umbe

r

DataAcks

Figure 1: Normal TCP Slow-Start (left) vs. Quick-Start (right), for a 384 Kbps bottleneck link and1-second RTT.

We note that it takes at least dlog2

`

N

W+ 1

´

e + 1 round-trip times for a TCP connection in slow-start to completea transfer of N packets, given an initial congestion windowof W packets. We illustrate this in Figure 2 using the ns-2 simulator. We use a simple scenario with capacity setat 100 Mbps, various link delays, routers with unlimitedbuffers, routers willing to allocate 90% of their capacity toQuick-Start requests and TCP making Quick-Start Requestsof 20 MB/sec. Figure 2 shows the results of the simulations.Although the simulation scenario is not necessarily realistic,it illustrates the potential impact of using Quick-Start. Theresults confirm that increasing the initial cwnd aids perfor-mance — especially for medium-sized transfers that are notmuch larger than the approved Quick-Start request. In ad-dition, the plots show that Quick-Start is less beneficial forexcessively short or long transfers; for short transters, thetransfer time is already small, and for large transfers, thestartup behavior has a limited impact on the overall trans-fer time. These results are similar to earlier results fromSundarrajan [24].

6.2 The Size of the Quick-Start Request4In this scenario the link bandwidth was 384 Kbps andthe round-trip delay one second, roughly motivated by aGPRS/EDGE wireless scenario [23].

5 10 50 100 500 5000

010

020

030

040

0

Transfer Length (KB)

Per

form

ance

Impr

ovem

ent (

%)

1000ms500ms200ms100ms

Figure 2: Relative improvement with Quick-Start,for a 100 Mbps link with a range of propagationdelays.

We next consider how the sender chooses the Quick-Startrequest size, and how the size of Quick-Start requests af-fects the aggregate usefulness of Quick-Start. As discussedin Section 3, an ideal Quick-Start request would contain theprecise sending rate the connection would like to use. How-ever, knowing such a sending rate is non-trivial and dependson a number of factors. A simple Quick-Start implementa-tion for TCP could send a fixed Quick-Start request eachtime a request is transmitted. This would not be unrea-sonable for initial Quick-Start requests, since in many casesthe TCP sender has no knowledge about the application orthe network path when the TCP SYN segment is sent. ForQuick-Start requests sent in the middle of a connection, e.g.,after an idle period, the sender may be able to make a moreinformed Quick-Start Request.

To illustrate the problem with overly large Quick-Start re-quests we simulate two scenarios involving web traffic thatuses one TCP connection for each web object transferred.In the first scenario, all TCP connections use a static Quick-Start request of 2 MB/sec. In the second scenario, the re-quests are ideal (even if unrealistic) for the amount of datathe given connection will ultimately transmit. In addition,Quick-Start is not used if the connection is able to send alldata in the standard three-segment initial cwnd. The simu-lations use an average web object size of 60 packets.

In the first scenario all connections use a fixed-size RateRequest and requests are generally granted for only the firstconnection in each web session. The router is generally un-able to approve requests of later connections in each ses-sion, because the first connection is granted all of the avail-able Quick-Start bandwidth even though the first connec-tion cannot use such a large allocation. As a result, the ex-tra allocation is “wasted”, in that subsequent Quick-Startrequests are denied unnecessarily. In this scenario, 9% ofQuick-Start requests are approved and 220 KBs of data istransmitted during Quick-Start. In the second scenario con-nections use ideal sizes for their Rate Requests and requestsare approved more often since there are fewer wasted ap-provals. For the second scenario, 40% of Quick-Start re-quests are approved and 769 KBs are transmitted duringQuick-Start.

While the ideal case above is preferable, TCP connectionsdo not, in general, have enough information to make idealrequests. However, there are several ways systems can cope.First, if an end-host is configured to understand the max-imum capacity of its last-mile hop, C bytes/sec, requestscould be chosen to be no larger than C. Going even further,a policy decision could be made to disallow any one TCPconnection from using more than some fraction of the capac-

ity and that could be used as an upper bound on the Quick-Start request (e.g., on a large web server). In addition, asender could leverage the size of the local socket buffer,S bytes, and the receiver’s advertised window, W bytes,when choosing a request size5. Given an RTT of R sec6 TCPcan send no faster than min (S, W ) / R bytes/sec (assumingW is non-zero and using S if it is). Finally, and more spec-ulatively, if an application informed the sender of the size ofa particular object (when known), say O bytes, the sendercould request precisely the rate required to transmit the ob-ject in a single RTT as (O + (O/MSS) ∗ H)/R bytes/secfor a given MSS size and estimated header size of H bytes.While these techniques do not necessarily provide for anideal Quick-Start request they could well provide a morereasonable request than simply picking a static rate for allcases.

When a Quick-Start packet is lost after an approved Quick-Start Request, we call this a Quick-Start failure. This situa-tion can arise for a number of reasons, for instance becausea burst of traffic arrives at a router immediately after therouter approves a Quick-Start Request, or because a buggyor broken router simply approves all Quick-Start requestsor mis-calculates the rate that should be approved. In thissituation the TCP sender disregards the cwnd determinedusing Quick-Start and uses slow-start to open the cwnd justas would have happened without Quick-Start. This is illus-trated and discussed further in [22].

6.3 Aggregate Impact of Quick-StartBecause Quick-Start requests are only approved when the

output link is significantly underutilized, Quick-Start shouldhave little effect on the long-term aggregate utilization anddrop rates on a link. In particular, when link utilization ishigh, routers should not approve Quick-Start requests; thus,Quick-Start is not a mechanism designed to help a routermaintain a high-throughput low-delay state on the outputlink. In Section 7 we study methods for routers to use tochoose whether to approve Quick-Start requests and howmuch capacity to grant each request. In addition, we illus-trate the implications of using Quick-Start when the routeris not significantly under-utilized.

0 20 40 60 80 100 120

0.00

0.02

0.04

0.06

Web sessions

Dro

p ra

te

Regular TCPQuick−Start

Figure 3: Comparison of drop rates with and with-out Quick-Start, with a 10 Mbps shared link.

5When sending a request in the initial SYN segment of aconnection the sender will not know the peer’s advertisedwindow.6Or, an approximation if the connection has not yet takenan RTT measurement.

2000 5000 10000 20000 50000 100000 200000

0.0

0.2

0.4

0.6

File size (Bytes)

Dur

atio

n (s

)

xxxx xx

xx

x xxxxxxx

xx

xxx xx

x xxxx

xx x

xxx

xxxxxxxx xx

xxxxx

xx

xxxx xxx

xx

x xxx

xx

xx xxx

xx

x xx xx

xxx xxx

xxx

xxx x

x xxxxx

xxx xxx

xxxx

xx

xxx

xxx

xx

xx x xxxx x

xx

xxx xx

xxx xxxxxxx xxxxx

x xxxxxxx x

x xxxxxxxx x

xx

xxx

xxxxx

xxxx

xx

xxxxxxx

xxxx x

xxxxxxxxx xxx xxxxx

xxxxx

xxx

xxxxxx

xxx

x xxx

xx

xxxx xxx

xx xxx xx

xx xx xx

xx

xxxxxxxx

xxx xxx

xx xxxxx

xxx

xxx

xxxx

xxxxxxxx xxx

xxx

xxx

xx

xx

xxxx xxxx

xx xxxx x

xxxxxxx

xxx

xxxxxxxx xxxxx xxx

xxx xxx

xx

xxxxxx

xxxxx

xxxxx x

xxxxxxx

xxxxx

xx

xx xx

xxxx

x xxxxx

xxx

xxxxxxxx xxxxx xxx

xxx

xx

x xxx xxx

xxxx

xxxx

xx x

xx

xxxxx xxx x

xx x

xxxx

xx xx xxxxxxxx xx xxxx

xx

xxx x

xxxx xxxx

xx xx

xx xxxxx x

xxx xx

xxx

xxx

xxx xxx

xx

xx xxx

xxxxxx

xxx xxx

xxxxxxxx

xxxxx xxx xxx

x xxx

xx

xx

xx

xx

xx

x xx xx xxxxxx

x xxx xxx

xx

xxxxx

xxx xxx

xx

xx

xxxxxxx

xxx

xxxx xxx

xxxxxx

xx

xxx

x xx x

xxxxx

xx

xx xx

xxx

x xxx xxx

xxx

xxx xxx x

xxx

xxxx

xxxx

xx

xxx

x xx

xx xxxxxx

x xxxxxx x

xxx x

xx

xxx

xxx

xx

x xxx

xx

xxx

xx

xxx

xxx

xx

xxx

xx

x xx

xxx

xxxxx

xx

xxx xx

xx xxxxxx x

xxxxxxxxxx xxxxxxx xxxxx

xxx

xx

xx

x xxx

xx

xxx

xxxxxx x

xxx

xxxxx

xxxxxxx

xxx

xxx xxxx

xxx x

xxxx

xxxxxxx xx

xxx

xxx xx

xxxxx xxxxx

xxxxx

xx xxxx

xx

xx

xx

xxxxx

xRegular TCPQuick−Start

2000 5000 10000 20000 50000 100000 200000

0.0

0.2

0.4

0.6

0.8

1.0

File size (Bytes)

Dur

atio

n (s

)

xxx

xx

x

x

xx

xx xxxxxxx xxxxxx xx

xx

xxxxxx

xx

x xx

x xxxx

x xx

x

xx x

x

x

x

x

x

xx

x x

xxxx

xxxx

xxxxxxxx x x

x xxx xx

xxx x

x

x

xxx x

xx

xxxx x

xxx

xx

xx

x xx

xxxxxxxx

xxx

xxx xx

xxxxxxx

xxxxx

xxx

xx

xxxxx xx

xxxxxx

xxxxx xxxx

xx

xx

x xx

xx

xxxxxxxx

xxx xxx

xx

x x

x

x xx xxx

xxxx

x

xx

x

x xxx xxx x

xx

xxx

xxxxxxx

xxx xx

xxx

xx

xx x xx

xx

x

xxxx xxxxxx

xxxxx

x

x x

x

x

x xxx

x

x

x xxxx

x

xx xx x

xx

x

xxx xxx x

xx xxx

xxx xx

x xxxxx xx

xxxx xxx

xx xxxxx xxxx

xxxxxx xxxxx x x

xxxxxx xx

xxx

xx x

xxxxx

xxx

xx xx

x xxxxxx xxxxxx xx

xxxxxx

xxx xxxxx xxx

xxx

xxx x

xxxxxxxx

xxx

xx

xxxxxxx

x xx xx

xxx

xxxxxxxxx xxx

xxxxxxx

xx

xx

xxx

xxx x

xx

xxxxxxxx xxx

xx

xx xxx

xx xxxxxx

xxxxx

xxxx

xxxx

xxx

xxx

xx x

x

xxxxx xx

x xxxx

x

x xx

x

x xx xxxxxxxxxx xx

x

xx xxxxx xxxx

xx xxxx x

xxxx

xxxx x

xxxx

xx

xxxxx

xxxxx x

xxxxxxxxxxx

xxxx xxxxxx xxxx x

xx xxx xx

xx

xxx x

xxx

xxx

x xx xxx

xx

x xxx xxx

xxx

xx

x xxxx

xxx

x xxxxxxx

xxx

xxxxxxx

xxxxx xx

xx

x x

x

x

xx

xx

xxxx

x

x xxx xx

x xxxx

xx x

xx

xxx xx

xx

xxxxx

xxx xx

xxxxx

xxxxxxxxx

xxxx

xxx

x xxx

xxxxxx

xxx

xx x

xx xx xx

x xxx

xxxxxx

xxx

xxx xxx xxxxx

x xx xxxxxxx

xxx xxx xxxx xxxxx

xx x

xxx

xxx

xx

xxxxxxxxx

x

xxxxxx

x

x x

x

xxx

x

x

x

xx

xxx

x

x

xx

x

x

x

x

x

x

x

xx

x

xxx

xxxx

xxx

xRegular TCPQuick−Start

100 Mbps

10 Mbps

Figure 4: Per-connection performance with andwithout Quick-Start, with 10 Mbps and 100 Mbpsshared links and three web sessions.

For the traffic models used in this paper, the amount ofdata requested by a user is independent of whether Quick-Start is used, and independent of the fate of the Quick-Startrequests. While the use of Quick-Start or particular allo-cations from the routers will have an impact on the timerequired for particular transfers, the aggregate amount ofdata requested is not affected. Given this model, althoughthe use of Quick-Start might be of great benefit to the in-dividual user, Quick-Start should have little effect on thelong-term aggregate link utilization or packet drop rates.

However, it is possible that the successful use of Quick-Start would increase the amount of data sent and receivedby each user. For example, some users could have a fixedamount of time available for using the network, rather thana fixed amount of data to send and receive. In this case, theuse of Quick-Start could result in an increase in aggregateutilization in under-utilized scenarios. Even in this case,however, the use of Quick-Start should not affect the uti-lization and loss rates over paths that are not under-utilized,because in these scenarios Quick-Start requests should notbe approved by the routers.

Figure 3 shows the aggregate drop rates with and withoutQuick-Start as a function of the number of web sessions,for a simulation scenario with web traffic with an averageobject size of 400 packets (as described in Section 5) ona 10 Mbps shared link. As shown in the figure, the droprates are largely independent of whether or not Quick-Startis employed. Also the link utilization is unaffected by theuse of Quick-Start, as will be discussed the next Section.We also conducted simulations with a smaller average webobject size (of 60 packets) and obtained similar results.

Figure 4 shows per-connection performance of all trafficinvolved in a simulation of 3 web servers. Each point on theplot represents the duration of a single connection, with thepoint type indicating whether Quick-Start is used. The top

plot shows the results from a simulation run over a 10 Mbpslink while the bottom plot uses a 100 Mbps link. For mediumto large transfers the plots show Quick-Start improves per-formance — by a factor of 2–3 in many cases, with larger sav-ings over the higher bandwidth path. The transfer durationshown in the figure includes the time for the SYN exchange.These plots show that even though the overall bandwidthusage and drop rates are similar with and without Quick-Start, per-connection performance is increased when usingQuick-Start.

7. ROUTER ALGORITHMSThis section discusses several possible Quick-Start algo-

rithms for routers to use to choose when to approve Quick-Start requests. We start with a basic algorithm that requiresminimal state, and proceed to an extreme Quick-Start algo-rithm that keeps per-flow state for approved Quick-Startrequests. It is desirable for routers to be able to processQuick-Start requests efficiently. At the same time, the Ex-treme Quick-Start algorithm explores the ability of an ideal

router to selectively approve Quick-Start requests in orderto maximize the use of Quick-Start bandwidth by the end-nodes.

7.1 Basic router algorithmsQuick-Start requests represent an increased packet pro-

cessing burden for routers that may also result in an in-creased end-to-end delay for packets with Quick-Start re-quests. Therefore, it is important that the algorithm forprocessing the Quick-Start requests at routers be as efficientas possible, with a small memory footprint.

To know if there is sufficient bandwidth available on theoutput link to approve a Quick-Start request, the routerneeds to know the raw bandwidth and have an estimateof the current utilization of the link. The router also hasto remember the aggregate bandwidth approved for use byend hosts in the recent past to avoid approving too manyrequests and over-subscribing the available capacity. In thissection we consider the algorithms used by routers to processQuick-Start requests for point-to-point links; algorithms formulti-access links are left as future work.

The first router design choice concerns the router’s methodfor estimating the recent link utilization. There are a rangeof measurement and estimation algorithms from which tochoose, including alternatives for the length of the measure-ment period. We discuss two methods for estimating thelink utilization, the moving average and measuring the peakutilization. We also note that developing and assessing al-ternate algorithms is an area for future work.

The moving average estimation technique uses a stan-dard exponentially weighted moving average to assess theutilization over the recent past. This scheme was originallyused for Quick-Start in [24]. We define U(t) as the utiliza-tion at time t, M(t) as the link utilization measurement attime t, δ as the interval between utilization measurementsand w as the weight for the moving average. The utilizationis defined as:

U(t + δ)← w ∗M(t + δ) + (1− w) ∗ U(t) (2)

We note that the weight w should depend on the interval δ,so that the utilization is estimated over the desired intervalof time.

With peak utilization estimation, the router measures

util_bw = bandwidth * utilization;util_bw += recent_qs_approvals;if (util_bw < qs_thresh * bandwidth) {

// Approve Quick-Start Requestapproved =

qs_thresh * bandwidth - util_bw;if (rate_request < approved) {approved = rate_request;

}recent_qs_approvals += approved;

}

Figure 5: The Target algorithm for processingQuick-Start requests.

the link utilization over the most recent N time intervals,and takes the highest of the N measurements as the currentlink utilization. Thus, if each time interval is s seconds, thenthe peak utilization method takes the peak s-second linkutilization measurement over the most recent N ∗ s seconds.The peak utilization method reacts quickly to a sudden in-crease of link utilization, but also remembers a period ofhigh utilization in the recent past. Unless otherwise noted,we use N = 5 intervals with interval length of s = 150 msecthat covers most of the RTTs in the network.

In addition to the two methods for estimating link uti-lization, we consider algorithms for deciding whether to ap-prove a given Quick-Start request and how much capacityto grant in an approval. These algorithms rely on know-ing recent qs approvals, the aggregate bandwidth promisedin recently-approved Quick-Start requests — ideally over atime interval at least as long as typical round-trip times forthe traffic on the link. If the time interval for this assess-ment is too small, then the router forgets recent Quick-Startapprovals too quickly, and could approve too many requests,thus over-subscribing the available bandwidth. On the otherhand, if the time interval is too large, the router errs onthe conservative side and remembers recent Quick-Start ap-provals for too long. In this case the router counts someof the Quick-Start bandwidth twice, in the remembered re-quest and also in the measured utilization, and as a resultmay deny subsequent Quick-Start requests unnecessarily.Unless otherwise noted, we compute recent qs approvals asthe aggregate Quick-Start bandwidth approved in the mostrecent two 150-ms intervals, including the current interval.

The Target algorithm, given in Figure 5, approves Quick-Start requests only when the link utilization, including thepotential bandwidth of recently-granted Quick-Start requests,is less than some configured percentage of the link’s band-width, denoted qs thresh. This gives a router direct controlover the notion of “significantly under-utilized”. When aQuick-Start request is approved, the approved rate is re-duced, if necessary, so that the total projected link utiliza-tion does not exceed qs thresh.

Figure 6 shows simulations with the Target algorithm.The simulations use a range of values for the qs thresh pa-rameter in the Target algorithm. The Target algorithm usesthe peak utilization method for estimating link utilization.The top graph of Figure 6 shows the overall link utilizationfor each simulation. The middle graph shows the fractionof Quick-Start Requests approved. Finally, the bottom plotshows the fraction of Quick-Start failures. We note thatthe fraction of failures for the Target algorithm is relativelysmall. [22] compares the performance of the Target algo-rithm with an algorithm, Share, that was proposed earlier

0 20 40 60 80 100 120

0.00

00.

010

0.02

00.

030

Web sessions

QS

Fai

lure

sTARGET: 0.95TARGET: 0.90TARGET: 0.85TARGET: 0.65

0 20 40 60 80 100 120

0.0

0.2

0.4

0.6

0.8

1.0

Web sessions

QS

Req

uest

s A

ppro

ved

(fra

ctio

n)

TARGET: 0.95TARGET: 0.90TARGET: 0.85TARGET: 0.65

0 20 40 60 80 100 120

0.0

0.2

0.4

0.6

0.8

1.0

Web nodes

Util

izat

ion

TARGET: 0.95TARGET: 0.90TARGET: 0.85TARGET: 0.65No QS

Figure 6: Evaluation of Target algorithm.

[24], and shows that the Target algorithm has superior per-formance.

Figure 7 compares the moving average and peak utiliza-tion methods for estimating link utilization. The simulationsuse the Target algorithm with a 10 Mbps shared link anda target level of 90%. The top graphs show the fraction ofQuick-Start requests approved, and the bottom graphs showthe fraction of approved Quick-Start requests with droppedpackets. The moving average simulations were run with arange of values for the weight w, and the peak utilizationsimulations were run with a range of values for the numberN of 150-msec intervals over which the peak utilization waschosen. As Figure 7 shows, the method for estimating thelink utilization does not significantly affect the approval rateof Quick-Start requests, but it does affect the failure rate;simulations using the moving average link utilization have ahigher fraction of Quick-Start failures — as the amount oftraffic increases.

Figure 7 shows that the selection of the weight w in themoving average equation does not have a strong effect onthe number of Quick-Start failures. The weight controls thetime interval over which the link utilization is estimated, butthe moving average method still estimates the average uti-lization; it doesn’t take into account the variance of traffic

0 20 40 60 80 100 120

0.00

0.02

0.04

0.06

Web sessions

QS

Fai

lure

s

w: 0.05w: 0.01w: 0.005

0 20 40 60 80 100 120

0.0

0.2

0.4

0.6

0.8

1.0

Web sessions

QS

Req

uest

s A

ppro

ved

(fra

ctio

n)w: 0.05w: 0.01w: 0.005

0 20 40 60 80 100 120

0.00

0.02

0.04

0.06

Web sessionsQ

S F

ailu

res

3 slots5 slots10 slots20 slots

0 20 40 60 80 100 120

0.0

0.2

0.4

0.6

0.8

1.0

Web sessions

QS

Req

uest

s A

ppro

ved

(fra

ctio

n)

3 slots5 slots10 slots20 slots

Moving Average Peak Utilization

Figure 7: Comparison of moving average and peak utilization mechanisms.

intensity that can be present, particularly on links with lowto moderate levels of link utilization. For Quick-Start, wherethe router doesn’t want to approve Quick-Start requests thatcould result in even transient congestion, tracking the aver-age link utilization can result in unwanted Quick-Start fail-ures.

For the simulations with the peak utilization method, theQuick-Start failure ratio is generally lower than with themoving average method. When there are more than 50 webservers, using only three recent measurements for peak uti-lization causes more Quick-Start failures than when largernumber of intervals are used. With twenty intervals thereare hardly any Quick-Start failures. However, when tenor more intervals are used, the approval algorithm is alsosubstantially more conservative, with fewer Quick-Start re-quests being approved.

7.2 Extreme Quick-Start in routersWe use the term Extreme Quick-Start for a Quick-Start

router that maintains per-flow state about Quick-Start re-quests. While not necessarily realistic, with Extreme Quick-Start we can analyze how much Quick-Start performancecould be improved if router efficiency was not a limitingfactor. For example, an Extreme Quick-Start router couldperform the following actions:• A router could keep track of individual approved Quick-

Start requests, and note when the Quick-Start bandwidthresulting from that request begins to arrive at the router (ifin fact it does). This allows the router to more accuratelyestimate the potential Quick-Start bandwidth from Quick-Start requests that have been approved but not yet used atthe end nodes.• A router could keep track on the fairness of Quick-Start

request approvals. If it appears that there are a numberof requests that are not approved because earlier requestshave allocated all of the available Quick-Start bandwidth,

the router could reduce the rate approved for individual re-quests in order to achieve better fairness between flows.

It is useful for an Extreme Quick-Start router to knowthe RTTs of flows, in order to set the length of the intervalfor measuring the arrival rate of packets from a flow afteran approved Quick-Start request. There are a number oftechniques for routers to estimate flows’ RTTs [13]. In theanalysis below, we assume that the Extreme Quick-Startrouter implements a reliable method for evaluating RTTs.

For each flow, an Extreme Quick-Start router estimatesthe number of bytes expected to arrive in the Quick-Startphase, based on the received rate request and the estimatedRTT. The Extreme Quick-Start router also maintains thenumber of received bytes for each flow. From this infor-mation the router can compose a detailed estimate of cur-rently unused Quick-Start bandwidth, and is able to moreaccurately establish how much bandwidth it is possible toapprove for an incoming rate request without exceeding thedesired target utilization. As the basic Quick-Start does nottrack per-flow state, but only the aggregate total of the re-cently approved Quick-Start requests in the recent qs appro-

vals variable, and because Quick-Start also uses the mea-sured link utilization in determining whether it is possibleto approve an incoming rate request, the basic Quick-Startis more conservative in its estimation of the available band-width: after the initial window of data has arrived at therouter, there is a period of time when recent qs approvals

accounts for the Quick-Start data that has already been re-ceived, while the arrived packets have also affected link uti-lization. Extreme Quick-Start aims to remove this overlap-ping, thus resulting in better acceptance ratio of the Quick-Start requests and higher Quick-Start bandwidth.

We illustrate the difference of the basic Quick-Start andExtreme Quick-Start by two examples below. Figure 8 com-pares the basic Quick-Start algorithm and the Extreme Quick-Start algorithm for scenarios with a small range of RTTs

0 10 20 30 40 50

0.0

0.1

0.2

0.3

0.4

0.5

Web nodes

QS

Byt

es /

All

Byt

es

Extreme QSQS

0 10 20 30 40 50

0.0

0.2

0.4

0.6

0.8

1.0

Web nodes

Util

izat

ion

Extreme QSQS

Figure 8: Basic Quick-Start and Extreme Quick-Start with a highly-tuned recent qs approvals pa-rameter.

0 10 20 30 40 50

0.0

0.1

0.2

0.3

0.4

0.5

Web nodes

QS

Byt

es /

All

Byt

es

Extreme QSQS

Figure 9: Basic Quick-Start and Extreme Quick-Start with a conservative recent qs approvals param-eter.

(80–120 msec), with the assumption in this scenario thatthe RTTs are known (or easily guessed) by the router, andthe router can accurately set recent qs approvals to roughlymatch the round-trip time (100 msec). In these simulations,the basic Quick-Start variant uses the Target algorithm withthe peak utilization method. From the top plot we see thatthe utilization is nearly the same regardless of whether basicQuick-Start or Extreme Quick-Start is employed. However,the bottom figure shows that the fraction of bytes trans-mitted using Quick-Start is slightly greater when ExtremeQuick-Start is used by the router to track each allocation indetail. This scenario is certainly not typical, but there couldbe some initial Quick-Start deployment scenarios, such as inlimited Intranets, where there is a limited range of RTTs,and also where the traffic and network characteristics couldbe accurately estimated. The figure shows that in such con-ditions, with carefully tuned parameters, it is possible toachieve nearly the same performance with basic Quick-Startas with Extreme Quick-Start.

As a point of contrast we changed the computation of re-

cent qs approvals to include the most recent two 1.5-secondintervals, to investigate Extreme Quick-Start in the context

of a basic Quick-Start router that does not have a “typical”RTT and therefore chooses a conservative setting (i.e., thissetting results in few Quick-Start failures, but also fewerQuick-Start request approvals). Figure 9 shows Quick-Starttraffic as a fraction of the total amount of data transmit-ted. The figure shows that the fraction of bytes sent duringthe Quick-Start phase of the connections is greater when us-ing Extreme Quick-Start. This illustrates Extreme Quick-Start’s power in terms of more closely tracking resourcesso that more requests can be approved. Therefore, lesswasted capacity is allocated by Quick-Start which allowsmore connections to be approved to use Quick-Start. Thedifference between basic Quick-Start and Extreme Quick-Start in this figure is larger than the difference shown inFigure 8 due to the more conservative setting for the lengthof recent qs approvals. In this simulation we also found theutilization of basic Quick-Start and Extreme Quick-Start tobe nearly identical (the plot is not shown due to space con-straints).

8. ATTACKS ON QUICK-STARTQuick-Start is vulnerable to denial-of-service attacks along

two vectors: (i) increasing the router’s processing and stateload and (ii) temporarily reducing the available Quick-Startbandwidth with bogus Quick-Start requests. Since Quick-Start requests represent a processing burden on the routersinvolved, a storm of requests may cause a router’s load toincrease to the point of impacting legitimate traffic. Giventhe processing burden imposed by Quick-Start, this couldwell be worse than a simple packet flooding attack. A sim-ple limit on the rate Quick-Start requests will be considered(with a policy of ignoring requests sent in excess of this rate)mitigates this attack on the router itself. In the case of Ex-treme Quick-Start another problematic aspect of a storm ofpackets is the memory requirement to track bogus “connec-tions”.

The second type of attack, an attack on the availableQuick-Start bandwidth, is more difficult to defend against.In this attack arbitrarily large Quick-Start requests are sentby the attacker through the network without any furtherdata transmission. With a relatively low-rate stream ofpackets, this can cause a router to allocate capacity to theattacker and thus temporarily reduce the amount of capacitythat can be allocated to legitimate Quick-Start users. Notethat the attack does not actually consume the requestedbandwidth and therefore the performance of connectionscompeting with attacks is no worse than connections thatsimply don’t make use of Quick-Start. These attacks areparticularly difficult to defend against for two reasons. First,the attack packets do not have to belong to an existing con-nection to do damage. And, second, since the attack justinvolves a Quick-Start request traversing the network pathin one direction only to trigger bogus allocations, a responseis not required. Therefore, spoofed source addresses are apossible aggravating factor for both hiding the location theattack is originating from and causing a simple blacklistingdefense to fail.

An additional problematic aspect of Quick-Start is thatlegitimate requests could well cause the same impact as at-tack packets. Consider a Quick-Start request for rate R thatis approved, and therefore marked “allocated” in the routerby the first router in the path. Now assume the same requesthits a downstream router that reduces the rate to some R′

that is less than R (maybe even to zero) for whatever reason.In this case, the first router has allocated some amount ofcapacity that cannot be used because of the conditions else-where in the network. From the vantage point of the firstrouter this is similar to the attack described above in thatcapacity allocated for Quick-Start goes unused and thereforereduces the router’s ability to approve further Quick-Startrequests.7 [22] explores the possible use of Extreme Quick-Start to enable routers to reduce Quick-Start requests fromsenders that have in the past used only a fraction of theirapproved Quick-Start bandwidth.

In addition to Denial of Service attacks, Quick-Start isvulnerable to cheating by routers or by end-nodes, as dis-cussed in [12]. Non-conformant routers or hosts might try tomodify the Quick-Start messages to benefit particular con-nections. For instance, a receiver could increase the rategiven in an arriving Quick-Start Request before echoing itback to the sender, in an effort to increase the connection’sperformance. Similarly, a router close to the sender and act-ing on the sender’s behalf (a “performance booster”) couldincrease the approved sending rate and/or adjust the re-ported TTLDiff ′ from the receiver to match the originalTTLDiff in an effort to mask the network’s lack of Quick-Start savvy. While it is possible to attempt to game Quick-Start, it also risks hurting instead of helping performance;lying about the size of the approved rate request could endup causing packet drops for Quick-Start packets, resultingin a slow-start for the connection in question.

9. CONCLUSIONS AND FUTURE WORKIn this paper we have discussed the potential costs and

benefits of Quick-Start on performance in an uncongestedenvironment, the appropriate response to the loss or ECN-marking of a Quick-Start packet, and the range of algorithmsfor routers for processing Quick-Start requests.

There are many issues we could not thoroughly study inthis work: How effective and beneficial would Quick-Startbe in practice in realistic scenarios of five or ten years fromnow? Would most of the potential Quick-Start bandwidthbe “wasted” by requests denied by downstream routers, orbecause aggressive or malicious senders make unnecessarilylarge requests denying Quick-Start bandwidth from otherusers? Would routers have sufficient incentives to implementQuick-Start, considering the potential benefits, but also theadditional processing costs and possible security concernsQuick-Start may introduce? What would be the minimalsufficient implementation at the routers and would there besufficient benefit in deploying more complex algorithms inrouters? How severe are the additional security issues dueto Quick-Start? We encourage future efforts in exploringthese issues further.

AcknowledgementsAmit Jain first presented the Quick-Start idea. SrikanthSundarrajan developed the initial Quick-Start implemen-tation for ns2. This material is based in part upon work

7At first glance, allowing the router to watch the Quick-Start responses offers more information. However, due toasymmetric routing we cannot assume that a router will seethe Quick-Start responses. In addition, an arbitrary routerhas no way to tell if the TTLDiff ′ in the response is validand therefore whether the sender will ultimately make useof the response.

supported by the National Science Foundation under GrantNo. 0205519. Any opinions, findings, and conclusions orrecommendations expressed in this material are those of theauthor(s) and do not necessarily reflect the views of the Na-tional Science Foundation.

10. REFERENCES[1] NS Simulator. URL http://www.isi.edu/nsnam/ns/.[2] The Quick-Start Web Page. URL

http://www.icir.org/floyd/quick-start.html.[3] M. Allman. TCP Congestion Control with Appropriate Byte

Counting (ABC). RFC 3465, Feb. 2003.[4] M. Allman, S. Floyd, and C. Partridge. Increasing TCP’s

Initial Window. RFC 3390, Oct. 2002.[5] M. Allman, V. Paxson, and W. Stevens. TCP Congestion

Control. RFC 2581, Apr. 1999.[6] H. Balakrishnan and S. Seshan. The Congestion Manager.

RFC 3124, June 2001.[7] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext

Transfer Protocol – HTTP/1.0. RFC 1945, May 1996.[8] R. Braden. Requirements for internet hosts – communication

layers. RFC 1122, Oct. 1989.[9] L. Breslau, S. Jamin, and S. Shenker. Comments on the Per-

formance of Measurement-Based Admission Control Algo-rithms. In Proceedings of IEEE Infocom 2000, volume 3,pages 1233 – 1242, Tel-Aviv, Israel, Mar. 2000.

[10] S. Floyd and E. Kohler. Internet Research Needs BetterModels. In Proc. of First Workshop on Hot Topics in Net-works (HotNets-I), Princeton, NJ, USA, Oct. 2002.

[11] V. Jacobson. Congestion Avoidance and Control. In Proceed-ings of ACM SIGCOMM ’88, pages 314–329, Aug. 1988.

[12] A. Jain, S. Floyd, M. Allman, and P. Sarolahti. Quick-Start for TCP and IP. Internet-draft “draft-amit-quick-start-04.txt”, Feb. 2005. Work in progress.

[13] H. Jiang and C. Dovrolis. Passive Estimation of TCP Round-Trip Times. ACM SIGCOMM Computer CommunicationReview, 32(3), July 2002.

[14] D. Katabi, M. Handley, and C. Rohrs. Congestion Controlfor High Bandwidth-Delay Product Networks. In Proceedingsof ACM SIGCOMM 2002, Pittsburgh, PA, USA, Aug. 2002.

[15] S. Kunniyur. AntiECN Marking: A Marking Scheme forHigh Bandwidth Delay Connections. In Proceedings of IEEEICC ’03, May 2003.

[16] A. Medina, M. Allman, and S. Floyd. Measuring Inter-actions Between Transport Protocols and Middleboxes. InACM SIGCOMM/USENIX Internet Measurement Confer-ence, Taormina, Sicily, Italy, Oct. 2004.

[17] V. Padmanabhan and R. Katz. TCP Fast Start: A TechniqueFor Speeding Up Web Transfers. In Proceedings of IEEEGlobecom, Nov. 1998.

[18] R. Pang, M. Allman, M. Bennett, J. Lee, V. Paxson, andB. Tierney. A First Look at Modern Enterprise Traffic. InACM SIGCOMM/USENIX Internet Measurement Confer-ence, Oct. 2005. To appear.

[19] C. Partridge, D. Rockwell, M. Allman, R. Krishnan, andJ. Sterbenz. A Swifter Start for TCP. Technical Report 8339,BBN Technologies, 2002.

[20] J. Postel. Transmission Control Protocol. RFC 793, Sept.1981.

[21] K. Ramakrishnan, S. Floyd, and D. Black. The Addition ofExplicit Congestion Notification (ECN) to IP. RFC 3168,Sept. 2001.

[22] P. Sarolahti, M. Allman, and S. Floyd. Evaluating Quick-Start for TCP: the Extended Version, 2005. ICSI TechnicalReport, URL http://www.icir.org/floyd/quickstart.html.

[23] E. Seurre, P. Savelli, and P.-J. Pietri. EDGE for Mobile In-ternet. Artech House, 2003.

[24] S. Sundarrajan and J. Heidemann. Study of TCP Quick-Start with NS-2. unpublished report, University of SouthCalifornia, 2002.