Maximum and Asymptotic UDP Throughput under CHOKe

Transcription

1 Maximum and Asymptotic UDP Throughput under CHOKe Jiantao Wang Ao Tang Steven H. Low California Institute of Technology, Pasadena, USA ABSTRACT A recently proposed active queue management, CHOKe, aims to protect TCP from UDP flows. Simulations have shown that as UDP rate increases, its andwidth share initially rises ut eventually drops. We derive an approximate model of CHOKe and show that, provided the numer of TCP flows is large, the UDP andwidth share peaks at e+1) 1 =.269 when the UDP input rate is slightly larger than the link capacity, and drops to zero as UDP input rate tends to infinity, regardless of the TCP algorithm. Categories and Suject Descriptors I.6.4 [Simulation and Modelling]: Model Validation and Analysis; C.2.5 [Computer Systems Organization]: Local and Wide-Area etworks General Terms Performance,Theory Keywords CHOKe, AQM, UDP, TCP,Bandwidth Share 1. ITRODUCTIO TCP is elieved to e largely responsile for preventing congestion collapse while Internet has undergone dramatic growth in the last decade. Indeed, numerous measurements have consistently shown that more than 9% of traffic on the current Internet is still TCP packets, which, fortunately, are congestion controlled. Without a proper incentive structure, however, this state of affair is fragile and can e disrupted y the growing numer of non-rate-adaptive e.g., UDP-ased) applications that can monopolize network andwidth to the detriment of rate-adaptive applications. This has motivated We acknowledge the support of SF through grants AI and AI-23967, and ARO through grant DAAD Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distriuted for pro t or commercial advantage and that copies ear this notice and the full citation on the rst page. To copy otherwise, to repulish, to post on servers or to redistriute to lists, requires prior speci c permission and/or a fee. SIGMETRICS 3, June 1 14, 23, San Diego, California, USA. Copyright 23 ACM /3/6...$5.. several active queue management schemes, e.g., [6, 2, 3, 1, 7, 9, 1], that aim at penalizing aggressive flows and ensuring fairness. The scheme, CHOKe, of [9] is particularly interesting in that it does not require any state information and yet can provide a minimum andwidth share to TCP flows. The asic idea of CHOKe is explained in the following quote from [9]: When a packet arrives at a congested router, CHOKe draws a packet at random from the FIFO first in first out) uffer and compares it with the arriving packet. If they oth elong to the same flow, then they are oth dropped; else the randomly chosen packet is left intact and the arriving packet is admitted into the uffer with a proaility that depends on the level of congestion this proaility is computed exactly as in RED). The surprising feature of this extremely simple scheme is that it can ound the andwidth share of UDP flows regardless of their arrival rates. In fact, as the arrival rate of UDP packets increases without ound, their andwidth share approaches zero! An intuitive explanation is provided in [9]: the FIFO first-in-first-out) uffer is more likely to have packets elonging to a misehaving flow and hence these packets are more likely to e chosen for comparison. Further, packets elonging to a misehaving flow arrive more numerously and are more likely to trigger comparisons. As a result, aggressive flows are penalized. This however does not explain why a flow that maintains a much larger numer of packets in the queue does not receive a larger share of andwidth, as in the case of a regular FIFO uffer. In [11], a detailed differential equation model of CHOKe is derived that clarifies the spatial characteristics of a leaky uffer. It is shown there that UDP packets are not uniformly distriuted across the length of the queue. Instead, as UDP rate increases, even though the total numer of UDP packets in the queue increase, the spatial distriution of UDP packets ecomes more and more concentrated near the tail of the queue, and drops rapidly to zero toward the head of the queue. When a single UDP flow shares a link with TCP flows, the numer of UDP packets in the queue is almost times that of a TCP flow, in the limit as UDP input rate tends to infinity. Despite their numer, most of the UDP packets are dropped efore they advance to the head. As a result the UDP andwidth share drops to zero, in stark contrast to a non-leaky FIFO queue where UDP andwidth shares approaches 1 as its input rate increases without ound. Though the model of [11] provides detail structural properties of TCP/CHOKe, it is too 82

