congestion control using multilevel explicit congestion ...jain//papers/ftp/mecn07.pdf ·...

Vol. 3 IPSJ Digital Courier Feb. 2007

Regular Paper

Congestion Control Using Multilevel Explicit Congestion Notification

Arjan Durresi,†1 Leonard Barolli,†2 Raj Jain†3

and Makoto Takizawa†4

Congestion remains one of the main obstacles to the Quality of Service (QoS) on the Inter-net. We think that a good solution to Internet congestion should optimally combine congestionsignaling from network and source reaction, with the following as its main goals: minimumlosses and delays, maximum network utilization, fairness among flows, and last but not least,scalability of the solution. The solution should not significantly increase the complexity ofrouter operations. In this paper, we present a new traffic management scheme based on anenhanced Explicit Congestion Notification (ECN) mechanism. Our Multilevel ECN (MECN)conveys more accurate feedback information about the network congestion status than thecurrent ECN. We have designed a TCP source reaction that takes advantage of the extrainformation provided about congestion. Therefore, MECN responds better to congestion byallowing the system to reach the stability point faster, which results in better network per-formance. We use control theoretical tools verified by ns2 simulations to show that MECNcan outperform up to twenty times in term of throughput the de facto standard RED/ECN.

1. Introduction

There is a strong demand for Quality of Ser-vice (QoS) in the Internet. One key elementof QoS is traffic management. Since the net-work traffic is bursty, it is difficult to make anyQoS guarantees without proper control of traf-fic. Currently, Internet Protocol (IP) only hasminimal traffic management capabilities. Thepackets are dropped when the queue exceedsthe buffer capacity. The Transmission ControlProtocol (TCP) uses the packet drop as a signalof congestion and reduces its load 1). While inthe past this strategy has worked satisfactorily,now we need better strategies for two reasons 2).First, the bandwidth of the networks, as wellas the distances, are increasing. For very highdistance-bandwidth product networks, packetdrop is not the optimal congestion indicator.Several megabytes of data may be lost in thetime required to detect and respond to packetlosses. Therefore, a better strategy for trafficmanagement in IP networks is required. Sec-ond, a large part of the traffic, particularly voiceand video traffic does not use TCP. Continuousmedia traffic uses User Data Protocol (UDP).The proportion of UDP traffic is increasing ata faster pace than TCP traffic. The UDP traf-

†1 Department of Computer Science, Louisiana StateUniversity, USA

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

†3 Washington University in St. Louis, USA†4 Tokyo Denki University

fic is congestion insensitive in the sense thatUDP sources do not reduce their load in re-sponse to congestion 3). Despite the fact that anumber of schemes have been proposed for con-gestion control, the search for new schemes con-tinues 2),4)∼25). A survey of various congestioncontrol algorithms proposed for use in routerscan be found in Refs. 26) and 27).

The research in this area has been going onfor at least two decades, for the following rea-sons: first, there are requirements for conges-tion control schemes that make it difficult to geta satisfactory solution; second, there are severalnetwork policies that affect the design of a con-gestion scheme. Thus, a scheme developed forone network, traffic pattern, or service require-ments may not work on another network, trafficpattern, or service requirements.

The proposed solutions expand over a widespectrum of improvements. At one end of thisspectrum are simpler, more incremental andmore easily employable changes to the currentTCP. Examples of such proposed solutions areRED 4) and ECN 2). At the other end of thespectrum, there are solutions with more pow-erful changes that result in new transport pro-tocols with higher performance but with lesschance to be deployed in a large scale on theInternet at least in the immediate future. Anexample of such solution is XCP 19). Otherproposals, such as REM 17), Proportional In-tegral Controller 18), HighSpeed TCP 28), andQuick Start TCP 29) reside along the simplicity-deployability spectrum. The choice among all

42

Vol. 3 Congestion Control Using Multilevel Explicit Congestion Notification 43

these solutions depends on the tradeoff betweenperformance and practical use that will betterfit the Internet. Because of the size and mul-tidimensional complexity of the Internet, therobustness in heterogeneity is valued over effi-ciency of performance, which leads to favor evo-lution compared to revolution of changes. Forthis reason, in our solution we propose minimalchanges to ECN and try to derive the maximumperformance improvements out of them.

Recognizing the need for a more direct feed-back of congestion information, the InternetEngineering Task Force (IETF) has come upwith Explicit Congestion Notification (ECN)method for IP routers 2),30). A bit in the IPheader is set when the routers are congested.ECN is much more powerful than the sim-ple packet drop indication used by existingrouters and is more suitable for high distance-bandwidth networks. In this paper, we ex-tend and justify with theoretical and simula-tion results the enhancements to ECN basedon multilevel ECN (MECN), which we pre-sented in Refs. 31) and 34). Our MultilevelECN (MECN) conveys more accurate feedbackinformation about the network congestion sta-tus than the current ECN. We have designeda TCP source reaction that takes advantageof the extra information provided about con-gestion. Therefore, MECN responds betterto congestion by allowing the system to reachthe stability point faster, which results in bet-ter network performance as shown in our re-sults in this paper. Another proposal to usetwo bits for signaling congestion is presentedin Ref. 25), but their scheme is different fromour MECN. The scheme presented in Ref. 25)measures the congestion by measuring the traf-fic load, while MECN uses the queue lengthfor the same purpose. We would like to stressthat, so far, all congestion control schemes usedfor TCP/IP are based on measurement of thequeue. Therefore, our approach would requireminimal change on routers.

