Gateway Algorithm for Fair Bandwidth Sharing

Transcription

1 Algorm for Far Bandwd Sharng We Y, Rupnder Makkar, Ioanns Lambadars Department of System and Computer Engneerng Carleton Unversty 5 Colonel By Dr., Ottawa, ON KS 5B6, Canada {wy, rup, oanns}@sce.carleton.ca Ioanns Marmorkos Department of Informatcs and Telecommuncatng Larsa Insttute of Technology Larsa, 4, Greece marmorkos@telar. Abstract In s paper we propose a Vrtual Round Robn () gateway algorm to enforce per-flow far bandwd allocaton by keepng per-flow nformaton. Ths mechansm acheves reasonably far bandwd allocaton and s easly amenable to hgh-speed mplementatons. It uses a sngle FIFO queue w probablstc drop-on-arrval. In our smulaton study, we compare e performance w oer two algorms, Random Early Detecton () and Flow Random Early Drop () []. Our smulaton results show at outperforms and n wde varety of scenaros. Keywords-Bandwd Allocaton; Congeston Control; Algorm; I. INTRODUCTION Mechansms at can farly allocate bandwd n e gateways can provde end users an ncentve to be adaptve to network congeston and are crtcal for Internet congeston control [6][7]. An approach for e gateway would en be to use per-flow queung and schedulng[4][9]. Ths approach can ensure farness, but t does not scale well consderng at many flows pass rough an Internet gateway. To reduce e complexty and ncrease effcency, e IP gateways usually use a sngle frst-n frst-out (FIFO) packet queue shared by all flows. They provde feedback to senders by dscardng packets under overload. Random Early Detecton ()[][5] uses randomzaton to ensure at all connectons encounter e same loss rate. However, s equal drop probablty does not lead to equal bandwd share. Anoer approach s to use perflow nformaton, not per-flow queueng and schedulng [][]. Ths approach uses sngle FIFO queue for packets from all arrvng flows, but counts e number of arrvng/departng packets of each actve flow, and calculates ts buffer occupancy. Ths per-flow nformaton s used to dfferentate droppng probablty among connectons. Flows w dfferent buffer occupancy have dfferent drop probabltes. Flow Random Early Drop () [] s e example of s approach. Ths approach has consderable less complexty an e mplementaton of per-flow queung and schedulng, us provdes an ntermedate soluton between and per-flow queung. We present a gateway algorm at provdes far bandwd allocaton to e dfferent flows passng rough e gateway. The proposed scheme, Vrtual Round Robn (), apples dfferent drop probablty to each flow by lookng at ts state so at each flow s servced w ts far share and excess packets are dropped. Ths mechansm acheves reasonably far bandwd allocaton. As shown n e smulatons, can acheve better farness an. It also has smlar complexty as and s easly amenable to hgh-speed mplementatons. It uses a sngle FIFO queue w probablstc drop-on-arrval; when a packet arrves eer e packet s dropped or placed on a FIFO queue. The droppng decsons are smple w O () complexty. Contrastng w, e per-flow states of are not e actual buffer occupancy of each flow, but e vrtual buffer occupancy of each flow as f all flows were servced n far round robn fashon. The gateway algorm s gven n secton. The algorms of makng drop decson upon packet arrval and of flow states management are ntroduced. In secton, e smulaton results analyss and performance evaluaton are presented. We compared e performance of under a varety of scenaros to two oer gateway algorms: and [][]. II. VIRTUAL ROUND ROBIN () In, e gateway can recognze packets from dfferent flows. All packets accepted wll be enqueued to a sngle FIFO queue. However, e number of packets accepted from each actve flow s accounted. For each flow, mantans two per-flow varables, qlen and strke. qlen represents e vrtual buffer occupancy of flow and strke ndcates wheer flow s responsve to congeston. The per-flow state qlen s of are not e actual buffer occupancy of each flow, but e number of buffered packets as f all flows were servced n far round robn fashon. The value of qlen s decrease w e far share rate of flow, and s ncreased when e packets from flow are accepted. Thus, e value of qlen represents e sze of sub-queue as f all e flows have er own sub-queue and are servced n a round-robn fashon. Alough all e packets are actually servced n sngle FIFO queue, e drop probablty of flow s calculated based on e value of qlen. Thus, s gateway wll have e same drop behavor as e gateway w per-flow queueng and schedulng. Snce all e packets accepted wll be eventually transmtted, e bandwd dstrbuton s actually determned by how e packets get dropped. Ths algorm can acheve smlar performance as gateway algorms w per-flow IEEE Communcatons Socety /4/$. (c) 4 IEEE

