TCP Libra: Exploring RTT-Fairness for TCP

Transcription

1 TCP Liba: Exploing RTT-Fainess fo TCP UCLA Compute Science Depatment Technical Repot #TR Gustavo Mafia, Claudio Palazzi, Giovanni Pau, Maio Gela, M. Y. Sanadidi, Maco Roccetti, Compute Science Depatment - Univesity of Califonia Los Angeles, CA {gmafia cpalazzi gpau gela medy}@cs.ucla.edu Dipatimento di Scienze del Infomazione, Univesity of Bologna - Italy occetti@cs.unibo.it Abstact The majoity of Intenet taffic elies on the Tansmission Contol Potocol (TCP ) devised in the ealy 970s to povide a eliable data tansfe acoss the ARPANET. Today s uses download lage multimedia files fom emote seves using TCP. If these TCP sessions shae the same bottleneck, they ae expected to eceive the same shae of bandwidth, thus achieving the same tansfe ate. Unfotunately, this is not the case when the ound tip delay RTT is vey diffeent among sessions. This may have negative pactical implications in downloads of delay-sensitive (though non-eal-time) infomation fom seves. Fo instance, suppose in a popula intenet cafè in New Yok City seveal uses ae simultaneously downloading multimedia files fom vaious seves. Most of the seves ae local. Howeve, one custome is downloading a lage file fom a emote seve in Austalia. All customes shae the same MBPS WiFi bottleneck. The custome connected to Austalia will make no visible pogess until all the customes downloading fom local seves ae done! One solution would be to set up a time day when only emote customes download. But this is not quite application tanspaent. Hee we popose a new vesion of TCP, namely TCP Liba, that guaantees fai shaing egadless of RTT. Liba in Latin means scale, thus indicating a balance between the sessions. In this pape we descibe the design of TCP Liba and pove that it is indeed RTT fai. The key element of TCP Liba is the window adjustment algoithm. The algoithm is deived by modeling TCP pefomance as a utility function and by optimizing this function such that the esult is independent of RTT, yet maintaining the function stability. Non-linea optimization is used, leading to a solution that povides fainess among TCP flows that shae the same bottleneck link egadless of RTT. The emakable popety of TCP Liba is that it achieves fainess while still maintaining thoughput efficiency and fiendliness with espect to TCP New Reno. Anothe impotant popety fom the implementation standpoint is the sende-side-only modification intoduced by TCP Liba. The fainess and stability popeties ae poved analytically and ae extensively tested via simulation. A compaison is also caied out with othe TCP vesions that have been epoted as RTT fai in the liteatue. I. INTRODUCTION The success of the Intenet is based on the ability to povide a eliable medium fo infomation exchange. In the cuent Intenet, taffic contol functionalities ae povided by the Tansmission Contol Potocol (TCP) in an end-to-end fashion. TCP was initially designed to povide a connection-oiented eliable sevice in the ARPANET [], and late, in the Intenet. TCP addesses two majo issues: eliability and congestion contol [2]. To achieve the second goal, TCP adapts the sending ate to avoid netwok oveflow o falling into sevice stavation. TCP congestion contol has been studied by the eseach community fo the last 25 yeas, leading to seveal TCP vaiants fo congestion contol with and without the explicit intevention of the netwok laye (a suvey can be found in [3]). This wok is patially suppoted by the Italian Ministy fo Reseach via the ICTP/E-Gid Initiative and the Intelink Initiative, the National Science Foundation though gants CNS /ANI , and the UC-Mico Gant MICRO pivate sponso STMicoelectonics. Liba is the Latin wod fo scale. This pape has been also submitted fo publication to the IEEE JSAC Special Issue on Non Linea Optimization. Refeence Autho: Giovanni Pau, Compute Science Depatment, Univesity of Califonia Los Angeles, CA 90095, gpau@cs.ucla.edu With TCP, unless specified, we efe to TCP New Reno.

2 2 The most popula vesion, TCP New Reno, implements a congestion contol algoithm, known as the AIMD (Additive Incease, Multiplicative Decease) algoithm. The vey basic concept can be summaized as follows: When a packet loss is detected, the TCP sende deceases its sending window by half. When a packet is successfully deliveed, it inceases its sending window by one. Natually, the TCP New Reno implementation goes well beyond the basic AIMD pinciple. To begin, if the packet loss is due to a timeout, the netwok is assumed to be seveely congested, hence the sending window is dastically educed to and a new slow-stat initiated. A sequence of thee duplicate acknowledgments indicates a mild congestion and leads to the Fast Retansmit and Fast Recovey algoithm followed by a congestion window eduction by half. The window incease ate slows down when a window theshold is eached fom one unit pe ACK eceived to one unit afte an entie RTT. In summay, the data-sending ate of TCP 2 is detemined by the ate of incoming acknowledgments (ACKs) to pevious packets. At a steady state, the sending ate of a TCP souce will match the aival ate of the elated ACKs. The congestion contol mechanisms tiggeed by a segment loss guaantees that the potocol automatically detects congestion buildup and thus deceases its sending ate. This behavio has been efeed to as TCPs self-clocking behavio. Unfotunately this self-egulation pocedue may be unfai. Expeimentally It has been obseved that competing TCP sendes, with diffeent end-to-end popagation delays, will typically have diffeent ates of feedback fom thei pees and will incease thei sending window at a diffeent pace. The diffeent incease ates of the sending windows (the faste, the shote the RTT between sende and eceive) detemine the RTT-bias o unfainess of TCP New Reno. This phenomena can also be analytically deived fom the fomula that models the TCP ate by Kuose in [4]. In paticula, it may be seen that competing flows will shae a bottleneck link based on the invese of thei ound-tip times. The RTT-bias has been ecognized fom ealy potocol deployment. In [5], the TCP New Reno authos poposed a solution to the potocol s RTTunfainess; unfotunately this has been found unstable by Hendeson stability studies in [6]. The RTT-bias shown by TCP negatively affects uses, content povides, and netwok povides. In paticula, uses with a lage RTT will expeience a lowe thoughput and highe latency and completion time. To ovecome this imbalance, content povides ae equied to use (fo a pice) a content delivey netwok with a fine-gain geogaphic distibution, whee content is downloaded off-line to sites elatively close to uses. The RTT-unfainess may also affect decisions on cache location, CDN deployment, ovelay netwoks topology, and capacity expansion [7]. In this pape we study the RTT-bias in TCP, appoaching the poblem fom a non-linea optimization and a system dynamics point of view. In paticula we leveage the seminal wok on TCP modeling done by Kelly, Vinniecombe, Low, Paganini and Doyle. Ou contibution lies in the design of a new utility function fo TCP that doesn t include RTT and theefoe is not sensitive to the self-clocking behavio. This esults in an enhanced congestion contol algoithm fo TCP. Ou scheme, namely TCP Liba (whee Liba in Latin means scale, i.e., balance, fainess), shows RTT-fainess as well as scalability (elated to netwok bottleneck size), and good fiendliness to TCP New Reno. The eminde of the pape is oganized as follows. In Section II we intoduce the cuent state of the at, while in Section III we pesent ou solution to the RTT-bias along with the dynamic and stability analysis fo TCP Liba, as well as seveal competing potocols. The simulation expeiments ae pesented in section IV and the pape is finally concluded by sections V. II. RELATED WORK In ecent yeas a lage amount of eseach has been conducted to undestand TCP behavio unde diffeent scenaios and netwok conditions. Paticulaly emakable ae the effots to povide a well-defined mathematical model suitable to study the behavio and stability of TCP and active queuing management (AQM) techniques in the Intenet. In this section we will epot the leading theoetical wok on congestion contol and AQM, focusing mainly on RTT-fainess and stability. The RTT-bias, as well as the busty natue of TCP taffic, was fist expeimentally discoveed by Sally Floyd and Van Jacobson in [5]. They also poposed a solution fo the RTT-bias based on a constant incease algoithm 2 We use as equivalents the tems congestion window, sending window, and data-sending ate.

