Adaptive RED: An Algorithm for Increasing the Robustness ...

AdaptiveRED:An Algorithm for IncreasingtheRobustnessof RED’sActiveQueueManagement

SallyFloyd, RamakrishnaGummadi,andScottShenkerAT&T Centerfor InternetResearchat ICSI

August1, 2001,undersubmission

Abstract

The RED active queuemanagementalgorithmallows net-work operatorsto simultaneouslyachieve high throughputand low averagedelay. However, the resulting averagequeuelength is quite sensitive to the level of congestionandto theREDparametersettings,andis thereforenotpre-dictable in advance. Delay being a major componentofthequalityof servicedeliveredto their customers,networkoperatorswould naturallylike to have a rougha priori es-timateof the averagedelaysin their congestedrouters;toachieve suchpredictableaveragedelayswith RED wouldrequireconstanttuning of the parametersto adjustto cur-renttraffic conditions.

Our goal in this paperis to solve this problemwith min-imal changesto the overall RED algorithm. To do so,werevisit theAdaptiveREDproposalof Fenget al. from 1997[6, 7]. We make several algorithmicmodificationsto thisproposal,while leaving thebasicideaintact,andtheneval-uateits performanceusingsimulation.Wefind thatthis re-visedversionof AdaptiveRED,whichcanbeimplementedasasimpleextensionwithin REDrouters,removesthesen-sitivity to parametersthat affect RED’s performanceandcanreliablyachieve aspecifiedtargetaveragequeuelengthin a wide variety of traffic scenarios.Basedon extensivesimulations,we believe that Adaptive RED is sufficientlyrobustfor deploymentin routers.

1 Introduction

End-to-endcongestioncontrolis widely usedin thecurrentInternetto preventcongestioncollapse.However, becausedatatraffic is inherentlybursty, routersareprovisionedwithfairly large buffers to absorbthis burstinessandmaintainhigh link utilization. Thedownsideof theselargebuffersisthatif traditionaldrop-tailbuffer managementis used,therewill be high queuingdelaysat congestedrouters. Thus,drop-tail buffer managementforcesnetwork operatorstochoosebetweenhigh utilization (requiring large buffers),

or low delay(requiringsmallbuffers).The RED buffer managementalgorithm managesthe

queuein a more active mannerby randomly droppingpackets with increasingprobability as the averagequeuesizeincreases;thepacket droprateincreaseslinearly fromzero,whenthe averagequeuesizeis at the RED parame-ter minthresh(denotedby �� ), to a drop rateof �� when the averagequeuesize reachesmaxthresh(denotedby �� ).1 Oneof RED’s maingoalsis to usethis com-binationof queuelengthaveraging(which accommodatesbursty traffic) andearly congestionnotification(which re-ducestheaveragequeuelength)to simultaneouslyachievelow averagequeuingdelayandhighthroughput.Simulationexperimentsandoperationalexperiencesuggestthat REDis quitesuccessfulin this regard.

However, ashasbeenpointedout in [18, 19, 20] amongotherplaces,oneof RED’smainweaknessesis thattheav-eragequeuesize varieswith the level of congestionandwith theparametersettings.Thatis, whenthelink is lightlycongestedand/or �� is high, the averagequeuesizeisnear�� ; whenthelink is moreheavily congestedand/or�� is low, the averagequeuesize is closerto, or evenabove, �� . As a result,theaveragequeuingdelayfromRED is sensitive to the traffic loadandto parameters,andis thereforenot predictablein advance.Delaybeinga ma-jor componentof the quality of servicedeliveredto theircustomers,network operatorswould naturallylike to havearougha priori estimateof theaveragedelaysin theircon-gestedrouters;to achieve suchpredictableaveragedelayswith REDwouldrequireconstanttuningof RED’sparame-tersto adjustto currenttraffic conditions.

A second,relatedweaknessof RED is that the through-put is alsosensitive to thetraffic loadandto RED parame-ters. In particular, RED oftendoesnot performwell whentheaveragequeuebecomeslarger than �� , resultinginsignificantlydecreasedthroughputandincreaseddropping

1In RED’s gentlemode,which we employ here,the droppingrateincreaseslinearly from �� atanaveragequeuesizeof �� to � atanaveragequeuesizeof �! "�� .

1

rates. Avoiding this regime would againrequireconstanttuningof the

#REDparameters.

Therehave beenseveralproposalsfor active queueman-agementschemesintendedto avoid these(andother)prob-lems.Wearecurrentlypreparinga detailedexaminationoftherelative performanceof theseschemes.However, all oftheseschemesrepresentsubstantialdeparturesfrom theba-sicRED design,andour purposehereis to look for a moreminimal changeto RED thatcanalleviate theproblemsofvariabledelayandparametersensitivity mentionedabove.

We think that the basicinsight for sucha solution liesin theoriginal Adaptive RED proposalof Fenget al. from1997 [6, 7]. This proposalretainsRED’s basicstructureandmerelyadjuststhe parameter��$ to keepthe aver-agequeuesizebetween�� and �� . In this paper,wedescribeanew implementationof AdaptiveREDwhichincorporatesseveral substantialalgorithmicchangesto theoriginal Adaptive RED proposalwhile retainingits basicintuition andspirit. In addition,thisnew Adaptive REDal-gorithm automaticallysetsseveral otherRED parameters;operatorsneedonly set the desiredtarget averagequeuelength.2

We have implementedthis revised proposalin the NSsimulator, anddescribeit here.This new versionof Adap-tiveREDachievesthetargetaveragequeuelengthin awidevariety of scenarios,without sacrificingthe otherbenefitsof RED. This not only leadsto a morepredictableaveragequeuingdelay, but alsominimizesthepossibilityof “over-shooting” �� ; thus, Adaptive RED reducesboth thepacket lossrateandthe variancein queuingdelay. Adap-tiveRED,thus,appearsto solvetheproblemof settingREDparameters,which hasbeenoneof thebanesof RED’s ex-istence.

While the Adaptive RED algorithmappearspromising,we make no claimsthat this proposalis the only, or eventhe best,way to solve the problemsaddressedhere. Wepresentit asanexistenceproof thatoneneednot abandonthebasicREDdesignin orderto stabilizetheaveragequeuelengthand“auto-tune”theotherRED parameters.We alsopresentAdaptiveREDasaseriousproposalfor deploymentin routers.Basedonextensivesimulations(only asubsetofwhich we canreporton here),andon the fact that Adap-tive RED representsa smallchangeto thecurrentlyimple-mentedREDalgorithm,webelieve thatthatAdaptiveREDis sufficiently robustfor deployment.

This paperhas eight sections,starting with Section2which discussesthe metricsand simulationscenarioswe

2To avoid confusionandcumbersometerminology, in what followsthe term original Adaptive RED will refer to the proposalof Fengetal. [6, 7] andthetermAdaptive RED will refer to therevisedproposaldescribedhere.

