led: load early detection: a congestion control algorithm based on

Vol. 2 IPSJ Digital Courier Feb. 2006

Regular Paper

Load Early Detection (LED): A Congestion Control Algorithm

Based on Routers’ Traffic Load

Arjan Durresi,†1 Leonard Barolli,†2 Mukundan Sridharan,†3

Sriram Chellappan†3 and Raj Jain†4

Efficient bandwidth allocation and low delays remain important goals, especially in high-speed networks. Existing end-to-end congestion control schemes (such as TCP+AQM/RED)have significant limitations to achieve these goals. In this paper, we present a new and sim-ple congestion control scheme, called Load Early Detection (LED), that achieves high linkefficiency and low persistent queue length. The major novelty of LED is that it gauges thecongestion level by measuring the traffic load instead of the queue length. We show analyt-ically that this feature of LED enables it to detect congestion earlier and react faster thanother schemes. To gain insight into the behavior of LED and compare it with RED, we ana-lyze a simple fluid model, and study the relation between stability and throughput, especiallyfor low delays. We evaluate the performance of LED using extensive ns2 simulations over awide range of network scenarios. Our simulation results show that LED achieves significantlyhigher link efficiency than RED (up to 83%), REM (up to 141%), and PI controller (up to88%), especially in the presence of low delays.

1. Introduction

End-to-end traffic management and conges-tion control continues to be one of the ma-jor pillars for the robustness of the Internet 1).Because of the randomness of Internet traffic,at least within short periods, over-provisioningcannot fully avoid congestion. Moreover, in-sufficient congestion control could lead to con-gestion collapse 1). Minimizing queuing delaysis especially important in high bandwidth net-works. The end-to-end delay that affects users’traffic is the sum of three components: (a) prop-agation delay, (b) transmission delay, and (c)queuing delay. Propagation delay depends onthe distance and speed of a signal, therefore fora given distance it cannot be minimized. Trans-mission delay is the ratio of the size of the datato be transmitted to the bandwidth. Therefore,it can be reduced by increasing the bandwidth.It is for this precise reason that users are willingto pay for more bandwidth. But, the advantageof using high bandwidth to reduce transmissiondelay can be lost in the presence of queuing

†1 Department of Computer Science, Louisiana StateUniversity, Baton Rouge, Louisiana, USA

†2 Department of Information and Communication En-gineering, Fukuoka Institute of Technology (FIT),Japan

†3 The Ohio State University, Columbus, Ohio, USA†4 Washington University in St. Louis, St. Louis, Mis-

souri, USA

delay, which increases the total end-to-end de-lay. Therefore, congestion control, with the ac-tive participation of routers, will be an impor-tant part of high-bandwidth Internet solutions.Since TCP is still the dominant protocol for theInternet, and in views of TCP’s known behav-ior of congesting the network in order to probeits capacity, we need schemes that have a veryfast response to an increase in the traffic level.

Although a number of schemes have been pro-posed for congestion control, the search for newschemes continues 1)∼11). As a result of the in-crease in web traffic on the Internet, there isa need for algorithms to react faster to con-gestion. Surveys of various congestion controlalgorithms proposed for use in routers can befound in Low, et al. 12) and Medina, et al. 13).

The proposed solutions cover a wide spec-trum of improvements. At one end of this spec-trum there are simpler, more incremental, andmore easily employable changes to the currentTCP. Examples of such proposed solutions areRandom Early Detection (RED) 14) and Ex-plicit Congestion Notification (ECN) 15). Atthe other end of the spectrum are solutions in-corporating more powerful changes that resultin new transport protocols with higher perfor-mance but with less chance to be deployed on alarge scale on the Internet, at least in the imme-diate future. An example of such a solution isXCP 11). Other proposals, such as Random Ex-ponential Marking (REM) 2), Proportional In-

94

Vol. 2 Load Early Detection (LED) 95

tegral (PI) controller 7), HighSpeed TCP 6), andQuick Start TCP 8) reside along the simplicity-deployability spectrum. In the end, the choiceamong all these solutions depends on makinga tradeoff between performance and practicaluse that is best suited to the Internet. Becauseof the size and multidimensional complexity ofthe Internet, robustness in heterogeneity is val-ued over efficiency of performance, which causesevolutionary change to be favored over revolu-tionary change. For this reason, in our solu-tion we propose minimal changes to RED/ECNand try to derive the maximum performanceimprovements out of them.

Today’s routers use some form of ActiveQueue Management (AQM) scheme based onthe queue length. RED 14) and ECN 15),16)

are well-known algorithms, and are consideredthe current standards. RED randomly dropspackets even before the queue is full, with aprobability of packet drop calculated from thequeue size. ECN is a modification to REDwhere a bit in the IP header is set and usedwhen the routers decide to drop a packet. Theprobability-calculating function used in ECN isthe same as that in RED (or with some mi-nor modification, but still based on the size ofthe queues built in routers). In our scheme,we still use the framework of the ECN to con-vey the congestion information to the source.That is, we still mark the same bits used inECN to indicate congestion, but we intend tochange the probability-calculating algorithm ofECN. REM 2) and PI controller 7) are two of theother well-known algorithms to which we com-pare our scheme. Both REM and PI controllerattempt to tune the average queue length to atarget queue size. REM embeds the differencein target and average queue size along with thedifference in input rate and the capacity of thelink into a parameter price, which serves as ameasure of congestion. Packets at the link arethen marked or dropped exponentially in rela-tion to the price. PI also employs the differencein average queue size and target queue size, aswell as the difference between queue size in theprevious time period and target queue. Theseare then scaled by factors a and b 7) to obtainthe loss probability. In LED, presented here,the probability of packet mark/drop is calcu-lated on the basis of the traffic load at routers.We also show that our LED performs betterthan RED, REM, and PI Controller. In par-ticular, we show by theoretical and experimen-