The remaining of the paper is organized asfollows. In Section 2, we present the MECNscheme. In Section 3, we derive the equationsfor Delay Margin (DM) and Sensitivity usingthe linearized fluid flow model. In Section 4,we verify the results of Section 3 using ns2 sim-ulations. In Section 5, we discuss the parametersetting and implementation issues. The conclu-sions of the study are given in Section 6.

2. Multilevel Explicit Congestion No-tification (MECN)

2.1 Marking Bits at the RouterThe current proposal for ECN uses two bits

in the IP header (bits 6 and 7 in the TOS octetin IPv4, or the traffic class octet in IPv6) toindicate congestion. The first bit is called ECT(ECN-Capable Transport) bit. This bit is set to1 in the packet by the traffic source if the sourceand receiver are ECN capable. The second bitis called the CE (Congestion Experienced) bit.If the ECT bit is set in a packet, the routercan set the CE bit in order to indicate conges-tion. The two bits specified for the purpose ofECN can be used more efficiently to indicatecongestion, since using two bits we can indi-cate four different levels. If non ECN-capablepackets are identified by the bit combination of’’00’’, we have three other combinations to in-dicate three levels of congestion. In our schemethe bit combination ’’01’’ - indicates no con-gestion, ’’10’’ - indicates incipient congestionand ’’11’’ - indicates moderate congestion.

Packet drop occurs only if there is severe con-gestion in the router and when the buffer over-flows. So, with packet-drop we have four differ-ent levels of congestion indication and appro-priate action could be taken by the source TCPdepending on the level of congestion. The fourlevels of congestion are summarized in Table 1.The marking of CE, ECT bits is done usinga multilevel RED scheme. The RED schemehas been modified to include another thresh-old called the midth, in addition to the minth

and maxth. If the size of the average queueis between minth and midth, there is incipientcongestion and the CE, ECT bits are markedas ’’10’’ with probability p1. If the aver-age queue is between midth and maxth, thereis moderate congestion and the CE, ECT bitsare marked as ’’11’’ with probability p2. Ifthe average queue is above the maxth all pack-ets are dropped. The packet dropping policy ofRED is shown in Fig. 1. The modified packetmarking/dropping policy of MECN is shown in

Table 1 Router response to congestion (probabilisticmarking of CE and ECT bits and packetdropping).

Congestion State CE bit ECT bitNo Congestion 0 1

Incipient Congestion 1 0Moderate Congestion 1 1

Severe Congestion Packet Drop

44 IPSJ Digital Courier Feb. 2007

Fig. 1 Probabilities of marking packets in RED.

Fig. 2 Probabilities of marking packets in MECN.

Fig. 2.We would like to stress that the major advan-

tage of MECN as compared to other congestionmanagement schemes is that it conveys moreaccurate feedback information about the net-work congestion status than the current ECN.We have designed, as shown in Section 2.3, aTCP source reaction that takes advantage ofthe extra information provided about conges-tion. This is the reason why MECN respondsbetter to congestion by allowing the system toreach the stability point faster, which resultsin better network performance as shown in oursimulation results.

2.2 Feedback from Receiver to SenderThe receiver reflects the bit marking in the IP

header, to the TCP ACK. Since we have threelevels of marking instead of two-level markingin the traditional ECN, we make use of threecombination of the 2 bits 8, 9 (CWR, ECE)in the reserved field of the TCP header, whichare specified for ECN. In ECN, the bit com-bination ’’00’’ - indicates no congestion and’’01’’ - indicates congestion. And in piggy-backed acknowledgments, ’’10’’ and ’’11’’ -indicated noncongestion and congestion respec-tively, with the receiver source indicating thatthe congestion window has been reduced.

In our scheme, if the source has to indicatethat the congestion window has been reduced,

Table 2 End Host reflecting congestion information(Marking of CWR and ECE bits).

Congestion State CWR bit ECE bitCongestion Window Reduced 0 0

No Congestion 0 1Incipient Congestion 1 0Moderate Congestion 1 1

then the congestion information has to wait forthe next packet. In this case, the congestioninformation is ignored. But, this will not causeany major problems to the scheme, because ifthe congestion is persistent then a lot of pack-ets are going to get marked and the receivedsource will eventually get the congestion infor-mation. So in the new scheme, ’’00’’ - willindicate congestion window reduced, ’’01’’ -will indicate no congestion, ’’10’’ - will in-dicate mild congestion and ’’11’’ - will in-dicate heavy congestion. The packet drop isrecognized using traditional ways, by timeoutsor duplicate ACKs. The marking in the ACKsCWR, ECE bits is shown in Table 2.

2.3 Response of TCP SourceWe believe that the marking of ECN should