usein evaluatingAdaptive RED. Section3 reviews somepreliminarysimulationresultsthat illustrateRED’s sensi-tivity to parametersandshow thatAdaptive RED doesin-deedaddressthisproblem.Section4describesthedetailsofthe Adaptive RED algorithm,including the automaticset-ting for theparametersmaxthreshand %'& (thequeueaver-agingconstant).Simulationresultsof Adaptive RED in avarietyof settingsarepresentedin Section5. Section6 dis-cussesthe inherenttradeoffs betweenthroughputand de-lay, andthedifficult issueof determiningthetargetaveragequeuesize. Relatedwork is discussedin Section7 andweconcludein Section8.

2 Metrics and Scenarios

In thissectionwedescribethemetricsandtherangeof sce-nariosthatweusedin evaluatingAdaptive RED.

The primary goalsof RED, or of active queuemanage-mentin general,areto provide low averagequeuingdelayand high throughput. Thus, for the evaluationsof Adap-tive RED in this paperwe focusmainly on the metricsofaveragequeuingdelayandthroughput.RED alsohasthesecondarygoalsof improving somewhatuponthe fairnessgivenby Drop Tail queuemanagementandof minimizing,for a given averagequeuelength, the packet droppingormarkingrate. We do not discussthe fairnessbehavior ofAdaptive RED,sincethis is quitesimilar to thefairnessbe-havior of RED. We only briefly considerthedrop-ratebe-havior of REDandAdaptiveRED,sincedegradeddrop-ratebehavior is generallyreflectedin degradedthroughput.

A few commentsaboutthesemetricsarein order. First,all of thesemetricsarerouter-based.While end-usermet-rics, suchas file transfertimes or per-packet delays,areimportantmeasuresof analgorithm’s validity, theend-usermetricsof interestfor AdaptiveREDcanbefairly easilyde-rivedfrom therouter-basedmetricswe present,andwebe-lieve that therouter-basedmetricsgive moredirect insightinto thedynamicsof AQM (Active QueueManagement).

Second,we do not considermetricsrelatedto theworst-casequeuingdelaysbecauseit is not a goal of AQM tocontrol theseworst-casedelays.We envision AQM asbe-ing intendedmainly for traditionalbest-effort traffic, wheresuchworst-caseguaranteescannotbeprovidedwith simplepacket multiplexing in any case.To theextent that worst-casequeuingdelaysareneeded,they arecontrolleddirectlybyconfiguringthequeue’sbuffer sizeattherouter(andthusareindependentof theAQM algorithm).

Third, we do not considermetrics directly measuringqueuelength oscillations. While therehasbeensubstan-tial recentinterestin queuelengthoscillations(see,for ex-ample,[8, 13]), we do not think that suchoscillationsare

2

harmfulunlessthey increasetheaveragequeuingdelayordecreasethe

#throughput,in whichcasetheeffectswouldbe

measuredby ourprimarymetrics.Wediscusstheimpactofoscillationsonourprimarymetricsin Section5.1.

In evaluatingAdaptive RED, we have exploreda widerangeof traffic scenarios,andhave investigatedthe sensi-tivity of Adaptive RED to our simulationparameters.Toverify robustness,we have consideredperformancefor arangeof workloads,levels of statisticalmultiplexing, andlevels of congestion.Workloadsinclude long-lived flowsandshortweb mice, alongwith reverse-pathtraffic. Thepresenceof datatraffic on the reversepathintroducesack(acknowledgment)compressionandthe lossof ack pack-ets,therebyincreasingthe burstinessof the datatraffic onthe forward path. Reverse-pathtraffic also forcesa rangeof packet sizeson the forward path, as the forward pathis now sharedbetweendataandack packets. We alsoex-plorescenarioswith changesin theworkloador in thelevelof congestionover the courseof the simulation. We havelooked at dynamicswith andwithout Explicit CongestionNotification(ECN). Finally, we have consideredtheeffectof large window advertisementsanddifferentdatapacketsizes.We do not have spacefor all of theseresultsin thispaper, but a morecompletedescriptionis availablein [10].

3 The Motivation for Adaptive RED

Beforedelving into detailsof the designandperformanceof Adaptive RED, which we describein Sections4 and5respectively, we first review somesimulationresultsillus-trating RED’s sensitivity to parameters,andshowing thatAdaptive REDdoesindeedaddressthisproblem.Thissec-tionshowssimulationsillustratingRED’swell-known char-acteristicof theaveragequeuesizeandperformancevary-ingasafunctionof theREDparameters�� and% & . Thissectionalsoincludessimulationresultswith AdaptiveRED,showing that by adapting��$ to keepthe target queuesizewithin a target rangebetween�� and �� , it ispossibleto achieve thesameperformanceof thatfrom REDwith avalueof �� tunedfor thatsimulationscenario:inotherwords,Adaptive RED successfully”auto-tunes”thevariousREDparametersto achieve reliablygoodresults.

Figures1 through3 show asetof simulationswith asin-glecongestedlink in adumbbelltopology, with thenumberof long-lived TCPflows rangingfrom 5 to 100. The long-lived flows have a rangeof round-trip times from 100 to(�)�*

ms,andthesimulationsincludewebtraffic andreverse-pathtraffic. Thecongestedlink is