2 schedulng n bandwd allocaton, but w sgnfcantly less complexty. A. Packet Drop algorm for mn : mnmum reshold of max : maxmum reshold of max p: maxmum droppng probablty of w q : e weght of Exponental Weghted Movng Average q lm: Buffer sze mn_ q =4: e mnmum value of qlen wout packet loss Global Varables: qlen: total queue sze avg: e average of qlen max Flow: ndex of e vrtual queue at have e most buffered packets Nact: No. of actve flow Per-flow Varables: qlen : vrtual queue sze of flow strke : f e value s, flow can have no more an mn_ q packets buffered For each arrvng packet from flow : Calculate e avg; Compute e drop probablty P based on algorm; //when buffer overflow, mark e flow w most packets buffered as unresponsve f ( avg max qlen q lm) strke max = ; Flow mn f ( qlen MAX( mn_ q, )) Nact Accept e packet from flow ; mn //unresponsve flow s not allowed to buffer more an Nact packets else f ( strke ==) else drop e packet; //operatng n random drop mode drop e packet w e probablty P ; B. Algorm for updatng e value of qlen In we decrement e value of qlen s n a round-robn way when e packets are servced, so at e qlen wll be e supposed number of buffered packets of flow f e packets from each flow are dequeued n a far round-robn way. We do s by keepng an ActveLst, whch s a lst of ndces of non-zero qlen. The algorm s: Whenever a packet from flow s accepted and enqueued: qlen ++; f ( qlen ==) // flow s a new actve flow append to e end of ActveLst; whenever a packet dequeued : let k be e frst element of ActveLst; qlen --; k remove e k from ActveLst f ( qlen >) k append k to e end of ActveLst; else dscard k ; III. SIMULATIONS We evaluate e performance of by smulatons n ns [8]. As a benchmark, we compare e performance of s gateway algorm to and. All data packets n our smulatons are bytes. To set e parameters of, we follow e gudelne from []. The s set to packets and s ree tmes. The s set to. and e value of s set to.. All e gateways have e buffer lmt of packets. The and have e same parameters as n e settng above, except at e of and of are 4 as recommended n []. Source Source Source n M M M gateway M(bottleneck) gateway Fgure A Sngle Congested Lnk M M M Snk Snk Snk n Sender Sources UDP-Snks Snk- Snk-9 Snk-(k-) Snk-(k-)9 Snk-k Snk-k9... UDP- UDP-9 UDP- UDP-9 UDP-k UDP-k9 Fgure Topology for Multple Congested Lnks To evaluate e performance, we measure e average roughput of each flow n all our smulatons. In some cases, we also calculate e Jan s farness ndex [] to measure how effectve dfferent gateway algorms can farly allocate e bandwd among flow. The farness ndex F s defned as: Where N b k = N k = Recever = ( ) F () N b b s e roughput of flow and N s e total number of actve flows n e gateway. A. Flows w dfferent sendng rates In s experment, we test e performance of gateway algorms when flows w dfferent arrval rate compete at e bottleneck lnk as n e topology n Fgure. Under an deal algorm, e bandwd acheved by each flow should be no more an ts far share rate no matter ts sendng rate. The excess packets from e flow at has hgher arrval rate an ts far share wll be dropped n e gateway and e flows w a sendng rate less an er far share should experence no packet drop. In s experment, we have UDP flows, IEEE Communcatons Socety /4/$. (c) 4 IEEE