2 complex to solve analytically for the maximum throughput attainale y the UDP flow. In this paper, we derive an approximate model of CHOKe and use it to derive the maximum and asymptotic UDP throughput. In Section 2 we present an algeraic model that allows us to numerically compute performance metrics, such as throughput, delay and loss proailities. In Section 3, we prove analytically that, provided that the numer of TCP flows is large, the maximum andwidth share attainale y the UDP flow is e +1) 1 =.269 and that this is attained when the UDP rate is 2e 1)/e+1) = times the link capacity approximately, when the congestion ased dropping proaility is small). Moreover, it drops to zero as UDP rate increases without ound. The same results are also otained in [8], independently using a different method. These results are intrinsic to CHOKe and insensitive to the specific algorithms of TCP, the round trip delay, and congestion ased dropping such as RED. We present ns simulations to validate these conclusions in Section CHOKE MODEL The asic idea of CHOKe is summarized in Section 1. A flow chart descriing its implementation with RED is given in Figure 2 from [9]. Y Admit ew Packet End Y Drop oth packets End Arriving Packet AvgQsize<=Minth? Both packets from same flow? Y Admit packet with a proaility r End Draw a packet at random from queue AvgQsize<=Maxth? Drop the new packet Figure 1: CHOKe flow chart from [8]. In general, one can choose more than one packet from the queue, compare all of them with the incoming packet, and drop those from the same flow. This will improve CHOKe s performance, especially when there are multiple unresponsive sources. It is suggested in [9] that more drop candidate packets e used as the numer of unresponsive flows increase. Here, we focus on the modeling of a single candidate drop packet. The analysis can e extended to the case of multiple drop candidates. The general setup for our model and our simulations is shown in Figure 2. There is a single ottleneck link with capacity c packets per second. We focus on the FIFO uffer at router R1 where packets are queued. The uffer is shared End TCP sources S1 S2 S3 S UDP UDP source R1 c R2 Figure 2: etwork topology TCP destinations D1 D2 D3 D UDP UDP sink y TCP flows and a single UDP flow. The TCP flows have round trip propagation delays d 1,d 2,...,d seconds respectively. We assume the system is stale and model its equilirium ehavior. 2.1 otations Quantities rate, acklog, dropping proaility, etc) associated with the UDP flow are indexed y. Those associated with TCP flows are indexed y 1,...,. These are equilirium quantities which we assume exist. Recall the setting c,, d i,i =1,...,)wherec is the link capacity, is the numer of TCP flows, and d i,arethe round-trip propagation delays of TCP flows. We collect here the definitions of all the variales and some of their ovious properties: i: packet acklog from flow i, i =,...,. : total acklog, = i= i. τ: common queueing delay. The round-trip delay for flow i is d i + τ. r: Congestion-ased dropping proaility. Maximum and asymptotic UDP throughput are insensitive to the specific algorithm, such as RED, to compute this proaility, as long as it is the same for all flows. In general, r = g, τ) for some function g as a function of aggregate acklog and common queueing delay τ. h i: p i: The proaility of incoming packets eing dropped y CHOKe for flow i, i =,...,: h i = i overall proaility that packets of flow i, i =,...,, is dropped efore it gets through, either y CHOKe or congestion ased dropping: p i = 2h i + r 2rh i 1) The explanation of 1) is provided elow. x i: source rate of flow i, i =,...,. Maximum and asymptotic UDP throughput are insensitive to the specific TCP algorithm, such as Reno or Vegas. In general, x i = f ip i,τ) for some function f i as a function of overall loss proaility p i and queueing delay τ at equilirium, i =1,..., 83

