Computer Networks. TCP Libra: Derivation, analysis, and comparison with other RTT-fair TCPs

Transcription

1 Compute Netwoks 54 (2010) Contents lists available at ScienceDiect Compute Netwoks jounal homepage: TCP Liba: Deivation, analysis, and compaison with othe RTT-fai TCPs Gustavo Mafia c, *, Claudio E. Palazzi b, Giovanni Pau a, Maio Gela a, Maco Roccetti c a Compute Science Depatment, Univesity of Califonia, Los Angeles, CA 90095, United States b Dipatimento di Matematica Pua e Applicata, Univesità degli Studi di Padova, Padova, Italy c Dipatimento di Scienze dell Infomazione, Univesità di Bologna, Bologna, Italy aticle info abstact Aticle histoy: Received 10 Mach 2009 Received in evised fom 9 Febuay 2010 Accepted 24 Febuay 2010 Available online 25 Mach 2010 Responsible edito: S. Mascolo Keywods: Fainess RTT TCP Tanspot potocol The Tansmission Contol Potocol (TCP), the most widely used tanspot potocol ove the Intenet, has been advetised to implement fainess between flows competing fo the same naow link. Howeve, when session ound-tip-times (RTTs) adically diffe, the shae may be anything but fai. This RTT-unfainess epesents a poblem that seveely affects the pefomance of long-rtt flows and whose solution equies a evision of TCP s congestion contol scheme. To this aim, we discuss TCP Liba, a new tanspot potocol able to ensue fainess and scalability egadless of the RTT, while emaining fiendly towads legacy TCP. As main contibutions of this pape: (i) we focus on the model deivation and show how it leads to the design of TCP Liba; (ii) we analyze the ole of its paametes and suggest how they may be adjusted to lead to asymptotic stability and fast convegence; (iii) we pefom model-based, simulative, and eal testbed compaisons with othe TCP vesions that have been epoted as RTT-fai in the liteatue. Results demonstate the ability of TCP Liba in ensuing RTT-fainess while emaining thoughput efficient and fiendly towads legacy TCP. Ó 2010 Published by Elsevie B.V. 1. Intoduction Taffic contol functionalities in the Intenet ae povided by the Tansmission Contol Potocol (TCP) in an end-to-end fashion. TCP addesses thee majo issues: eliability, flow contol and congestion contol [1]. To achieve the thid goal, TCP adapts the sending ate to avoid netwok oveflow. The most popula vesions, TCP New Reno and TCP SACK [2], implement a congestion contol algoithm which falls into the AIMD (Additive Incease and Multiplicative Decease) family of algoithms and whose vey basic concepts can be summaized as follows: when a packet loss is detected, the TCP sende deceases its sending window by half; * Coesponding autho. addesses: mafia@cs.unibo.it (G. Mafia), cpalazzi@math. unipd.it (C.E. Palazzi), gpau@cs.ucla.edu (G. Pau), gela@cs.ucla.edu (M. Gela), occetti@cs.unibo.it (M. Roccetti). when a packet is successfully deliveed, the TCP sende inceases its sending window by one ove the sending window. TCP s feedback fo the successful delivey of a packet is embodied by a etuning acknowledgement (ACK). As a esult, competing TCP sendes with diffeent end-to-end popagation delays will typically eceive feedbacks at diffeent ates and adapt thei sending ate at a diffeent pace. This phenomenon detemines the RTT-bias, o RTT-unfainess, of TCP New Reno and TCP SACK. A numbe of TCP vaiants have been designed to limit the effects of this poblem and to impove scalability ove gigabit links. Most of them adopt a poactive appoach based on monitoing packets RTT and eacting to its incease in an attempt to avoid netwok congestion [3]. This behavio is justified by the assumption of a stong coelation between packet loss and RTT incease pio to the loss event. Yet, this dependency has been poven to be weak in [4], RTT pobes may still be too coase to coectly foesee congestion [5] /$ - see font matte Ó 2010 Published by Elsevie B.V. doi: /j.comnet

2 2328 G. Mafia et al. / Compute Netwoks 54 (2010) Examples of algoithms that fit into this categoy ae TCP Vegas [6], TCP DUAL [7] and FAST TCP [8,9]. Instead, we have chosen a diffeent appoach, named TCP Liba, 1 by which, even if the sending window is contolled based on RTT measuements, the main tigge fo window changes emains the packet loss [10]. Even if ou scheme takes into account the delay infomation, it does not use it to lowe the sending ate; athe, the RTT infomation is used to delay just the speed incease of the sending ate. In essence, TCP Liba delays the moment at which congestion will occu, instead of just peventing congestion in the netwok. The contibutions of this wok include the complete deivation of the TCP Liba algoithm, an analysis of its stability bounds, the validation of the algoithm implemented both in Matlab, in NS2, and in the Linux stack, even though the compaison with othe RTT-fai schemes. The est of the pape is oganized as follows. In Section 2 and Section 3 we pesent the state of the at in RTT-fainess and TCP modeling, espectively. The congestion contol algoithm of TCP Liba is intoduced in Section 4, along with a subsection dedicated to a stability analysis of Liba. A model-based compaison with othe RTT-fai schemes is pefomed in Section 5. Expeimental assessment and esults ae epoted in Section 6 and in Section 7, espectively. Finally, conclusions and futue wok ae pesented in Section Addessing RTT-unfainess: elated wok A detailed mathematical model fo the TCP thoughput at steady state, including the Fast Retansmit Fast Recovey phases and TCP s timeout impact, was fist intoduced by Padhye et al. in [11]. In [12 15] the congestion contol poblem is expessed as a utility maximization poblem, whee the netwok utility function is epesented by the sum of utilities of each single souce, and the constaints ae given by links inteconnections and capacities. This flow of wok shows that TCP stability can be achieved in the afoementioned netwok model if the TCP utility function is concave. A futhe substantial advancement in developing the theoy fo netwok congestion contol is exploited in the pimal/dual modeling appoach [16]. The theoetical esults have been used to dive the design of an enhanced AQM technique, namely Random Ealy Mak (REM), and of a new tanspot potocol, namely FAST TCP. Moe in detail, the latte implements a congestion contol mechanism, based on queuing time, which achieves netwok stability and high utilization in multi-gigabit netwoks [8,9,17,18]. The RTT-bias was fist expeimentally obseved in [19]. The authos popose a solution fo this poblem based on a constant window incease algoithm. Hendeson [20] and Hendeson et al. [21] show that such solution leads to instability and thus RTT-unfainess. This is especially tue fo links with long popagation delays and small buffes such as satellite links. To this aim, a few woks have ecently poposed new RTT-fai TCPs. Among the most elevant ones, TCP Hybla [22] implements a constant incease algoithm and povides RTT-fainess unde a cetain stability bound. TCP Vegas [6] povides good RTT-fainess but disegads fiendliness. FAST TCP [8,9] inceases TCP Vegas stability bounds, but with a behavio that esults eithe too timid o too aggessive when coexisting with legacy TCP potocols (e.g., TCP New Reno and TCP SACK). Finally, CUBIC [23] featues a linea RTT-fainess that claims to impove BIC [24]. In paticula, CUBIC ties to decouple the window gowth fom the etuning ACK pocess (a simila appoach is poposed also by H-TCP [25]). With CUBIC, the window size is a function of the time elapsed since the last packet loss, thus allowing highe efficiency (in tems of total bandwidth utilization) in case of long fat RTTs and educing, even if not completely eliminating, the thoughput dependency fom the RTT. Indeed, the thoughput still coesponds to the atio between the window size and the RTT, whee two flows with simila packet loss tend may have the same window but diffeent RTTs. Instead, as we discuss in Section 4, ou appoach takes into account the RTT infomation to dynamically adapt the speed incease of the sending ate. This allows to futhe impove the RTT-fainess while peseving efficiency. 3. TCP model backgound In this section we eview the backgound necessay to intepet the end-to-end congestion contol poblem as a netwok utility maximization poblem [26]. We show how TCP New Reno fits in this model and why it pevents fai RTT behavio. Needless to say, the following discussion about TCP New Reno model holds also fo othe simila potocols such as TCP SACK Netwok model and optimization poblem The netwok is modeled as a finite set of nodes N and links L of finite capacity, which connect the nodes in N. We define c as the vecto of link capacities whee each ow ðc l ; l 2 LÞ epesents the capacity of link l 2 L. S is the set of souces that accesses netwok esouces, typically a subset of N and L. Routing matix R has enty one in position ði; jþ if link i is utilized by souce j, zeo othewise. Each souce 2 S is chaacteized by its tansmission ate, x ðtþ. The aggegate flow at link l is defined as the sum of the contibutions fom all souces that use that link: y l ðtþ ¼ X R l x ðt s f l Þ; whee s f l is the fowad delay fom souce to link l. We define pice to be the maginal cost (o penalty) pe unit flow that a souce incus in sending that flow incement. Intuitively, a link sends an inceased pice, as a feedback signal, when congestion is detected. The aggegate pice seen by souce is: ð1þ 1 Liba in Latin means scale, thus indicating a balance between the sessions.modelling k ðtþ ¼ X l R l p l ðt s b l Þ; ð2þ