(�+Mbps.

Thesimulationsin Figure1 useRED with NS’s defaultvaluesof % &�, *.-/*0*21

and �� , *.-�(, andwith ��

and �� set to 20 and 80 packets respectively. RED

is run in gentlemode in all of thesesimulations. Eachcrossshows the resultsfrom a singlesimulation,with the� -axis showing the averagequeuingdelayin packetsoverthe secondhalf of the 100-secondsimulation,and the 3 -axis showing the link utilization over the secondhalf ofthe simulation. Eachline shows resultsfrom simulationswith 4 flows,with linesfor valuesof 4 rangingfrom 5 to100. The crosseson eachline show the resultsof simula-tionswith �� rangingfrom 0.5on theleft to 0.02on theright. Thepacketdropratein thesesimulationsrangesfromcloseto zero(for thesimulationswith five flows) up to 8%(for the simulationswith 100 flows). As Figure1 shows,theperformancevariesbothwith thenumberof flows andwith �� , with poorerthroughputfor thosesimulationswith a larger numberof long-lived flows. For thesesimu-lations,increasingthe numberof flows decreaseslink uti-lization,andincreasing�� leadsto lowerqueuelengths.Thedownturnin utilizationfor low valuesof �� reflectscaseswheretheaveragequeuelengthovershoots�� asignificantportionof thetime.

As discussedlater in Section4.3, the queueweight of0.002is too large for a link bandwidthof

(�+Mbps, since

it only averagesthe queuelengthover a fraction of a typ-ical

(5*0*ms round-trip time. The simulationsin Figure 2

differ from thosein Figure1 only in thatthey use%'& setto0.00027insteadof 0.002.As is apparentfrom Figure2,anddiscussedmore thoroughlyin Section4.3, RED’s perfor-manceis bestwhentheaveragequeuesizeis estimatedoverasmallmultipleof round-triptimes,andnotovera fractionof a singleround-triptime. Figures1 and2 areevidencethatRED’s performanceis sensitive to thevalueof thepa-rameter% & . Figure 2 also shows that non-adaptive REDcangive quitegoodperformancewith this “good” valueof% & , but thattheaveragequeuesizeandthroughputarebothstill a function of RED’s parameter�� . In particular,throughputsuffers in thesimulationswhen �� is smallrelative to the steady-statepacket drop rate,andthe aver-agequeuesizesometimesexceedsthe �� valueof 80packets. Thus,achieving goodthroughputandreasonableaveragequeuelengthswith RED requirescarefultuningofboth % & and �� . It is this carefultuning that AdaptiveREDis designedto doautomatically.

While we have yet to describethe Adaptive RED algo-rithm in detail (which we do in Section4), thegeneralde-signof Adaptive RED canbeeasilysummarizedassetting% & automatically(basedon the link speed)and adapting�� in responseto measuredqueuelengths.Later, in Sec-tion 5 wewill exploretheperformanceof AdaptiveREDinmoredetail, but for now we show a few simulationsthatsuggestthatAdaptive REDdoesindeedremovetheneedtocarefullytunetheseREDparameters.

3

86

88

90

92

94

96

98

100

10 20 30 40 50 60 70 80 90

Link

Util

izat

ion6

Average Queue Length

"5 flows""10 flows""20 flows""30 flows""40 flows""50 flows""60 flows""70 flows""80 flows""90 flows"

"100 flows"

Figure 1: Delay-Utilization Tradeoff with RED, % &7,*.-/*0*21.

86

88

90

92

94

96

98

100

10 20 30 40 50 60 70 80 90

Link

Util

izat

ion6



"100 flows"

Figure 2: Delay-Utilization Tradeoff with RED, % &7,*.-/*0*0*210).

98

98.2

98.4

98.6

98.8

99

99.2

99.4

99.6

99.8

100

100.2

40 42 44 46 48 50 52 54 56 58

Link

Util

izat

ion6



"100 flows"

Figure3: Delay-UtilizationTradeoff with Adaptive RED.

Figure 3 shows the same simulationswith AdaptiveRED; in this graphthevariousvaluesof �� arethe ini-tial values,andAdaptive RED adjuststhem,asdescribedin 4, in responseto measuredbehavior. Note that the � -and 3 -axesof Figure3 don’t matchthoseof Figures1 and2, so Figures1 and2 containa box showing the areaforFigure3. The entireregion depictedin Figure3 occupiesasmallareain the“good” performanceregionof Figures1and2. As in theearliergraphs,Figure3 shows theresultsfrom thesecondhalf of a 100-secondsimulation;theclus-teringof thepointsfor a givencurve shows thattheresultsareessentiallyindependentof theinitial valueof �� .

Thesesimulationsshow that Adaptive RED, in setting% & automaticallyandadjusting �� in responseto cur-

rent conditions,is effective in achieving high throughputalong with maintainingits averagequeuesize within thetargetinterval [44, 56]. This rangecorrespondsto thealgo-rithm’s requirementof maintainingtheaveragequeuesizewithin apre-determinedrangearound8 ��:9;��<>= 1 ,asexplainedin Section4. Theonly simulationswith anav-eragequeuesizeoutsidethatrangearethosewith 5 flows;thesesimulationshave few packet drops,a smalleraveragequeue,andfull link utilization.

The simulations with Adaptive RED all have highthroughput,with thethroughputrangingfrom98%upwards(with 100 flows) to 100%(with 5 flows). For eachnum-ber of flows, one could choosea static settingfor �� suchthat non-adaptive RED gives the sameperformanceasAdaptive RED. The catchis that this staticsettingfor�� would have to be a function of the simulationsce-nario. For example,for thesimulationswith 20 flows, theperformanceof Adaptive RED correspondsroughly to theperformanceof non-adaptive RED with �� setto 0.07,while for thesimulationswith 100flows, theperformanceof adaptive RED correspondsroughly to the performanceof non-adaptive REDwith �� setto 0.2.

0

0.02

0.04

0.06

0.08

0.1

20 30 40 50 60 70 80 90

Link

Los

s



"100 flows"

Figure4: Delay-LossTradeoff with Normal RED, %'& ,*.-/*0*0*210).

0

0.02

0.04

0.06

0.08

0.1

40 42 44 46 48 50 52 54 56 58

Link

Los

s



"100 flows"

Figure5: Delay-LossTradeoff with Adaptive RED.

Figures4 and5 show thepacket dropratesfrom thesim-ulationsin Figures2 and3. They show thatwhile bothREDandAdaptiveREDhaveroughlythesamepacketdropratesfor a particularsetof flows,Adaptive RED,by keepingthe

4

averagequeuesize away from �� , avoids the higherpacket lossthatREDincurswhentheaveragequeuesizeisaround �� . We have alsoexploredfairness,andhaveverifiedthat thefairnesspropertiesaresimilar in thesimu-lationswith REDandwith Adaptive RED.

We have exploredthesesimulationsfor a rangeof sce-narios,includinga rangeof link bandwidthsandmixesofweb traffic, with and without ECN, with the queuemea-suredbothin unitsof packetsandin unitsof bytes,andwithREDin bytemode(takinginto accountthesizeof apacketin bytesin decidingwhetheror not to dropthepacket) andin packetmode.In all of thesesimulations,weseethesamegoodperformancefrom Adaptive RED.

3.1 Illustrating RED’s Varying Queue Size

The previous simulationsshowed the steady-stateperfor-manceof REDandAdaptiveRED.Wenow investigatehowRED andAdaptive RED respondto a rapid changein thecongestionlevel. ThesimulationspresentedhereillustrateRED’s well-understooddynamicof theaveragequeuesizevarying with the congestionlevel, resulting from RED’sfixed mappingfrom the averagequeuesize to the packetdroppingprobability. For Adaptive RED,thesesimulationsfocuson thetransitionperiodfrom onelevel of congestionto another.

Thesesimulationsusea simpledumbbelltopologywitha congestedlink of

(�-?+Mbps. The buffer accommodates

35 packets,which, for 1500-bytepackets,correspondsto aqueuingdelayof 0.28seconds.In all of thesimulations,% &is setto 0.0027,�� is setto five packets,and �� issetto 15packets.3

For thesimulationin Figure6, theforwardtraffic consistsof two long-livedTCPflows,andthereversetraffic consistsof onelong-lived TCPflow. At time 25 twentynew flowsstart,oneevery0.1seconds,eachwith amaximumwindowof twentypackets.This is not intendedto modela realisticload, but simply to illustrate the effect of a sharpchangein the congestionlevel. The graphin Figure6 illustratesnon-adaptive RED, with the averagequeuesizechangingasa functionof thepacket droprate. Thedark line showstheaveragequeuesizeasestimatedby RED,andthedottedline shows the instantaneousqueue.The packet drop ratechangesfrom 1% over the first half of the simulation,to12.6%over thesecondhalf, with correspondingchangesintheaveragequeuesize.

The graph in Figure 7 shows the samesimulationus-ing Adaptive RED. Adaptive RED shows a similar sharpchangein theaveragequeuesizeat time25. However, after

3The valuesfor @�A and �"��0�� areobtainedfrom theguidelinesinSection4.3,while thevaluefor ��B�C �D� is apolicy choice.

roughly ten seconds,Adaptive RED hasbroughtthe aver-agequeuesizebackdown to the target range,between9and11 packets. Thesimulationswith Adaptive RED havea slightly higher throughputthanthosewith non-adaptiveRED, (95.1%insteadof 93.1%),a slightly lower overallaveragequeuesize (11.5 packets insteadof 13.4), and asmallerpacket drop rate. The simulationswith AdaptiveREDillustratethatit is possible,by adapting�� , to con-trol therelationshipbetweentheaveragequeuesizeandthepacket droppingprobability, and, thus, maintaina steadyaveragequeuesizein thepresenceof traffic dynamics.

Figure 8 shows a relatedsimulation with twenty newflows startingat time 0, andendingat time 25. The sim-ulation with non-adaptive RED in Figure8 shows the de-creasein theaveragequeuesizeasthe level of congestionchangesat time 25. This time, the packet drop rateswithnon-adaptive RED are9.7%over thefirst half of thesimu-lation,and.8%over thesecondhalf.

Thereis a similar changein the averagequeuesize inthesimulationwith Adaptive RED in Figure9, but withintensecondsAdaptive RED hasbroughtthe averagequeuesizebackto the target range. The simulationwith Adap-tiveREDhasasimilarthroughputto thatwith non-adaptiveRED, (93%insteadof 92.7%),anda slightly lower overallaveragequeuesize(11.1packetsinsteadof 12.4).

4 The Adaptive RED Algorithms

The overall guidelinesfor Adaptive RED asimplementedherearethe sameasthosefor the original Adaptive REDfrom [6], that is, of adapting �� to keep the averagequeuesizebetween�� and �� . Our approachdif-fersfrom originalAdaptive RED in four ways:EF�� is adaptednot just to keepthe averagequeue

sizebetween�� and �� , but to keeptheaver-agequeuesizewithin a targetrangehalf waybetween�� and �� .

EF��$ is adaptedslowly, over time scalesgreaterthana typical round-triptime,andin smallsteps.

EF�� is constrainedto remainwithin therange[0.01,0.5] (or equivalently, [1%, 50%]).

E Insteadof multiplicatively increasingand decreas-ing �� , we useanadditive-increasemultiplicative-decrease(AIMD) policy.

Thealgorithmfor Adaptive RED is givenin Figure10.Theguidelineof adapting��$ slowly andinfrequently

allows the dynamicsof RED—of adapting the packet-droppingprobability in responseto changesin theaverage

5

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30 35 40 45 50

Siz

e (in

Pac

kets

)G

Time (in Seconds)

"ave_queue""queue"

Figure6: REDwith anIncreasein Congestion.

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30 35 40 45 50

Siz

e (in

Pac

kets

)G

Time (in Seconds)

"ave_queue""queue"

Figure7: Adaptive REDwith anIncreasein Congestion.

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30 35 40 45 50

Siz

e (in

Pac

kets

)G

Time (in Seconds)

"ave_queue""queue"

Figure8: REDwith a Decreasein Congestion.

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30 35 40 45 50

Siz

e (in

Pac

kets

)G

Time (in Seconds)

"ave_queue""queue"

Figure9: Adaptive REDwith aDecreasein Congestion.

Every ��HJI�K�L�$M seconds:if ( �L�NPOQHJ�KRN$I�H and �� TS *.-?+

)increase �� :�� VU �� 9XW ;

elseif ( �L2NZYQH[�KRN$I5H and �� ]\ *.-/*^()

decrease �� :��$ U ��$ "_a` ;Variables:�L2N : average queue size

Fixed parameters:��H>I5K�L$�M : time; 0.5 secondsHJ�KRN$I�H : target for �L�b ;c ��9 *.-ed _ 8 ��gfh��< ,��i9 *.-?) _ 8 ��jfh��<�k .W : increment; min(0.01, �� /4)` : decrease factor; 0.9

Figure10: TheAdaptive REDalgorithm.

queuesize—todominateonsmallertimescales.Theadap-tion of �� is invoked only asneededover longer timescales.

The robustnessof Adaptive RED comesfrom its slowandinfrequentadjustmentsof �� . Thepriceof thisslowmodificationis thatafterasharpchangein thelevel of con-gestion,asin Figures7 and9, it couldtakesometime,pos-sibly tenor twentyseconds,before�� adaptsto its new

value. To ensurethat the performanceof Adaptive REDwill not be unduly degradedduring this transitionperiod,our third guidelinerestricts�� to staywithin therange[0.01, 0.5]. This ensuresthat during the transitionperiodtheoverall performanceof RED shouldstill beacceptable,eventhoughtheaveragequeuesizemight not be in its tar-getrange,andtheaveragedelayor throughputmightsufferslightly.

We do not claim thatour algorithmfor Adaptive RED isoptimal,or evencloseto optimal,but it seemsto work wellin a wide rangeof scenarios,andwe believe that it couldsafelybedeployednow in RED implementationsin theIn-ternet.As a resultof theslow adaptationof �� , thede-signof Adaptive RED givesrobust performancein a widerangeof environments. As statedabove, the cost of thisslow adaptationis that of a transientperiod,after a sharpchangein the level of congestion,whentheaveragequeuesize is not within the target zone. Adaptive RED is thusconsciouslypositionedin the conservative, robust end ofthespectrumof AQM mechanisms,with theaim of avoid-ing themorefinely-tunedbut alsomorefragiledynamicsatthemoreaggressive endof thespectrum.

Adaptive RED’s algorithmin Figure10 usesAIMD toadapt�� . While weexperimentedwith otherlinearcon-trolssuchasMIMD (Multiplicative IncreaseMultiplicativeDecrease)aswell asproportionalerror controls,asmightbesuggestedby somecontrol-theoreticanalyses,our expe-rienceshave beenthattheAIMD approachis morerobust.

This completesthe generaldescriptionof the AdaptiveRED algorithm. Embeddedin this algorithmaredetailed

6

choicesfor variousparameters.Wenow briefly justify thesechoices.

4.1 The range for lhm.n The upperboundof 0.5 on ��$ canbe justified on twogrounds. First, we are not trying to optimize RED forpacket drop ratesgreaterthan50%. In addition,becauseweuseREDin gentlemode,thismeansthatthepacketdropratevariesfrom 1 to �� astheaveragequeuesizevariesfrom �� to �� , andthepacket dropratevariesfrom�� to 1 as the averagequeuesize variesfrom ��to twice �� . Thus, with ��$ set to 0.5, the packetdropratevariesfrom 0 to 1 astheaveragequeuesizevariesfrom �� to twice �� . Thisshouldgivesomewhatro-bust performanceeven with packet drop ratesgreaterthan50%. The upperboundof 0.5 on �� meansthat whenthe packet drop rateexceeds25%, the averagequeuesizecouldexceedthetargetrangeby up to a factorof four.4

Thelower boundof 0.01on �� is motivatedby a de-sire to limit the rangeof �� . We believe that for sce-narioswith verysmallpacket droprates,REDwill performfairly robustly with �� setto 0.01,andno oneis likelyto objectto anaveragequeuesizelessthanthetargetrange.

4.2 The parameters o and pWe notethat it takesat least

*.-ed�q =RW intervals for �� toincreasefrom 0.01to 0.50;this is 24.5secondsfor our de-fault parametersfor W and ��HJI�K�L�$M (seeFigure10). Simi-larly, it takesat least r�s0t *.-/*21 = r�s0t ` intervals for �� todecreasefrom 0.50 to 0.01; with our default parameters,this is 20.1seconds.Givena sharpchangefrom onelevelof congestionto another, 25 secondsis thereforeanupperboundon theinterval duringwhich theaveragequeuesizecouldbeoutsideits targetrange,andtheperformanceof theAQM mightbesomewhatdegraded.

In recommendingvaluesfor W and ` , we want to en-sure that under normal conditionsa single modificationof �� doesnot result in the averagequeuesize mov-ing from above the target rangeto below it, or vice versa.Let’s assumefor simplicity that when ��$ is adaptedthesteady-statepacket droppingprobability u remainsthesame,andtheaveragequeuesize�L�N simplyshiftsto matchthe new value of �� . Thus, assumingu Y �� ,when �� increasesby W , �L2N can be expectedto de-creasefrom ��v9 w!xzy � 8 ��]fQ��< to ��j9 w!xzy �|{~} 8 ��gf��< - This is adecreaseof

4For �� V�� "B�C �� , the target queuesize is �J�.�� "B�C �� , andwith packet drop ratesapproaching100%and �"�� set to 50%, theaveragequeuesizeapproaches�� B�C �� .

W8 �� 9FW�< u�� 8 ��vfh��< -

As long asthis is lessthan*.-?1 8 ��Pf��< , the av-

eragequeuesize shouldnot changefrom above the tar-get rangeto below the target rangein a single interval.This suggestschoosing }� w�x�y �5{~}2� Y *.-?1

, or equivalently,WFY *.-?10+ �� . Our default settingof W (shown in Figure10)obeys thisconstraint.

Similarly, we have to checkthat the mutliplicative de-creaseof �� doesnotcausetheaveragequeuesizeto gofrom below to above the target rangeaftera singleadjust-mentof �� . A similar analysisto that for W shows thataslongasu�8 ( fh`�<�� ` 8 ��vfh��<!Y *.-?1 8 ��vfh��<��the averagequeuesizeshouldnot changefrom below thetarget rangeto above the target rangein a single interval.This suggestschoosing �>�� Y *.-?1

, or equivalently, `7O*.-?�0�. Thisconstraintis satisfiedby ourdefault valueof 0.9

for ` (seeFigure10).

4.3 Setting RED parameters lhm.n �� and � &As describedabove,Adaptive REDremovesRED’sdepen-denceontheparameter��$ . To reducetheneedfor otherparameter-tuning for RED, we alsospecifyproceduresforautomaticallysettingtheREDparameters�� and % & .

In automaticmode �� is set to threetimes �� .This follows therecommendationsin [9].5 In this casethetargetaveragequeuesizeis centeredaround

1!� �� , andis thereforedeterminedonly by theREDparameter�� .Considerationsin specifyingthe target averagequeuesizearediscussedin Section6.

Theguidelinesfor setting %'& given in theoriginal REDpaper[12] arein termsof the transientqueuesizeaccom-modatedby RED, and the time requiredby the estimatorto respondto a stepchangein theactualqueuesize. From[12], if thequeuesizechangesfrom onevalueto another, ittakes f ( = r��8 ( f % & < packet arrivalsfor theaveragequeueto reach63%of thewayto thenew value.Thus,werefertof ( = r��8 ( f %'& < asthe“time constant”of theestimatorfortheaveragequeuesize,eventhoughthis “time constant”isspecifiedin packet arrivalsandnot in time itself.

The default in the NS simulator is for %'& to be set to0.002; this correspondsto a time constantof 500 packetarrivals. However, for a 1 Gbpslink with 500-bytepack-ets,500packet arrivalscorrespondsto a smallfractionof a

5By chance,we haven’t followed this recommendationin all of thesimulationsin this paper, but following the recommendationdoesnotchangeour results.

7

round-triptime (1/50-thof an assumedround-triptime of100ms). Clearly

�higher-speedlinks requiresmallervalues

for % & , so that the time constantremainson the orderofround-triptimes,ratherthanfractionsof round-triptimes.Following theapproachsin [15, 21], in automaticmodeweset %'& asa functionof thelink bandwidth.

For RED in automaticmode,we set % & to give a timeconstantfor theaveragequeuesizeestimatorof onesecond;this is equivalentto tenround-triptimes,assumingadefaultround-triptimeof 100ms.Thus,weset

% &�, ( f�I5� u:8 f ( =0�V< (1)

where � is the link capacityin packets/second,computedfor packetsof thespecifieddefault size.

5 SimulationsThesimulationsin Section3 suggestthatAdaptiveRED,byautomaticallysetting % & and continually adapting �� ,achieves the goals of high throughputand low averagequeueingdelaysacrossawidevarietyof conditions.In thissectionwe more closely examinethreeaspectsAdaptiveRED’s behavior: oscillations,effectsof %'& , andresponseto routingdynamics.

5.1 Exploring Oscillations

Becauseof the feedbacknatureof TCP’s congestioncon-trol, oscillations in the queuelength are very common.Someoscillationsare “malignant”, in that they degradeoverall throughputand increasevariancein queuingde-lay; otheroscillationsare“benign” oscillationsanddo notsignificantlyeffect either throughputor delay. Figures11through14 eachshow theaveragequeuesizefor a simula-tion with 100long-livedflows,eachwith a round-triptimeof

10+�*ms, and with a congestedlink of

(�+Mbps. All of

theflows useECN and1000-bytedatapackets. TheREDqueuemanagementhas�� , 1�*

and �� , ��*.

Thesimulationin Figure11,which usesRED,hasthreefactorsthat eachencourageoscillationsin the queuesize:(1) a fixed (andoverly small) valuefor �� ; (2) a highvaluefor %'& ; and(3) a simpletraffic mix of one-way traf-fic of long-lived flows. Figure11 shows dramaticoscilla-tionsin theaveragequeuesize,with theaveragequeuesizegoing below �� andabove �� in eachoscillation.This leadsto oscillationsbetweenperiodsof high packetdrop ratesand periodsof no packet drops,and resultsindegradedthroughputandhigh variancein queueingdelay.Exceeding�� incursa non-linearityin the form of alargepacket drop,with acorrespondingdecreasein utiliza-tion, andforcestheaveragequeuesizeto decreasesharply,

in this case,below �� . But when the averagequeuesizefalls below �� , the averagepacket drop probabil-ity becomeszero,andthe flows onceagainrampup theircongestionwindows over thenext few RTTs, therebysus-taining the oscillations. In this case,RED achievesa linkutilization of

q�*��, anda high variancein queuingdelay.

The packet loss rate is about�$-?+2�

, even with the useofECN.

Figure12shows thatsuchmalignantoscillationsaresig-nificantlydampenedwith amorerealistictraffic mix includ-ing reversepathtraffic andwebtraffic; that is, evenwith abadly tunedandnon-adaptive RED, many of theworstef-fectsof theoscillationsaredecreasedwhenaslightly morerealistictraffic loadis used.

We now considerhow Adaptive RED, with its lowervalue for % & and its automaticallyadapting �� , faresin thesetwo traffic scenarios.Figure13 shows that evenwith the simple traffic mix of one-way, long-lived traffic,Adaptive RED is able to eliminatethe malignantoscilla-tions,andturn theminto benignoscillations.Thus,in spiteof the high, fixed RTT of

10+�*ms andwith neitherreverse

traffic nor webtraffic, Adaptive RED achievesa utilizationofq0)$-?�2�

, anaveragequeuingqueuesizeoscillatingwithinthe target rangeof [44, 56] packets,anda negligablelossrate.(Recallthatthetraffic is usingECN.)Wenotethatma-lignantoscillationspersistwith Adaptive RED if thelargervalueof 0.002is usedfor % & ; that is, adapting�� andchoosinga goodvaluefor % & areboth requiredfor elimi-natingthemalignantoscillationsfor thisscenario.

Figure14shows thatwith aslightly morerealistictrafficmix, with web traffic andreversetraffic, the benignoscil-lationsof Figure13 have beenreplacedby moreirregularvariationsof the averagequeuesize,generallywithin thetargetrangeof [44, 56] packets.Theutilization in this caseis alsoslightly higherthanthatin Figure13.

5.2 The Effects of Queue Weight

While Figure1 showed theperformancecosts,in termsofdecreasedthroughput,of too largea valuefor % & , this sec-tion illustratesthecosts,in termsof increasedqueuingde-lay, of toosmallavaluefor % & .

Figures15 through17show theresultsof asimplesimu-lation with two long-lived TCP flows, eachwith a round-trip around

d�+ms, competingover a

(�+Mbps link. The

secondTCP flow startsa time 2.5 in a 10-secondsimula-tion. With two TCPflows, theaveragecongestionwindowshouldbearound85packets.All threesimulationsusenon-adaptiveRED,anddifferonly in %'& . Thesesimulationsalsoillustrateoneof thecostsof anoverly-smallvalueof % & , ofbeingslow to respondto a large, sustainedincreasein the

8

0

20

40

60

80

100

120

0 20 40 60 80 100

Ave

rage

Que

ue L

engt

h

�

Time (in Seconds)

Figure11: RED,one-way long-livedtraffic, % & =0.002.

0

20

40

60

80

100

120

0 20 40 60 80 100

Ave

rage

Que

ue L

engt

h

�

Time (in Seconds)

Figure12: RED,richertraffic mix, % & =0.002.

0

20

40

60

80

100

120

0 20 40 60 80 100

Ave

rage

Que

ue L

engt

h

�

Time (in Seconds)

Figure13: Adaptive RED,one-way long-livedtraffic, % & =0.00027.

0

20

40

60

80

100

120

0 20 40 60 80 100

Ave

rage

Que

ue L

engt

h

�

Time (in Seconds)

Figure14: Adaptive RED,richertraffic mix, % & =0.00027.

instantaneousqueue.

Thesimulationin Figure15usesREDwith a largevaluefor % & of 0.002. All of the simulationsusethe automaticsettingsfor �� and �� , resultingin �� setto 19packetsand �� setto

� �� . Figure15 shows thein-stantaneousqueuesize,aswell as the averagequeuesizeestimatedby RED. Although thesecondTCP is cut off inits slow-startslightly beforeit reachesits desiredconges-tion window in Figure 15, Figures15 and 16 both showreasonablegoodperformancefor this scenario.

In contrast,Figure17 shows oneof the costsof having% & set too small. In this simulation % & , *.-/*0*0*^(, with

the result that RED is slow to detecta suddenincreaseincongestion,anddoesnot detectthecongestionbuilding upat time 2.5 until a queueof 350 packets hasbuilt up. Inthissimulationthesharpincreasein thequeueis dueto theslow-startof a singlehigh-bandwidthTCPflow, but thein-creasecouldalsohave beendueto a flashcrowd, a routingfailure,or adenial-of-serviceattack.Thissimulationis runwith a largebuffer size,allowing thespike in thequeuetoreach350packets. If thebuffer sizehadbeensmaller, thenthesimulationwouldsimplyhaverevertedto thetypicalbe-havior of Drop-Tail queuemanagement,of multiple pack-etsdroppedfrom awindow of data.Weexploredarangeofscenarios,andin almostall cases,evenin steady-statesce-narios,thelink utilizationsufferedwhenweusedasmallervalueof % & thansuggestedby Equation1.

5.3 Simulations of Routing Changes

Thissectionexploresbriefly thetransientbehavior of Adap-tive RED in environmentswith sharpchangesin the loaddue to routing changes.Figure18 illustratesthe averagequeuesizeasa functionof time in a simulationwheretheoutput link becomesunavailable from time

+�*to time

)�*(in seconds).Thesimulationtopologyincludesanalternatepathwith a lower precedencebut only half the link capac-ity, sotheTCPconnectionscontinueto sendpacketsduringthe link outage.Whenthe link comesbackup, the entireloadis shiftedbackto theoriginal link. Thelink utilizationreaches88.3%over the10-secondperiodimmediatelyfol-lowing the repair, and96.1%for the following 10-secondperiod.Thus,this scenariodemonstratesthegooddynamicbehavior of Adaptive RED.More extensive resultsarepre-sentedin [10].

6 Tradeoffs between Throughput andDelay

Given theAdaptive RED algorithmandtheautomaticset-ting of maxthreshand % & describedearlierin thispaper, theonly critical parameterleft to specifyfor RED is thetargetaveragequeuesize. Adaptive RED maintainsan averagequeuesizeof twice minthresh;therefore,givena target fortheaveragequeuesize,settingminthreshis straightforward.Thehardpartis determiningthedesiredaveragequeuesize.

The“optimal” averagequeuesizefor a routeris a func-tion of therelative tradeoff betweenthroughputanddelay,

9

0

50

100

150

200

250

300

350

400

0 1 2 3 4 5 6 7 8 9 10

Siz

e (in

Pac

kets

)

¡

Time

"ave_queue""queue"

Figure15: RED,two flows, % & too large,at 0.002.

0

50

100

150

200

250

300

350

400

0 1 2 3 4 5 6 7 8 9 10

Siz

e (in

Pac

kets

)

¡

Time

"ave_queue""queue"

Figure16: RED,automaticsettingfor % & , 0.00027.

0

50

100

150

200

250

300

350

400

0 1 2 3 4 5 6 7 8 9 10

Siz

e (in

Pac

kets

)

¡

Time

"ave_queue""queue"

Figure17: RED, % & toosmall,at0.0001.

andthis tradeoff is necessarilya questionof policy. In ad-dition, thesetradeoffs betweenthroughputanddelayareafunction of characteristicsof the aggregatetraffic, in par-ticular of the burstinessof the aggregate. Thus,scenarioswith one-way traffic, long-lived flows, shortRTTs, and ahigh level of statisticalmultiplexing allow both very highthroughputandvery low delay, while scenarioswith higherburstinessthatresultsfromtwo-waytraffic andwebmiceorscenarioswith low levelsof statisticalmultiplexing requiresomehardertradeoffs betweenthroughputanddelay.

Leaving behindtheissueof optimality, andfollowing Ja-cobsonet al. in [15] and the simulationscripts in [11],in automaticmodewe set �� asa functionof the linkbandwidth. For slow andmoderatespeedlinks, we havefoundthatsetting �� to five packetsworkswell, sowecontinueto usethis asa lower boundfor �� in auto-

0

20

40

60

80

100

120

140

160

180

200

0 20 40 60 80 100 120 140 160 180 200

Tim

e (in

Sec

onds

)

¢


Figure 18: Average queue size variation with routingchange.

matic mode. For a high-speedlink, however, an averagequeuesizeof tenpacketsis verysmallrelative to thedelay-bandwidthproduct,andresultsin a severelossof through-put.

Our rule of thumb for a plausible tradeoff betweenthroughputand delay is to requirethat the averagequeu-ing delayat a routerbe only a fraction of the end-to-endround-trip time, using a default value of

(5*0*ms. Setting�� ,¤£z¥[¦ xz§ �©¨>ª¬«[®�.¯° givesa targetaveragequeuingdelay

of ± I�M² 3 � xz³J´ ¥ � seconds,for � the link capacityin pkts/sec.Weusea ± I�M² 3 � xz³J´ ¥ � of

+ms,andin automaticmodeweset�� to µ ��·¶ + � £z¥[¦ x�§ �©¨Jª�«¸²��¯° ¹ packets. This translatesto

settingminthreshto 12.5packetsfor a(5*

Mbpslink, andto125packetsfor a

(5*0*Mbps link. [10] reportson extensive

simulationsexploringthetradeoffs betweenthroughputanddelayin a rangeof settings.

7 Related Work

The parametersensitivity of RED hasbeendiscussedin anumberof papers,andwe briefly discusssomeof this re-latedwork in this section.Thereis a growing bodyof re-searchon AQM, and our paperbuilds upon observationsfrom a rangeof this earlier work. We do not attempttoevaluateeachof theseproposalshere,but simply notethatwe don’t believe that any of theseproposalshasyet pre-sentedthefull answerto theparametersensitivity of RED.In particular, we believe thatnoneof theseproposalshavepresenteda deployable mechanismfor adaptingthe REDparameter�� . Similarly, for the proposalsnot baseduponRED,wedonotbelieve thatany of thesehasyetpro-vided a robust, deployableproposalfor AQM for realisticscenarioswith burstytwo-way traffic anda rangeof packetsizes.Someof theseproposalswill beevaluatedin a sepa-ratework.

TheAdaptiveREDproposalin thispaperis basedontheoriginal Adaptive RED proposedby Fenget al., in [6, 7],

10

of adapting��$ asa functionof theaveragequeuesize.This originalº Adaptive RED adjuststhe packet droppingprobability, �� , in RED to keeptheaveragequeuesizegreaterthanminthreshandlessthanmaxthresh.In particu-lar, theoriginal versionof Adaptive RED increased�� multiplicatively when the averagequeuesize went belowminthresh,anddecreased�� multiplicatively whentheaveragequeuesizewentabove maxthresh.

Jacobsonet al. in [15], a early draft of an in-progresspaper, suggestaself-tuningREDwith theREDparametersdeterminedby thebandwidthof theoutputlink. Otherpro-posalsin [15] includesettingtheaveragequeuesizeto theinstantaneousqueuesizewhenever theinstantaneoussizeislessthantheaverage,andsettingminthreshto

*.-?��».

Ziegler et al.[21, 22, 23] explore the stability of RED,andrecommendsettingsfor �� sothattheaveragequeuesize converges to

w½¼D¾ �D� { w!xzy ��° . In this paper, we followtheir goal of loosely converging to a certainqueuesize:“we defineconvergencevery loosely asachieving a stateof boundedoscillationof thequeue-sizearoundavaluebe-tween�� and �� sothattheamplitudeof theoscil-lationof theaveragequeuesizeis significantlysmallerthan��¿f �� andthe instantaneousqueue-sizeremainsgreaterthanzeroandsmallerthanthetotalbuffersize”[21].[21] recommendssettingsof �� , �� , % & , and �� to achieve thesegoals. Ziegler et al. set %'& asa functionof the link bandwidthto give a fixed time constantin ofonesecondfor theestimator. Ziegler et al. alsoshow thattheoriginalAdaptiveREDfrom [6, 7] doesnotalwaysgivegoodperformance.

May et al.’s critical evaluationof RED in [18] summa-rizesasfollows: “RED with smallbuffersdoesnot improvesignificantlytheperformanceof thenetwork”, and“param-etertuning in RED remainsan inexact science,but hasnobig impactonend-to-endperformance”.

Christiansenet al.[5] evaluatedREDexperimentallyin alaboratoryscenariowith webtraffic with congestiononly inthe forward path,andconcludedthat RED offers no clearadvantageover tail-drop FIFO in termsof per-connectionresponsetimesfor web users.The paperalsoreportsthatperformanceis quitesensitive to thesettingof REDparam-eters.

Misra et at. in [19] alsodiscussthedifficulties in tuningREDparameters.They illustratethebenignoscillationsintheinstantaneousqueuesize,andsaythatthey arecurrentlyinvestigatingtuningRED parameters.Hollot et al. in [13]also focus on oscillationsin the queuesize, and usethisstartingpoint to recommendvaluesfor REDparameters.

Firoiu et al. in [8] alsoconsideredproblemswith REDsuchasoscillationsin thequeuesize,andmaderecommen-dationsfor configuringREDparameters.[8] recommended

that the ideal rate for samplingthe averagequeuesize isonceperround-triptime.

A numberof papershaveproposedalternatemechanismsfor activequeuemanagement.TheseincludeOttetal.’sSta-bilized RED (SRED)[20], Lapsley et al.’s RandomEarlyMarking(REM) [17, 4], Hollot etal.’sProportional-Integral(PI) controller[14], andKunniyuretal.’sAVG [16].Severalof theseproposalsshareAdaptive RED’s goal of keepinga stableaveragequeuesize with changinglevels of con-gestion. AVG tries to keepthe averagequeuesize smallevenduringhigh congestion,andusesa tokenbucket witha fill rate lessthanthe link capacity. The PI controller isprimarily designedto avoid oscillationsin the queuesize.SREDtacklesthegoalof stabilizingthebuffer occupancyby estimatingthe numberof active flows. Aweya et al.’sDynamic-RED(DRED) [2, 3] alsohasthe goal of main-taining thequeuesizecloseto a thresholdvalue,andusesa controllerthat adaptsthe packet-droppingprobability asa function of the averagedistanceof the queuefrom thethresholdvalue.

8 Conclusions

In thispaperwehavereportedonAdaptiveRED,which,byadaptingthe RED parameter�� andautomaticallyset-ting the RED parameters% & and �� , maintainsa pre-dictableaveragequeuesizeandreducesRED’s parametersensitivity. Adaptive RED, however, leaves the choiceofthetargetqueuesizeto network operatorswho mustmakea policy tradeoff betweenutilization anddelay. In futurework, we plan to explore the useof Adaptive RED in vir-tual queueswith the goal of providing very small averagequeueingdelays. In this case,the virtual queuewould beconfiguredwith a throughputslightly lower thantheactualthroughputof the link so that the queuingdelaywould bedeterminedsolelyby thetraffic burstiness.

References

[1] J.Aweya,M. Ouellette,D. Y. MontunoandA. Chap-man. EnhancingTCP Performancewith a Load-adaptive RED Mechanism. International Journal ofNetwork Management, V. 11,N. 1, 2001

[2] J.Aweya,M. Ouellette,D. Y. MontunoandA. Chap-man.A ControlTheoreticApproachto Active QueueManagement.Computer Networks 36, 2001.

[3] J.Aweya,M. Ouellette,D. Y. MontunoandA. Chap-man. An Optimization-orientedView of Random

11

Early Detection. Computer Communications, 2001,to appear.

[4] S.Athuraliya,D. Lapsley, andS. Low. An EnhancedRandomEarly Marking Algorithm for InternetFlowControl. Infocom 2000.

[5] M. Christiansen,K. Jeffay, D. Ott, andF. D. Smith.TuningREDfor WebTraffic. SIGCOMM, pages139–150,Sep.2000.

[6] W. Feng,D. Kandlur, D. Saha,andK. Shin. Tech-niques for Eliminating Packet Loss in CongestedTCP/IP Network. U. Michigan CSE-TR-349-97,November1997.

[7] W. Feng,D. Kandlur, D. Saha,andK. Shin. A Self-ConfiguringREDGateway. Infocom, Mar 1999.

[8] Victor Firoiu andMarty Borden. A Studyof ActiveQueueManagementfor CongestionControl.Infocom,pages1435–1444,2000.

[9] S. Floyd. RED: Discussions of Set-ting Parameters, November 1997.http://www.aciri.org/floyd/REDparameters.txt.

[10] S. Floyd, R. Gummadi,and S. Shenker. AdaptiveRED: An Algorithm for IncreasingtheRobustnessofRED. TechnicalReport,to appear, 2001.

[11] S. Floyd, M. Handley, J. Padhye, and J. Widmer.TFRCWebPage,2000.http://www.aciri.org/tfrc/.

[12] S. Floyd and V. Jacobson. RandomEarly Detec-tion Gatewaysfor CongestionAvoidance.IEEE/ACMTransactions on Networking, 1(4):397–413, Aug.1993.

[13] C. Hollot, V. Misra, D. Towsley, and W. Gong. AControlTheoreticAnalysisof RED. Infocom, 2001.

[14] C.Hollot, V. Misra,D. Towsley, andW. Gong.OnDe-signingImprovedControllersfor AQM RoutersSup-portingTCPFlows. Infocom, 2001.

[15] V. Jacobson,K. Nichols, and K. Poduri, REDin a Different Light, September1999. draft,www.cnaf.infn.it/̃ferrari/papers/ispn/red light 9 30.pdf.

[16] S.KunniyurandR.Srikant.AnalysisandDesignof anAdaptive Virtual Queue(AVQ) Algorithm for ActiveQueueManagement.CSL TechnicalReport,Univer-sity of Illinois, January2001.

[17] D. Lapsley andS. Low. RandomEarly Marking forInternetCongestionControl. Proceedings of Globe-com ’99, pages1747–1752,December1999.

[18] M. May, J. Bolot, C. Diot, and B. Lyles. ReasonsNot to Deploy RED. Proc. of 7th. International Work-shop on Quality of Service (IWQoS’99), pages260–262,June1999.

[19] VishalMisra, Wei-Bo Gong,andDonaldF. Towsley.Fluid-basedAnalysisof a Network of AQM RoutersSupportingTCP Flows with an Application to RED.SIGCOMM, pages151–160,2000.

[20] T. Ott, T. Lakshman,andL. Wong. SRED:StabilizedRED. Infocom, 1999.

[21] T. Ziegler, S. Fdida, and C. Brandauer. Stabil-ity Criteria for RED with Bulk-data TCP Traffic,2001. TechnicalReport,August 1999.http://www-rp.lip6.fr/publications/production.html.

[22] T. Ziegler, S. Fdida, and C. Brandauer.Stability Criteria for RED with TCPTraffic, May 2000. Technical Report,http://www.newmedia.at/tziegler/papers.html.

[23] T. Ziegler, S. Fdida, C. Brandauer, and B. Hechen-leitner. Stability of RED with Two-wayTCP Traffic, October 2000. IEEE ICCCN,http://www.newmedia.at/tziegler/papers.html.

12

Adaptive RED: An Algorithm for Increasing the Robustness ...

Documents

Transcript of Adaptive RED: An Algorithm for Increasing the Robustness ...