Abstract Tradeoffs of Implementing TCP Fairness Schemes

Tradeoffs of Implementing TCP Fairness Schemes Xudong Wu Ioanis NikolaidisComputing Science DepartmentUniversity of AlbertaEdmonton,Alberta T6G2E8,Canada{xudong,yannis}@cs.ualberta.caAbstractIn this paper we consider two recently proposed schemes for the fair allocation of bandwidth in high speed networks carrying TCP traffic:XCP and Fair-Share.We explain the different design philosophies represented by each one and demonstrate through a set of simulations that FairShare,by making better use of the round-trip-time information,avoids the performance shortcomings that appear in XCP under environments with diverse round–trip times.Further-more,it is pointed out that XCP cannot perform well under environments where short lived and long lived flows share the link bandwidth and the isolation of flows on the basis of their lifetimes,as implemented in FairShare is preferable.Keywords:TCP,XCP,Max–Min Fairness,Router Policies1IntroductionProviding bandwidth fairness guarantees across TCP connections in the Internet is a challenging problem. Part of the problem is due to the lack of mechanisms installed in the core routers of the network to enforce certain per–flow policies.Another part of the prob-lem is the fact that shortflows,like the ones related to HTTP transfers,are too short lived to be meaning-fully compared against otherflows on the basis of the bandwidth they receive.That is,the fact that they last for a short amount of time means that they are hardly capable of substantially increasing their con-gestion window,and are thus unable to exploit the available link bandwidth.It thus makes sense to study the bandwidth fairness across long livedflows,leaving the short livedflows for separate consideration.In a previous study[24]we addressed the topic of short versus long livedflows,how they can be separated and how they can be handled independently.The schemes discussed in detail in this paper are FairShare[23,25] and XCP[19].Both schemes rely on knowledge of the round–trip times and the congestion window of each flow.Nevertheless,they obtain this information via different mechanisms and produce distinctly different results.In the model of fairness we consider,if Nflows are“greedy”,i.e.,they can use as much bandwidth as is available,and if the link bandwidth is C,then each should be allocatedλi=C/N.However,flows may be bottlenecked elsewhere along their path,and cannot,as a result,behave in a greedy fashion.In such case,their demands can be considered bounded. Evidently,in the previous example,if oneflow was al-ready bounded to a rate less than C/N,it would make no sense to assign C/N to the particularflow.How the bandwidth is assigned depending on the demands (represented by a demand vector)is dependent on the particular fairness criterion.Note also that aflow may have reduced demands not only because of a bottle-neck at a remote link,but also because,simply,the flow does not have enough data to send at all times.A fairness algorithm provides,given a resource de-mand vector,an allocation vector,with elementsλi, that are less or equal to the requested demands.An allocation is called max–min fair if,it is feasible(with respect to the capacity constraints),andλi cannot in-crease without reducing the allocation for some other session(s),j,for whichλj≤λi.An alternative is proportional fairness.An allocation is proportionally fair if,for any alternate allocation vectorλ i the net proportional improvement brought about by an alter-nate allocation vector is negative,i.e.,iλi−λiλi≤0.An extension of proportional fairness is(p,α)–proportional fairness,whereby,any alternative allo-cation vector,λ results inip iλ i−λiλαi≤0.It can beshown,[9],that(p,α)–proportional fairness approxi-mates max–min fairness,asα→∞.When determining the fair allocation of bandwidth toflows,allflows present in the network have to be considered.Whether such an approach is technically feasible depends,apparently,on the type of fairness. For example,max–min fairness appears difficult to achieve without global information.Nevertheless,this does not eliminate the possibility of deriving(e.g.,via measurements)or inferring a part of this global infor-mation that is necessary for max–min allocation by each individual link.Charny[16]studied distributed algorithms for achieving global max–min fairness.The algorithm presented in[16]is better understood in its centralized form.It involves the identification of the most congested link(first level bottleneck),and ap-plication of the max–min fairness on theflows cross-ing this link.The demands of allflows crossing this first link are then limited(bounded)by the share they receive in this most congested link.Given the new bounds for some of theflows,the residual capacity in the remaining links is calculated and this,in turn, changes the share received by otherflows.The pro-cess is repeated until allflows have been marked by a certain rate.Note that allflows are assumed to be greedy,but it is trivial to force the realistic assump-tion of boundedflows by assuming that each traffic flow is introduced via an access link,which is of course bounded,and possibly congested.The important element of[16]is the proof that the process terminates after a limited number of itera-tions,resulting in a global max–min fairness alloca-tion.Nevertheless,in order to achieve this objective we need two building blocks(a)a means for allocating bandwidth at each link in a max–min fashion depend-ing on the demands of theflows,and,(b)a means to actually calculate the demands of theflows.Both of the building blocks can be found in the FairShare scheme,and we have thus demonstrated its ability to reach global max–min fairness[25].The open ques-tion is whether XCP is also capable of global max–min fairness.In this study we indicate that XCP cannot provide max–min fairness even on a single link(hence, cannot provide building block(a)),and therefore its potential for global fairness is very much at doubt.Another important element in our study is the fact that we consider essential the involvement of the routers in attaining the global max–min fair operat-ing point.A totally distributed implementation of a fairness scheme relying solely on the endpoint oper-ation is an open research issue.In particular,using end-to-end mechanisms[9]it was shown that it is pos-sible to achieve(p,1)–proportional fairness,but max–min fairness has so far been unimplementable on an end–to–end basis.Moreover,even the implementable (p,1)–proportional fairness is unattractive because it requires a different end-to-end congestion control pro-tocol,which is neither TCP nor any other legacy pro-tocol.For this reason,and also because proportional fairness tends to victimizeflows that span over a longer path,we consider max–min fairness as a preferable alternative and we are looking for support of legacy TCPflows instead of proposing a new congestion con-trol scheme.2The Unfairness ProblemTCPflows combined with DropTail router policy are difficult to predict and control,and the resulting divi-sion of the bandwidth of congested links is significantly unfair.By attributing the unfairness to the router drop policy,proposals have indicated how it should be changed to alleviate the problem.One such proposal is the Random Early Detection(RED)[8].Its essence is that although not all of the TCPflows will receive con-gestion signals in times of congestion,the TCPflows with more packets stored in the buffer are more likely to receive such congestion signal1.RED and its vari-ant are frequently called Active Queue Management (AQM)policies.Unfortunately,even though RED improves fairness and also eliminates the“Phase Effect”,it is far from being sufficient to ensure fairness.This fact is already known since[8]but it helps to know what magnitude of unfairness we are up against.Figure1demonstrates the ratio of the throughput received by twoflows,as a function of the ratio of their corresponding prop-agation delay RTTs.The twoflows share the same bottleneck link with a buffer space of24packets and a link speed of100packets per second(fixed size pack-ets)but the ratio of the RTTs of the twoflows spans an order of magnitude.Specifically,the RTT offlow 1is set to100msec(approximating the RTT of aflow within the North American continent),while that of flow0ranges from100msec to1sec(representing the range from intra-continental to inter-continental traf-fic).As it can be seen,DropTail results in a ratio up 1RED defines two thresholds,minth and max th.When the average queue occupancy,Q is below the min th,packets are not marked.If,Q is between min th and max th,each arriving packet will be marked with probability max p Q−min thmax th−min th.If Q is larger than max th,the packet is marked.Note that Q is the moving average of the queue length:Q=Q(1−w q)+q·w q where q is the queue occupancy measurement and w q is a weight factor of the exponential moving averaging.5101520253035T h r o u g h p u t R a t i o (F l o w 1 / F l o w 0)RTT Ratio (Flow 1 / Flow 0)(a)DropTail5101520253035T h r o u g h p u t R a t i o (F l o w 1 / F l o w 0)RTT Ratio (Flow 1 / Flow 0)(b)REDFigure 1:Comparison of the ratio of throughputs achieved under,(a)DropTail and,(b),RED ,of two TCP flows,with different RTT values,but otherwise indistinguishable.to 34:1between the throughput achieved by the two flows (the lesser throughput received by flow 0)while RED produces 2a ratio up to 14:1.This is precisely what we wish to avoid.The ideal ratio in this exam-ple ought to be 1:1regardless of the RTT of the two flows.3The FairShare SchemeThe FairShare scheme [23]is a class-based bandwidth allocation and active queue management scheme.Given a link l with capacity C l ,the capacity is split be-tween UDP traffic,long TCP traffic,short TCP traffic,and routing–related traffic,with capacity,correspond-ingly:C UDP l ,C L-TCP l ,C S-TCP l ,and,C Route l ,where C l =C UDP l +C L-TCP l +C S-TCP l +C Route l .The rest of the paper deals with how to administer the C L-TCP l among long lived flows.FairShare is the scheme that will perform this function.It is as-sumed that the class capacities are quasi–static,that is,they can change but with operator intervention and at time scales much larger than the average connec-tion lifetime.We believe that this is a reasonable as-sumption,in light of the fact that operators may wish to,intentionally,restrict the total bandwidth available to long lived flows in order to provide short response times to short transfers,as is the case for most Web document transfers.The first step of the control is to determine the fair share of capacity at the bottleneck link for a particular TCP flow,i .Let us denote this share as share i .The share is the element of the allocation vector provided by the fairness algorithm 3,i.e.,share i =λi .Shares can be calculated on the basis of a demand vector.The demand vector is obtained by a measurement process that will be described later in this section.We will use demand i to describe the measured demand of flow i .Given an intended share value share i and the RTT of flow i ,rtt i ,the desirable long–run window size that would provide the share i to flow i is simply W =rtt i ·share i .Let us define a TCP–Tahoe “epoch”as the time interval from the point that the TCP congestion win-dow is 1until the first packet loss occurs.A single epoch of congestion window evolution consists of two periods,t 1,the exponential growth period,and t 2,the linear growth period.In steady state,the final win-2REDparameters:max p =0.02,min th =5,max th =15,w q =0.002.3We tacitly assume in the rest that the fairness implemented is max–min fairness,but any fairness objective could be used in its place.dow size at the end of the epoch,which coincides with the end of the linear growth,W ,is twice as large as that of the exponential stage.Because the congestion window increases exponentially before it reaches W 2,we have W 2=2y,where y stands for the rounds that the TCP–Tahoe flow spends in exponential growth.Since the congestion window increases only by one perround,the rounds spent in linear growth is W 2or 2y.In short,the time of one epoch of TCP–Tahoe with RTT as the unit can be presented as y +2y .The to-tal count of the packets communicated in one epoch is the sum of packets transferred in the exponential in-crease phase, y 02x dx ,and those in the linear growthphase, Ty (2y +x )dx .Based on the congestion control window evolution algorithm,we can derive equation (1),where W is the average congestion window.The numerator of the left side of equation (1)is the num-ber of packets transferred in steady state during one epoch (including both exponential and linear increase phase).The denominator is the the number of rounds within the complete TCP–Tahoe epoch.W =y2x dx +Ty(2y +x )dxy +2y(1)If a packet loss is scheduled at the point where the window size is 2y +1,it will effectively limit the long-term average flow to approximately W .By setting,W =rtt i ·share i ,a loss scheduled to occur when the flow’s window is 2y +1effectively controls the long–run throughput of the flow to be consistent with the calculated fair share.Based on this observation,we claim that we can regulate the long–term flow rate by inflicting losses when the window of the flow reaches a specific value.Hence,we can use on–line observations of the window size to drive the loss instants with the intention of preserving a desirable long-term mean.Equation (1)can also be expressed as equation (2),but given the lack for an explicit solution for y to equation (2),a table lookup can be implemented to determine the target window size as soon as the aver-age congestion window size objective is calculated.1ln 22y +32(2y )2=W (2y +y )(2)For TCP–Reno,the calculation is straightforward be-cause of the simplicity of the algorithm.We assume the ideal equilibrium state will be reached and the con-gestion window of TCP–Reno will construct a perfect “sawtooth”with a peak at W 2.Therefore,the time of one epoch in terms of RTT is W 2,and the packets communicated in one epoch is (W 2+W )W22.The aver-age congestion window size is calculated by W =3W 4.init long flow (p ):1.rtt i ←rttlookup (p.src,p.dst );2.count i ←p.size ;3.demand i ←C L-TCP l ;4.share ←maxmin (demand ,C L-TCP l );5.flag i ←FALSE ;6.dropevent i ←0;7.tick ();Figure 2:The init long flow ()function.In the following,we need the inverse of this function,that is,a function transforming the average window size to the peak window size necessary at the time of packet loss.We will assume that this function is called avg2peak ().3.1The AlgorithmIn this section,the pseudo-code of the FairShare al-gorithm is presented in the form of three basic func-tions.We assume the existence of a simple functionmaxmin ()which,given the link bandwidth and the demands of the flows,produces a vector indicating the per-flow bandwidth allocation as per the max–min fairness criterion.A packet is indicated by the variable p .In addi-tion,p.size ,p.src ,and p.dst stand,respectively,for the packet size,source and destination.The per–flow variables maintained for each long TCP flows are ly:flag i :binary flag indicating whether a loss is due on the flow.dropevent i :timestamp of last loss inflicted on the flow.count i :bytes arriving from the flow within the last RTT.rtt i :the RTT time of the flow.demand i :the flow demand (average of measured rate).share i :the flow share allocated by the fairness scheme.All flows,when first starting are assumed to be short lived.If a flow is active more than a few seconds,or has sent more than 50packets,it is revised to being assumed long lived and is upgraded to share the band-width set aside for long lived flows alone.On deciding that the flow is a long TCP flow,init long flow (Fig-ure 2)is invoked.First,the RTT value of the flow is determined via the collaboration of the routing infor-mation (line 1).The first packet arrival sample within the current RTT window is recorded (line 2).Because the demand is yet unknown,it is assumed to be un-bounded (“greedy”flow),so,technically,it is sufficient to be set as high as all the available bandwidth of theclass(line3).The introduction of the newflow re-quires the re-calculation of the shares not just forflow i,but the entire share vector4for all long TCPflows (line4).A grace period of at least one RTT is given (lines5and6)for the dropping of packets–since we need at least one measurement,i.e.,one RTT period before we can gauge an approximation of the true de-mands of theflow.The last step is to invoke the tick function to periodically check the demands of theflow.The purpose of tick(Figure3)is to perform the observation of the rate during the last RTT(line2), thus resetting the counter(line3).If the share al-located to theflow is less than its demand,then the flow needs to be regulated by introducing losses,but this is necessary only when the current rate(trans-lated into its window value)reached the correspond-ing maximum value possible as per the TCP window model of subsection3.1(line4).If this is the case,we signal to the next arrival that it has to be discarded (line5).The demand is subsequently calculated(line 9)and the new shares are calculated(line11)if the demands over all theflows cannot be satisfied with the bandwidth available to the class(line10).The next observation will occur an RTT later(line13).Finally,function upon packet arrival is the sub-stance of operations taking place when a packet of flow i arrives.The only decision taken is whether the packet ought to be enqueued or dropped.Dropping the packet is a decision based on(a)whether the tick function has determined it is time to do so,and(b)if enough time has elapsed since the last drop,because, otherwise,repeated losses within an RTT time would likely force the TCPflow to timeout and its through-put deteriorate substantially.We should note that the proper operation of Fair-Share involves knowledge of the end–to–end RTT of aflow.The RTT can be measured on-line by sam-pling the time between thefirst few packets of aflow when theflow isfirst set up,i.e.,time from SYN to SYN/ACK or until the transmission of thefirst data packet,depending on whether both upstream and downstream,or only one direction of aflow traverse the router.The on–line passive measurement(i.e., without the use of a”ping”command)and estima-tion of RTT of aflow has been studied recently in [22].Suffice is to say that the RTT can be estimated within reasonable accuracy,using a passive scheme, in thefirst few seconds of a long livedflow’s lifetime. Another aspect of FairShare’s operation is that it is keeping track of the number of packets sent by aflow 4Variables in typewriter font without the subscript i are as-sumed to represent the entire vector.within an RTT through the use of the count i vari-able.That is,FairShare is actually monitoring what is essentially the evolution of each longflow’s window size.4XCPThe design rationale of XCP[19]is based on recog-nizing the inherent weaknesses of the current TCP congestion control design.Firstly,TCP has no spe-cific and explicit congestion signal.Packet loss is in-terpreted as congestion signal.This interpretation is based on the assumption that congestion causes far more packet loss than unreliable underlying network. In fact,this assumption does not always hold in all environments,such as wireless network.The impre-cise interpretation of packet loss causes unnecessary throttling of the sending rate and waste of precious bandwidth.Secondly,loss as a congestion signal only reflects the worst case congestion scenario.With current con-gestion signaling,the sender is notified only after the buffers are overflown,which is the worst outcome of congestion.Thus,senders only provide reaction on se-vere congestion,rather than act proactively and elim-inate congestion at an early stage.Thirdly,current congestion control is slow.TCP receives only implicit congestion signals.Congestion signals are inferred by detected timeouts and persis-tent packet reordering.Both mechanisms need more time than explicit congestion signaling.Fourthly,the current congestion signal is a binary signal.It can only indicate whether congestion oc-curs or not.It cannot provide information on the de-gree of congestion.With such imprecise information, TCP senders have to react conservatively.Instead of sending at a precise available rate,TCP senders back offdrastically and recover cautiously in the presence congestion.This protocol design leads to oscillatory behavior of individual TCPflows,which is particu-larly undesirable feature when the protocol is used for delivering real time traffic.Lastly,the loss congestion signal is unreliable.The current mechanism cannot guarantee all TCP senders receive congestion signals.And the congestion signal does not provide information on how senders should react to the congestion.Thus,the reaction on conges-tion is unbalanced;some aggressive TCPflows might get significantly more bandwidth than their competi-tors.XCP accounts for the weakness of TCP by provid-ing explicit congestion signaling,precise congestion in-tick ():1.while (1)2.m ←count i /rtt i ;3.count i ←0;4.if (share i <demand i and m >avg2peak (share i ))then5.flag i ←TRUE;6.else7.flag i ←FALSE;8.endif9.demand i ←m ·β+demand i ·(1−β)10.if (i demand i >C L-TCP l )then11.share ←maxmin (demand ,C L-TCP l );12.endif13.sleep (rtt i );14.endwhileFigure 3:The tick ()function.upon packet arrival (p ):1.now ←time ();2.if (flag i and dropevent i +rtt i <now )then3.dropevent i ←now ;4.drop (p );5.else6.count i ←count i +p.size ;7.enqueue (p );8.endifFigure 4:The upon packet arrival ()function.formation,decoupled efficiency control(EC)and fair-ness control(FC),and robust design[19].Towards this end,XCP proposes a specific congestion header as an extension of the TCP header(optionalfields) to carry necessary information for congestion control, the state of eachflow,and feedback from routers. The header options provide an opportunity for the sender to disclose to intermediate routers the conges-tion window size(cwnd)and the current RTT esti-mate.The routers use this information to determine the link utilization status,and how to reassign the bandwidth towards the fairness objective.The inter-mediate routers instruct the senders to adjust their window size by stipulating feedback information in the congestion header of each packet.The informa-tion in these”congestion”headers is copied in the ac-knowledgments(ACKs)returned to the sender,thus the feedback loop is closed.With respect to the information used by XCP,we note that it includes both the current window size and,in essence,the round-trip-time,as they both are obtained from the header information that XCP re-quires TCP endpoints to support.In this respect, XCP is similar to FairShare which requires the same information.We note however that contrary to XCP that obtains this information with the collaboration (and hence the modification)of the TCP endpoints, FairShare utilizes router-based estimators for both the congestion window size and the round-trip-time.It would therefore appear that XCP and FairShare are almost equivalent with respect to complexity.Unfor-tunately,this is not the case because in XCP,the headers also convey control information back to the senders.Specifically,XCP senders update their congestion window of aflow by adding the feedback received in each and every packet to the current congestion win-dow(Equation3).The feedback contains the control information from routers.It is either positive or nega-tive,which means increasing or decreasing congestion window size,respectively.The units of feedback and window size are bits.Although feedback is mainly used as instruction supplied by the router,senders initialize the feedback at the start indicating their de-mands on bandwidth.The XCP sender algorithm is described in the following formula.The s in the for-mula(Equation3)is the length of a packet in bits.It stands for the minimum unit of updating congestion window,which is one packet.cwnd=max(cwnd+F eedback,s)(3) The operation of the congestion window adjustment in XCP is the most significant difference regarding the TCP endpoint behavior,compared to FairShare.Fair-Share does not require any particular window adjust-ment scheme at the sender,or copying of control at the recipient from incoming data packets to the ACKs sent on the reverse path.4.1XCP Fairness&Efficiency ControlA feature of XCP is the decoupling of(bandwidth) efficiency control(EC)from the(bandwidth)fairness control(FC)in the router policy.The objective of EC is to maximize the link utilization and minimize the packet dropping and thus control the queue size.The algorithm is described in(Equation4)φ=α×d×S−β×Q(4)φstands for the total feedback generated in the router within the control epoch d,where d is the aver-age RTT of allflows traversing the link.S is the differ-ence between the sum of demands of allflows and the link capacity.Q stands for persistent queue size that is obtained by smoothing from transient queue size via a simple low passfilter.Finally,αandβare opera-tional constants.Basically,the total feedback is pro-portional to the difference between expected demands of bandwidth of allflows and the actual bandwidth. To be more accurate,the feedback is also adjusted to account for the packets stored in the buffer.The Fairness Control(FC)(Equation5)is the al-gorithm for apportioning the total feedback,that is obtained in EC,to each individualflow.The basic idea of FC can be described as follows:In case of pos-itive feedback,that is,the expected total demand is smaller than actual capacity,the surplus bandwidth is apportioned to allflows equally.To increase the per-flow surplus bandwidth the increase of the sending rate is the same regardless of theflow’s RTT.In case of negative feedback,that is,the expected total demand exceeds the actual capacity,allflows reduce their send-ing rate by the same fraction.Feedback apportioned to the individualflow is uniformly distributed to all packets from that particularflow that will be handled by the router during the next control epoch,of length d time units.The positive and negative feedback com-ponents are communicated back to the sender in the feedback ly,for each packet from flow i the feedback indicated in the packet header is:F eedback=p i−n i(5) where p i is the”positive”component and the n i is the ”negative”component of the feedback.Ifφ(the totalfeedback)is positive,φ>0,it means that the linkis underutilized,and thus we have spare bandwidthto distribute.In XCP,such spare bandwidth is dis-tributed equally among the activeflows.That is,therate increase of eachflow should be the same,leadingto the following:∆r=∆r1+∆r2+...+∆r n∆r1=∆r2=...=∆r nHere,∆r is the total increase rate(spare bandwidth,φd )in one epoch,and∆r i stands for the increased rateforflow i.n stands for the number of activeflows.From the above two equations,we also have∆r i=∆rn=φndand it can be found after some algebra that:p i=ξp∗rtt2i cwnd iwhereξp=φd∗all packets in epoch drtt icwnd iWhenφ<0,congestion has occurred.That is, the total demands for bandwidth exceeds the link ca-pacity.In XCP FC policy,everyflow should reduce its rate by the same fraction.Suppose f is the com-mon reduction factor,we translate the policy into the following formulas:∆r=∆r1+∆r2+...+∆r n∆r i=r i∗f=cwnd irtt i∗fand after some algebra wefind:n i=ξn∗rtt iandξn=φd∗(#packets in d)It thus appears that XCP’s advantage is in simpli-fying the router operation.XCP’s claim is that it does not need to maintain a record for each one of the in-dividualflows traversing a link,i.e.,no per–flow state. Namely,ξp can be calculated by adding up the RTT over cwnd rations of each packet that arrived since the last control epoch.Similarly,ξn appears to be calculated by counting the packets that arrived since the last epoch.We note two caveats though:(a)the value of d is the average RTT,and the means to ob-tain it are not clear,and certainly calculating it at the router is not the suggested way for XCP as it would require per-flow state,and(b)there is no clear indica-tion that the max–min fairness is indeed attainable by XCP.To settle(a)we will assume that off-line infor-mation exists on the average RTT.It is not unreason-able to assume that an off-line statistical processing of the”typical”workload,is the source of the aver-age RTT value,d.We will also consider the fact that FairShare isolates the short from the long livedflows, while XCP does not.Hence,to the points(a)and(b) we add,(c),the appearance that XCP can operate on short and long livedflows alike.This is a matter of definition for XCP:by not possessing per-flow state,it cannot distinguish short from long livedflows–indeed it possesses no notion of a”flow”anyway.Instead it deals with each packet individually without concern whether it came from a short or long livedflow.5Simulation ResultsIn this section we present two sets of the most rep-resentative results that illustrate the shortcomings of XCP compared to FairShare.The results should be seen in the context of the corresponding complexity. That is,both XCP and FairShare require RTT and window size information from theflows.Whereas XCP requires the cooperation of the endpoints in the adjustment of the window size using special feedback information,FairShare does not.At the same time, FairShare requires per–flow state information which, in principle anyway,is avoided by XCP.This last dif-ference is weakened by the fact that XCP requires a reliable estimate of the average RTT over allflows, which is not available by the endpoints alone without some substantial cooperation from the routers.5.1Fairness for Mixed RTTsIn the experiments we consider a simple”dumbell”topology with a single bottleneck link.The bottleneck link rate is4500packets per second.Severalflows ar-rive,after experiencing different propagation delays, to the bottleneck link.We study the fraction of the bandwidth obtained by each TCPflow as a function of the discrepancy of the RTTs between theflows.The simulations for XCP were conducted with the code provided from[19]using ns2version2.1b9[12].We vary the difference between RTTs from0to100ms. That is,we assign RTTs that are t time units apart where t varies from0to100msec.We also conduct。