3 G. Mafia et al. / Compute Netwoks 54 (2010) whee s b l is the backwad delay in the feedback path fom link l to souce ; p l ðtþ is the pice signal sent by link l at time t. We also define the maginal link pice f l ðyþ as the maginal cost fo sending taffic at ate y l ¼ P :l2 x on link l. Let us now suppose we ae able to define a function that descibes pecisely the etun that each souce expeiences when sending data at ate x. In fact, it is vey difficult to undestand which is the eal advantage fo a use when sending at a cetain ate. The function that descibes this advantage is defined in economics as a utility function. The utility function of a congestion contol scheme shapes its equilibium popeties, such as the equilibium sending ate and its fainess popeties. We now have all the ingedients to state the optimization poblem we want to addess: moves towads the solution at each step. This tem detemines the speed of convegence and the stability of the algoithm. (2) U 0 ðx Þ k ðtþ, the diection in which the algoithm is poceeding, seaching fo a solution (stable point). A detailed poof of convegence can be found in [26]. Howeve, we notice that the function with the deivative shown on the ight-hand side of (5) is concave by constuction. The multiplicative tem does not change the value x that nullifies the gadient. Thus, the gadient method leads to the unique optimum of function VðxÞ. In bief, Theoem 3.1 states that in the absence of feedback delay, any congestion contol algoithm that can be mapped into a concave utility function attains global asymptotic stability. max x VðxÞ; subject to: R x 6 c; x P 0; 8 2 S; ð3þ ð4þ 3.2. TCP New Reno Let us now conside the fluid model fo congestion contol of TCP New Reno. Fom hee on we will follow the notation: whee VðxÞ ¼ P U ðx Þ P R P s:l2s xs l 0 f l ðyþdy. By definition R P s:l2s xs 0 f l ðyþdy is the total cost incued at esouce l fo pushing the contibutions fom all souces that utilize l (i.e., P s:l2s x s epesents the aggegate flow pushed though l). Thus, VðxÞ is the net gain, i.e., the net utility of souces S, which must be maximized. Theoem 3.1 ([26,27]). Unde the assumptions: (1) U ðx Þ is a continuously diffeentiable, non-deceasing, stictly concave function; (2) f l ðyþ is a non-deceasing, continuous function; stating fom any initial condition fx ð0þ P 0g, the distibuted congestion contol algoithm, x_ ¼ k ðx Þ U 0 ðx Þ k ðtþ ; ð5þ (whee k ðxþ is any non-deceasing, continuous function such that k ðxþ > 0; 8x > 0) will convege to the unique solution of (3) (4). In othe wods, xðtþ!^x as t!1, whee ^x is the unique solution to (3) and (4). Intuitively, we can identify packet loss o end-to-end delay as k ðtþ and the algoithm s behavio as U 0 ðx Þ in (5). A high packet loss o end-to-end delay, accoding to (5), povokes a lowe sending ate and vice vesa. The ight-hand side of (5) epesents the th component of VðxÞ, to which the multiplicative tem k ðx Þ was added. Nomally, in the conventional gadient method, k ðx Þ¼1. Thee is no ham, howeve, in intoducing a non-deceasing function that acts as a gadient amplifie. Moe intuitively, the quantities that appea in the expession ae: (1) k ðx Þ, the stepsize of the algoithm. As mentioned ealie, this tem is an amplification facto that detemines the amount by which the algoithm The subscipt means we ae consideing the th souce. x ðtþ is the ate of the connection at time t. w ðtþ is the window size of the connection at time t. g RTT is the aveage RTT. k ðtþ is the pobability of loss at time t. a, the incease facto, is a constant that in TCP New Reno is set to 1. b, the decease facto, is a constant that in TCP New Reno is set to 1/2. TCP New Reno incements the window by 1=w ðtþ pe each eceived ACK, hence the window inceases as xðtþ ð1 k wðtþ ðtþþ. Similaly, evey thee consecutive duplicate ACKs (i.e., a packet loss indication), the window is cut by half. The ate of this event is x ðtþk ðtþ. The window then deceases at a ate of x ðtþk ðtþw ðtþ=2. We now may wite the fluid model fo congestion contol fo an AIMD-like congestion contol scheme (e.g., TCP New Reno) unde the assumption that RTT ðtþ ¼RTT g ; w ðtþ ¼x ðtþrtt g, and taking in account feedback delays: _x ðtþ ¼ x ðt g RTT Þ grtt a 1 k ðtþ x ðtþ g RTT b k ðtþx ðtþ g RTT! : ð6þ In (6) we conside that a window update at time t is detemined by the window state at time t RTT g, because of feedback delay. This non-linea diffeential equation models the thoughput of the th flow. TCP New Reno implements an appoximate gadient algoithm fo the esolution of the congestion contol poblem. In tems of (5), and consideing the feedback delay as negligible, we can wite [26]: _ x ¼ a b a x 2 ðtþþ 1 RTT 2!! 1 b a RTT 2 x2 ðtþþ1 k ðtþ : ð7þ