3 3 fo the TCP window at steady state. In a futhe study they also intoduced a netwok laye technique, namely RED, designed as a elief fom the effects of taffic busts [8] [9]. Biefly, RED monitos the queue length at the outes and pobabilistically dops a andom TCP packet fom the queue upon eaching a cetain queue length thus leading to a moe egula taffic patten [0]. Hendeson in [] [6] shows that using constant incease and RED to achieve RTT-fainess leads to an unstable solution fo links with long popagation delays and small buffes such as satellite links. A detailed mathematical model fo the TCP thoughput at steady, including the the Fast Retansmit Fast Recovey phases and TCP s timeout impact, was fist intoduced by Towsley in [4] and [2]. Additionally, in [3] the same authos developed a new fluid based modeling methodology fo studying TCP behavio in a netwok that featues AQM outes. In paticula, the poposed appoach models TCP behavio that includes the tansient effects intoduced by AQM outes such as RED gateways. 3 A fesh impulse to congestion contol modeling in communication netwoks has to be acknowledged: Fank Kelly intoduced a new mathematical fomulation fo congestion contol in communication netwoks in tems of non-linea optimization poblem (pimal/dual). The netwok is modeled as an inteconnection of uses/souces which geneate data and esouces/links. The key constaint is that the netwok contol infomation can only be passed along the same outes as the data that is being tansmitted, and with the same popagation delay as data [4]. In [5] and [6] it was shown that TCP stability can be achieved in the afoementioned netwok model if the TCP utility function is concave [7] [7]. Kelly s esults have been extended by seveal eseaches. In paticula, Vinnicombe, Massoulie, Johai and Tan addessed the stability in netwok congestion contol schemes [8]. Vinnicombe showed that delay instability is chaacteized by the incease ule; while Ott has shown that stochastic instability is pimaily influenced by the decease ule [9] [20] [2]. Additionally Vinnicombe and Massoulie deived the stability condition fo scenaios with heteogeneous delays [22] [23]. A futhe substantial advancement in developing the theoy fo netwok congestion contol was made by Low, Paganini and Doyle. They fully exploited the Pimal/Dual modeling appoach, finding the conditions needed fo a scalable and stable congestion contol fo the Intenet [24] [25] [26] [27] [28] [29]. The theoetical esults have been used to dive the design of an enhanced AQM technique namely Random Ealy Mak (REM) that impoves RED pefomance while educing the dawbacks, and TCP Fast that contains a congestion contol mechanism, based pimaily on queuing time, able to guaantee netwok stability and high utilization in multi-gigabit netwoks [30], [3] [32] [33]. Focusing ou attention on the TCP RTT-bias it is woth noting that thee ae few ecent TCP vaiations that have tied to addess RTT-unfainess. In paticula, TCP CUBIC [34], developed by Noth Caolina Univesity, featues a linea RTT-faines, while TCP Hybla [35], that enhances the solution poposed by Floyd in [9], povides RTT-fainess unde a cetain stability bound, and TCP Vegas [36] that povides good RTT-vainess if it is the only TCP in the Netwok. In summay, in almost a decade new modeling techniques fo netwok congestion contol have been developed which offe a new set of mathematical tools fo undestanding scalability and stability limits of netwok algoithms and potocols. In paticula, netwok congestion contol has been modeled as a non-linea optimization poblem in which the pimal models the system as seen fom the souce/destination point of view, while the dual models the system as seen fom the esouce point of view. The use of this fomulation benefits theoetical studies of the system dynamics fom both netwok and tanspot layes. III. MODEL In this section we will fist descibe the netwok model and pesent the optimization poblem. We will then give a bief eview of TCP New Reno and TCP Vegas, and intoduce and analyze the TCP Hybla solution. We will finish consideing othe solutions by adding some comments on TCP CUBIC. Finally, we will show the steps in the design choices of TCP Liba and include a stability analysis, using a contol theoetic appoach. 3 The fluid model pesented in [3] shows, as a potential souce of instability, the RED adaptive sampling and aveaging algoithms. These algoithm, indeed, ae dependent on packet size and aival ates.