not be treated the same way as a packet drop,since ECN indicates just the start of congestion,and the buffers still have space. But, there isnot actual congestion and the buffers still havespace. And now with multiple levels of conges-tion feedback, the TCP’s response needs to berefined.

We have implemented the following scheme.When there is a packet-drop the ’’cwnd’’ isreduced by β3 = 50%. This is done for two rea-sons: first, a packet-drop means severe conges-tion and buffer overflow and some severe actionsneed to be taken; second, to maintain backwardcompatibility with routers which do not imple-ment ECN.

For other levels of congestion, such a dras-tic step as reducing the ’’cwnd’’ to half isnot necessary and might make the flow lessvigorous. When there is no congestion, the’’cwnd’’ is allowed to grow additively as usual.When the marking is ’’10’’ (incipient conges-tion), ’’cwnd’’ is decreased by β1%. Whenthe marking is ’’11’’ (moderate congestion)the ’’cwnd’’ is decreased multiplicatively notby a factor of 50% (as for a packet drop), butby a factor β2% less than 50% but more thanβ1%. Table 3 shows the TCP source responsesand the value of βs we have implemented.

Another method could be to decrease addi-tively the window, when the marking is 10 (in-


Table 3 TCP source response.

Congestion State CWND ChangeNo Congestion Increase ’cwnd’ additively

Incipient Congestion Decrease multiplicatively by β1 = 20%Moderate Congestion Decrease multiplicatively by β2 = 40%

Severe Congestion Decrease multiplicatively by β3 = 50%

cipient congestion), instead of maintaining thewindow. This again will be analyzed in futurestudy.

If the average queue length is less than midth,then the modified-TCP congestion windowscorresponding to the marks ’’10’’ keep in-creasing by one every round-trip time in conges-tion avoidance mode, thus linearly increasingthe sending rates of these flows. Consequently,the average queue length will keep increasingunless some marks ’’11’’ are received by thesources, which correspond to operating in theregion where the average queue length is largerthan midth. We can thus conclude that thesteady-state average queue length is larger thanmidth.

3. Mathematical Modeling of ECNand MECN Schemes

3.1 ECN Mathematical ModelWe first give a very brief introduction to

an already performed linearization of the ECNscheme. For detailed derivation refer toRef. 32). The following ignores the TCP slowstart and time out mechanisms, thus provid-ing a model and analysis during the congestionavoidance mode only.

The open loop transfer function of the linearmodel of TCP/RED dynamics in the case ofN flows traversing through a single router 32) isthen given by:

G0(s) =e−R0s(

sK + 1

)(R0s + 1)

· K0

R20C

2N s + 1,

(1)where N = Number of flows, R0 = Steadystate Round Trip Time (RTT) and C = Linkcapacity of the router in packets/sec with

K0 = LRED0

(R0C)3

(2N)2, (2)

and K defined by K = −C ln(1 − α), whereα is RED’s averaging weight and LRED0 =Pmax/(maxth −minth) is the slope of the prob-ability of packet mark function shown in Fig. 1.The maxth and minth are the maximum andminimum thresholds in packets which are set

at the router.3.2 MECN Mathematical ModelIn the following, we do the linearization of

the new system following the same method ofRef. 32) for ECN. In fact, we derive the trans-fer functions when the average queue length isbetween midth and maxth.

We ignore the TCP slow start and time outmechanisms, thus providing a model and analy-sis during the congestion avoidance mode only.

The dynamics of the new TCP in our schemeare derived as follows:

W (t) =1

R(t)

−W (t)β1

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

Prob1(t−R(t))

−W (t)β2

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

Prob2(t−R(t))

(3)

q(t) =

N(t)R(t) W (t) − C

if q(t) > 0

max{

0, N(t)R(t) W (t) − C

}if q(t) = 0

(4)where Prob1 is the probability of receiving amark ’’01’’ and Prob2 is the probability ofreceiving a mark ’’11’’, thus Prob2 = p2 andProb1 = p1(1 − p2).

Using similar techniques as in Ref. 32) a lin-ear model of Eq. (3) and Eq. (4) can be derived.

We first assume that the number of TCPflows and the outgoing link capacity are con-stant. The operating point (W0, q0, R0, p10 , p20)defined by W (t) = 0 and q(t) = 0 satisfies

W 20

(p10

β1(1 − p20) +

p20

β2

)= 1 (5)

p10 = (q0 − minth)LRED1 (6)p20 = (q0 − midth)LRED2 (7)

W0 =R0C

N(8)

R0 =q0

C+ Tp (9)

with LRED1 = Pmax/(maxth−minth), LRED2 =


Pmax/(maxth − midth) as shown in Fig. 2.Next, the time-varying nature of the RTT de-

lay in the terms “t−R(t)” is ignored and theseterms are approximated by “t−R0”. However,the queue length still depends on the RTT inthe dynamic Eq. (4).

Let’s definef(W, WR, q, qR, p1R

, p2R)

=1

qC + Tp

− WWRqR

C + Tp

[p1R

β1(1 − p2R

) +p2R

β2

](10)

g(W, q) =N