3 We make two remarks. First, it is important to keep in mind that x is the only independent variale; all other variales listed aove are functions of x, though this is not made explicit in the notations. Second, x i is the sending rate of flow i. The rate at which flow i packets enter the tail of the queue after going through CHOKe and congestion ased dropping) is x i1 h i)1 r), and the rate at which flow i packets exit the queue throughput) is x i1 p i). Clearly, x i1 p i) x i1 h i)1 r) x i. 2.2 Model We make three key approximations in our model. The first approximation, descried next, yields an algeraic model that allows us to numerically compute performance metrics such as throughput, loss proailities, and queueing delay. The other two approximations, descried in the next section, lead to a simple method to estimate the maximum and asymptotic UDP throughput under CHOKe. A packet may e dropped, either on arrival due to congestion e.g., according to RED) or CHOKe, or after it has een admitted into the queue when a future arrival from the same flow triggers a comparison. We approximate the system y one in which the order of congestion ased dropping and CHOKe is reversed: a packet is admitted with proaility 1 r, and if it is admitted, it is then compared with a packet randomly chosen from the queue and dropped with proaility h i. With this approximation, the proaility that a packet from flow i is eventually dropped is given y 1). To see this, note that every arrival from flow i can trigger either packet loss, 1 packet loss due to congestion, or 2 packet losses due to CHOKe. These events happen with respective proailities of 1 h i)1 r), r, and1 r)h i.hence,each arrival to the uffer is accompanied y an average packet loss of 21 r)h i + r + 1 h i)1 r) and hence the overall loss proaility p i in 1). 1 This implies that the proaility that a packet of flow i goes through the queue without eing dropped is: 1 p i = 1 r)1 2h i) 2) We now derive this proaility from another perspective. Consider a packet of flow i that eventually goes through the queue without eing dropped. The proaility that it is not dropped on arrival is 1 r)1 h i). Once it enters the queue, it takes τ time to go through it. In this time period, there are on average τx i1 r) packets from flow i that survive congestion ased dropping and arrive at the queue. The proaility that this packet is not chosen for comparison is 1 1 ) τxi 1 r) 1 The overall loss proaility for the original CHOKe algorithm is see [11]): p i = 2h i + r rh i which is larger than the approximate loss proaility given y 1) ecause a packet that is first dropped due to congestion saves a potential loss of two packets due to CHOKe. The difference however is small since oth r and h i are typically small. Hence, the overall proaility that a packet of flow i survives the queue is 1 p i = 1 r)1 h i) 1 1 ) τxi 1 r) 3) We will equate p i in 2) and 3) to derive an equation which is one of the two) key equations that allow us to estimate the maximum and asymptotic UDP throughput see Section 3). A simple interpretation of a leaky uffer is as follows: x i is the source rate of flow i and x i1 r)1 h i)isthe rate at which flow i enters the queue after congestion-ased dropping and CHOKe. This flow splits into two flows: one eventually exits the queue and the other is dropped inside the queue y CHOKe. The rate of the former flow is flow i s throughput x i1 p i)=x i1 r)1 2h i)andtherateof the latter flow is its leak rate x i1 r)h i, so that they sum to the input rate x i1 r)1 h i). Since the link is fully utilized, the flow throughput sum to link capacity: x 1 p )+ x i1 p i) = c 4) This completes the description of the model. In summary, the independent variale is UDP rate x. The dependent variales of the model are: acklogs i of flow i, i =,...,; total acklog = i= i. congestion ased dropping proaility r, CHOKe dropping proailities h i, and overall dropping proailities p i, i =,...,. TCP rate x i, i =1,...,. queueing delay τ. The relations among these variales define our model. For ease of reference, we reproduce these ten equations here: 1 p i = 1 r)1 2h i), i =,..., 5) 1 p i = 1 r)1 h i) 1 1 ) τxi 1 r) 6) h i = i, i =,..., 7) c = x 1 p )+ x i1 p i) 8) = i 9) i= x i = f ip i,τ), i =1,..., TCP) 1) r = g, τ) e.g. RED) 11) We assume that this set of equations has a solution for x i,τ,r,,, i,h,h i,p,p i,i = 1,...,), once the TCP algorithm x i = f ip i,τ) and AQM algorithm r = g, τ) are specified, and that the limits of these quantities as x exist. Our goal is to compute the maximum and asymptotic values as x ) of UDP throughput x 1 p ). We now show that if is large, then only three equations are needed for this calculation the two equations 5) 6) for 84