4 4 A. Netwok Model and Optimization Poblem The netwok is modeled as a finite set of nodes N and links L, which connect the nodes in N. Each link is chaacteized by a finite capacity. We define c as the vecto of capacities whee each ow (c l, l L) epesents the capacity of link l L. S is the set of souces that accesses netwok esouces, typically a subset of N and L. We may define the outing matix R as: {, if link l L is utilized by souce S R l = () 0, othewise Each souce S is chaacteized by x (t), the tansmission ate. The aggegateflow at link l is defined as the sum of the contibutions of the souces that use that link: y l (t) = R l x (t τ f l ) (2) whee τ 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. The pice is sent back to souce as a feedback signal by the link when congestion is detected. The pice(s) to which an algoithm is sensitive shapes its dynamics: TCP New Reno is, fo example, sensitive to packet loss, while TCP Vegas is sensitive to queueing delay. The aggegate pice seen by souce is: q (t) = R l p l (t τl b ) (3) l whee τ 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. The pice, also known as baie [37] is a function of the link flow. We define f l (y) as the pice fo sending taffic at ate y l = :l x on link l. Let s 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 tue advantage fo a use when sending at a cetain ate. The function that descibes this advantage, U (x ), is defined in economics as a Utility function. The utility function of a congestion contol scheme is vey impotant, since it detemines the equilibium popeties of the scheme, 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: max x V (x) (4) subject to: { R x c x 0, S, (5) whee V (x) = U (x ) P s:l s xs l 0 f l (y)dy. By definition P s:l s xs 0 f l (y)dy is the cost incued by esouce l when it pushes flow y though the netwok. Thus, V (x) is the net gain, i.e. net utility of souces x, which must be maximized. Theoem 3.: Unde the assumptions [38] [37]: ) 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 {x (0) 0}, the congestion contol algoithm: x = k (x )(U (x ) q (t)) (6) (whee q is the aggegate pice function defined ealie and k (x) is any non-deceasing, continuous function such that k (x) > 0, x > 0) will convege to the unique solution of (4) (5), x(t) ˆx as t. The left-hand side of (6) epesents the component of the gadient of V (x), to which the multiplicative tem k (x ) was added. Nomally, in the conventional gadient method, k (x ) =. Thee is no ham, howeve, in intoducing a non-deceasing function that acts as an amplificato of the gadient. The convegence point does not

5 5 change. The eason fo this tem will become cleae late when the utility function will be used to intepet vaious existing heuistic flow contol schemes. The deivative ẋ on the ight-hand side eflects the fact that in the gadient optimization method, the incemental change of x ove a unit time should be popotional to the value of the gadient. The detailed poof of convegence is found in [40]. The caeful eade, howeve, will notice that the function with the deivative shown on the ight hand side of (6) 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). This theoem is theefoe telling us that in the absence of feedback delay, any congestion contol algoithm that can be mapped into a concave utility function, attains global asymptotic stability. In the following sections we will show how the potocols that we use fo compaison fit into this famewok and how they implement diffeent vesions of this algoithm. B. TCP New Reno TCP New Reno implements a vey simple and effective algoithm. This algoithm is able to scale vaious odes of magnitude in tems of netwok dimensions and speed. The algoithm may be biefly summaized as follows: On eceiving an ACK: window n+ = window n + window n. On an indication of mild congestion (3 DUPACK): window n+ = 2 window n. This may be undestood as an attempt to pobe the netwok tying to sense which sending ate may be achieved at the cost of packet loss when the pobing fails [39]. Lets now conside the fluid model fo congestion contol of TCP New Reno. Fom now on we will follow the notation: 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. T is the aveage ound tip time. λ (t) is the pobability of loss at time t. a, the incease facto, is a constant that in TCP New Reno is set to. b, the decease facto, is a constant that in TCP New Reno is set to /2. With the AIMD algoithm, TCP New Reno incements the window by /w (t) pe each eceived ACK, hence the window inceases instantaneously as x(t) w (t) ( λ (t)). Similaly, pe each 3 DUPACK, the window is cut by half. The ate of this event is x (t)λ (t). The window then deceases at a ate x (t)λ (t)w (t)/2. We now may wite the fluid model fo congestion contol fo an AIMD-like congestion contol scheme (of which TCP New Reno is an example): 4 ẇ (t) = a λ (t) T (t) By setting T (t) = T, w (t) = x (t) T, we have: b x (t)λ (t)w (t) (7) λ (t) ẋ (t) = a b x (t)λ (t)x (t) (8) T 2 This may be e-witten in a moe geneal fom, taking in account feedback delays, as: ẋ (t) = x (t T ) λ (t) (a T x (t) T b λ (t)x (t) T ) (9) We took in account that the update at time t is detemined by the flow that left the souce at a time T in advance. The incease o decease in the second paenthesis of the ight-hand side of equation (9) is then done in tems of the ate at time t T, because of feedback delay. 4 Hee and in the est of the pape, we will ignoe the 4 facto that takes in account that the window, w(t), oscillates between 2 w(t) 3 3 and 4 w(t) with an aveage w(t). We will also avoid substituting the values of a and b in ode to keep a clea undestanding of how 3 these paametes influence the dynamics of the algoithm.

6 6 TCP New Reno implements an appoximate gadient algoithm fo the esolution of the congestion contol poblem. In tems of (9), and consideing feedback delay negligible, we may wite [38]: x = a ( λ (t) T 2 b x 2 a (t)λ (t)) = a (( b )x 2 a (t) + T 2 )( b a T 2 x 2 (t) + λ (t)) (0) Following the stuctue of eq. (6), the deivative of the net utility function that TCP New Reno implements and the congestion measue TCP New Reno is sensitive to ae: Integating in x the tem U (x ), we get the utility function as: C. TCP Hybla U (x ) q t (t) = ( b a T 2 x 2 (t) + λ (t)) () U(x ) = T a b tan ( b a T x ) (2) The Hybla scheme has been intoduced in [35]. This scheme, fom a congestion contol point of view, is mainly based on the modification to the incease of the AIMD algoithm poposed in [5] and futhely analysed in [8] [9] [6] []. The fluid flow model may be easiliy obtained fom (9) by making the following substitution: We then have: dx (t) dt a a T 2 T 2 0 = x (t T ) T (a T x (t)t0 2 ( λ (t)) b x (t) T λ (t)) (4) whee the new vaiable, T 0, is a constant efeence value. We may intepet T 0 as the efeence ound-tip time to which Hybla is adjusting the behavio of a flow. Moe pecisely, whateve the ound-tip time of a geneic flow, the flow will attempt to behave as a flow that is a expeiencing a ound-tip time of T 0 with the sink. This popety becomes cleae by obseving the value of the stable point: x = a λ T 0 b w 2 a b λ T 0 T 2 λ T 2 0 (3) a b λ (5) By compaing (5) with (35), it is clea that TCP Hybla achieves the same aveage thoughput as a New Reno flow with aveage RTT T 0. Fom equation (6) we expect that in the futue Hybla will suffe fom the same scalability poblem known pe New Reno. The fluid model is showing that the pobability of loss necessay to suppot a lage window size may become exceedingly small, so that the equilibium window value expessed in (6) may be difficult to achieve. Hee we ecall the sufficient condition fo the local asymptotic stability of a netwok with hosts with heteogenous delays opeating an AIMD-like congestion contol scheme [22] [9] and apply it to Hybla: a x T = T x T 2 0 < π 2β Obseving (7) and efeing to Kelly [7], one concludes that fo Hybla, we expect thee may be delay instability on outes whee the atio T /x is lage and appoaches the theshold. Convesely, the convegence will be slow on outes whee the atio is small. We also deived the expession of the appoximate gadient pojection algoithms that Hybla implements: x = a ( λ (t) T0 2 b x 2 a (t)λ (t)) = a ( T0 2 + b x 2 a (t))( (6) (7) + b a T0 2x2 (t) λ (t)) (8)