qR

C + TpW − C (11)

where WR(t) = W (t − R0), qR(t) = q(t − R0),p1R

(t) = p1(t − R0) and p2R(t) = p2(t − R0).

By evaluating partials of f and g at the op-erating point and using similar techniques as inRef. 32), we obtain the linearized transfer func-tion and neglecting some high-frequency dy-namics, the linearized dynamics of TCP-MECNresults in the open-loop transfer function

G(s) =1(

R20C

2N s + 1)

(R0s + 1)

· KMECN · e−R0s

sK + 1

(12)

with

KMECN =R3

0C3

2N2

·[1 − p20

β1LRED1 +

(1β2

− p10

β1

)LRED2

],

(13)where LRED1 = Pmax/(maxth − minth),LRED2 = Pmax/(maxth − midth) as shown inFig. 2.

The p10 and p20 are solutions of Eq. (5) with

p10 =Pmax

maxth − minth(q0 − minth) (14)

p20 =Pmax

maxth − midth(q0 − midth). (15)

Similarly to Ref. 32), we assume that the low-pass filter pole K is less than the corner fre-quencies of the new TCP, and that it dominatesthe closed-loop system behavior. The unity-gain crossover frequency ωg (i.e. |G(jωg)| = 1)thus satisfies:

ωg � min{

2N

R20C

,1

R0

}. (16)

Then, at low frequency we have

G0(s) ≈ e−R0s K0sK + 1

(17)

and

G(s) ≈ e−R0s KMECNsK + 1

. (18)

3.3 Sensitivity Transfer FunctionIdeally, we would like small oscillations

around the steady state queue. If the averagequeue is settling at a value greater than midth,the queue is not very likely to become empty,and thus we are more concerned with oscilla-tions in the queue length at steady state thatlead to jitter (delay variation).

We would like to design the MECN schemesuch that the magnitude of the sensitivitytransfer function is reduced compared to RED.Ideally, a transfer function with low sensitivitymeans better tracking of the steady state value.

In order to analyze the performance improve-ment, we compute the ratio between the sen-sitivity transfer functions of MECN and ECNfor the case where the queue settles above themidth:

S(s)S0(s)

=(1 + G(s))−1

(1 + G0(s))−1(19)

≈ 1 + K0

1 + KMECN·

1 + sK(1+K0)

1 + sK(1+KMECN)

(20)

where we neglected the dynamics of the time-delays of Eq. (17) and Eq. (18).

If KMECN > K0, we have a performanceimprovement for ω ∈ [0, K(1 + K0)] with asensitivity function reduced such that

∣∣∣ SS0

∣∣∣ ≈1+K0

1+KMECNwith 1+K0

1+KMECN< 1.

3.4 Stability AnalysisThe delay margin DM is also a parameter of

major interest. The DM is a measure of thestability of the system (low oscillations). Thephase margins of the systems without delay are(see for example Ref. 33))

PM(ωg) ≈ π − tan−1(ωg

K

)(21)

where ωg is such that |G(jωg)| = 1, i.e. ωg0 =K

√K2

0 − 1 for the traditional TCP-ECN, andωg = K

√K2

MECN − 1 for TCP-MECN.The DM, which represents how much the

RTT can be increased without violating sta-bility of the feedback system (see for exampleRef. 33)), is then


DM(ωg) ≈ PM(ωg)ωg

− R0 (22)

≈ π − tan−1(ωg

K

)ωg

− R0. (23)

If KMECN > K0, we have ωg > ωg0 , and sinceDM(ωg) is a decreasing function of ωg, we havea decrease in the DM by using MECN.

The reasons for studying stability in this re-gion are: first, queue oscillations around herecan lead to packets being dropped if the queuecrosses the maxth; and second, if the queueoscillations reach low values (including zero),which mean that very few or no packet are beingserved, then the throughput (link utilization)will be low. But, this is the price we pay forhaving an improved performance while still us-ing such a simple feedback control mechanism.Increasing KMECN further will mean more os-cillations that will lead to packets drop.

3.5 Tradeoff of Performance Improve-ment and Stability Margins

In Fig. 3, we plot the DM of Eq. (23) andthe performance improvement defined by (1 +KMECN)/(1+K0) > 1 as a function of KMECN.We clearly see the following tradeoff: KMECN

should be chosen as large as possible for goodperformance improvement, but it should be lessthan some value to ensure a sufficient DM. Forexample, in Fig. 3, we see that for the case ofK0 = 0.1, R0 = 0.2 s and K = 0.1, we can havea DM of 1 s while having a performance im-provement (1 + KMECN)/(1 + K0) ≈ 13.3 withKMECN = 13.64. By performance improve-ment, we mean better tracking of the steadystate queue, resulting in less jitter.

3.6 Stability and Performance Anal-ysis when Steady State QueueLength Settles Between minth andmidth

On the other hand, if the average queue set-tles at a value less than midth, it is more im-portant to have a good throughput and thusto have good stability margins to prevent thequeue from becoming empty too often as de-scribed in Section 3.4.

In this region, we have LRED2 = 0. Thus, theopen-loop transfer function is