tal analysis that LED reacts faster to conges-tion than other solutions. The predominanceof short-lived traffic on the Internet requiresrouters to employ congestion control algorithmsthat detect congestion early and react fast.

The remainder of the paper is organized asfollows. In Section 2, we present the LED al-gorithm and describe it in detail. In Sections 3and 4, we analyze our scheme, using control the-oretic tools. We use Delay Margin (DM) prin-ciples to check the stability of the system andanalyze its effect on the throughput of LED incomparison with RED. The ns2 simulationshave been used to compare the performance ofLED to that of the other schemes (RED, REM,and PI Controller). In Section 5, we presentour simulation results using ns2 17) simulator.In Section 6, we discuss parameter settings andimplementation issues. In Section 7, we presentthe conclusions of our research.

2. Algorithm for Calculating the Prob-ability of Packet Marking UsingLED

It is a known fact that in any AQM-basedscheme the delay in the system could be tradedfor better throughput. The significance of ourscheme is that it achieves a better tradeoff thanthe current AQMs. The principle behind thescheme is to use the traffic load at the router todetermine the packet mark strategy. By trafficload, we imply the ratio of the number of bytesreceived to the capacity of the router in a partic-ular interval of time. If an algorithm can keepthe value of the traffic load always one, that is,if it can make the in-rate equal to the out-rate,then such a system will be able to guarantee a100 percent throughput with zero delay.

The ultimate aim of any traffic managementscheme is to keep the traffic load at the routerequal to one. A traffic load of less than oneleads to under-utilization of bandwidth, while atraffic load more than one results in congestionand queue build up. Rather than trying to con-trol the queue at an optimum value and therebyindirectly controlling the traffic load, a schemethat directly controls the traffic load will per-form better by itself adapting faster to changesin traffic load. Traffic-load-based schemes suchas LED can sense an increase in traffic prior toqueue build-up, which is a consequence of con-gestion.

A scheme based on queues can never sensean increase in traffic, unless there is an actual

96 IPSJ Digital Courier Feb. 2006

queue build-up. For example, in RED, if theminth is set to, say, 20 packets, then the routerwould not start marking the packets unless thequeue reaches at least 20 packets, but in ab-solute terms, even a queue of one would meanan imbalance between the in-rate and the out-rate. On the other hand, if we set the thresh-olds very low, the RED queue oscillates moreand reaches the value zero often, thus, leadingto a significantly lower throughput in the low-delay region. We also show in Sections 3 and 4,using control theoretical tools, that the queuein a scheme based on traffic load, such as LED,oscillates less and consequently leads to higherthroughput in the low-delay region, than thequeue in RED. In the high-delay region, whichis not desirable for users, all schemes producegood throughput. Our proposed algorithm usedto calculate the probability of packet markingor dropping is described in following section.

2.1 AlgorithmLED computes an average traffic load run-

ning average similar to the one used to calculatethe queue length in TCP-RED. That is, theaverage load factor is computed as a weightedaverage of the previous average and the new (in-stantaneous) load estimate. The average trafficload is calculated at discrete intervals of timet = nτ , where n = 0, 1, 2, 3, . . . , n and τ isthe time interval. The traffic load is given byEq. (1):

Lavg(nτ ) = (1−α)Lavg((n−1)τ )+αL(nτ ),(1)

whereLavg(nτ ) = Average traffic load

at t = nτ, (2)L(nτ ) = Traffic load at t = nτ

=Bytes arrived in (nτ, (n+1)τ )

Cτ,

(3)α = Averaging weight, 0 < α < 1. (4)

The reason for using an average load fac-tor rather than an instantaneous one is thatit captures more accurately the notion of con-gestion. Because of the bursty nature of theInternet traffic, the load factor can oscillaterapidly. Therefore, the weighted average cal-culation tries to balance the reaction to long-lived and instantaneous congestion, by filter-ing short-term changes in the load factor. Theweighting parameter α is selected to smooth the

Fig. 1 Probability of a packet being marked.

instantaneous traffic load. A large α trackschanges in traffic load but might be heavilyinfluenced by temporary fluctuations. On theother hand, a small α might not be quickenough to adapt to real changes in traffic. Moredetails of how to select the weighting parameterα are given in Section 6.2. The average trafficload calculated at time t = nτ is used in theinterval [nτ, (n+1)τ )] to mark or drop packets.

Two thresholds, namely, minimum threshold(minth) and maximum threshold (maxth), aremaintained for the traffic load. At the timeof each packet arrival, the calculated averagetraffic load is compared to thresholds. If theaverage traffic load is below (minth), no ac-tion is taken. If the traffic load is found tobe between (minth) and (maxth), the packet ismarked if it is ECN-capable and dropped if itis not with some probability, whose calculationis described later in this section. If the trafficload is above (maxth), the packet is marked ifit is ECN-capable and dropped if it is not.

If Lavg(nτ ) > maxth

Mark/Drop packet;else if(minth < Lavg < maxth)

Mark/Drop packetwith Probability p;

The calculation of the probability of packetmarking or dropping follows a linear pattern asshown in Fig. 1. As the traffic load varies fromminimum to maximum thresholds, the proba-bility of marking varies from 0 to 1 linearly.The maximum probability of dropping in thisscheme is 1. This is then adjusted against thecount, which is the number of packets since thelast drop or mark. The probability is also mod-ified to take care of the packet length. Thus,the probability is given by