7 7 The utility function that TCP Hybla optimizes is: U(x ) = T 0 a b tan ( b a T 0 x ) (9) We note the similaity with TCP New Reno, whee T is eplaced with constant T 0. Thus, the utility function does not depend on ound-tip time. D. TCP Vegas Hee we follow the simple model descibed in [40]. We hee assume that buffe size is lage enough so that equilibium queue length is smalle than the buffe and that thee is no packet loss in equilibium. In this situation, we may assume that the only pice that is sensed fo congestion is queueing time. As stated in [24], a souce monitos its diffeence between its expected ate and its actual ate, and incements o decements its window by one in the next ound-tip time accoding to whethe the diffeence is less o geate than a paamete α. Souce sets its window accoding to the following ule: whee T w (t) + w (t + ) = w (t) w (t) T (t) T (t) if w(t) T if w(t) T else w(t) T (t) < α w(t) T (t) > α is the popagation delay expeienced by the -th flow. We can then obseve that: w (t) T w (t) T (t) = w (t)( T (20) T (t) ) (2) = w (t) T (t) (T (t) T T ) (22) = x (t)( T (t) T T ) (23) = x (t) φ (t) T (24) whee in (24), φ (t) = T (t) T is the instantaneous queueing time expeienced by the -th flow. We then see that we can expess (20) moe simply as: ẇ (t) = T (t) sgn(α T φ (t) x (t)) (25) whee sgn(x) = if x > 0, sgn(x) = if x < 0 and sgn(x) = 0 if x = 0. By substituting w (t) = T (t)x (t) and assuming that T (t) T we see that we can wite (25) in tems of thoughput as: ẋ (t) = T 2 sgn( α T φ (t) x (t)) (26) = T 2 sgn( α T x (t) φ (t)) (27) Fom (27) we may notice that: ) The step of the Vegas algoithm is given by T 2. 2) Consideing that in the Vegas algoithm α is a paamate that depends on the invese of T, we may then assume α = k/t, whee k is some constant. The equilibium sending ate is then given by: x = α T φ = k φ (28) The above equation states that the equilibium ate achieved by the Vegas algoithm is independent fom popagation delay; it depends only fom aveage queuing time φ. 3) The utility function that TCP Vegas attempts to maximize is: U(x ) = α T log(x ) (29)

8 8 E. TCP CUBIC TCP CUBIC [34] has been designed to enhance the window contol of TCP BIC [4]. The congestion window of TCP CUBIC is detemined by the following: W cubic = C(t K) 3 + W max (30) whee t is the elapsed time fom the last window eduction, W max is the window size just befoe the last window eduction, C is a constant and K = 3 Wmax β/c, whee β is a constant multiplication decease facto applied fo window eduction at the time of loss event (i.e., the window educes to βw max at the time of the last eduction). TCP CUBIC claims linea RTT fainess in tems of thoughput. Suppose two competing flows, with two diffeent ound-tip times T and T 2, shae the same path. Let s also suppose both flows sense losses in a synchonized manne [42], and that the initial paametes ae the same. We then have that the instantaneous thoughputs fo the two flows (making the assumption that T (t) T and T 2 (t) T 2 ) may be witten as: x (t) = w (t) T (3) x 2 (t) = w 2(t) T 2 (32) But since the time elapsed fom the last window eduction is the same, we have that w (t) = w 2 (t). It is easy then to see that x(t) x = T 2 2(t) T, fom which we may deive the linea RTT-fainess popety that is claimed by this algoithm. F. Compaison We have witten all of the congestion contol algoithms (with the exception of TCP CUBIC which we popose to study in moe detail in the futue) that we have so fa analysed in the fom: ẋ (t) = k (x )(U (x ) q (t)) (33) The quantities that appea in the expession ae: ) k (x ) is the stepsize of the algoithm. As we mentioned ealie, this tem is an amplification facto that detemines the amount by which the algoithm moves towad the solution at each step. This tem detemines the speed of convegence and the stability of the algoithm. Fo all the algoithms we have consideed hee, k (x ) is a continuous, non-deceasing function such that k (x ) > 0, x > 0. 2) (U (x ) q (t)) is the diection in which the algoithm is poceeding, seaching fo a solution (stable point). Moe in paticula, U (x ) is the maginal utility function and q (t) is the congestion measue (i.e., the maginal penalty) to which the algoithm is sensitive to. The maginal (utility-penalty) functions chaacteizes the location of the equilibium point of the algoithm (see Table I). Algoithm Stable Point Stepsize Maginal Utility Congestion Measue NewReno Hybla Vegas q a λ T b λ q a λ T 0 b λ ( b a )x 2 (t) + T 2 b a ( b a x 2 (t) + ) T0 2 α T φ T 2 T a 2x2 (t)+ b a T 0 2x2 (t)+ α T x TABLE I DYNAMIC AND EQUILIBRIUM PROPERTIES loss pobability loss pobability queueing delay