4 i = and a new equation 13) elow that replaces 5) 7) for i =1,...,). It suggests that these are intrinsic properties of CHOKe and are insensitive to TCP/AQM algorithms f i,g). 3. THROUGHPUT AALYSIS The second key assumption we make is that is large. Since i h i = + j=1 j we assume for TCP sources that h i is on the order of 1/, so that h i when is large, for i = 1,...,. Then a comparison triggered y a TCP packet arrival seldom yields a match. This means that, once in the queue after congestion ased dropping), a TCP packet will never e dropped. The overall dropping proaility p i then reduces to sustitute h i = into 1)): p i = r, i =1,..., More importantly, this provides a simple relation etween queueing delay, throughput and acklog. Since there is no leaking for TCP packets in the uffer, the throughput rate for TCP flow i is x i1 p i),i =1,...,. There are i packets in the uffer from this TCP flow i. Then Little s Theorem implies: i τ = for i =1,..., 12) x i1 p i) From the condition 8) of full link utilization, the aggregate TCP throughput is xi1 pi) =c x1 p). The aggregate numer of TCP packets in the uffer is i = = 1 h ). Summing the numerators and denominators on the right side of 12) over i =1,...,,weget: τ = i xi1 pi) = 1 h ) 13) c x 1 p ) This assumption makes the estimate of UDP throughput insensitive to TCP algorithms. ote that with this assumption, the model 5) 11) is simplified to dependent variales x i,τ,r,,, i,h,p, i = 1,...,), with h i =andp i = r, i =1,...,, and equations with the three equations 5) 7) for i =1,..., replaced y the single equation 13). The third key approximation we make is that the total acklog is large so that 1 1 ) e 1 Equating 1 p i in 5) and 6) for i =,wehave 1 1 ) τx 1 r) = 1 2h 14) 1 h Sustituting 13) into 14) to eliminate τ, and apply the third approximation, we have ) 1 h x1 r)1 h ) = exp 15) 1 2h c x 1 r)1 2h ) where we have used 5). This equation yields the maximum and asymptotic UDP throughput. Theorem The maximum UDP andwidth share is µ =e +1) 1 = It is attained when the UDP input rate after congestion ased dropping is x 1 r ) = c2e 1)/e +1) = 1.193c. 3. In this case, the CHOKe dropping rate for UDP is h =e 1)/2e 1) =.387. Proof. Denote UDP andwidth share y using 5)) µ := 1 p ) x c Then rewrite 15) as Let γh ) denote 1 h 1 2h = exp = 1 r)1 2h ) x c 1 h 1 2h µ 1 µ ) 16) γh ) := 1 h 1 2h 17) Then 16) ecomes: or γh ) = e γh ) µ 1 µ ln γh ) µ = 18) γh )+lnγh ) It is easy to check that the right-hand side has a unique maximum at γh )=e with maximum andwidth share µ given y µ max γ ln γ γ +lnγ = 1 1+e =: µ 19) Sustituting γh )=e into the definition 17) of γh ), the maximum UDP andwidth share is attained when the CHOKe dropping proaility h for UDP is h = e 1 2) 2e 1 Since h = /, this implies that 39% of the queue are UDP packets when UDP attains the highest throughput. Since µ = x 1 r )1 2h )/c, the UDP rate after congestion ased dropping, x 1 r ), that attains the maximum throughput is x 1 r ) = µ c 1 2h Sustituting 19) and 2), we have x 1 r ) = 2e 1 e +1 c The next result says that the UDP throughput x 1 p ) drops to zero as UDP rate x grows without ound, under the assumption that rates x i under TCP algorithm remains finite when loss proaility p i ecomes large, i.e., lim pi 1 f ip i,τ) <, i = 1,...,. This assumption is always satisfied when TCP flows are controlled not to send packets infinitely fast when the capacity is fixed. 85