p =p′ × PacketSize

Maximum Packet Size, (5)


where

p′ =p′′

1 − count × p′′and

p′′ =Lavg − minth

maxth − minth.

As shown in this section, the implementa-tion of LED is simple. Only the probability-calculating algorithm need to be changed inrouters that implement RED/ECN. No changeis required in TCP end users.

2.2 Initialization and Idle Period Set-tings

The average traffic load is set to the mini-mum threshold during the initialization of thequeue. When the link is idle for a particularperiod of time, which is denoted by the absenceof any packet arrivals, the average traffic loadis calculated during that period by setting theinstantaneous traffic load to zero. Hence, if thelink is idle for a period of n time intervals, atthe end of the idle period the average trafficload is scaled to

Lavg((n + k)τ ) = (1 − α)nLavg(kτ). (6)At the end of the idle period, the average traf-

fic load is set to the minimum of the value cal-culated above and the minimum threshold setfor the average traffic load. Thus, the averagetraffic load is gradually reduced during the idleperiod, but never allowed to go below the mini-mum threshold. This is done to ensure a fasterresponse of the router to the congestion infor-mation when it comes back from the idle period.

3. Stability Analysis

To study the stability of the LED system,we have developed a control theoretical model,which is presented in the Appendix. We useDM as the major metric 18) to estimate the sta-bility of LED as a closed feedback system. IfDM is negative, the system will oscillate. Apositive DM represents how much the RoundTrip Time (RTT) can be increased without vio-lating the stability of the feedback system. Ourgoal is to keep the system stable, while the delayis low. If the system oscillates when the delay islow (i.e., when the queue is small), the systemwill have often an empty queue and therefore alow link utilization.

Assuming that a steady-state queue lengthexists at equilibrium, from Eq. (A.18),Eq. (A.19) and Eq. (A.21) the open loop trans-fer function of the LED scheme is

GLED =C2N s(

s + 2NR2

0C

) (s + 1

R0

)e−R0s

× LLED

1 + skLED

, (7)

where

LLED =1

maxth − minth.

We further assume that the low-pass fil-ter pole kLED is less than the corner fre-quency of TCP’s dynamics and that it dom-inates the closed-loop system behavior. Theunity-gain crossover frequency ωLED (i.e.,|gLED(jωLED| = 1)) thus satisfies

ωLED � min

{2N

R20C

,1

R0

}. (8)

Then at low frequency we have

GLED(s) ≈ KLEDs

1 + skLED

e−R0s, (9)

where

KLED =R3

0C2

(2N)2LLED. (10)

The phase margin of the LED system Eq. (7)without delay is:

PMLED(ωLED) = π+π

2− arctan

(ωLED

kLED

)

=3π

2− arctan

(ωLED

kLED

),

(11)and the DM, which represents how much theRTT can be increased without violating the sta-bility of the feedback system, is then

DMLED(ωLED) =PMLED(ωLED)

ωLED− R0

=3π2 − arctan

(ωLED

kLED

)ωLED

−R0, (12)

where ωLED is the smallest solution of|GLED(jωLED)| = 1, i.e.,

ωLED =1√

K2LED − 1

k2LED

. (13)

On the other hand, as shown in Hollot, etal. 20), the open-loop transfer function of theclassical TCP-RED scheme is

GRED(s) ≈ KREDs

1 + skRED

e−R0s, (14)

where,


KRED =R3

0C2

(2N)2LRED, (15)

LRED =Pmax

maxth − minth, (16)

kRED = −C ln(1 − αRED), (17)where αRED is RED’s queue-averaging weight.The DM for RED is thus

DMRED(ωRED) =π − arctan

(ωRED

kRED

)ωRED

− R0, (18)where

ωRED = kRED

√K2

RED − 1.

Note that the derivative term appearing inthe open-loop transfer function from Eq. (A.18)adds a 90◦ phase and thus increases the DM ofthe system. Therefore, the oscillations in thequeue are reduced, leading to an improvementin the throughput, with correspondingly low de-lays.

To achieve high stability, we need to keep (bychanging the scheme parameters) a large posi-tive value of DM in the presence of low delays.The delay level is set by minth and (maxth −minth). A larger DM would lead to fewer os-cillations in the system. In Fig. 2, Fig. 3, andFig. 4, we plot the DM as a function of thenetwork parameters N , (maxth − minth) andα. The DM increases as N , (maxth − minth),increases. It decreases as α increases.

Figure 2 shows the variation of the DM withN , for the link capacity C = 200 packets/sec,R0 = 0.06 s, α = 0.05, minth = 0.8, andmaxth = 1.2. Figure 3 shows the variation ofDM with (maxth − minth) for C = 200 pack-ets/sec, R0 = 0.06 s and N = 5. Figure 4 showsthe variation of DM with α for C = 200 pack-ets/sec, R0 = 0.06 s, minth = 0.8, maxth = 1.2,and N = 5.

Fig. 2 Variation of DM with N .

The estimator of stability for low delay isthe DM, which is shown in Fig. 2, Fig. 3, andFig. 4. Because the fluid model used for thesystem is an approximation of TCP, we validatethe model with ns2 simulations. In the follow-ing, we analyze the performance of the LEDscheme. Our comparisons are based on ns2plots of average traffic load and queue lengthversus time. Figure 5 shows the performanceof LED scheme with corresponding parametersspecified in Table 1.