9 9 G. Dynamic Analysis Let us stat by ecalling the fluid model fo the TCP New Reno congestion contol scheme: dx (t) dt = x (t T ) a ( T x (t) T ( λ (t)) b x (t) T λ (t)) (34) This is an NL diffeential equation in the vaiable x (t) and models the ate s behavio of the -th flow. Fo steady state equilibium we let t. The stable point coesponds to the value of x (t) that nullifies the gadient. It is found by setting the ight hand side = 0. We then have: x = T a b λ λ (35) whee x, T, λ ae the stable points that ae eached afte the tansient phase by the -th connection in the netwok. A dynamic system may be geneally expessed as: { ẋ = f(x, u) y = g(x, u) whee x is the vecto of state vaiables, u is the vecto of inputs to the system and y is the vecto of outputs. We want to lineaize system (34) aound its stable point, in ode to expess it as (fo a stictly causal system): { ẋ = A x + B u (37) y = C x In (34) we may identify x (t) and x (t T ) as state vaiables [44], and λ (t) as the input to the system. We lineaize (34) aound its stable point in ode to study the behavio of the system in its neighbohood. In equations (38) to (40) we show the esults of computing the deivatives of (34) with espect to the state and input vaiables, and we substitute the value of (35) fo x (t) and x (t T ). df ( dx (t) ) eq = 2 b λ a ( λ ) (38) T b λ (36) df ( dx (t T ) ) eq = 0 (39) df ( dλ (t) ) eq = a T 2 λ (40) In the lineaization we assume that x (t) = x + δx (t), x (t T ) = x + δx (t T ), and λ (t) = λ + δλ (t) and that these quantities vay slowly aound thei equilibium point. We ae now able to find A and B, both S x S matices, whee S is the numbe of souces, in the lineaized system: A = diag 2b λ T The lineaized fom of (34), fo the -th flow, is then : δẋ (t) = 2 b λ T a ( λ ) b λ { B = diag a } T 2 λ (4) (42) a b ( λ λ )δx (t) a T 2 λ δλ (t) (43)

10 0 The Laplace tansfom of the tansfe function esults to be (hee we have that C = I, the identity matix, in (37), since the output y is equal to state vaiable x): G(s) = C(sI A) B (44) = diag a T 2 λ ( ) (45) s + 2 λ b a T b ( λ ) λ Recall that a and b vay fom implementation to implementation of the AIMD-type contol mechanism. Now we choose these paametes in a way that will lead to the desied fainess esults. The values â and ˆb that we popose ae: â α T 2 T 0 + T a (46) ˆb T T 0 + T b (47) Note that a new coefficient α was intoduced. Its setting and function will be explained late. These values lead to the following stable point fo the -th souce: a α x = λ (48) b T λ We now have that (4) and (42) become: A = diag 2T λ b T 0 + T { B = diag λ T b λ } α a α a ( T + T 0 ) λ Kelly in [7] deives the vaiance fo a flow in the case of N flows though a single esouce (bottleneck), whee all flows shae the same values of â, ˆb, T ; and assuming that queues ae modeled as M/M/, with a finite buffe β. In ou case we have that: va {x (t)} = ˆb x 2 2N ( 2( λ ) + β + N 2( λ ) ) (5) = (49) (50) T b x 2 2N( T + T 0 ) ( 2( λ ) + β + N 2( λ ) ) (52) We can now explain the design choices in (46) and (47) fo â and ˆb : ) We achieve a stabilized ate independence fom ound-tip time by having â T 2. 2) We achieve a educed sensitivity to ound-tip time in (49), the system matix (fo T 0 >> T ). 3) We do not penalize the convegence speed of the system to the stable point by multiplying pe facto α. 4) We achieve scalability (this point will be thoughly discussed in the next section). 5) We educe the vaiance of thoughput with espect to TCP New Reno, accoding to expession (52). The vaiance of a flow may be contolled by setting the T 0 and T paametes. In paticula, by setting a value of T 0 and T, we can diminish the vaiance by a facto of at least /( T + ). 6) The vaiance of a flow scales with x 2. The coefficient of vaiation (i.e. the atio: standad deviation/mean) of x (t) does not depend on x. This scale invaiance popety was fist identified by Ott in [45].

11 H. The α Coefficient In the pevious section we intoduced the new α coefficient. The design of the α facto was accomplished with the objective of pusuing the following main objectives: ) Incease convegence speed and achieve scalability fo the algoithm. 2) Keep the algoithm behavio stable. 5 Fo the above easons, the α facto has been decoupled in the poduct of two components say: α = S P, whee ) S = Scalability facto. 2) P = Penalty o Damping facto. We achieve scalability by adjusting the scalability facto to the capacity of the bottleneck link. To compute the latte, we use packet pai techniques that ae un in paallel to the algoithm. In paticula, we set: S = k C (53) whee k is a constant and C is the capacity of the bottleneck link seen by the -th souce. The penalty facto P has been designed in ode to make the incease ate of the algoithm adaptive to the amount of congestion in the netwok. We adopted queueing time as a measue of congestion of the netwok, the same measue on which TCP Vegas elies, namely: (T (t) T min ) (54) The ole of the penalty facto is then to penalize the incease of the window in the pesence of congestion and to maintain the window as close to the maximum value as long as possible. We may use diffeent expessions of penalty functions fo this pupose. In Tab. II we show a few options, whee T (t) epesents the instantaneous the minimum ound-tip time expeienced by the -th connection. All these functions tend to penalize the gowth of the congestion window when the instant ound-tip time gets close to the maximum ound-tip time expeienced duing the connection. In Fig. and 2 we see the ound-tip time, T max the maximum ound-tip time and T min Penalty Functions T (t) T max T min k 2( T max ) max T (t) 2T ( T max T min T min T (t) T max T min k 2( T max )) e k T (t) T min 2 T max T min TABLE II MONOTONICALLY DECREASING FUNCTIONS IN TERMS OF QUEUEING DELAY esults of a simulation whee we have two flows, with ound-tip times of 400 and 0 ms espectively, in a buttefly configuation, competing in a 00Mbps bottleneck. In the simulation elated to Fig., we used a penalty function, while we omitted it in the simulation elated to Fig Hee we mean stability in tems of the local asymptotic stability. We then expect that in its stable behavio, the potocol will achieve the aveage thoughput expessed in (48).