5 Theorem 2. Suppose lim pi 1 f ip i,τ) <,,...,. As x, /2 ut µ. Proof. ote that from 5), h = 1 2 p r 1 r 1 2 since p 1. We argue that / = h 1/2 asx. From 8), we have x 1 p ) c for all x. Hence p 1 as x. Hence from 5), we have 1 r ))1 2h )) = where all limits exist y assumption) r ) := lim r x and h ) := lim x h Hence either r ) = 1 or h ) = 1/2. If r ) = 1, then lim x p i = r ) =1, i =1,...,. This implies that x i = f ip i,τ) < as x. The condition of full link utilization 8) then implies that UDP throughput x 1 p )=c. This violates Theorem 1. Hence r ) < 1 and h ) =1/2. Then γ from 17), and hence, using 18), µ. We visualize equation 15) in Figure 3. It illustrates oth theorems aove. µ UDP andwidth share Peak Value β=x 1 r)/c Figure 3: µ v.s. x 1 r)/c We close this section y presenting another way to derive the key equation 14). The rate of flow i is x i1 r)1 h i) when it first enters the tail of the queue after congestionased dropping and CHOKe, and it takes τ seconds for packets to reach the head of the queue. After traveling down the queue for t seconds, t τ, the packets arrive at a certain point yt) [,], where it has een thinned y a factor 1 1/) xi1 r)t following the same argument that leads to 3)) and the rate of the flow at yt) is x it) := x i1 r)1 h i) 1 1 ) xi 1 r)t Hence x it)dt is the infinitesimal volume of the fluid at the point yt) in the queue, and the acklog from flow i is thus τ i = x i1 r)1 h i) 1 1 ) xi 1 r)t dt If we approximate 1 1/) y e,whenis large, then the aove integral reduces to i = 1 h i) 1 ) e x i1 r)τ/ In particular, since h = /, this implies 1 2h = e x 1 r)τ/ 1 h This is equivalent to 14) when we approximate 1 1/) y e SIMULATIOS In this section, we present simulation results to validate our model 5) 11) and throughput analysis. We implemented a CHOKe module with RED in ns-2 version TCP/AQM algorithms The model for RED dropping proaility is r = k ) where k := p max/ ) is the slope of the RED drop profile. We chose parameters of our simulations so that the equilirium queue length always lied etween the minimum queue threshold and the maximum queue threshold. We have conducted simulations with TCP ewreno,tcp Vegas and a modified Vegas to verify that the UDP throughput is insensitive to TCP algorithms. TCP Reno or its variants such as ewreno or SACK) is modeled y the following relation etween the equilirium source rate x i, the overall dropping proaility p i, and the round trip time d i + τ see e.g., [4]): p i = 2 2+x 2 i di + τ)2 This is equivalent to the well-known square-root-p formula when the loss proaility is small. For TCP Vegas, the source rate x i is related to the round trip propagation delay d i and queueing delay τ in equilirium according to see [5]): x i = αdi 21) τ where α is a protocol parameter. In equilirium, the ith Vegas source puts αd i numer of packets in the queue and hence the total numer of TCP packets in the queue is αdi. Under the large- assumption where TCP packets are not leaked from the queue, the queueing delay, given y 13), is then τ = αdi 22) c x 1 p ) Since x 1 p ) = oth when x =orwhenx = Theorem 2), queueing delay under TCP Vegas is small oth whenudprateissmallandwhenitislarge. Thisinteresting prediction is verified y the simulation elow. ote that the model 21) 22) of Vegas assumes a Droptail router that has a large enough uffer capacity to accommodate the αdi packets that Vegas sources attempt to keep in the network, so that there are no packet loss in equilirium; see [5]. RED and CHOKe dropping violates this assumption. As a result, Vegas reacts more or less like 86

6 Reno: halving its window on each drop and increases it y one packet per round trip time. We present simulation results with three TCP implementations, ewreno, Vegas, and modified Vegas. In modified Vegas, the source does not halve its sending window when there is a loss. In all our simulations large uffer capacity is used so that all packet drops are due to RED or CHOKe. Since modified Vegas uses only queueing delay as congestion feedack, the equilirium ehavior of modified Vegas matches well the model 21) 22). We will see that the throughput share µ as a function of UDP rate x 1 r)/c is insensitive to these TCP implementations. Our simulations focus on TCP Vegas oth to show that UDP throughput is insensitive to TCP algorithm and ecause TCP Vegas scales etter than TCP Reno with respect to link capacity, especially under CHOKe. This is ecause CHOKe increases the overall loss proaility, limiting the achievale rate of TCP Reno. Since TCP Vegas sets its rate ased on queueing delay, it does not have this limitation. 4.2 Simulation setup We simulated the network in Figure 2 to study the equilirium ehavior of CHOKe. There is a single ottleneck linkfromrouterr1torouterr2sharedy = 1 TCP sources and one UDP source. The UDP source sends data at a constant rate. The link capacity is fixed at c = 15Mps for all simulations. We use RED+CHOKe as the queue management with RED parameters: min th = 2pack- ets, max th = 12 packets, p max =.1). Packet size is 1KBytes. The simulation time is 2 seconds. The original Vegas implementation in ns-2 works poorly in a lossy environment, for two reasons. First the implementation estimates RTT naively y setting it to the difference etween sending time of a packet and receiving time of its ACK. When packets are lost, the ACK may e a duplicate ACK or it may e triggered y the retransmitted packet. A more sophisticated estimation is required when losses are frequent. Second, when there are multiple losses in the same round trip time, which is not infrequent since CHOKe drops two packets every time a comparison yields a match, the Vegas implementation often incurs timeout and slow-start. As a consequence, we implemented a modified Vegas module in ns-2 ased on the ewreno code which etter handles losses. There are three major changes. First, we do not estimate RTT with duplicate ACKs, especially with the first and second duplicate ACKs when fast retransmit/fast recover phase is not yet entered. Second we use the ewreno s fast retransmit and fast recovery code to deal with multiple losses. Third, we change the Vegas code such that it only response to queueing delay not loss. These changes should not affect the equilirium ehavior of the TCP algorithms. In our simulations, we vary UDP sending rate x from.1c =1.5Mps to 1c = 15Mps. We measure the following quantities, and compare with the numerical solutions of 5) 11): 1. ormalized UDP andwidth share µ = x 1 p )/c. 2. aggregate queue size 3. round-trip time d i + τ The results illustrate oth the equilirium ehavior of CHOKe and the accuracy of our analytical model. They show the aility of CHOKe to protect TCP flows and agree with those aggregate measurements of [9]. We next discuss these results in detail. 4.3 Simulation results We show two sets of results. The first set presents measurements of uffer size, queueing delay and throughput share using the modified Vegas with identical flows. It validates our model. The second set validates Theorems 1 and 2, and confirms that UDP share µ is insensitive to TCP algorithms, RED parameters, and round trip delay Equilirium properties Since extensive simulation results have een previously reported in [9] and [11] with TCP Reno, we focus here on modified Vegas which matches model 21) 22) well. In the simulations of modified Vegas in this susection, a common round trip delay d =1ms is used. We set α such that each source tries to put αd = 2 packets in the uffer. The system is stale and converges to a steady state modulo random fluctuations) very quickly. A sample queue size and congestion window are given in Figure 4, for UDP rate x = 15Mps, one of the data points in Figure 5. Queue size pkts) Congestion window pkts) Simulation time sec) a) Queue size v.s. time Simulation time sec) ) Congestion window v.s. time Figure 4: Example queue size and congestion window under modified Vegas 87