We now tune the system for a more stableresponse. From Eq. (12), we can do this by de-creasing kLED (decreasing α), as this will givea higher delay margin, making the system lessoscillatory. We thus decrease α to 0.001. Theresponse of the system is shown in Fig. 6, where

Fig. 3 Variation of DM with minth − maxth.

Fig. 4 Variation of DM with α.

Fig. 5 Traffic load vs. time in case 1.


Table 1 Simulation parameter choices.

Case Weight maxth minth C N1 0.05 1.2 0.8 200 102 0.01 1.2 0.8 200 103 0.005 1.2 0.8 200 104 0.05 1.2 0.8 200 20




the system is less oscillatory. However, an in-crease in the averaging parameter causes a moresluggish response, and there are still certain os-cillations in the queue.

We can further stabilize the system by de-creasing the averaging parameter as shown inFig. 7, where α = 0.005.

The number of flows in the router also playsan important role in the queue oscillations. Alarger N will lead to fewer oscillations, as shownin Eq. (12). As in case 1, we keep α = 0.05 andincrease N to 20. The response shown in Fig. 8is less oscillatory than that in Fig. 5.

As shown by the above experiments, the pre-dictions of our model are validated by ns sim-

ulations. Our model can thus be used to tunethe parameters in the LED scheme.

4. Performance Improvement

In this section, we use the DM to analyze whythe LED scheme performs much better thanthe RED scheme in the low-delay region, as inQuet, et al. 19).

The DM measures the stability of the sys-tem. In the low-delay region, we will show thatRED has more oscillations in the queue thanthe LED scheme. Oscillations in the queue inthe low-delay region cause the queue to go tozero often. In this case, the link is greatly un-derutilized, which reduces the throughput. Incontrast, LED enables higher throughput in thelow-delay region because there are fewer oscil-lations. We proceed to explain this result bycomparing the DM for both cases.

Equation (12) gives us the DM for the LEDscheme. From Hollot, et al. 20), we derived DMfor RED in Eq. (18).

We can see that DM is a decreasing func-tion of ωg and k (for both the RED and LEDschemes). Then, from Eq. (12) and Eq. (18),if KLED is less than KRED, and kLED is lessthan kRED, we have a higher DM for the LEDscheme than for RED. Our comparison of theRED and LED schemes uses the same valueof R0. From Eq. (10) and Eq. (15), we seethat KLED is less than KRED in the low-delayrange, where minth and (maxth − minth) arelow for the RED scheme. If minth is set high,then we operate in the high-delay range, whereoscillations in the queue have no effect on thethroughput of the system. From Eq. (A.9) andEq. (17), we see that kRED is higher than kLED

in most cases. This implies that, in the low-delay region, oscillations are higher in the REDscheme than in the LED scheme.

The above DM analysis shows that LED en-ables fewer oscillations than RED in the low-delay regions. This means that the traffic loadin the RED scheme oscillates more than thetraffic load in the LED scheme. From Eq. (A.7),we see that oscillations in the queue in theLED scheme are fewer than in the RED scheme.Thus, in the low-delay region, in the LEDscheme the queue does not go to zero as of-ten as it does in similar regions for RED. Wecan see the confirmation of this phenomenon inFig. 11, Fig. 12, Fig. 13, and Fig. 14, which wereobtained by ns2 simulations.

Consider the cases shown in Fig. 12 and


Fig. 14. The capacity of the router’s outputlink is C = 187.5 packets/sec, number of flowsN = 30, α = 0.05, and Tp = 52 ms. For the caseof the LED scheme, the thresholds were set to0.8 and 1.5. We observe an R0 value of 0.2 s inFig. 12. Furthermore, in the cases we have ana-lyzed, we assume that τ = R0 to compute kLED

from Eq. (A.9). The calculated DM is higher inthe LED scheme than in RED. Therefore, thethroughput is expected to be higher in LEDthan in RED.

The above theoretical analysis is confirmedby the simulation results presented in Sec-tion 5. We would like to stress that, for high-bandwidth networks, it is important to ob-tain high throughput while keeping the queuinglow. The main reason for users to use and payfor higher-bandwidth networks is to reduce thewhole communication time by reducing trans-mission delay. Therefore, it is very important tominimize the queuing delay. Otherwise, whatwould be gained in terms of delay from usinghigh bandwidth would be lost through queuingdelays. In queuing systems, including RED andLED, it is generally possible to trade through-put for delay, which means that such systemscould provide high throughput in the presenceof high delays. But, as we explained, espe-cially in high-bandwidth networks long queu-ing delays cannot be tolerated. As is shown bythe simulation results, LED guarantees higherthroughput than RED in the low-delay range.Therefore, the ability of the LED scheme to pro-vide higher throughput in the low-delay regionis its principal advantage, which finally justifiesits implementation.

5. Simulation Results

5.1 FTP Traffic ModelThree different simulation configurations are

used to compare the LED scheme to RED 14),REM 2), and PI controller 7). Our goal is tominimize the changes required in routers, in or-der to have a chance for the protocol to be usedin practical conditions. For this reason, we donot compare LED to solutions that require theimplementation of new protocols in routers andend users such as XCP 11).

The first configuration simulates FTP traffic.This model is used to study the effects of thescheme on the TCP dynamics. A number ofsources, S1, S2, S3, . . . , Sn, are connected toa router R1 through 10 Mb/s, 2 ms delay links.Router R1 is connected to R2 through a 5 Mb/s,

Fig. 9 Network configuration.

Table 2 Parameter values for RED, REM, and LED.

Parameter RED LED REMQueue weight 0.002

Maximum probability 0.2Minimum threshold 1–40 0.8Maximum threshold 3–120 0.95–1.75