3 ndexed from to 9. The sendng rate of e frst flow s e Mbps, whch s equal to far share rate, and every subsequent flow sends at a rate.mbps hgher an e prevous flow. Thus flow transmts at. Mbps, flow transmts at. Mbps, and e last flow transmts at.8 Mbps.. x 6.5. an ts far share and qlen becomes zero. When qlen becomes zero, e value of qlen cannot be decreased and flow wll mss ts round. From e pont of vew of gateways, s flow temporarly becomes nactve and cannot clam ts share of bandwd. For all e actve flows, e farness s stll mantaned. Bandwd (bps) Index of flows Fgure. Bandwd of TCP flows Fgure 4. TCPs w dfferent RTT w dfferent sendng rate (E(u), mean of u) Fgure summarzes e bandwd share of each flow gotten when dfferent gateway algorms are used n e bottleneck lnk. has e best performance n s scenaro. Each flow got exactly ts far share and well-behaved flow suffer no packet loss because t sends packets at ts far share rate. On e contrary, bandwd share of each flow s proportonal to ts sendng rate w. s much farer an, all e flows receve roughly er far share. However, e roughputs of hgh sendng rate flows are stll slghtly hgher an low sendng rate flows. The roughput of flow s.94mbps n gateway. That means flow suffered 6% packet drop rate even ough t sends at ts far share. B. TCP flows w dfferent RTT In s experment we show e effectveness of gateway algorms to protect e TCP flow w large round-trp delay. In s smulaton we let n TCP flows traverse e gateway, where flow has long RTT(ms) and e oer flows have short RTT(4ms). Because e TCP s bas aganst e large RTT flows, flow normally get less roughput compared to e oer flows. We measure u, e dfference between long RTT TCP bandwd and average low RTT TCP bandwd, where n u = B B () n = n s e number of TCP flows, and B s e bandwd of flow. In an deal case, e flow w less roughput has low drop probablty and ts roughput ncreases. So e value of u should be small. Under and, each smulaton s repeated tmes and e mean value of u, E[u], are computed. As shown n e Fgure 4, e mean value of u n s always smaller an n. However, flow stll gets less roughput an oer flows under even ough adopt a far round-robn fashon to decrease qlen so at each flow at has non-zero value of qlen should obtan ts exact far share. Ths s because e TCP flow s sendng rate s fluctuatng whle e sze of congeston wndow s changng. For certan perod of tme, ts sendng rate s less C. Mxture of TCP flows and UDP flows In e frst experment we show e mpact of one nonadaptve UDP flow on a set of adaptve TCP flows. In s smulaton, ere are 5 flows traverse e bottleneck lnk. We assume at flow s runnng non-adaptve UDP whle e rest of e flows are adaptve TCP connectons. The smulaton results are shown n Fgure As we can see n Fgure 5., has no control over non-adaptve flow when t competes to adaptve TCP flows. The hgher sendng rate e CBR flow has, e more bottleneck bandwd t can obtan. The oer TCP flows can only share e leftover bandwd. W e grow of CBR sendng rate to e lnk rate, TCP flows get very lttle share. Bandwd of Flows(Mbps) Bandwd of Flows(Mbps) flow(cbr) flow flow CBR sendng rate(mbps) Fgure5. Flow bandwds ().5 x 6.5 flow(cbr) flow flow CBR sendng rate(mbps) Bandwd of Flows(Mbps) TCP bandwd/ideal bandwd.5.5 flow(cbr) flow flow CBR sendng rate(mbps) Fgure5. Flow bandwds () No. of flows Fgure5. Flow bandwds () Fgure 6 A TCP competng w multple UDP Comparng to, oer actve queue management schemes n our experment can all effectvely prevent e nonadaptve flow from takng all e bottleneck bandwd. In, e CBR flow may get hgher bandwd an TCP flows when ts sendng rate s hgher an Mbps as seen n Fgure 5.. However, comparng to Fgure 5., e performance of s stll better an n s scenaro. Under flow can get no more an.mbps roughput, whch s 5% more an ts far share. Under flow wll acheve.9mbps roughput, whch s 45% more an ts far share. In e followng experment, we measure how well e algorms can protect a sngle TCP flow aganst multple nonadaptve UDP flows. We consder experments nvolvng N flows, N =. Out of ese we assume N UDP flows and one TCP flow for each experment. Each UDP IEEE Communcatons Socety /4/$. (c) 4 IEEE