12 2 Fig.. Thoughput of two flows, using a penalty function Fig. 2. Thoughput of two flows, omitting the penalty function I. Stability Analysis Hee we will give a simple stability analysis fo TCP Liba, which will show the impotance of the choice of the α coefficient. Let s conside a single TCP souce on a single link. We will ecall the esults fom the analysis available in [38] fo TCP New Reno and compae them with the same analysis fo TCP Liba. We assume that the pice is set as in [22] fo simplicity: λ(x) = ( x(t) C )β (55) which epesents the pobability of having a queue of length β o geate fo a M/M/ queueing system; x(t) is the aival ate and C is the capacity of the link. We make the assumption that the queue is close to full most of the time. We then have that the ound-tip time is equal to the sum of the queueing delay and popagation delay. The sufficient condition fo asymptotical local stability is: λ κ T λ < π (56) 2 consideing that fo a TCP New Reno flow κ = / T 2 we have that: λ λ < π T 2 Let s now conside a TCP Liba flow. Fo a TCP Liba flow we have that κ = we can simply substitute this value in (56) and obtain: λ λ < π( T + T 0 ) 2α T (57) α T 0+ T 6. The analysis is the same, fom which we ae able to find the uppe bound α < T +T 0, which gives us the values that α may assume in ode to T keep a stability egion geate than that of New Reno fo 2 this simple case. Recalling that α = Scalability F acto P enalty F acto = S P, we see that the above bound gives a condition on k 2 once k is fixed, and vice vesa. We can find the following expession: 6 Hee we substitute a =. (58) k 2 > T max T min log( T + T 0 ) (59) T T min k C T 2

13 3 Once k is fixed and the othe paametes and chaacteistics of the link ae known, the above expession establishes the minimum value of k 2 in ode to guaantee a stability egion at least as wide as New Reno s. The above is clealy a qualitative analysis, since we have consideed the simple case of a single link and a single flow, but it gives us a feeling of how the choice of k and k 2 must be made. As we intuitively expected, (59) is telling us that: If k is inceased, then k 2 must be also inceased in ode to keep the same stability bound as New Reno. Highe values of C and T equie a highe value of k 2.. J. TCP Liba Algoithm Finally, we ae eady to deive the algoithmic expession of TCP Liba. We will use a synthesis pocess that is the evese of what we employed in the analysis of pevious TCP potocols. As we did fo the algoithms analyzed and pesented until now, we will deive the utility function that TCP Liba optimizes (though we will do it befoe knowing the actual algoithm), and will deive the fluid model algoithm TCP Liba implements, with the modification we designed in (46) and (47). TCP Liba s fluid flow algoithm is: 7 dx (t) dt = x (t T ) α T ( T x (t)( T + T 0 ) ( λ (t)) T 2 x (t) T λ (t) T + T 0 ) (60) We may wite the fluid model algoithm as in (6), by pefoming the same substitutions in (0): ẋ = ( T T + T 0 x 2 (t) + α T + T 0 )( T α x 2 (t) + λ (t)) (6) and we can see that the maginal utility function, U (x), is not dependent on T. TCP Liba is attempting to minimize the sum of the tansfe delays in the netwok, independently fom the ound-tip time expeienced by the souce. Finally, the TCP Liba algoithm: window n+ window n + window n α nt 2 n T n+t 0 in case of a successful tansmission. window n+ window n Twindown 2(T n+t 0) in case of loss (and the theshold is set accodingly). In the following section we will show the simulation esults fo TCP Liba. The simulations have been obtained by substituting T 0 =, T =, k = 2, k 2 = 2 and using the exponential penalty function epoted in Table II. While a highe value of k 2 would have impoved the link utilization by keeping the window at its maximum fo a longe time, we have noticed that a highe value k 2 geneates an excessively timid behavio of TCP Liba towad TCP New Reno. We adjusted this value as a tadeoff between utilization and fiendliness. The paamete k is adjusted accodingly to k 2, as we discussed in the pevious section. We finally set T 0 to, since in the geat majoity of cases this will esult in T << T 0 [46], which gives a diminished sensitivity of (49) fom T, without excessively penalizing the stepsize in (6). IV. PERFORMANCE EVALUATION In this section we evaluate TCP Liba using the NS-2 [47] simulation platfom. We also compae it to TCP New Reno and with othe RTT-fai TCP vesions namely TCP Vegas, CUBIC and Hybla. Fo TCP New Reno and Vegas, we used existing NS-2 modules; fo TCP Hybla and TCP CUBIC we used the code povided by the developes; and we developed ou own code fo TCP Liba. Default paametes had to be changed only in the case of TCP Vegas, as inspied by liteatue [48]. Each expeiment was un fo 000 seconds of simulation time (if not othewise specified in the elative figue). We chose such a long peiod because we wanted to evaluate the behavio of the vaious potocols afte they stabilize. Unless stated diffeently, the netwok topology was set as in Figue 3. Fou FTP connections ae established between the souce destination pais Si, and Ri shown in Fig 3. The pais S, R and S2, R2 have RTT = 40 ms, 7 Hee we will substitute the values fo â and ˆb ; we also substitute a =, b = /2 in (46) and (47).

14 4 S3 R3 S R S2 X Y R2 S4 R4 Fig. 3. NS-2 simulation topolgy epesenting coss county links. The pais S3, R3 and S4, R4 have RTT = 60ms, epesenting intecontinental links. Link capacities ae unifom fo all links. Link X, Y is thus the common bottleneck. Buffe size at oute X (the bottleneck buffe) vaies with the expeiments. In one seies of expeiments we set the buffe size in X to the pipe size, i.e., to the numbe of outstanding packets that can fill the pipe. This is equal to the poduct of bottleneck capacity by the lagest RTT (i.e., 60ms in most of the simulations) divided by packet size. In the emainde of this pape we efe to this value as the longest pipe size. In othe expeiments, the buffe size was set equal to 200 o 500 packets which ae the suggested values fo buffes in Cisco Systems outes [49]. We ae, in this manne, able to test potocols behavio with buffes sizes that esemble the eal outes, as well as with buffe sizes simila to those found in the liteatue; moeove, we had the oppotunity to study TCP Liba stability in elation to the buffe size (see eq.59). Finally, the TCP packet size, including TCP/IP heades, was set to 500 Bytes. We evaluated the following pefomance measues: ) available bandwidth utilization 2) inta-potocol RTT-fainess 3) inte-potocol RTT-fainess 4) fiendliness to the legacy potocol TCP New Reno 5) scalability of TCP Liba to many flows, lage capacity and lage RTT