LED weight 0.05Update interval (sec) 0.05 0.002

γ 0.01φ 1.001

Target queue 1-80

20 ms delay link, and is the congested link inthis configuration. A number of destinationnodes D1, D2, D3, . . . , Dn are connected tothe router R2 via a 10Mb/s, 4 ms delay link.The packet size is 1,000 bytes. Figure 9 showsthe simulation configuration.

The parameter settings for RED, REM, andLED are shown in Table 2. Another simu-lation is performed using the above topology,but with variation in the RTT of the sources.The link delay for source and destination linksvaries from 1–10 ms, resulting in different RTTfor different flows. In addition reverse path traf-fic is induced by adding some sources startingat nodes D1, D2, and so on.

5.2 Mixed Traffic ModelThe mixed traffic model is configured to sim-

ulate web traffic. It consists of• Several exponential traffic sources running

over the UDP, which create a self-similartraffic, used to model the Internet back-ground traffic.

• Several web sources and clients, to modelthe web traffic to be analyzed.

• Between five and ten FTP sources to modelthe bulk data traffic.

The network configuration used was an un-balanced dumbbell topology, very similar to theconfiguration for FTP traffic. The sources con-nected to node R1 were replaced by a combi-nation of web sources, FTP sources, and expo-nential sources, as mentioned above. The desti-nation nodes were collection web clients, TCP


Fig. 10 Simulation configuration for multiplecongested gateways.

and UDP sinks.In this model, we wanted to simulate typical

high-bandwidth Internet conditions, which areshown to be characterized by self-similar traffic.We measure the “self-similarity” of our modeltraffic by using the Hurst parameter. Thisparameter indicates the degree of traffic self-similarity. Usually, the Hurst parameter of webtraffic is between 0.75 and 0.85. For our mixedmodel, the Hurst parameter was measured byusing a variance-time plot 21), and was found tobe 0.807.

5.3 Multiple Congested Gateways Mo-del

The multiple congested gateways model isused to observe the response of the schemewhen multiple congested links all following thesame queue management scheme are used. Itis a typical parking lot configuration. Differ-ent flows in the network travel for different dis-tances. There are N +1 routers in the network,R0 to RN . At each router, 20 flows enter thenetwork. In our experiment, we used a config-uration with four routers. In addition, 20 flowsexist between routers R0–R1 and R1–R2. Thesimulation configuration is shown in Fig. 10.

5.4 Simulation ResultsIn all configurations, the throughput versus

the queuing delay at the congested link is plot-ted. The parameters used for the schemes areshown in Table 2 and Table 3. RED, REM,and LED have the same parameters for all theconfigurations. For PI, the two critical pa-rameters a and b are calculated by followingthe procedure outlined in Hollot, et al. 7). ForREM, the guidelines specified in Athuraliya 22)

have been followed to obtain high responsive-ness. For the multiple congested gateways,configuration the total system throughput ver-sus the end-to-end queuing delay is compared.For flows using TCP as transport protocol, thethroughput is calculated for the total number of

Table 3 Parameter values for PI.

Parameter FTP Mixed Multiple gatewaysTarget queue 1–80 1–80 1–80

A 0.1965 0.09 0.0592B 0.024 0.013 0.0102

Fig. 11 RED queue for minth = 1.



acknowledged packets. For UDP packets, onlythe packets successfully reaching the destina-tion node are included in the calculation. Itshould be noted here that this throughput is dif-ferent from the actual number of packets thathas actually left the congested link, since du-plicate acknowledgments and packets that mayhave been dropped at destination nodes are notincluded in throughput measurement.

Figure 11, Fig. 12 and Fig. 13 plot the av-erage queue length at the output link for RED,while Fig. 14 does the same for LED. The


Fig. 14 Queue for the LED scheme.

Fig. 15 Throughput vs. queuing delay (FTP traffic).

oscillations in the queue decrease for RED asthe difference between the minimum and maxi-mum thresholds is increased from 2 to 20 pack-ets (when the minimum threshold is increasedfrom 1 to 10, the maximum threshold becomesthree times the minimum threshold), with acorresponding increase in the throughput, al-beit at a higher delay. The average queue forthe LED scheme is shown in Fig. 14, for a mini-mum threshold of 0.8 and a maximum thresholdof 1.2.

Comparing the queues in Fig. 12 and Fig. 14,it can be observed that LED leads to fewer os-cillations in the queue than RED, for similarqueuing delay. Therefore, LED enables a higherutilization of the link than RED. These resultscan be explained by the faster response to con-gestion by LED than that of RED. As shownin Fig. 13, to achieve a similar throughput asLED, RED needs to operate with an averagedelay (20 packets) higher than LED. Therefore,these experimental results validate our theoret-ical conclusion that LED with correspondinglylow delays can achieve higher throughput thanRED.

We plot four cases of throughput versus queu-ing delay graphs that illustrate superiority ofLED performance to those of RED, REM, andPI controller. The first two cases, the Fig. 15and Fig. 16, show the throughput for FTP

Fig. 16 Throughput vs. queuing delay (with reversetraffic, FTP traffic).

Fig. 17 Throughput vs. queuing delay (multiplecongested gateways).

sources. The simulation configuration is shownin Section 5.1. In Fig. 15, we set the minimumthreshold to 0.8 and vary the maximum thresh-old from 1.0 to 1.75 in such a way that the aver-age delay increases with throughput. Figure 15shows the FTP throughput with forward pathtraffic only. As can be seen, LED performs bet-ter in terms of link efficiency than RED (up to115%), REM (up to 141%), and PI controller(up to 44%), in the presence of low delays. Fig-ure 16 shows the throughput when reverse traf-fic is also included. Again, in the low-delay re-gion, LED performs better in terms of link ef-ficiency than RED (up to 42%), REM (up to65%), and PI controller (up to 188%).