G(s) ≈ e−R0s K1sK + 1

, (24)

with

K1 =R3

0C3

2β1N2LRED1 . (25)

Fig. 3 Tradeoff between performance improvementand DM.

Since β1 > 2, we have K1 < K0, and from theanalysis carried out in Section 3.4 we have anincrease in the DM as desired.

4. NS2 Simulations

In this section, we use ns2 simulations toprove the results obtained in the previous sec-tion and also show how to tune the MECN, sothat tradeoffs among various performance met-rics can be achieved from the algorithm. We arealso interested in showing that MECN performsbetter than ECN, not only in throughput butalso in average delay and jitter under variousscenarios and traffic mixtures. Because MECNintroduces minimal changes to ECN, we com-pare MECN to ECN and not to solutions withmore powerful changes that result in new trans-port protocols such as XCP 19),25).

4.1 Simulation ConfigurationsWe used three different simulations config-

urations to capture a wide range of scenariosand to prove the robustness of the MECN al-gorithm. The first one is a simple FTP config-uration shown in Fig. 4. A number of sourcesS1, S2, S3, . . . , Sn are connected to a router R1

through 10 Mbps, 2 ms delay links. Router R1

is connected to R2 through a 1.5Mbps, 40 msdelay link and a number of destinations D1,D2, D3, . . . , Dn are connected to the routerR2 via 10Mbps, 4ms delay links. The linkspeeds are chosen so that congestion will hap-pen only between routers R1 and R2 where ourscheme is tested. An FTP application runs oneach source. Reno TCP is used as the trans-port agent (the modifications were made to theReno TCP). The packet size is 1,000 bytes andthe acknowledgment size is 40 bytes. The num-ber of sources is varied to alter the congestion


level. The weight used for queue averaging isα = 0.002.

The next simulation configuration is used tomodel a traffic pattern closer to that of today’sInternet. The configuration is shown in Fig. 5.The model consists of:( 1 ) 25 exponential traffic sources running

over UDP, which creates a self-similartraffic;

( 2 ) 30 web clients and a server, to model theweb traffic;

( 3 ) 5 FTP sources to model the bulk datatransfer.

The third simulation configuration is usedto study the effect of the algorithm on multi-ple congested gateways. The configuration isshown in Fig. 6. It is a typical parking lot con-figuration. Different flows in the network, travelfor different lengths. There are N + 1 routersin the network, R0 to RN . At routers R0 toRN−1 flows enter the network and at routerRN all flows leave the network. At each routerfive flows enter the network. In our experiment,we used a configuration with four routers. Thethroughput of the system was found by addingup the throughput of the individual flows. We

Fig. 4 Network configuration for ns2 simulations.

Fig. 5 Simulation configuration for Web traffic.

Fig. 6 Simulation configuration for multiplecongested gateways.

intend to show that a system which uses MECNon all routers has a better overall throughputthan a system which uses ECN.

4.2 Simulations ResultsIn this section, we use FTP configuration as

shown in Fig. 4. We first use low threshold lev-els. For analyzing ECN, we set minth as 1 andmaxth as 4 packets. For analyzing MECN, weset minth as 1, midth as 2 and maxth as 4 pack-ets. Figure 7 shows the instantaneous and av-erage queue of ECN where the oscillations inthe queue are very high and the queue goesto zero often. This results in a substantial re-duction in the throughput of the router. How-ever, the MECN scheme shown in Fig. 8 givesa higher throughput because the oscillationsare reduced. This leads to a higher through-put (link utilization). The control inferenceof this observation is the fact that the instan-taneous queue better tracks the steady-statequeue with MECN compared to ECN, thus im-proving performance. Figure 9 compares the

Fig. 7 Queue size of ECN for lower delay, minth = 1and maxth = 4.

Fig. 8 Queue size of MECN for lower delay,minth = 1, midth = 2, and maxth = 4.


Fig. 9 Comparison of link efficiency for ECN andMECN.

Fig. 10 Queue size of ECN for higher delay.

link efficiency of ECN with MECN scheme forlow thresholds used in Fig. 7 and Fig. 8, respec-tively. From Fig. 7 and Fig. 8, we observe thatMECN should give a better link efficiency thanECN. This is clearly shown in Fig. 9, where wecompare the throughput of ECN and that ofMECN by varying minth. One important ob-servation from Fig. 9 is that MECN provides amuch higher throughput (up to 20 times) com-pared to ECN at the low delay ranges (smallminth).

In Fig. 10 and Fig. 11, we compare the per-formance of ECN and MECN respectively, overa broader range of thresholds. We set minth as30, midth as 60 and maxth as 90 packets. An in-crease in throughput beyond a certain maxth isnot possible. However, the MECN scheme out-weighs the ECN scheme, thus the oscillationsin the queue are reduced, and that is the rea-son why MECN reduces the jitter compared toECN, as shown later in Fig. 16.

From Fig. 12, Fig. 13 and Fig. 14, we see

Fig. 11 Queue size of MECN for higher delay.

Fig. 12 Effect of parameter tuning on MECN: lowKMECN and jitter is 15ms.