7 Figure 5 illustrates the effect of UDP rate x on queue size and queueing delay under modified Vegas. Each of the Similarly there are three curves from ns-simulation, complete model, and simplified model. The curve corresponding to the simplified model is marked as Intrinsic UDP andwidth share, and is the same curve in Figure 3, ecause its calculation does not depend on specific TCP algorithm f i,or AQM algorithm g, or delay values. It is calculated using equation 15). The complete model matches the simulation etter, ut the prediction from the intrinsic curve is also acceptale. Queue size pkts) Simulation Complete model Simplified model UDP sending rate/link capacity x /c a) Queue size µ UDP andwidth share Simulation andwidth share Complete Model andwith share Intrinsic UDP andwidth share β=x 1 r)/c Round trip delay sec) Complete Model Simulation Simpplified model UDP sending rate/link capacity x /c ) Round trip time τ + d Figure 5: Effect of UDP rate x on queue size and queuing delay under modified Vegas. = 1, d = 1ms, c =15Mps, x =.1c to 1c, simulation duration = 2sec. figures shows three curves: measurements from ns-2 simulations, numerical solution of the complete model 5) 11), and that ased on the simplified model descried at the eginning of Section 3. The difference etween the numerical solutions of the complete model and that of the simplified model is negligile. The error etween simulation results and the numerical solutions is always less than 5 percent. When UDP rate x is small, the queue size is close to αd = 2pkts. The aggregate queue length steadily increases as UDP rate x rises. It will approach 4pkts if there were no RED dropping ecause when UDP rate is very large, UDP packets take up half of the queue see proof of Theorem 2) and there are aout αd = 2 Vegas packets in the uffer = 1 is large). With RED dropping, the value is slightly less than 4pkts. As discussed in Section 4.1, the queueing delay is small oth when x =.1c and when x =1c. The UDP andwidth share is shown in Figure 6. Figure 6: UDP andwidth share µ v.s. UDP rate after RED dropping x 1 r)/c Throughput share The second set of results, shown in Figure 7, illustrates the UDP andwidth share for three TCP implementations: ewreno, modified Vegas, and original Vegas. Each sufigure has two curves: from simulation, and from the simplified model. The curves from the model are the same curve in Figure 3, and hence different TCP implementations yield similar simulation curves. The 1 sources have various propagation delays with 1 sources at each of the 5, 6,...,14ms delay values. Figure 8 shows the corresponding curves for theoriginalvegaswhenallsourceshavethesamedelayof 1ms. Comparing Figures 6, 7, and 8, we see that the throughput share is sensitive neither to TCP implementation nor propagation delay. Theorems 1 and 2 predict that the UDP andwidth share peaks at around.269 and tends to zero as x increases. Simulation shows a slightly smaller peak UDP share. The discrepancy is proaly due to the approximations we made in our model. Finally, the UDP andwidth share with a different slope of RED s drop profile is shown in Figure 9. The RED parameters are : min th = 2 packets, max th = 42 packets, p max =.1). Herewehavemodified from 12 to 42 to get a steeper slope of the drop profile than used in earlier simulations. The sources are ewreno with the same delay values as the previous set of simulations. It shows that the andwidth share is almost independent of RED parameters. 5. COCLUSIO We have developed an analytical model of CHOKe which is not only much simpler to solve numerically than the previous model of [11], ut also allows us to compute analytically 88