Figure 17, shows the result for the multi-ple congested gateways configuration. As canbe seen, LED performs better in terms of linkefficiency than RED (up to 34%), REM (up to46%), and PI controller (up to 43%), especiallyin the presence of low delays. It can also beobserved that the effect is multiplied in com-parison with the simple FTP configuration inFig. 15. For the results shown in Fig. 18, weused the simulation configuration described inSection 5.3. This configuration is used to testour scheme on a more realistic traffic model,which includes simultaneous web, FTP, and


Fig. 18 Throughput vs. queuing delay (mixed trafficmodel).

UDP traffic. As shown in Fig. 18, in the low-delay region LED performs better in terms oflink efficiency than RED (up to 83%), REM (upto 75%), and PI controller (up to 75%).

6. Discussion of Parameters and Im-plementation

6.1 Time IntervalThe first parameter to be considered is the

interval at which the traffic load is estimated.The effect of the actions taken by the traf-fic management scheme affects the router oneround trip time later. Hence the time constantof the dynamics of the traffic load cannot befaster than the lowest RTT among all of theflows. While the choice of estimated interval inthe presence of different RTT-s is beyond thescope of this paper, a practical solution wouldbe to set τ equal to the average RTT. For allour simulations, we chose an estimation intervalcomparable to RTT.

6.2 Traffic Load Weight αFollowing the same principles of the RED

time constant as in Floyd and Jacobson 14)

and Floyd, et al. 23), we assume that it takes−1/ln(1 − α) time intervals for the traffic loadestimator to reach 63% of a new value, or thatthe time constant of our system is −τ/ln(1−α)seconds. Letting this time constant in our sys-tem to be 1 second, we get

α = 1 − e−τ . (19)6.3 Thresholds (minth and maxth)Minimum threshold setting for the algorithm

determines how soon the packet marking iscommenced. A threshold of 0.8 indicates thatthe algorithm starts marking or dropping assoon as the number of bytes that have ar-rived exceeds 80% of the capacity of the link.The maximum threshold determines the size ofburst the link can tolerate. The higher the max-imum threshold, the higher the link delay andvice versa. The setting for the thresholds de-

pends on the amount of acceptable delay for thesystem and the input traffic pattern. One broadguideline would be to set maxth and minth oneither side of 1.0, both for stability and perfor-mance reasons. We are working on tuning theminimum and maximum thresholds adaptively,according to the traffic load.

6.4 Implementation IssuesThe implementation of the LED scheme is go-

ing to be similar to that of RED, since theyhave a similar architecture. The overhead in-volved in calculating the probability is going tobe less than in RED, since it is done once ev-ery second and not at the time of each packetarrival. The overhead is comparable with thatof REM and PI controller, since both employ asimilar time period. The complexity of settingthe parameters is also similar to that of REM,PI, or RED.

7. Conclusions

In this paper, we have presented LED, a newand simple congestion control scheme. LED hasa faster response to congestion than other solu-tions, because it measures the congestion levelby using the traffic load at routers.

To better understand the behavior of LEDand compare it with RED, we developed a fluidmodel, and used this model to analyze the sta-bility and efficiency of LED, especially for lowdelays.

Using extensive ns2 simulations, we showthat LED achieves high utilization for low de-lays. Our simulation results show that LEDperforms better in terms of link efficiency thanRED (up to 83%), REM (up to 141%), and PIcontroller (up to 88%), especially in the pres-ence of low delays.

Appendix

A.1 Appendix: Mathematical ModelIn the following, we develop a mathemati-

cal model that will allow us to justify our de-sign by carrying out a stability analysis of theimplicit feedback control system the schemeforms. Moreover, this model will help explainthe performance improvement we observe whilecomparing the LED to the RED-ECN scheme,and will provide guidelines for tuning the designparameters.

We consider a network configuration consist-ing of a single router supporting N homoge-neous TCP flows. As shown in Hollot, et al. 24)

and Misra, et al. 20), the congestion avoidance


mode of TCP can be modeled by using a fluidflow approximation:

W (t) =1

R(t)− W (t) × W (t − R(t))

2 × R(t − R(t))× p(t − R(t)), (A.1)

where W (t) is TCP’s congestion window size,R(t) is the RTT delay and p(t) is the probabil-ity of packet mark due to the AQM mechanismat the router. The RTT R(t) is composed ofthe propagation delay Tp and the queuing de-lay q(t)

C , where q(t) is the queue length of thebuffer and C is the outgoing link capacity, andthus

R(t) = TP +q(t)C

. (A.2)

The traffic load L(t) is defined as the ratio ofthe aggregate incoming rate to the router andthe outgoing link capacity. Hence,

L(t) =BytesArrived(nτ, (n + 1)τ )

Cτ.

(A.3)Now if Wx(t) is the window of packets that

could be sent in τ seconds, then

L(t) =NWx(t)

Cτ. (A.4)

Wx(t) is given by

Wx(t) =W (t)τR(t)

. (A.5)

L(t) becomes

L(t) =NW (t)CR(t)

. (A.6)

We then haveq(t)C

= L(t) − 1. (A.7)The above equation is true for both the RED

and LED schemes. Using similar techniques tothose used in Hollot, et al. 20), Eq. (1) is equiv-alent to the frequency-domain relationship:

Lavg(s) =L(s)

1 + skLED

(A.8)

where

kLED =− ln(1 − α)

τ, (A.9)

and the packet marking probability obeys thefollowing equation:

p(t) =Lavg(t) − minth

maxth − minth. (A.10)

From the above equations, the equilibriumof the dynamical system satisfies the followingequations:

W 20 p0 = 2, (A.11)

p(t) =L0(t) − minth

maxth − minth, (A.12)

L0 =NW0

CR0, (A.13)

R0 = TP +q0

C. (A.14)

Thus, since we would like to operate with aunitary traffic load (L0 = 1) and an equilibriumqueue q0 = 0, the traffic management schemeparameters minth and maxth should satisfy:

Tp2C2

N2

1 − minth

maxth − minth= 2. (A.15)

Following similar techniques to the ones usedin Hollot, et al. 20), we then carry out alinearization of Eq. (7) around the operatingpoint. To do so, we make the following as-sumptions: we neglect the effect of an even-tual queue length on the RTT dynamic (whichis reasonable if we keep a small queue size),we assume that L0 = 1, and we neglect somehigh-frequency dynamics (similarly to Hollot,et al. 20)). The perturbed variables about theoperating point then satisfy

δW (s)δp(s)

=R0C2

2N2

s + 2NR2

0C

e−sR0 . (A.16)

From Eq. (10), we also haveδL(s)δW (s)

≈ N

R0C. (A.17)

Thus, the plant to be controlled by the trafficmanagement scheme (transfer function form δpto δTL) is

P (s) =C2N

s + 2NR2

0C

e−sR0 , (A.18)

while our scheme (transfer function form δTLto δp) has the following linearization:

C(s) =LLED

1 + skLED

, (A.19)

where

LLED =1

maxth − minth. (A.20)

A block diagram of our scheme is shown inFig. 19. We further assume that the low-passfilter pole kLED is less than the corner fre-quency of TCP’s congestion window dynamicand that it dominates the closed-loop systembehavior. The unity-gain crossover frequencywg (i.e., |GLED(jwg)| = 1), where


Fig. 19 Block diagram of LED model.

GLED(s) = P (s)C(s) (A.21)is the open loop transfer function thus satisfies

wg � 2N

R20C

. (A.22)

Then, at low frequency, we have

GLED ≈ KLED

1 + skLED

e−R0s, (A.23)

where

KLED =(R0C)2 LLED

(2N)2. (A.24)

References

1) Floyd, S. and Fall, K.: Promoting the Use ofEnd-to-End Congestion Control in the Inter-net, IEEE/ACM Transactions on Networking,Vol.7, Issue 4, pp.458–472 (Aug. 1999).

2) Athuraliya, S., Low, S., Li, V. and Yin, Q.:REM Active Queue Management, IEEE Net-work Magazine, Vol.15, No.3, pp.48–53 (Aug.2001).

3) Clark, D.D. and Fang, W.: Explicit Al-location of Best-effort Packet Delivery Ser-vice, IEEE/ACM Transactions on Networking,Vol.6, No.4, pp.362–373 (Aug. 1998).

4) Durresi, A., Sridharan, M., Liu, C., Goyal, M.and Jain, R.: Congestion Control Using Multi-level Explicit Congestion Notification in Satel-lite Networks, Proc. 10th IEEE InternationalConference on Computer Communications andNetworks (ICCCN ), pp.483–488, Phoenix, AZ(2001).

5) Feng, W., Kandlur, D., Saha, D. and Shin, K.:Blue: A New Class of Active Queue Manage-ment Algorithms, Technical Report UM-CSE-TR-387-99, University of Michigan (1999).

6) Floyd, S.: HighSpeed TCP for Large Conges-tion Windows, IETF, RFC 3649 (Dec. 2003).

7) Hollot, C., Misra, V., Towsley, D. and Gong,W.B.: On Designing Improved Controllers forAQM Routers Supporting TCP Flows, Proc.INFOCOM-2001, San Francisco, CA, Vol.3,pp.1726–1734 (2001).

8) Jain, A., Floyd, S., Allman, M. and Sarolahti,P.: Quick-Start for TCP and IP, IETF Internet-draft, draft-amit-quick-start-04.txt (Feb.2000).

9) Jain, R., Kalyanaraman, S. and Viswanathan,R.: Ordered BECN: Why We Need a Times-

tamp or Sequence Number in the RM Cell,ATM Forum/94-0987 (Oct. 1994).

10) Kalyanaraman, S., Jain, R., Fahmy, S., Goyal,R. and Vandalore, B.: The Erica Switch Algo-rithm for ABR Traffic Management in ATMNetworks, IEEE/ACM Transactions on Net-working, Vol.8, No.1, pp.87–98 (Feb. 2000).

11) Katabi, D., Handley, M. and Rohrs, C.: In-ternet Congestion Control for Future HighBandwidth-delay Product Environments, Proc.ACM SIGCOMM-2002, pp.69–102 (Aug.2002).

12) Low, S.H., Paganini, F. and Doyle, J.C.: Inter-net Congestion Control, IEEE Control SystemsMagazine, Vol.22, pp.28–43 (Oct. 2002).

13) Medina, A., Allman, M. and Floyd, S.: Mea-suring the Evolution of Transport Protocols inthe Internet, ACM CCR, Vol.35, No.2, pp.35–51 (Apr. 2005).

14) Floyd, S. and Jacobson, V.: Random EarlyDetection Gateways for Congestion Avoid-ance, IEEE/ACM Transactions on Network-ing, Vol.1, Issue 4, pp.397–413 (Aug. 1993).