that we can improve the performance of MECNby a proper choice of KMECN. For the first case(Fig. 12), we have N = 40 and Pmax = 0.1. Inthe second case (Fig. 13), we have N = 40 andPmax = 0.2, thus we have increased KMECN byincreasing Pmax from 0.1 to 0.2, using Eq. (13).When we compare the two graphs, we see thatthe oscillations in the queue decrease drasti-cally in the second case and as a result, jitterdecreases from 30ms to 15 ms. The jitter cal-culated above is the average end-to-end jitterfrom source to destination for individual flows.Now, we can further extract better performanceby still increasing KMECN. In the third case(Fig. 14), we have N = 20 and Pmax = 0.2,thus we increase KMECN by decreasing N andthe jitter decreases to 7ms. The reduction ofjitter is a good result for real-time applicationsthat are sensitive to jitter.

As shown above, for any given traffic level Nwe can tune the MECN parameters using the


Fig. 13 Effect of parameter tuning on MECN: highKMECN and jitter is 15ms.

Fig. 14 Effect of parameter tuning on MECN: higherKMECN and jitter is 7ms.

results in Section 3 to obtain the needed trade-off among delay, throughput and jitter per-formance. As shown by Fig. 12, Fig. 13 andFig. 14, the jitter in MECN can be reduceddrastically compared to ECN.

Figure 15 shows a plot of throughput ver-sus average delay, which is a useful metric foranalyzing performance of network. Ideally, wewould like to have high throughput without in-troducing delay to the traffic. We can clearlysee the improvement in performance of MECNover ECN. It is a well known fact that through-put can be traded-off with average delay. Wewant higher throughput with lesser delay. Fromthe figure, we can see that MECN provides upto 112% more throughput than ENC for theminimal delay. On the other hand MECN givesthe same throughput as ECN with less than halfof ECN average delay. MECN∗ indicates finetuned MECN (larger KMECN) using Eq. (13).

Fig. 15 Comparison of link efficiency vs. averagedelay for ECN and MECN.

Fig. 16 Jitter vs. average delay for MECN and ECN.

In this case, for MECN∗ and MECN we use thesame parameters used in Fig. 12 and Fig. 14, re-spectively. As we can see, better performancecan be obtained by having a higher KMECN.

Figure 16 and Fig. 17 are generated by sim-ulations using the simple FTP simulation con-figuration. Figure 16 shows that MECN con-sistently has up to 146% less jitter than ECN,which leads to a much smoother traffic pattern.Figure 17 shows the corresponding link efficien-cies of the two systems for the same simulationfor a given average delay. These two graphsprove that MECN gives up to 7.6 times higherthroughput performance at low delays, and alsobetter jitter performance (the measured jitterat the router). A lower jitter is advantageousnot only for these sources but also for the wholenetwork, since other audio/video applicationsrunning on UDP will also benefit from usingMECN at the router.

4.3 Results for Internet Traffic ModelThe Internet traffic model described in Sec-

tion 4.1 and shown in Fig. 5, is used to test the


Fig. 17 Link efficiency vs. average delay for MECNand ECN using FTP traffic model.

Fig. 18 Link efficiency vs. average delay for ECN andMECN using Web traffic model.

MECN algorithm under typical network traffic.In this model, we would like to simulate typi-cal high bandwidth Internet conditions, whichis shown to be characterized by self-similar traf-fic. We measure the “self-similarity” of ourmodel traffic by using the Hurst parameter.This parameter indicates the degree of trafficself-similarity. Usually Hurst parameter of webtraffic is between 0.75 and 0.85. For our mixedmodel, the Hurst parameter was measured us-ing variance-time plot 35) and was found to be0.807.

It is found that MECN performs better thanECN for many different RTTs, but only a sam-ple result is shown in Fig. 18, where MECNprovides up to 12 times more throughput thanECN for low delays. Similar results were ob-served for RTTs in the range 20–300ms. Also,the results get better with the increase of per-centage of TCP traffic in the network, sinceonly TCP is sensitive to the algorithm.

4.4 Multiple Congested GatewaysThe MECN was tested under various network

configurations. Figure 19 shows the plot of

Fig. 19 Throughput vs. Minth for multiplecongested gateways.

Fig. 20 Throughput vs. Minth for MECN fordifferent Pmax.

throughput versus Minth for ECN and MECN,using the multiple congested gateways config-uration defined in Section 4.1 and shown inFig. 6. The system throughput here is definedas the sum of throughput of the individual flows(the throughput of individual flow is the to-tal number of packets that the receiver receivedduring the simulation time). From the figure,we can see that by using MECN the overall per-formance of the network increases up to 147.2%,since the performance of each link in the systemis increased.

Even though the control theory derived inSection 3 does not exactly capture the dynam-ics of this configuration, the guidelines derivedin that section seems to work even in the caseof multiple congested links. This is because theguidelines where derived for a single link andas the efficiency of each link in the system isincreased the total network performance alsoincreases. Figure 20 shows the throughput ofMECN system for three different Pmax. An in-crease in Pmax leads to an increase in KMECN