4 2330 G. Mafia et al. / Compute Netwoks 54 (2010) The above expession fits into the mathematical famewok intoduced in Section 3.1. Obseving the stuctue of (7) and compaing it with (5) we have: U 0 ðx Þ k t ðtþ ¼! 1 b a RTT 2 x2 ðtþþ1 k ðtþ : ð8þ Integating in x the tem U 0 ðx Þ, the utility function of TCP New Reno follows: 0 Uðx Þ¼ 1 ffiffiffiffi sffiffiffiffi 1 a tan b grtt RTT g x A: ð9þ b a By obseving (9) we note that setting a ¼ crtt g 2 (with c some constant value) would poduce an RTT-independent utility function. This solution is discussed in [19 21]. The main dawbacks may be summaized in a slow convegence speed to the fai shae and a deceased stability of the potocol. In the following we intoduce TCP Liba s design, which leads to fast convegence and stable behavio; we intuitively justify the fome and analytically demonstate the latte. 4. The TCP Liba algoithm In the pevious liteatue, Floyd et al. in [19] and Hendeson in [20] pove that the simple constant incease appoach poposed ealie fo RTT-fainess fails. This simple appoach consists in multiplying the congestion window by the squae of the RTT duing the additive incease potion of the TCP algoithm. Even though this appoach claims to make TCP s utility function RTT-independent, it fails fo stability easons, as Kelly poved in [12]. In the est of this section we show how TCP Liba s utility function is not fee fom RTT components, as the eade might at this point expect; yet, we pove that TCP Liba, with a coect setting of its paametes, can achieve a good stability egion. Intuitively, what TCP Liba does is to take into account how close the flow is to oveflowing the netwok with packets. This is measued by obseving how close the cuent RTT is to the maximum expeienced RTT: the close these two values ae, the slowe the congestion window will gow and congest the netwok Enhancing TCP New Reno The feedback contol system fo egula TCP New Reno is descibed in (6), whee x is the state vaiable, k is the input to the system, a and b ae contol paametes that can be tuned. The new tems ^a and ^b that we popose in TCP Liba and that substitute a and b ae: ^a ¼ a g RTT 2 T 0 þ RTT g a ; T 1 ^b ¼ T 0 þ RTT g b : ð10þ ð11þ Please note that compaed to the solution discussed in [19 21] we hee have two new enties, the coefficients a and T 1 =ðt 0 þ g RTT Þ, whee T 0 and T 1 ae constants. In bief: a ¼ k 1 C e k 2 RTT ðtþ RTT min RTT max RTT min ; ð12þ whee k 1 and k 2 ae constants, C is the capacity of the naow link seen by the th souce, RTT min and RTT max ae the minimum and maximum RTT seen by souce. The component k 1 C, intoduced in [10] as the scalability facto, adapts the convegence speed of the potocol as the naow link RTT ðtþ RTT min capacity inceases. Instead, e k 2 RTT max RTT min is the penalty facto discussed in [10]. The caeful eade may object that we ae hee e-intoducing the dependency fom the RTT. Instead, we shall see fom ou esults that this tem keeps the potocol asymptotically stable and peseves RTTfainess. The fluid model fo TCP Liba can be deived by substituting ^a and ^b into (7) with (10) and (11), espectively, and by setting a ¼ 1; b ¼ 1=2. The esulting equation is: _x ¼ T 1 =2 grtt þ T 0 x 2 ðtþþ ~a grtt þ T 0!! 1 T 1 2~a x 2 ðtþþ1 k ðtþ : ð13þ The maginal utility function U 0 ðxþ loosely depends on g RTT (the aveage RTT) though ~a, but we shall see that this dependence is vey low. We can theefoe state that TCP Liba minimizes the sum of the tansfe delays in the netwok, yet independently fom the RTT expeienced by the souce. These values lead to the following stable point fo the th souce: ~x ¼ sffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi 2 ~a 1 k ~ : ð14þ T 1 ~k Summaizing now the design choices in (10) and (11) fo ^a and ^b, espectively, we can state that: (1) we achieve a stabilized ate, almost independent fom RTT, as we shall see in the next sections; (2) convegence speed to the stable point is peseved as link speed inceases though the intoduction of a scalability facto; (3) stability and RTT-fainess ae enfoced though the penalty facto. Algoithm 1. Congestion Window Update in TCP Liba window n ( congestion window at step n theshold n ( slow stat theshold at step n if a packet is successfully deliveed then window nþ1 ( window n þ 1 anrtt 2 n windown RTTnþT 0 else if thee duplicate acknowledgements then window nþ1 ( window n T 1windown 2ðRTTnþT 0 Þ theshold nþ1 ( window n T 1windown 2ðRTTnþT 0 Þ end if end if

5 G. Mafia et al. / Compute Netwoks 54 (2010) Algoithm The esulting algoithm is epesented in Algoithm 1. Simulations in Section 6 ae obtained setting T 0 ¼ 1; T 1 ¼ 1; k 1 ¼ 2; k 2 ¼ 2. A highe value of k 2 would have impoved the link utilization; this can be explained by obseving that a highe k 2 would stengthen the dependence of the window incease algoithm on the RTT and thus delay packet loss events. In bief, a highe k 2 enfoces the sending window to be at its maximum fo a longe time, but we have noticed that a highe k 2 geneates an excessively timid behavio of TCP Liba towad TCP New Reno. Paametes k 2 and k 1 ae stictly elated and ae adjusted as a tadeoff between utilization, fainess, and fiendliness. T 1 is the paamete that sets the multiplicative decease tem, wheeas T 0 is the paamete that sets the sensitivity of the potocol to RTT. The window incease is diven, fo RTT n T 0 (the typical case if T 0 ¼ 1 [28]), by the a facto and by the squae of the RTT. In this case, RTT-fainess is enfoced and the algoithm helps lage bandwidth-delay-poduct flows, by letting thei windows gow much faste than in TCP New Reno. If instead RTT n T 0 (a athe ae event whee pathological congestion o outing poblems ae affecting the connection), the window incease is diven by the a facto and the RTT; in this case, RTT-fainess is not peseved, yet, it is weighted only as the invese squae oot of the RTT Stability analysis As we have seen in the pevious section, paametes k 1 ; k 2 ; T 0, T 1 play an impotant ole in TCP Liba. We hee show, extending the stability analysis of TCP New Reno to TCP Liba, how they should be set. We will also undestand the impotance of the penalty facto in keeping the potocol within the asymptotic stability bounds. Let us conside a single TCP souce on a single link, whee the pobability of loss is modeled as the pobability of having a queue of length P b on a M/M/1 queuing system. Fom [26] we have that sufficient condition to achieve asymptotical local stability fo an AIMD potocol is: j g RTT ~ k 0 ~k < p 2 ; ð15þ whee j depends fom the paticula TCP scheme in the AIMD family. In the case of a TCP New Reno flow, j ¼ j NewReno ¼ a = g RTT 2 (we substitute a ¼ 1 fom now on): ~k 0 ~k < p g RTT 2 : ð16þ Let us now conside a TCP Liba flow. Fo a TCP Liba flow we have that j Liba ¼ j NewReno ^a ¼ a. 2 We substitute T 0 þf RTT this value in (15) and obtain: ~k 0 ~k < pð g RTT þ T 0 Þ 2a g RTT : ð17þ By satisfying the condition that holds fo TCP New Reno in (16), we find an uppe bound fo a. In paticula, a < 2 Hee we substitute a ¼ 1. ðrtt g þ T 0 Þ= RTT g 2 gives us the values of a fo which the stability egion of Liba is geate o equal than New Reno s. Recalling fom Section 4.1 that a ¼ Scalability Facto Penalty Facto, we see that the above bound gives a condition on k 2 once k 1 and T 0 ae fixed, and vice vesa. We deive the following fom (12) and (17):! k 2 > RTT max RTT min grtt RTT min log g RTT þ T 0 k 1 C g RTT 2 : ð18þ The above is clealy a qualitative analysis, since it elates to the simple case of a single link and a single flow, but it gives us the feeling of how a choice of k 1 ; k 2 and T 0 should be made. Specifically, two impotant consideations emege fom (18): an incease of k 1 should coespond to an incease of k 2 o T 0 in ode to keep the same stability bound as New Reno; as expected, highe values of C and g RTT stess the potocol and equie a highe value of k 2 to pevent potential aggessiveness of the tanspot potocol. The ole of k 2 can be appeciated in Figs. 1 and 2, whee we see the esults of a simulation pefomed in NS2. Two flows, with ound-tip popagation delay of 400 ms and 10 ms, espectively, in a dumbbell topology, compete on a 100 Mbps naow link. In the simulation elated to Fig. 1, we set k 1 ¼ 2; k 2 ¼ 2; T 0 ¼ 1, and T 1 ¼ 1 the two flows shae the link faily. Instead, in the simulation elated to Fig. 2 we set k 2 ¼ 0 (i.e., we omit the penalty function) and leave othe paametes unchanged. The second expeiment shows that without a penalty function (thus, simila to [19 21]) RTT-fainess is not peseved. Outcomes fom othe simulative configuations, implemented both in Matlab and NS2, allow us to obseve the behavio of two Liba flows as T 0 and k 1 incease (othe paametes ae set to the default values, T 1 ¼ 1 and k 2 ¼ 2). Specifically, we simulate two flows shaing a single 100 Mbps naow link: flow 1 and flow 2, with ound-tip popagation delays of 10 ms and 83 ms, espectively. In ou NS2 simulations, we have set the slow stat theshold to 1 and the packet size to 1500 Bytes. We have also consideed RED implemented on the bottleneck oute with the following paametes: l max ¼ 0:1; b ¼ 150 pkts; B ¼ 600 pkts, and queue aveaging weight = Results achieved by flow 1 in thee configuations employing diffeent T 0 and k 1 values ae epoted in Figs. 3 5; wheeas concuent esults of flow 2 ae shown in Figs In the thee simulative configuations the aveage thoughput achieved by each flow is about the same, egadless of the flow s ound-tip popagation delay. Indeed, stability is peseved by having utilized a constant T 0 =k 1 value. Moeove, a eduction of the instantaneous thoughput vaiance can be obseved when inceasing T 0 and k 1. This is coheent with what aleady obseved in [14]: the thoughput vaiance depends on the AIMD decease ule thus having highe T 0 values poducing the shown effect. We can also appoach the poblem fom the opposite diection. We fist set T 0 ¼ T 1 ¼ 1; k 1 ¼ 2; then, we esti-

6 2332 G. Mafia et al. / Compute Netwoks 54 (2010) Fig. 1. Thoughput of two flows, using a penalty function. Fig. 2. Thoughput of two flows, omitting the penalty function. mate the vaiables in a typical connection and use (18).We hee assume a 100 Mbps link speed with 100 ms one-way delay. The buffe is set to the pipe size, 833 packets fo a packet length set to 1500 Bytes. We also conside the case in which the link is congested, the aveage RTT is equal to the maximum RTT, g RTT ¼ RTTmax. Fom (18), we deive: k 2 > log 0:2 þ ð0:2þ 2! ¼ logð0:15þ ¼1:89: ð19þ Coheently, we have set k 2 ¼ 2 in ou simulations. We will see in Section 7 that the chosen set of values fo the TCP

7 G. Mafia et al. / Compute Netwoks 54 (2010) Fig. 3. Flow 1, with ound-tip popagation delay = 10 ms, competing with flow 2 on a 100 Mbps bottleneck. T 0 ¼ 1 and k 1 ¼ 2. Fig. 6. Flow 2, with ound-tip popagation delay = 83 ms, competing with flow 1 on a 100 Mbps bottleneck. T 0 ¼ 1 and k 1 ¼ 2. Fig. 4. Flow 1, with ound-tip popagation delay = 10 ms, competing with flow 2 on a 100 Mbps bottleneck. T 0 ¼ 4 and k 1 ¼ 8. Fig. 7. Flow 2, with ound-tip popagation delay = 83 ms, competing with flow 1 on a 100 Mbps bottleneck. T 0 ¼ 4 and k 1 ¼ 8. Fig. 5. Flow 1, with ound-tip popagation delay = 10 ms, competing with flow 2 on a 100 Mbps bottleneck. T 0 ¼ 8 and k 1 ¼ 16. Fig. 8. Flow 2, with ound-tip popagation delay = 83 ms, competing with flow 1 on a 100 Mbps bottleneck. T 0 ¼ 8 and k 1 ¼ 16.

8 2334 G. Mafia et al. / Compute Netwoks 54 (2010) Liba paametes shows a good tadeoff in all pefomance measues. As a esult of this discussion we can summaize that k 2 should be big enough to peseve stability. Similaly, we could incease also both T 0 and k 1 to the aim of peseving stability; instead, T 1 does not ente into the stability discussion, but a small T 1 will limit the thoughput vaiance (same effect on the decease ule of choosing a high T 0 ). Fom a lage numbe of simulations we obseved that k 2 has also anothe key effect: it tunes the fiendliness of TCP Liba to TCP New Reno. Fo this eason we have chosen k 2 ¼ 2, as it shows a good degee of fiendliness to TCP New Reno in a boad ange of netwok/taffic conditions. 5. RTT-fai schemes: model-based compaison Table 1 summaizes the qualitative behavio of TCP schemes in tems of RTT-fainess as can be deived also taking inspiation fom [6,11 15,22,29]. The key paamete to obseve is the steady state solution (i.e., the stable point). In Fig. 9 we plot Column III, fom the left, of Table 1. We ae hee assuming that: (i) the two flows expeience the same maximum queuing delay, RTT max RTT min ; (ii) grtt RTT min ; and (iii) the two flows have the same steady state pobability of loss and queuing delay. In Fig. 9 we plot the thoughput atio of two flows, with diffeent RTTs, which ae competing on the same naow link. In this figue, RTT 1 and RTT 2 epesent the aveage RTT of flow 1 and flow 2, espectively, wheeas x 1 and x 2 ae the aveage thoughput of flow 1 and flow 2. As we can see in Fig. 9, when the RTT of flow 1 (i.e., RTT 1 ) is equal to 100 ms, TCP Liba s esponse function is vey close to the constant incease algoithm. This means that, no matte what RTT atio is between flow 1 and flow 2, they will almost always achieve the same ate. When T 1 is equal to 500 ms, TCP Liba still impoves ove the linea behavio of TCP New Reno. Likewise, [28] poves though measuements that 50% of the TCP flows expeience a RTT equal to o below 100 ms. Theefoe, TCP Liba pefoms as a constant incease algoithm in the geat majoity of cases. This appoach is a tadeoff between fainess and stability. Fainess is affected by including the RTT, as shown in Fig. 9; howeve, fo ealistic RTTs, TCP Liba behaves vey closely to a constant RTT algoithm and peseves RTTfainess. Fom the steady state solution, it is evident how TCP New Reno implements linea RTT-fainess; the thoughput that a connection may expect depends invesely fom the aveage RTT of the connection. Table 1 Dynamic and equilibium popeties. Algoithm Stable point ~x 1 =~x 2 Stepsize Maginal utility Congestion measue qffiffiffiffiffiffiffiffiffiffiffiffi NewReno 1 a 1 ~ k / f RTT 2 b x 2 b frtt ~k ~ a ðtþþ 1 1 Loss pobability b f RTT1 RTT 2 frtt a 2 x2 qffiffiffiffiffiffiffiffiffiffiffiffi ðtþþ1 Hybla 1 a 1 ~ k / 1 b a T x2 0 b ~k a ðtþþ 1 1 Loss pobability T 2 b 0 a T2 0 x2 ðtþþ1 Vegas 1 ~/ / Queueing delay et 2 x Liba qffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi a a 1 k ~ b T1 ~k / e k 2 2 ð f RTT 1 f RTT 2Þ b T 1 x 2 a ~a ðtþþ frtt þt0 frtt þt0 1 b T 1 a ~a x2 ðtþþ1 Loss pob. and queuing delay Fainess Hybla, Vegas Liba, RTT1=0.1 Liba, RTT1=0.5 Liba, RTT1=1 Reno 1 Thoughput Ratio (x1/x2) RTT2/RTT1 Fig. 9. Thoughput atio between two flows, fo vaying RTT atios.

9 G. Mafia et al. / Compute Netwoks 54 (2010) TCP Hybla is a constant incease algoithm that foces all flows to act as if they saw the same RTT: in fact, Table 1 shows that the stable point does not depend on the RTT, but on T 0, which is constant fo all flows. In this way the algoithm is ideally fai as we see in Fig. 9. Yet, in [14], though a stability analysis, it is highlighted that constant incease algoithms expeience delay instability on outes whee atio RTT =x is lage and slow convegence on outes whee the atio is small. To confim this statement, extensive simulation esults in Section 6 show how this poblem can lead to unfainess. TCP Vegas implements an RTT-fai scheme. Fom simulation esults we veify that TCP Vegas impoves TCP s RTTfainess. Howeve, the poblem of TCP Vegas is the choice of congestion measue, namely, queuing delay. This measue makes TCP Vegas too timid while competing with TCP New Reno (o with simila legacy potocols: see esults about TCP SACK in Section 6). Finally, Fig. 9 shows that TCP Liba is not constant RTTfai as TCP Vegas o TCP Hybla, but it appoaches such limit as RTT 1 appoaches zeo and it theoetically impoves TCP New Reno. Futhemoe, in Section 6 we show how TCP Liba s algoithm esults both RTT-fai and fiendly towads TCP New Reno, with a choice of paametes that woks fo a boad set of tests, wheeas othe RTT-fai potocols do not. 6. Pefomance evaluation We have used the NS2 platfom to evaluate TCP Liba [30]. We have divided ou expeiment campaign into thee main sets. In the fist one, we have ceated a simple simulative scenaio, i.e., a dumbbell topology, and consideed the potocols discussed and modeled in the pevious sections: (i) TCP New Reno (with the SACK option enabled, i.e., TCP SACK), (ii) ou TCP Liba, and othe RTT-fai TCP vesions such as (iii) TCP Vegas, and (iv) TCP Hybla; futhemoe, we have also added CUBIC as this potocol epesents the default TCP vesion on cuent Linux eleases (since kenel [31]). Fo TCP SACK and Vegas, we have used existing NS2 modules; fo TCP Hybla and CUBIC we have used the code povided by thei espective developes; and we have ceated ou own module fo TCP Liba. Default paametes have been changed in the case of TCP Vegas as inspied by the liteatue [32]. The pupose of this fist set of expeiments is that of achieving deep undestanding of potocols discussed in Section 5 (including TCP Liba), confiming thei popeties in a contolled and noise fee scenaio. Instead, the aim of the second set of expeiments is that of testing TCP Liba in a highly ealistic simulative scenaio, as simila as possible to the eal wold. We have hence taken lage inspiation fom [33] and ceated a complex scenaio with backgound coss taffic, diffeent queue sizes, and both dop-tail and RED queue management. The impotance of including backgound taffic lies in its ability to pevent phase effects and in its impact on the fainess and convegence of the potocols [33,34]. The pesence of backgound taffic causes noise in the RTT measuements, which ae an impotant component of TCP Liba s algoithm; we have hence to conside also this facto in ode to enhance the tustwothiness of achieved esults. Finally, as a confimation fo excellent simulative esults achieved by ou TCP Liba, we have tested ou tanspot potocol even in a eal netwok testbed scenaio. Real expeiments ae geneally moe difficult to be pefomed than simulations. Yet, they embody an univaled testbed scenaio as no simulation can geneate the same ealism. In the following subsections, we pesent the thee afoementioned expeiment settings in detail. Whee not diffeently stated, TCP packet size has been set equal to 1500 Bytes, all simulations have been un fo 1000 s in ode to each steady state, and the advetised window fo each connection has been set lage than the coesponding pipe size so that occasional packets may be dopped, even when that connection is the only active one Expeiment setting #1 The simulated netwok topology fo the fist set of expeiments is epoted in Fig. 10. Fou FTP connections ae established between the souce destination pais (S i and R i shown in Fig. 10). The pais S 1 R 1 and S 2 R 2 have ound-tip popagation delay equal to 40 ms, thus epesenting inta-continental links. The pais S 3 R 3 and S 4 R 4 have ound-tip popagation delay equal to 161 ms, epesenting inte-continental links. The link X Y embodies the shaed naow link. The buffe size in node X is set eithe with a value suggested fo Cisco Systems outes (i.e., 200 o 500 packets [35]), o as the poduct of the naow link capacity by the lagest ound-tip popagation delay (i.e., 161 ms in most of the simulations) divided by packet size. In the emainde of this pape we efe to this latte value as the longest pipe size. In this context, we focus on the following pefomance measues: (1) inta-potocol RTT-fainess (Section 7.1); (2) inte-potocol RTT-fainess (Section 7.2); (3) scalability of TCP Liba to many flows (Section 7.3). S3 S4 S1 S2 X Y R1 R2 R3 R4 Fig. 10. Dumbbell topology fo expeiment setting #1.

10 2336 G. Mafia et al. / Compute Netwoks 54 (2010) S 1 R 1 S1 S 2 R 2 R 1 flows 1, 2-RTT180ms S 2 fowad R 2 B 1 X 10ms 100Mbps backwad Y C 3 S 3 S 4 flows 3, 4 - RTT 90ms R 4 R 3 100Mbps Bottlenecks X 2 X 3 X 4 X 5 X 6 X 7 X 8 X 1 B N 6.2. Expeiment setting #2 In the second expeiment setting, we compae again the same set of tanspot potocols consideed in the fist set of expeiments. Howeve, we focus on two diffeent topologies, each featuing diffeent scenaios. Fist, we have consideed again the dumbbell topology; but, in this case, we have adapted the simulation scipt povided on the BIC/CUBIC website [31]. We have chosen those scipts as they impove the classic dumbbell topology by including backgound taffic. Indeed, each link is configued to have diffeent RTTs and diffeent stat times and end times to educe the phase effect [36,34]. Being moe pecise with the help of Fig. 11, the one way popagation delay on the links is 21 ms fo the shot connections (fom S 2 to R 2 and between B i and C i ) and 119 ms fo the longest one (fom S 1 to R 1 ). Backgound taffic flows in both diections between nodes B i to C i. This backgound taffic is composed by 4 fowad egula long-lived TCP SACK flows, 4 backwad egula long-lived TCP SACK flows, 25 small TCP flows with advetised window limited to 64 segments and an amount of web taffic in both diections able to occupy fom 20% to 50% of the available bottleneck link capacity when no othe flow is pesent [24,31]. Second, following the suggestions povided in [33] about consideing diffeent netwok topologies in simulative expeiments, we have consideed also the so called paking lot topology (see Fig. 12). In paticula, this topology includes eight end-to-end flows: flows 1 and 2 have 180 ms of minimum RTT and tavese 9 links; flows 3 and 4 have 90 ms of minimum RTT and tavese 9 links too. The emaining flows, 5 8, ae shot flows; they utilize 3 link paths with 30 ms minimum RTT. To ovecome phase effects, flows wee stated at andom times within the fist 5 s of simulation [36]. The bottleneck buffe can take two diffeent values: (a) the numbe of packets that would fill the bottleneck link o (b) the packets that would fill the longest path. Space limitations allow us to pesent only a subset of the obtained simulation esults. Theefoe, we epot hee only on esults elated to the case with a 100 Mbps bottleneck link, since the use of othe bandwidth values did not show significant diffeence. Results obtained though this expeiment setting ae discussed in Section 7.4. C N Fig. 11. Dumbbell topology fo expeiment setting # Expeiment setting #3 Afte the compehensive simulative compaison of diffeent TCP potocols, we also povide esults attained though a eal testbed evaluation. The test has been conducted compaing TCP Liba against legacy TCP SACK. The testbed is simply composed of two end hosts and a dummynet bidge. The two end hosts un Linux Kenel , wheeas the bidge uns FeeBSD 6.1 with kenel polling enabled and Dummynet [37] configued to simulate a 100 Mbps link with a 250 packets queue size. As fo the one-way popagation delays, 100, 150, and 200 ms have been set associating diffeent delays to diffeent pots. Finally, Ipef has been used to geneate the netwok load. Each expeiment has been un fo 900 s and, duing this time, thee concuent TCP flows using the same tanspot potocol ente and exit at diffeent times: a 150 ms oneway popagation delay flow uns fom the beginning to the end, a 100 ms one is active duing the s time fame, and a 200 ms one tansmits between 360 and 540 s. Ou compaison aims at expeimentally confiming: (i) the unfainess poblem of legacy TCP potocols and (ii) TCP Liba flows capability to convege to an equal shae, even when expeiencing vey diffeent popagation delays. Results obtained though this expeiment setting ae shown in Section Results S 5 R 5 S 6 R 6 S 7 R 7 S 8 R 8 flows 5, 6, 7, 8 - RTT 30ms Fig. 12. Paking lot topology fo expeiment setting #2. In this section we pesent the outcome of the expeiment settings discussed in Section 6. In paticula, Sections 7.1, 7.2, and 7.3 efe to the simple simulative setting discussed in Sections 6.1, 7.4 efes to the complex simulative setting discussed in Sections 6.2 and 7.5 efes to the eal testbed expeiment setting discussed in Section Expeiment setting #1: inta-potocol fainess Jain s Fainess Index is adopted in the liteatue to evaluate the fainess degee of data flows that shae a single naow link [38]. We have computed its value fo the

11 G. Mafia et al. / Compute Netwoks 54 (2010) Fig. 13. Jain s Fainess Index vs. naow link capacity fo TCP SACK, TCP Vegas, CUBIC, TCP Hybla, and TCP Liba. Buffe size at the naow link is equal to the longest link pipe size. Fig. 15. SLAC Asymmety Index [39]. Buffe size at the naow link is equal to the longest link pipe size. Fig. 14. Jain s Fainess Index vs. naow link capacity fo TCP SACK, TCP Vegas, CUBIC, TCP Hybla, and TCP Liba. Buffe size at the naow link is equal to 200 packets: suggested default value in the CISCO Systems configuation manual(s) [35]. tested potocols while consideing diffeent naow link capacities and buffe sizes. In Fig. 13 the buffe size is set equal to the longest pipe size, while in Fig. 14 the buffe size coesponds to 200 packets. TCP Liba shows a bette RTT-fainess than its competitos in almost all the consideed scenaios. An exception is TCP Hybla that shows a slightly bette RTT-fainess fo a naow link of 80 Mbps and 160 Mbps, and 200-packet buffe. Indeed, TCP Hybla was specifically intended to be RTT-fai though popotionally inceasing the congestion window of long-rtt flows so as to make them behave like a efeence-rtt (i.e., 25 ms) flow. Howeve, this solution woks if the queuing delay of buffes along the path does not significantly modify the atio between the minimum RTTs of the vaious flows. This means that TCP Hybla can ensue RTT-fainess in case of big pipes and small buffes, simultaneously pesent, as demonstated by the chats Expeiment setting #1: inte-potocol fainess (Fiendliness) We hee evaluate the case whee a TCP vaiant competes on the same naow link with legacy TCP SACK flows. In this setting TCP SACK is used fo one shot ound-tip Fig. 16. SLAC Asymmety Index [39]. Buffe size at the naow link is equal to 200 packets [35]. popagation delay flow (fom S2 to R2 in Fig. 10) and one long ound-tip popagation delay flow (fom S4 to R4 in Fig. 10), while the emaining two concuent flows ae diven by one of the othe TCP flavos. This allows us to investigate the impact of the coexistence on the RTT-fainess degee and the fiendliness of the altenative TCP vesions towads TCP SACK. The SLAC Asymmety Index [39] is used as the fiendliness metic; this index is defined as: A ¼ x 1 x 2 x 1 þ x 2 ; ð20þ whee x 1 and x 2 coespond to the aveage thoughput values achieved by two diffeent potocols competing fo the same channel. The index can be employed to linealy indicate the degee of aggessiveness between two potocols. In essence, when A ¼ 0, the two potocols evenly shae the naow link. Convesely, A > 0 indicates that x 1 is moe aggessive than x 2, wheeas A < 0 implies the invese situation. In Figs. 15 and Fig. 16 we epot the SLAC Asymmety Index when TCP SACK is coexisting altenatively with TCP Vegas, CUBIC, TCP Hybla, and TCP Liba. In the coesponding simulation, two TCP SACK flows with ound-tip

12 2338 G. Mafia et al. / Compute Netwoks 54 (2010) popagation delays set to 40 ms and 161 ms, espectively, compete with two othe flows (again, with ound-tip popagation delays set to 40 ms and 161 ms). An index value equal to zeo means pefect fiendliness; an index value lowe than zeo means that the consideed tanspot potocol is moe consevative than TCP SACK when coexisting; an index value highe than zeo means that the consideed tanspot potocols is moe aggessive than TCP SACK when coexisting. In Fig. 15 the buffe size is set to the longest pipe size (2133 packets), wheeas in Fig. 16 the buffe size is much smalle: 200 packets, as suggested default value in the CISCO Systems configuation manual (s) [35]. The chats show that when TCP Vegas competes against TCP SACK, the latte is able to each highe thoughputs (the Asymmety Index fo TCP Vegas is: A < 0). This was expected; indeed, when TCP Vegas detects that a queue is building up, it educes the tansmission ate. Instead, TCP SACK keeps pobing the channel and gaining shaes of bandwidth. As a consequence, TCP Vegas quickly bings its congestion window to a low value, thus achieving a low thoughput level. Convesely, TCP Hybla shows aggessiveness towads TCP SACK, thus using most of the bandwidth and educing TCP SACK s thoughput. In fact, TCP Hybla s Asymmety Index is positive in all cases. This is coheent with the fact that TCP Hybla inceases its tansmission ate as if it wee expeiencing a pe-defined RTT value (i.e., 25 ms [22]), ignoing the factual RTT value. Since the competing TCP SACK flows see a ound-tip popagation delay of 40 ms and 161 ms, thei bandwidth shae is obviously less than the bandwidth shae of TCP Hybla flows. When competing with concuent TCP SACK flows, CU- BIC is neithe as consevative as TCP Vegas, no as aggessive as TCP Hybla. Howeve, in geneal, TCP Liba showed an even bette fiendliness degee. In summay, TCP Liba shows to be able to faily shae the available bandwidth with TCP SACK. The only configuation whee anothe potocol (i.e., CUBIC) achieves a bette asymmety index than TCP Liba is when a small buffe of 200 packets is employed in combination with a 160 Mbps naow link (see the ightmost seies of columns in Fig. 16). As a final note, we have to epot that TCP Liba also attained inta-potocol fainess when coexisting with TCP SACK. In fact, the simulation esults showed that the two TCP Liba connections tend to achieve the same thoughput, which is close to the mean thoughput of the two TCP SACK connections Expeiment setting #1: TCP Liba scalability discussion We hee study how TCP Liba scales in elation to the numbe of flows shaing the same naow link. To this aim, we have set the dumbbell configuation pesented in Fig. 10 with a naow link of 622 Mbps (i.e., an OC12 link). We pefom thee expeiments involving 110 contempoaneous flows each. The ound-tip popagation delay is set to the following values: 16 ms fo 30 flows (i.e., a egional connection); 61 ms fo 60 flows (i.e., an inta-continental connection); 181 ms fo 20 flows (i.e., an inte-continental connection). TCP SACK pefomance is shown in Fig. 17 in tems of acknowledged packets pe time fo each of the 110 simulated flows. As expected, TCP SACK is affected by heavy Fig. 17. Acknowledged packets fo TCP SACK. Naow link of 622Mbps (i.e., OC12), 110 flows with heteogeneous RTTs. Buffe size at the naow link has been set equal to 500 packets: suggested default value fo high speed coe outes in the CISCO Systems configuation manual (s) [35].

13 G. Mafia et al. / Compute Netwoks 54 (2010) Fig. 18. Acknowledged packets fo TCP Liba with k 2 ¼ 2. Naow link of 622 Mbps (i.e., OC12), 110 flows with heteogeneous RTTs. Buffe size at the naow link has been set equal to 500 packets: suggested default value fo high speed coe outes in the CISCO Systems configuation manual (s) [35]. Fig. 19. Acknowledged packets fo TCP Liba with k 2 ¼ 12. Naow link of 622 Mbps (i.e., OC12), 110 flows with heteogeneous RTTs. Buffe size at the naow has been set equal to 500 packets: suggested default value fo high speed coe outes in the CISCO Systems configuation manual (s) [35]. RTT-unfainess and geneates thee distinct clustes of lines with a wide gap in between. Using the same expeiment scenaio and metic, we evaluate TCP Liba s pefomance. In paticula, Fig. 18 and Fig. 19 show TCP Liba s esults when employing k 2 ¼ 2 o k 2 ¼ 12, espectively. As it is evident fom the chats, both with k 2 ¼ 2 and with k 2 ¼ 12, TCP Liba achieves a bette RTT-fainess degee among its flows than TCP SACK does. Yet, in this simulative

14 2340 G. Mafia et al. / Compute Netwoks 54 (2010) configuation, Fig. 19 shows a bette fainess than Fig. 18. This outcome can be explained though the fact that in the configuation efeing to Fig. 19 TCP Liba opeates at the boundaies of its stability egion defined by (18); by inceasing k 2 fom 2 to 12, it safely etuns to stability and achieves a good RTT-fainess level as shown by Fig Expeiment setting #2: complex simulative scenaios In this subsection we compae the pefomance of the consideed tanspot potocols, utilizing the complex simulative configuation explained in Section 6.2. We stat with the dumbbell topology including also a significant amount of backgound taffic, both fowad and backwad. Fo the sake of conciseness, we show hee only the outcome fo the case in which the bottleneck buffe is small (i.e., equal to bottleneck link pipe size): the most demanding case fo the tanspot potocols. Two diffeent queuing policies ae tested: dop tail and RED (Random Ealy Detection). The Jain s index values ae epoted in Fig. 20. Clealy, TCP Liba and TCP Hybla outpefom the othe potocols in tems of povided RTT-fainess; among the othe potocols, CUBIC pefoms bette than TCP Vegas and TCP SACK. Results in Fig. 20 also confim the patial RTT-independency of CUBIC we mentioned in Section 2. This potocol ties to decouple the window gowth fom the etuning ACK pocess. With CUBIC, the window size is a function of the time elapsed since the last packet loss, thus allowing highe efficiency (in tems of total bandwidth utilization) in case of long fat RTTs and educing the thoughput dependency fom the RTT. Yet, this smat solution is not able to completely eliminate the RTT-unfainess as, even if the window size becomes independent fom the RTT, the final thoughput does not. The thoughput still coesponds to the atio between the window size and the RTT, whee two flows with simila packet loss tend may have the same window but diffeent RTTs. Fo instance, if we link the window size to the time elapsed since the last packet loss, two flows with diffeent RTTs (say, RTT 1 and RTT 2 ) but same time elapsed since the last loss may have the same window (say, W). This implies that W bytes ae sent in RTT 1 and RTT 2 seconds by the two flows, espectively, befoe sending out anothe window of data. As evident, even with the same window the thoughputs will be diffeent. Of couse, this is bette than using egula TCP as, in that case, we also have lage windows fo smalle RTT flows. Instead, TCP Liba appoach ties to eliminate the RTT-bias by having a highe window gowing ate fo flows with longe RTT. In this way, if RTT 1 < RTT 2, the two windows (W 1 and W 2 ) will be computed so that W 1 < W 2. This impoves the RTT-fainess with espect to CUBIC. On the othe hand, ou solution is not specifically designed fo long fat pipes thus esulting less efficient in tems of total bandwidth utilization. Anothe inteesting popety shown in Fig. 20 is that RED impoves fainess; this esult is a consequence of the fact that RED was indeed designed to pevent captue by aggessive flows. Focusing on the paking lot topology, in Fig. 21 we epot the Jain s index values consideing fo its computation only flows 1 4. Both the bottleneck pipe size and the longest pipe size have been consideed as the bottleneck buffe size. As evident, TCP Liba is the only potocol among the consideed ones that povides good fainess in both cases. Indeed, the penalty facto in Liba adapts the window incease slope to the elative backlog time, thus educing sensitivity to buffe size. The chat also shows a high Jain s index fo TCP SACK in the case with the longest pipe as buffe size. This appaently supising esult is indeed due to the fact that the flows 5 8 (i.e., the shot- Fig. 21. Jain s index values among flows 1 4, fo each diffeent potocol; paking lot topology. Fig. 20. Jain s index values achieved by the evaluated potocol while competing with a lage amount of concuent taffic. Fig. 22. Jain s index computed ove all the 8 connections; paking lot topology.

15 G. Mafia et al. / Compute Netwoks 54 (2010) Fig. 23. Efficiency in the paking lot topology. Fig. 24. Fiendliness evaluation. Goodput achieved by TCP SACK flows (on y-axis) when anothe tanspot potocol (on x-axis) is suppoting half of the concuent flows. RTT flows) captue the whole bandwidth thus leaving flows 1 4 with vey low (and simila) bandwidth. This is confimed by the Jain s index esulting when consideing both shot RTT connections 5 8 and longe RTT connections 1 4 (see Fig. 22). A significant fluctuation of fainess index is noted and TCP SACK, which had an acceptable Jain s index if computing only the goodputs of connections 1 4, obtains a vey poo value when consideing all the eight connections togethe. The thoughput efficiency on the fist bottleneck of the paking lot topology is shown in Fig. 23. TCP Liba s utilization of the fist bottleneck is somehow consevative to allow the shot flows on subsequent bottlenecks to bette exploit the shaed channel and achieve a bette fainess. Futhemoe, as expected, the utilization of the available bandwidth inceases with the buffe size, fo all potocols. Finally, the coexistence between the legacy TCP (i.e., TCP SACK) and the new potocols is evaluated in Fig. 24. The ba chat pesents the elative TCP SACK goodputs when TCP SACK is competing with itself fist, and then with each of the new potocols. We measue the TCP SACK goodput achieved in each of the RTT flow classes (long to shot) as well as the aggegate goodput ove all of its connections. Moe pecisely, TCP SACK was used fo flows 2 (180 ms of RTT), 4 (90 ms of RTT), 6 and 8 (30 ms of RTT each), while the new potocol was used fo flows 1 (180 ms of RTT), 3 (90 ms of RTT), 5 and 7 (30 ms of RTT each). As expected, when coexisting with TCP Vegas, TCP SACK achieves a slight incease in its achieved goodput, wheeas the aggessive behavio of TCP Hybla penalizes concuent TCP SACK flows. CUBIC and TCP Liba do not ham significantly concuent TCP SACK flows. In paticula, CUBIC shows a balanced behavio towad TCP SACK, wheeas Fig. 25. Dynamic Scenaio: instantaneous thoughput of thee TCP SACK flows.

16 2342 G. Mafia et al. / Compute Netwoks 54 (2010) Fig. 26. Dynamic Scenaio: instantaneous thoughput of thee TCP Liba flows. the aggegate thoughput of the TCP SACK flows diminishes by 11% when coexisting with TCP Liba. Howeve, thee is a desiable, even if limited, edistibution of the TCP SACK goodput fom the 30 ms RTT flows to the 90 ms and 180 ms RTT ones when coexisting with TCP Liba flows; hence, TCP Liba seems to help the coexisting TCP SACK flows by (slightly) impoving thei fainess degee Expeiment setting #3: eal testbed expeiments In this subsection we compae the pefomance of ou TCP Liba against a legacy TCP vesion, TCP SACK, utilizing the eal expeiment testbed discussed in Section 6.3. In Figs. 25 and 26, we depict the instantaneous thoughput achieved by thee concuent TCP flows when employing one of the two tanspot potocols we ae consideing fo compaison: TCP SACK and TCP Liba, espectively. In each of the chats it is possible to clealy see the diffeent activity peiods of the thee flows. In summay, the smallest RTT flow stats (and ends) fo second, wheeas the longest RTT flow stats (and ends) fo thid. It is hence inteesting to see whethe the employed tanspot potocol pivileges one of the flows o behaves faily. To this aim, Fig. 25 confims how TCP SACK geneates a RTT-unfai shae of the available bandwidth. Indeed, the flow with the smallest RTT unfaily captues most of the shaed bandwidth as soon as it stats tansmissions. Moeove, as expected, the flow having longe RTTs ae chaacteized by a slowly gowing instantaneous thoughput. Instead, Fig. 26 depicts the behavio of TCP Liba flows in the same scenaio. Regadless of the RTT and of the stat/end time, all the thee flows convege to an equal shae of the bandwidth esouce when coexisting. This is clealy visible in the chat aound 500 s, when the thee flows have vey simila thoughput values and gowth ates. Even befoe, fom 200 s to 350 s, when only two flows whee competing fo the shaed bandwidth, they have vey simila thoughput and tend. Theefoe, compaing these two peliminay eal-testbed evaluations, it is evident how TCP Liba confims its ability in eaching the fai shae of the channel, even in dynamic conditions and egadless of RTT diffeences. These expeimental esults ae coheent with what we have obtained though dumbbell topology simulation in Fig. 20, in the case with dop tail queue management of the buffe, which is the simulation configuation that moe closely esembles the setting of ou eal testbed. 8. Conclusions and futue wok This pape analyzes TCP Liba, a new potocol designed to be RTT-fai while maintaining a good fiendliness towads legacy TCP and poviding bandwidth scalability. We have showed how TCP Liba can be analytically deived fom TCP New Reno, explained the diffeences with pevious appoaches aimed at building an RTT-fai TCP, and analyzed its stability bounds. Futhemoe, we have also expeimentally confimed TCP Liba s qualities, compaing it against othe RTT-fai TCPs in diffeent simulative settings and in demanding scenaios, even consideing an OC12 link shaed by moe than a hunded of concuent flows. Finally, we have also povided peliminay esults of a eal testbed implementation based on Linux stack that confims the efficacy of ou new potocol. In summay, we have pesented hee a eally compehensive evaluation of the inteesting popeties possessed by TCP Liba, exploiting model analysis, simulations, and

17 G. Mafia et al. / Compute Netwoks 54 (2010) eal testbed expeiments, wheeas the vast majoity of papes in the liteatue conside only one o two among these thee methods. The encouaging esults achieved stongly motivate us in continuing this wok to deploy a final poduct that could be factually exploited to impove the Intenet. Refeences [1] V. Jacobson, Congestion avoidance and contol, in: ACM SIGCOMM 88, Stanfod, CA, USA, August [2] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, Rfc2018: TCP selective acknowledgment options, Netwok Woking Goup, Technical Repot, [3] R. Jain, A delay based appoach fo congestion avoidance in inteconnected heteogeneous compute netwoks, Compute Communications Review, ACM SIGCOMM, vol. 19, Octobe 1989, pp [4] J. Matin, A.A. Nilsson, I. Rhee, The incemental deployability of RTTbased congestion avoidance fo high speed TCP intenet connections, in: ACM SIGMETRICS 2000, Santa Claa, CA, USA, June [5] R.S. Pasad, M. Jain, C. Dovolis, On the effectiveness of delay-based congestion avoidance, in: 2nd Intenational Wokshop on Potocols fo Fast Long-Distance Netwoks, Agonne National Laboatoy Agonne, IL, USA, Febuay [6] L.S. Bakmo, S.W. O Malley, L.L. Peteson, TCP vegas: New techniques fo congestion detection and avoidance, in: SIGCOMM 94, London, UK, August Septembe [7] Z. Wang, J. Cowcoft, Eliminating peiodic packet losses in the 4.3- tahoe BSD TCP congestion contol algoithm, ACM Compute Communication Review 22 (1992) [8] C. Jin, D. Wei, S. Low, Fast TCP: motivation, achitectue, algoithms, pefomance, in: IEEE INFOCOM 2004, Hong Kong, China, Mach [9] C. Jin, D. Wei, S.H. Low, G. Buhmaste, J. Bunn, D.H. Choe, R.L.A. Cottell, J.C. Doyle, W.C. Feng, O. Matin, H. Newman, F. Paganini, S. Ravot, S. Singh, Fast TCP: fom backgound theoy to expeiments, IEEE Netwok 19 (2005) [10] G. Mafia, C.E. Palazzi, G. Pau, M. Gela, M. Sanadidi, M. Roccetti, TCP Liba: exploing RTT-fainess fo TCP, in: IFIP/TC6 Netwoking Confeence, NETWORKING 2007, Atlanta, GA, USA, May [11] J. Padhye, V. Fioiu, D. Towsley, J. Kuose, Modeling TCP thoughput: a simple model and its empiical validation, in: ACM SIGCOMM 98, Vancouve, BC, Canada, August Septembe [12] F.P. Kelly, A.K. Maulloo, D.K.H. Tan, Rate contol in communication netwoks: shadow pices, popotional fainess, and stability, Jounal of the Opeational Reseach Society 49 (1998). [13] R. Gibbens, F. Kelly, Resouce picing and the evolution of congestion contol, Automatica 35 (12) (1999) [14] F. Kelly, Mathematical modelling of the intenet, in: Bjon Engquist, Wilfied Schmid (Eds.), Mathematics Unlimited 2001 and Beyond@Spinge, [15] F. Kelly, Fainess and stability of end-to-end congestion contol, Euopean Jounal of Contol 9 (2003) [16] F. Paganini, Z. Wang, S. Low, J.C. Doyle, A new TCP/AQM fo stable opeation in fast netwoks, in: IEEE INFOCOM 2003, San Fancisco, CA, USA, Mach Apil [17] S. Athualiya, D.E. Lapsley, S.H. Low, An enhanced andom ealy making algoithm fo intenet flow contol, in: IEEE INFOCOM 2000, Tel Aviv, Isael, Mach [18] S. Low, R. Sikant, A mathematical famewok fo designing a lowloss, low-delay intenet, Netwoks and Spatial Economics 4 (2003) [19] S. Floyd, V. Jacobson, Taffic phase effects in packet-switched gateways, Intenetwoking: Reseach and Expeience 3 (1992) [20] T. Hendeson, Netwoking Ove Next-geneation Satellite Systems, Ph.D. Dissetation, Univesity of Califonia, Bekeley, [21] T.R. Hendeson, R.H. Katz, Tanspot potocols fo intenetcompatible satellite netwoks, IEEE Jounal on Selected Aeas in Communications 17 (1999) [22] C. Caini, R. Feincelli, TCP Hybla: a TCP enhancement fo heteogeneous netwoks, Intenational Jounal of Satellite Communications and Netwoking 22 (2004) [23] I. Rhee, L. Xu, Cubic: a new TCP-fiendly high-speed TCP vaiant, in: 3d Intenational Wokshop on Potocols fo Fast Long-Distance Netwoks, Lyon, Fance, Febuay [24] L. Xu, K. Hafous, I. Rhee, Binay incease congestion contol fo fast, long distance netwoks, in: IEEE INFOCOM, 2004, Hong Kong, China, Mach [25] R. Shoten, D. Leith, H-TCP: TCP fo high-speed and long-distance netwoks TCP, in: Second Intenational Wokshop on Potocols fo Fast Long-distance Netwoks, Agonne, IL, USA, Febuay [26] R. Sikant, The Mathematics of Intenet Congestion Contol, A Bikhause Book, [27] D.P. Betsekas, Nonlinea Pogamming, Athena Scientific, [28] J. Aikat, J. Kau, F.D. Smith, K. Jeffay, Vaiability in TCP ound-tip times, in: 3d ACM SIGCOMM Confeence on Intenet Measuement, New Yok, NY, USA, [29] L.A. Gieco, S. Mascolo, Pefomance evaluation and compaison of westwood+, new eno, and vegas TCP congestion contol, ACM Compute Communication Review 34 (2) (2004) [30] The vint poject, ns2, nsnam. [Online] < nsnam/>. [31] BIC and CUBIC potocol default TCP algoithm in linux. [Online]. Available: < [32] S.H. Low, L.L. Peteson, L. Wang, Undestanding TCP vegas: a duality model, in: SIGMETRICS/Pefomance, Cambidge, MA, USA, June [33] L. Andew, C. Macondes, S. Floyd, L. Dunn, R. Guillie, W. Gang, L. Egget, S. Ha, I. Rhee, Towads a common TCP evaluation suite, in: 6th Intenational Wokshop on Potocols fo FAST Long-Distance Netwoks (PFLDnet 2008), Mancheste, UK, [34] S. Mascolo, F. Vacica, The effect of evese taffic on TCP congestion contol algoithms, in: 4th Intenational Wokshop on Potocols fo Fast Long-distance Netwoks, Naa, Japan, Febuay [35] C.S. Inc. Buffe tuning fo all cisco outes document id: [Online] < [36] S. Floyd, E. Khole, Intenet eseach needs bette models, ACM SIGCOMM Compute Communication Review 33 (2003) [37] Dummynet home page. [Online] < dummynet/>. [38] R. Jain, D. Chiu, W. Hawe, A quantitative measue of fainess and discimination fo esouce allocation in shaed compute systems, DEC Reseach Labs, Technical Repot TR-301, [39] L. Cottell, H. Bullot, R. Hughes-Jones (2004, Febuay) Evaluation of advanced TCP stacks on fast long-distance poduction netwoks. Pesentation at SLAC, Stanfod. EPFL, SLAC and Mancheste Univesity. [Online]. < pfld-feb04.ppt>. Gustavo Mafia eceived a Lauea degee in Telecommunications Engineeing fom the Univesity of Pisa in He eceived a Ph.D. in Compute Science fom the Univesity of Califonia, Los Angeles, in He is cuently a Postdoctoal Reseache at the Depatment of Compute Science of the Univesity of Bologna. His eseach inteest include: ad hoc netwoks, tanspotation systems and multimedia steaming. Claudio E. Palazzi eceived the M.S. degee in compute science fom the Univesity of Califonia, Los Angeles (UCLA), in 2005, the Ph.D. degee in compute science fom the Univesity of Bologna, Bologna, Italy, in 2006, and the Ph.D. degee in compute science fom UCLA in 2007, though the joint Ph.D. Pogam in Compute Science oganized by the Univesity of Bologna and UCLA. His Ph.D. thesis was focused on inteactive online gaming ove wied/wieless netwoks. He is cuently an Assistant Pofesso with the Dipatimento di Matematica Pua e Applicata, Univesità degli Studi di Padova, Padova, Italy. His eseach is pimaily in the aea of potocol design and analysis fo wied/wieless netwoks, with emphasis on netwok-centic multimedia entetainment and vehicula netwoks. D. Palazzi was the ecipient of the Best Full Pape Awad at the 3d ACM Intenational Confeence on Compute Game Design and Technology and

18 2344 G. Mafia et al. / Compute Netwoks 54 (2010) the Best Pape Awad at the Euosis GAMEON 2007 Intenational Confeence fo his Ph.D. thesis. Giovanni Pau eceived the Italian Lauea degee in Compute Science and a Ph.D. in Compute Engineeing, both fom the Univesity of Bologna, Bologna, Italy. He is cuently a eseach scientist at UCLA. His aea of expetise includes mobile compute netwok envionment, fields in which he has coauthoed ove 60 technical efeeed papes. developing a Vehicula Testbed fo safe navigation, uban sensing and intelligent tanspot. A paallel eseach activity exploes pesonal communications fo coopeative, netwoked medical monitoing (see fo ecent publications). Maco Roccetti eceived the Italian Lauea degee in electonic engineeing fom the Univesity of Bologna, Bologna, Italy. He has been a Full Pofesso with the Dipatimento di Scienze dell Infomazione, Univesità di Bologna since His eseach inteests include digital audio and video, compute entetainment, and web-2.0-based applications, fields in which he has authoed almost 250 technical efeeed papes. Maio Gela is a Pofesso in the Compute Science at UCLA. He holds an Engineeing degee fom Politecnico di Milano, Italy and the Ph.D. degee fom UCLA. He became IEEE Fellow in At UCLA, he was pat of the team that developed the ealy ARPANET potocols unde the guidance of Pof. Leonad Kleinock. He joined the UCLA Faculty in At UCLA he has designed and implemented netwok potocols including ad hoc wieless clusteing, multicast (ODMRP and CODECast) and Intenet tanspot (TCP Westwood). He has lead the $12M, 6 yea ONR MINUTEMAN poject, designing the next geneation scalable aibone Intenet fo tactical and homeland defense scenaios. He is now leading two advanced wieless netwok pojects unde ARMY and IBM funding. His team is