15 5 Is woth noting that in ou expeiments thee ae no andom eos on links. Thus TCP New Reno behaves the same as TCP Sack. Thus, ou fiendliness esults will hold also fo TCP Sack. A. Inta-Potocol Fainess The Jains Fainess Index [50] is geneally adopted in scientific liteatue to evaluate the RTT-fainess degee among data flows shaing a single bottleneck; theefoe we have adopted it even in ou analysis. We computed its values to compae the vaious potocols in vaious configuations chaacteized by diffeent bottleneck capacities and buffe sizes. In paticula, Figue 4 consides the scenaio having the buffe size always equal to the longest pipe size, while Figue 5 coesponds to the case whee the buffe size is set 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 bottleneck of 80 Mbps and 60 Mbps, and 200-packet buffe. This esult can be taced back to Hybla s stability with lage bottleneck capacities and small buffes, and can be deived fom the bound in equation (7). The slightly wost behavio of TCP Liba in the expeiment with a buffe size of 200 packets may be explained by obseving that fo smalle buffes the penalty potion in the α facto clealy has a less impotant influence compaed to the lage buffes sizes. This poblem may be educed by inceasing the value of k 2 in the functions of table II. 0.9 Jain s Fainess Index Bottleneck Capacity (Mbps) NRENO VEGAS CUBIC HYBLA LIBRA Fig. 4. Jain s Fainess Index vs. bottleneck capacity fo TCP New Reno, TCP Vegas, TCP Cubic, TCP Hybla, and TCP Liba. Buffe size at the bottleneck was set equal to the longest pipe size. B. Inte-Potcol Fainess (Fiendliness) With an aim at veifying the compatibility of newly poposed potocols with Intenet s de facto standad we need to evaluate scenaios whee each of the new potocols competes fo the same bottleneck with the taditional TCP

16 6 Jain s Fainess Index Bottleneck Capacity (Mbps) NRENO VEGAS CUBIC HYBLA LIBRA Fig. 5. Jain s Fainess Index vs. bottleneck capacity fo TCP New Reno, TCP Vegas, TCP Cubic, TCP Hybla, and TCP Liba. Buffe size at the bottleneck was set equal to 200 packets, as suggested default value in the CISCO Systems configuation manual(s) [49] New Reno. We theefoe consideed vaious configuations whee TCP New Reno was used fo one shot RTT flow (fom S2 to R2) and one long RTT flow (fom S4 to R4), while the othe two concuent flows wee diven by one of the othe TCP flavos. This allowed us to investigate the impact of coexistence on the RTT-fainess degee and the fiendliness of the altenative TCP vesions towads TCP New Reno. We chose the asymmety index [5] as fiendliness metic. The Asymmety Index A is defined in equation (62) below. A = x x 2 x + x 2 (62) In this fomula x and x 2 coespond to the aveage thoughputs achieved by two diffeent potocols competing fo the same channel. If, as in ou case, the two competing potocols ae povided with exactly the same initial conditions and each of them is able to exploit (almost) all the available bandwidth when employed alone, then this index can be employed to linealy indicate the degee of aggessiveness of the two potocols towad one anothe. In essence, when A = 0, the two potocols shae the bottleneck pefectly evenly. Convesely A > 0, coespond to having the fist potocol moe aggessive than the second, while A < 0 imply the invese situation. In Fig. 6 and Fig. 7 the asymmety index is pesented fo all the bandwidth configuations and, fo each of them, TCP New Reno coexists with one of the altenative TCP vesions. In paticula, in Fig. 6 the buffe size was equal to the longest pipe size (233 packets), while in Fig. 7 the buffe size was 200 packets. As can be seen in the chats, when TCP Vegas is used concuently with TCP New Reno, the latte always pesents vey high incements of thoughput (the Asymmety Index fo TCP Vegas is : A < 0). This is because as soon as TCP Vegas detects that the queue is stating to build up, it educes the tansmission ate. The same

17 7 00% 80% 60% Asymmety Index 40% 20% 0% -20% -40% % -80% -00% Bottleneck Capacity (Mbps) VEGAS-NRENO CUBIC-NRENO HYBLA-NRENO LIBRA-NRENO Fig. 6. SLAC Asymmety Index [5]. TCP New Reno vs. TCP Vegas, TCP CUBIC, TCP Hybla, and TCP Liba. Two TCP New Reno flows compete with two othe flows. RTT values 40ms and 60ms espectively. Index = 0 pefect fiendliness; Index < 0 TCP New Reno is moe aggessive; Index > 0 the compaed TCP is moe aggessive than TCP New Reno. Buffe size at the bottleneck has been set equal to the longest link pipe size. consevative behavio is not adopted by the concuent TCP New Reno, which continues to pobe the channel fully exploiting available queues and bandwidth along the path and making TCP Vegas sense a continuous congestion in the netwok. As a consequence, TCP Vegas quickly bings its congestion window to a stable but vey low value, thus achieving vey low thoughput levels. In opposition, TCP Hybla is pedisposed to be too aggessive towad TCP New Reno, thus using most of the bandwidth and sensibly educing TCP New Reno s thoughput when competing fo the same channel, as confimed by Hybla s Asymmety Index always positive. This is because egadless of the actual cuent RTT, TCP Hybla ties to make all the TCP connections achieve a tansmission ate equivalent to the one that would be attained by a connection expeiencing the efeence RTT value (i.e., in this expeiment, 25 ms as epoted in [35]). TCP CUBIC was not as highly consevative o aggessive towad TCP New Reno as TCP Vegas and TCP Hybla wee. Howeve, in all the configuations simulated, even in those that we did not pesented hee due to space limitation, TCP Liba showed the highest fiendliness degee among all the potocols compaed in this wok. Indeed, TCP Liba is the potocol that had the least impact on the thoughput achieved by the concuent TCP New Reno connections and, in a few configuations, (slightly) educed the thoughput attained by TCP New Reno as confimed by the Asymmety Index. In summay, TCP Vegas is excessively timid, while TCP Hybla and TCP CUBIC ae too aggessive. TCP