(from Eq. (13)) and a corresponding increase


in the performance. The figure confirms thisresult. Let us call MECN1 the scheme withPmax = 0.33 (largest KMECN), MECN2 withPmax = 0.1 (medium KMECN) and MECN3with Pmax = 0.03 (smallest KMECN). FromFig. 20, we can see that MECN1 outperformsMECN2 and MECN3 in terms of throughputup to 147% and 3.25 times respectively, whileMECN2 provides up to 2.6 times throughputthan MECN3.

5. Discussion on Parameters and Im-plementation

The MECN parameters enable to obtain wideranges of tradeoffs among throughput, delay,jitter and RTT.

The minth determines how soon the packetmarking is commenced, and therefore influencesthe minimum delay. The maxth determines theamount of burst the link can tolerate. Thehigher the maximum threshold, higher the linkdelay and vice versa.

In setting the MECN parameters, the resultsof Section 3 are a good guidance. So, usingEq. (13) and varying its components, we wouldlike to select a larger KMECN such that we canget the needed performance improvement, cap-tured by Eq. (20), which enable us to keep smallthe queue oscillations. On the other hand, inthe low delay area, small queue oscillations leadto higher throughput because the queue lengthreaches not often zero. At the same time, smallqueue oscillations lead to lower jitter.

While improving the performance, followingthe conclusions of Section 3.4, we have to becareful not to make zero the DM in Eq. (23),which represents how much the RTT can beincreased without leading to oscillations.

The implementation of the MECN scheme isgoing to be similar to ECN since they follow thesimilar architecture, that means the congestionis measured by measuring the queue length.

6. Conclusions

In this paper, we have studied the perfor-mance of a MECN scheme. We propose mini-mal changes to ECN and try to derive the max-imum performance improvements out of them.Two bits are now used to indicate four levelsof congestion. The major advantage of MECNis that it conveys more accurate feedback in-formation about the network congestion statusthan the current ECN. We have designed aTCP source reaction that takes advantage of

the extra information provided about conges-tion. Therefore, MECN responds better to con-gestion by allowing the system to reach fasterthe stability point, which results in better net-work performance as shown in our simulationresults. We have explained the performance im-provement of MECN over ECN using classicalcontrol theory tools and these results have beenvalidated by ns2 simulations. For low thresh-olds (delay), MECN obtains up to twenty timesmore throughput than ECN. For higher thresh-olds (delay), the improvement is seen in the re-duction up to 146.6% of the jitter experiencedby the flows.

Acknowledgments This research workhas been partially supported by National Sci-ence Foundation Awards NSF-CNS-9980637and NSF-CNS-0413187.

References

1) Stevans, W.: TCP Slow Start, CongestionAvoidance, Fast Retransmit and Fast Recov-ery, RFC 2001 (1997).

2) Ramakrishnan, K. and Floyd, S.: A Proposalto Add Explicit Congestion Notification (ECN)to IP, RFC 2481 (1999).

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

4) Floyd, S. and Jacobson, V.: Random EarlyDetection Gateways for Congestion Avoidance,IEEE/ACM Trans. on Networking, Vol.1, Is-sue 4, pp.397–413 (Aug. 1993).

5) Clark, D.D. and Fang, W.: Explicit Allo-cation of Best-effort Packet Delivery Service,IEEE/ACM Trans.on Networking, Vol.6, No.4,pp.362–373 (Aug. 1998).

6) 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).

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

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

9) Floyd, S. and Fall, K.: Router Mechanisms toSupport End-to-End Congestion Control, LBLTechnical Report (Feb. 1997).

10) Mathis, M., Semke, J., Mahdavi, J. and Ott,T.: The Macroscopic Behaviors of the TCP


congestion Avoidance Algorithm, ComputerCommunications Review, Vol.27, No.3, pp.67–82 (July 1997).

11) Chiu, D. and Jain, R.: Analysis of theIncrease/Decrease Algorithms for CongestionAvoidance in Computer Networks, Journalof Computer Networks and ISDN Systems,Vol.17, No.1, pp.1–14 (July 1989).

12) Floyd, S. and Henderson, T.: The NewRenoModification to TCP’s Fast Recovery Algo-rithm, Internet RFC 2582, Experimental (Apr.1999).

13) Mathis, M., Mahdavi, J., Floyd, S. andRomanow, A.: TCP Selective AcknowledgmentOptions, IETF Internet RFC 2018 (Oct. 1996).

14) Ramakrishnan, K.K. and Jain, R.: A BinaryFeedback Scheme for Congestion Avoidance inComputer Networks, ACM Trans.on ComputerSystems, Vol.8, No.2, pp.158–181 (May 1990).

15) Jain, R., Kalyanaraman, S. and Viswanathan,R.: Rate Based Schemes: Mistakes to Avoid,AF-TM 940882 (Sep. 1994).

16) 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).

17) 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).

18) 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).

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

20) Wang, C., Li, B., Hou, T., Sohraby, K. andLin, Y.: LRED: A Robust Active Queue Man-agement Scheme Based on Packet Loss Ratio,Proc. IEEE INFOCOM-2004, Vol.1, pp.1–12(Mar. 2004).