4 sends at twce ts far share rate of N Mbps. Fgure 6 plots e rato between e average bandwd of e TCP flow and e far share bandwd t should receve. has e best performance across e entre range; TCP flow can acheve ts deal far share. In, TCP flow s completely shut out by e non-adaptve flows and obtans no bottleneck bandwd. can also protect e TCP flow effectvely from beng shut out. However, t s harder for TCP flow to get ts far share under as e number of competng UDP flows ncreases. In case of 9 competng UDP flows, e TCP flow only acheves 46.4% of ts far share. Bandwd(mbps) x 6 Far Share Index of flows farness ndex tme Fgure 7. Mx of 9 TCP flows and Fgure 8. Farness ndex of each UDP flows ms perod for mx traffc D. Mxture of heterogeneous flows Ths experment has a mx of TCP and CBR UDP flows. There are 9 TCP flows and CBR flows. The TCP flows have dfferent round-trp tmes; e frst TCP have round-trp tmes close to ms, e next ree have RTTs around 4ms, and e last ree have RTTs around 6ms. The CBR flows, w flow numbers 9,,, have sendng rate of 5 Mbps, Mbps and Mbps respectvely. Fgure 7 shows e bandwd of each of e flows w, w and w. W, e hgh-bandwd CBR flows get almost all e bandwd, leavng lttle for e TCP flows. All e flow experence e same loss rate, so e flows w hgher sendng rate wll acheve hgher bandwd. As seen n Fgure 7, under flow9 gets 4.7Mbps bandwd whch s close to ts 5Mbps sendng rate. Bo and are able to restrct e bandwd receved by e CBR flows to near e far share. However, w all e flows have a more evenly dstrbuted bandwd share. In a subsequent smulaton, we compare e performance of when e traffc rates are randomly changng. We use e same traffc combnaton as above. We assume ntervals of seconds each. Durng each nterval a flow has 6% probablty to transmt. We run and as gateway algorms and compute e farness ndex of each s tme nterval. As shown n fgure 8, e farness ndex of s consstently hgher at at of. Also e value of farness ndex under s much smooer an e one under. The average value of farness ndex of s.986, and confdence nterval s [.98,.99] The average value of farness ndex of s.848, and confdence nterval s [.8,.874] E. Multple congested lnks We now analyze how e roughput of a well-behaved flow s affected under dfferent gateway algorms when e flow traverses more an one congested lnk. The smulatons are performed based on e topology shown n Fgure. Except e flow from e sender to recever, all flows are Mbps UDP flows. The capacty of each lnk n e system s Mbps, and each lnk between gateways has 9 UDP flows at Mbps sendng rate. Ths wll cause all lnks between gateways beng congested. In e frst smulaton, we let a UDP flow sendng at ts far share rate of Mbps from Sender to Recever. In an deal case, s flow should suffer no packet loss and have all ts traffc forwarded because t sends at ts far share. Fgure 9 shows e fracton of UDP flow at s transferred versus e number of congested lnks. has e best performance n s case. W e ncrease of e number of congested lnks, e roughput of well-behaved UDP flow s always close to ts far share bandwd. also performs sgnfcantly better an. The outperforms e n e entre range n Fgure 9. When e number of congested lnks s, e well-behaved UDP flow under acheves only 8% of ts far share, whle under t obtan ts full far share. There s an 8% dfference n bandwd sharng between and n s case. UDP bandwd/far share (under /) Number of Congested Lnks Fgure 9 A well-behaved UDP flow Traversng multple congested lnks Cumulatve Fracton Transfer delay Fgure Cumulatve fracton of web transfer delay UDP flow bandwd/far share (under ) TCP flow bandwd/far share Number of Congested Lnks Fgure TCP flow traversng multple congested lnks average transfer delay No. of lnks Fgure average web transfer over multple congested lnks In anoer smulaton, we show e behavor of TCP flow traversng multple congested lnks. We use e same topology as n Fgure, and send a FTP flow from sender to recever nstead of a UDP flow. In an deal gateway, s test flow should experence very lttle packet loss at every congested lnk when ts arrval rate s lower an ts Mbps far share. And s low drop rate wll allow e TCP congeston wndow of s connecton grow, so s flow can acheve ts Mbps far share roughput. The actual roughput of test TCP flow under dfferent algorms s shown n Fgure, when TCP flow traverses multple congested lnks, ts roughput decreases n all gateway algorms w e number of IEEE Communcatons Socety /4/$. (c) 4 IEEE