18 8 00% 80% 60% Asymmety Index 40% 20% 0% -20% -40% % -80% -00% Bottleneck Capacity (Mbps) VEGAS-NRENO CUBIC-NRENO HYBLA-NRENO LIBRA-NRENO Fig. 7. BIC, TCP Hybla, and TCP Liba. Two TCP New Reno flows compete with two othe flows. RTT values 40ms and 60ms espectively. Index = 0 pefect fiendliness; Index < 0 TCP New Reno is moe aggessive; Index > 0 the compaed TCP is moe aggessive than TCP New Reno. Buffe size at the bottleneck has been set equal to 200 packets. This is the suggested default value in the CISCO Systems configuation manual(s) [49]. Liba demonstates that is geneally able to faily shae the available bandwidth with TCP New Reno. The only configuation whee anothe potocol (i.e., TCP CUBIC) achieves a bette asymmety index than TCP Liba is when a buffe of 200 packets is employed in combination with a 60Mbps bottleneck link (in this configuation, the actual pipe size would be 233 packets an ode of magnitude geate). Finally, not only is TCP Liba RTT-fai when employed as the only tanspot potocol and fiendly to TCP New Reno when coexisting with it, but in this latte case it also maintains the inta-potocol RTT-fainess. Indeed, the simulation esults obtained using the afoementioned symmetic topology (see Fig. 3) showed that each of the two TCP Liba connections tends to achieve a thoughput which is close to the aveage thoughput attained by the two RTT-unfai connections utilizing TCP New Reno. C. TCP Liba Scalability Discussion We studied TCP Liba scalability focusing on thee diffeent aspects: () scalability in elation to link capacity, (2) scalability in elation to numbe of flows acoss a given bottleneck and, (3) scalability in elation to the displacement of RTT(s) among the flows. ) Link capacity scalability: The cuent slow stat and congestion contol mechanism implemented by taditional TCP flavos has poved to have difficulty eaching full utilization on high-speed 8 links, paticulaly on connections 8 Hee we ae tageting coe links at gigabit speeds

19 9 chaacteized by lage RTT [52]. We have theefoe decided to evaluate the scalability of TCP Liba with a 60ms RTT connection ove a 244Mbps link (i.e., OC24). Figue 8 shows the acknowledged packets as a function of time. The deivative is the thoughput. One can see that the slope (i.e., thoughput) stabilizes vey apidly in TCP Liba. In contast, TCP NReno is still climbing afte 000 seconds. In fact, in 8 one can veify that TCP Liba hits 96% of channel utilization afte 000 sec. Unde the same conditions, TCP New Reno only achieves about 9% (see Figue 9). We tested also configuations with 400Mbps, 500Mbps, and 622Mbps (i.e., OC2) obtaining simila esults. Fig. 8. TCP Liba. Acknowledged packets vs.time. Bottleneck link bandwidth equal to Oc24(i.e.,.244Gbps), RTT set to 60ms. The TCP Liba link utilization is about = 96%. Buffe size at the bottleneck has been set equal to the longest link pipe size. 2) Numbe of flows scalability: In this expeiment we studied TCP Liba scalability in elation to the numbe of flows shaing the same bottleneck. In paticula, we used the buttefly configuation in Fig. 3 with a bottleneck link of 622 Mbps (i.e., OC2). We designed thee expeiments involving 00 contempoaneous flows each. The RTT was set as follows: 30 flows with RTT 6 ms (i.e., a egional connection) 60 flows with RTT 60 ms (i.e., a coss-county connection) 20 flows with RTT 80 ms (i.e., tansatlantic connection) Fist we un TCP New Reno, and then we un TCP Liba using two diffeent settings fo the k 2 paamete (see eq. 59). TCP New Reno pefomance is shown in Fig. 0. As expected fom the model, in paticula fom the utility function in equation (2), TCP New Reno shows RTT-unfainess due to dependency on the RTT duing the incease phase. Using the same expeimental scenaio, we pefomed a set of expeiments diected at studying TCP Liba s stability and fiendliness. In paticula, Fig. shows TCP Liba s pefomance with k 2 = 2, while Fig. 2 shows the esults with k 2 = 2. It is woth noting the key ole played by TCP Liba s paamete k 2. In

20 20 Fig. 9. TCP New Reno. Acknowledged packets vs.time. Bottleneck link bandwidth equal to Oc24(i.e.,.244Gbps), RTT set to 60ms. The TCP New Reno link utilization is about 9% Buffe size at the bottleneck has been set equal to the bottleneck link pipe size. paticula, the stability bound in equation (59) suggests the following consideations: (a) in this expeiment we ae on the bode of the stability egion fo TCP Liba and by inceasing k 2 we safely etun to the stability egion and achieve a good RTT-fainess (see Fig. 2); (b) with elatively small buffes (compaed to the pipe size) the penalty function has a lowe effect thus educing the RTT-fainess and inceasing the fiendliness to TCP New Reno; (c) the cluste effect in Fig. 2 suggests that in this condition with k 2 = 2, TCP Liba still attenuates the RTT-unfainess even though aggegates the flows in egions due to the fact that is on the bode of its stability aea. In summay, especially with small buffes, a caeful selection of TCP Liba s paametes is needed to balance the algoithm s RTT-faness (o effectiveness aea) with its fiendliness to TCP New Reno as suggested by the TCP Liba s Model. 3) Flows with lage RTT spead and staggeed stat times: In this expeiment fou diffeent TCP Liba flows (Fig. 3) with RTTs 20, 00, 60, 200, 400 ms ae stated in sequence at diffeent times. Bottleneck link bandwidth is equal to 00 Mbps. The buffe size at the bottleneck has been set equal to the longest pipe size. Fig. 2 shows the acknowledged packets vesus time. It is woth noting that the slopes ae the same acoss the flows. Thus, even in the case of a atio of :20 in RTT, TCP Liba allows all the flows to achieve thei fai shae. In contast, Fig. 3 shows a simila expeiment with TCP New Reno. One can eadily see that the shot flow captues the bottleneck. V. CONCLUSIONS AND FUTURE WORK This pape intoduces TCP Liba, a new potocol designed to be RTT-fai while maintaining a good fiendliness with TCP New Reno, thus allowing a seamless deployment in the netwok. We analytically studied TCP-Liba and its competitos using the pimal/dual netwok modeling fomulation and deiving the elative stability bounds. Ou study was completed with a simulation analysis pefomed using NS2 that confimed TCP Liba chaacteistics. In paticula, we discoveed that TCP Liba, when used within its stability egion, is able povide RTT-fainess and