15) Ramakrishnan, K. and Floyd, S.: Proposal toAdd Explicit Congestion Notification (ECN) toIP, IETF, RFC 2481 (Jan. 1999).

16) Floyd, S.: TCP and Explicit Congestion Noti-fication, ACM SIGCOMM Computer Commu-nications Review, Vol.24, No.5, pp.8–23 (Oct.1994).

17) NS Project Homepage: Available athttp://www.isi.edu/nsnam/ns/

18) Ozbay, H.: Introduction to Feedback ControlTheory, CRC Press LCC, Boca Raton, FL(1999).

19) Quet, P.F., Chellappan, S., Durresi, A.,Sridharan, M., Ozbay, H. and Jain, R.: Guide-lines for Optimizing Multi-level ECN UsingFluid Flow Based TCP Model, Proc. ITCOM-2002, Quality of Service over Next GenerationInternet, Boston, MA, pp.106–116 (2002).

20) Hollot, C., Misra, V., Towsley, D. and Gong,W.B.: A Control Theoretic Analysis of RED,Proc. INFOCOM-2001, San Francisco, CA,pp.1510–1519 (2001).

21) Leland, W., Taqqu, M., Willinger, W. andWilson, D.: On the Self-similar Nature ofEthernet Traffic, IEEE/ACM Transactions onNetworking, Vol.2, Issue 1, pp.1–15 (Aug.1999).

22) Athuraliya, S.: Available at http://netlab.caltech.edu/pub/papers/REMparameter.pdf(Mar. 2002).

23) Floyd, S., Gummadi, R. and Shenker, S.:Adaptive RED, An Algorithm for Increasingthe Robustness of RED, Technical Report,ATT Center for Internet Research at ICIR(2001).

24) Misra, V., Gong, W.B. and Towley, D.: Fluid-


based Analysis of a Network of AQM RouterSupporting TCP Flows with an Applicationto RED, Proc.ACM/SIGCOMM-2000, pp.151–160 (2000).

(Received May 18, 2005)(Accepted November 1, 2005)

(Released February 8, 2006)

Arjan Durresi received theBSEE, M.S. and Ph.D. (allsumma cum laude) all in Elec-tronic and Telecommunications,in 1986, 1991 and 1993, respec-tively and a Diploma of SuperiorSpecialization in Telecommuni-

cations from La Sapienza University in Rome,Italy and Italian Telecommunications Institutein 1991. He is currently an Assistant Profes-sor in the Department of Computer Science,Louisiana State University. His current re-search interests include network architectures,heterogeneous wireless networks, security, QoSrouting protocols, traffic management, opticaland satellite networks, and bioinformatics. Dr.Durresi has authored more than 100 papers inrefereed Journals and International Conferenceproceedings. He is an area editor for the AdHoc Networks Journal. He is Program Chair ofIEEE AINA-2006. Dr. Durresi is the recipientof the Lumley Research Award from The OhioState University in 2002. He received the appre-ciation certificate from IEEE Computer Societyin 2005. He is a senior member of the IEEE.

Leonard Barolli receivedB.E. and Ph.D. degrees fromTirana University and YamagataUniversity in 1989 and 1997,respectively. Presently, he isa Professor at the Departmentof Information and Communica-

tion Engineering, Fukuoka Institute of Technol-ogy (FIT). Dr. Barolli has published more than100 papers in Journals and International Con-ference proceedings. He was an Editor of theIPSJ Journal and has served as an Guest Editorfor many Special Issues of International Jour-nals. Dr. Barolli has been a PC Member ofmany International Conferences. He was a PCCo-Chair of AINA-2003, PC Chair of AINA-2004 and PC Chair of ICPADS-2005. He isa General Co-Chair of AINA-2006. His re-search interests include network traffic control,fuzzy control, genetic algorithms, agent-basedsystems, ad-hoc networks, sensor networks andP2P systems. He is a member of SOFT, IPSJ,IEEE Computer Society and IEEE.

Mukundan Sridharan iscurrently a research assistant forthe Dependable Distributed andNetworked Systems Lab and ispursuing his Ph.D. degree inThe Ohio State University. Hereceived his B.E. and M.S. de-

grees from University of Madras and The OhioState University in 2000 and 2003, respectively.His research interest includes wireless and sen-sor networks, Internet measurements and con-gestion control.

Sriram Chellappan is agraduate student in the Depart-ment of Computer Science andEngineering at The Ohio-StateUniversity. His current researchinterests are in network security,congestion control and wireless

networks. He received his B.E. from Univer-sity of Madras and M.S. from The Ohio StateUniversity in 2003.


Raj Jain is a Professor ofComputer Science and Engi-neering at Washington Univer-sity in St. Louis. He is also aCo-founder and Chief Technol-ogy Officer of Nayna Networks,Inc. He was a Professor of Com-

puter and Information Sciences at The OhioState University in Columbus until August 2002and then an Adjunct Professor until August2004. He is a Fellow of IEEE, a Fellow of ACMand is on the Editorial Boards of ComputerCommunications, Journal of High Speed Net-works, Mobile Networks and Nomadic Applica-tions, International Journal of Virtual Technol-ogy and Multimedia, and International Journalof Wireless and Optical Communications. Hehas 14 patents, more than 40 journal and mag-azine papers, and more than 60 conference pa-pers. His papers have been widely referencedand he is known for his research on congestioncontrol and avoidance, traffic modeling, perfor-mance analysis, and error analysis.

led: load early detection: a congestion control algorithm based on

Documents