21) Jin, C., Wei, D.X. and Low, S.H.: FAST TCP:Motivation, Architecture, Algorithms, Perfor-mance, Proc. IEEE INFOCOM-2004, pp.2490–2501 (Mar. 2004).

22) King, R., Riedi, R. and Baraniuk, R.: TCP-Africa: An Adaptive and Fair Rapid IncreaseRule for Scalable TCP, Proc.IEEE INFOCOM-2005, Vol.3, pp.1838–1848 (Mar. 2005).

23) Low, S., Andreq, L. and Wydrowski, B.: Un-derstanding XCP: Equilibrium and Fairness,Proc. IEEE INFOCOM-2005, Vol.2, pp.1025–1036 (Mar. 2005).

24) Wu, Q. and Rao, N.: A Class of Reliable UDP-

based Transport Protocols based on StochasticApproximation, Proc. IEEE INFOCOM-2005,Vol.2, pp.1013–1024 (Mar. 2005).

25) Xia, Y., Subramanian, L., Stoica, I. andKalyanaraman, S.: One More Bit is Enough,Proc.ACM SIGCOMM-2005, Philadelphia, PA(Aug. 2005).

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

27) 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).

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

29) 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).

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

31) Durresi, A., Sridharan, M., Liu, C., Goyal, M.and Jain, R.: Traffic Management Using Mul-tilevel Explicit Congestion Notification, Proc.5th World Multi-Conference on Systemics, Cy-bernetics and Informatics (SCI-2001 ), ABRover the Internet, Orlando, FL, pp.12–17 (July2001).

32) Hollot, C., Misra, V., Towsley, D. and Gong,W.B.: Analysis and Design of Controllers forAQM Routers Supporting TCP Flows, IEEETrans. on Automatic Control, Vol.47, No.6,pp.945–959 (June 2002).

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

34) 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, pp.106–116 (July 2002).

35) Leland, W., Taqqu, W., Willinger, W. andWilson, D.: On the Self-similar Nature of Eth-ernet Traffic, IEEE/ACM Trans. on Network-ing, Vol.2, pp.1–15 (Aug. 1994).

(Received May 15, 2006)(Accepted November 2, 2006)

(Released February 7, 2007)


Arjan Durresi received theB.S.E.E., 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 Supe-rior Specialization in Telecom-

munications from La Sapienza University inRome, Italy and Italian TelecommunicationsInstitute in 1991. He is currently an Assis-tant Professor in the Department of ComputerScience, Louisiana State University. His cur-rent research interests include network archi-tectures, heterogeneous wireless networks, se-curity, QoS routing protocols, traffic manage-ment, satellite networks, and bioinformatics.Dr. Durresi has authored more than 100 papersin refereed Journals and International Confer-ence proceedings. He is an area editor for theAd Hoc Networks Journal. He was ProgramCo-Chair of AINA-2006 and is Workshops Co-Chair of AINA-2007. Dr. Durresi has recivedmany Research Awards. 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 andYamagataUniversity in 1989 and 1997,respectively. Presently, he isa Professor at the Departmentof Information and Communica-

tion Engineering, Fukuoka Institute of Tech-nology (FIT). Dr. Barolli has published morethan 180 papers in refereed Journals and In-ternational Conference proceedings. He was anEditor of the IPSJ Journal and has served asan Guest Editor for many Special Issues of In-ternational Journals. Dr. Barolli has been a PCMember of many International Conferences. Hewas a PC Co-Chair of AINA-2003, PC Chair ofAINA-2004, PC Chair of ICPADS-2005, Gen-eral Co-Chair of AINA-2006 and WorkshopsChair of iiWAS-2006. He is Workshops Co-Chiar of AINA-2007. His research interests in-clude network traffic control, fuzzy control, ge-netic algorithms, ad-hoc networks, sensor net-works and P2P systems. He is a member ofSOFT, IPSJ, and IEEE.

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.

Makoto Takizawa receivedhis B.E., M.E. and Ph.D. de-grees from Tohoku University,Japan in 1973, 1975, 1984, re-spectively. From 1975 to 1986,he worked for Japan Informa-tion Processing Developing Cen-

ter (JIPDEC). He has been a Full professor ofthe Department of Computers and Systems En-gineering, Tokyo Denki University (TDU) since1986. He was Dean of the Graduate School ofScience and Engineering, Tokyo Denki Univer-sity from April of 2001 to March of 2005. Heis a Golden Core Member and a Board of Gov-ernors (BoG) of IEEE Computer Society. Heis a senior member of IEEE. He has been aPC member, PC Chair and General Chair ofmany International Conferences. He is Steer-ing Committee Chair of IEEE AINA Interna-tional Conference. He has published more than70 Journal papers and 250 International Con-ference papers. His research interest includesnetwork protocols, group communication, dis-tributed systems, fault-tolerant systems andP2P systems. He is a member of IEEE, ACM,and IPSJ.

congestion control using multilevel explicit congestion ...jain//papers/ftp/mecn07.pdf ·...

Documents