8 Sharing Curve of Heterogeneous Reno Sources.25 Share Curve of Original Vegas µ UDP andwidth share Intrinsic UDP andwidth share Simulation andwidth share β=x 1 r)/c a) ewreno: d i =5, 6,...,14ms Sharing Curve of Heterogeneous Vegas Sources µ UDP andwidth share Intrinsic UDP andwidth share Simulation andwidth share β=x 1 r)/c a) Original Vegas: d i = 1ms µ UDP andwidth share Figure 8: UDP andwidth share µ : Original Vegas, d i =1ms for all sources, =1, c =15Mps..5 Intrinsic UDP andwidth share Simulation andwidth share β=x 1 r)/c ) Modified Vegas: d i =5, 6,...,14ms Share curve with different RED parameter Sharing Curve of Original Vegas with Heterogeneous Sources µ UDP andwidth share µ UDP andwidth share Intrinsic UDP andwidth share Simulation andwidth share β=x 1 r)/c c) Original Vegas: d i =5, 6,...,14ms Figure 7: UDP andwidth share µ as a function of UDP rate after RED dropping x 1 r)/c. = 1, c =15Mps. Intrinsic UDP andwidth share Simulation andwidth share β=x 1 r)/c Figure 9: UDP andwidth share µ : different RED configuration, ewreno. 89

9 the maximum and asymptotic throughput. In particular, we prove that UDP andwidth share peaks at e+1) 1 =.269 when UDP rate is slightly larger than link capacity, and drops to zero when UDP rate approaches infinity. The models and results here and in [11] complement each other. Here, we compute the macroscopic properties of CHOKe. The differential equation model of [11] provides detail spatial characters of a leaky uffer that explain the mechanism through which these properties are produced. 6. REFERECES [1] W. Feng, K G. Shin, D. Kandlur, and D. Saha. Stochastic Fair Blue: A queue management algorithm for enforcing fairness. In Proceedings of IFOCOM, April 21. [2] S. Floyd and V. Jacoson. Random early detection gateways for congestion avoidance. IEEE/ACM Trans. on etworking, 14): , August ftp://ftp.ee.ll.gov/papers/early.ps.gz. [3] Dong Lin and Roert Morris. Dynamics of random early detection. In Proceedings of SIGCOMM 97, pages , Septemer http: // [4] Steven H. Low. A duality model of TCP and queue management algorithms. IEEE/ACM Trans. on etworking, to appear, Octoer [5] Steven H. Low, Larry Peterson, and Limin Wang. Understanding Vegas: a duality model. J. of ACM, 492):27 235, March [6] P. McKenny. Stochastic fairness queueing. In Proceedings of Infocom, pages , 199. [7] T. J. Ott, T. V. Lakshman, and L. Wong. SRED: Stailized RED. In Proceedings of IEEE Infocom 99, March ftp://ftp.ellcore.com/pu/tjo/sred.ps. [8] Rong Pan, Chandra air, Brian Yang, and Balaji Prahakar. Packet dropping mechanisms: some examples and analysis. In Proc. of 38th Annual Allerton Conference on Communication, Control, and Computing, Octoer 21. [9] Rong Pan, Balaji Prahakar, and Konstantinos Psounis. CHOKe: a stateless AQM scheme for approximating fair andwidth allocation. In Proceedings of IEEE Infocom, March 2. [1] I. Stoica, S. Shenker, and H. Zhang. Core-stateless fair queueing: achieving approximately fair andwidth allocations in high speed networks. In Proceedings of ACM Sigcomm, [11] Ao Tang, Jiantao Wang, and Steven H. Low. Understanding CHOKe. In Proc. of IEEE Infocom, April