5 congested lnks because ts packets are more lkely to be dropped. As an extreme case, TCP flow gets completely shut down when e congested gateway uses. Under, e roughput e TCP flow decreases sgnfcantly w e number of congested lnks ncrease. outperforms over all range. Under, flow acheve 78.% of ts far share when flow traverse congested lnks, t acheves 78.% of ts far share under and only 5.9% under. F. Short-lved web transfers In s smulaton we assess e performance of w short-lved web traffc. Short-lved web flows spend sgnfcant amount of tme n e slow start phase, so ey send at low rate most of e tme. A far gateway algorm should be able to reduce e loss rate of web traffc and allow e short flow to fnsh sooner. The background traffc n e smulaton s e mx of long lved FTP flows and unresponsve UDP flows. There are 9 FTP flows w dfferent RTT and CBR flows w 5Mbps, Mbps, and Mbps sendng rate respectvely. In addton, we consder 6 web-objects transfer w average of packet per web-object to transfer. We use e bult-n web-traffc model n NS. The competng flows starts randomly wn e ntal 5s of smulaton whle e web-traffc start after 5s. We record e object transfer delays for each web transfer. Fgure s e cumulatve dstrbuton of transfer delay of web-traffc under dfferent gateway algorms. Bo and can reduce e loss rate of web traffc compared to. So e transfer delay s smaller n ese two algorms. The results are summarzed n Table below: Algorm Transfer delay Std. dev Loss rate % % % Because e loss rate n s less an n, e transfer delay under s less an under. As e experment above shown, bo and can protect low bandwd web-transfer flow. So s two algorm can reduce e transfer delay of short web traffc. We now study e performance of ese algorms when e web connectons traverse multple congested lnk. We use e topology of Fgure. Each congested lnk has Mbps capacty and FTP background connectons. The short webtraffc connectons start after 5s smulaton tme from e sender to receve. Each smulaton s repeated 5 tmes and e mean loss rate and transfer delay are e average of all smulatons. We record e average object transfer delay for web transfers n fgure. As shown n e fgure, as e number of congested lnks ncrease, e mean transfer delays are ncreasng. Ths s because e packets from web-traffc are more lkely to be dropped when ey go rough multple congested lnks. Under e average transfer delays of web traffc are smaller an n all range of fgure. Ths shows at has better protecton of low bandwd flows an. IV. CONCLUSION We have suggested, a gateway algorm at enforce farness among actve flows by dfferentate er drop probabltes accordng to e flow. Ths approach s sutable for hgh-speed mplementatons because t use a sngle FIFO queue for all ncomng packets w probablstc drop-onarrval. It can allocate bandwd farly and has smlar complexty as. The performance of s compared w and n our smulaton studes. In all cases, and acheve sgnfcant performance mprovement over because of extra flow states used. W e same complexty as, outperform REFERENCES [] S. Floyd, V. Jacobson, Random Early Detecton for Congeston Avodance, IEEE/ACM Transactons on Networkng (4), August 99, [] D. Ln, R. Morrs, Dynamcs of Random Early Detecton, Proceedng of ACM Sgcomm, ACM, New York, 997, pp [] F. Anjum, L. Tassulas, "Far Bandwd Sharng among Adaptve and Non-Adaptve Flows n e Internet." Proc. IEEE INFOCOM, Mar. 999, 4-4. [4] E. L. Hahne, Round robn schedulng for far flow control n data communcatons networks, IEEE JSAC, vol. 9, no. 7, Sept. 99, pp. 4-9 [5] B. Braden et al., Recommendatons on Queue Management and Congeston Avodance n e Internet, RFC 9, IETF, Aprl 998 [6] G. Hasegawa, M. Murata, Survey on Farness Issues n TCP Congeston Control Mechansms, IEICE Trans. Commun., June, Vol.E84-B, No.6. [7] A. Mank, K. Ramakrshn, Congeston Control Survey, RFC54, IETF, August 99 [8] Network Smulator. [9] M. Shreedhar, G. Varghese, "Effcent far queung usng defct round robn", IEEE/ACM Trans. Networkng, June 996 [] Sally Floyd, ": Dscussons of Settng Parameters", [] R. Jan, "The Art of Computer Systems Performance Analyss", New York: Wley-Interscence, 99 IEEE Communcatons Socety /4/$. (c) 4 IEEE