7/25/2019 744 Report

1/15

Evaluation of Queue Management Algorithms Course Project Report for15-744 Computer Networks

Ningning Hu (hnn@cs.cmu.edu)

Liu Ren (liuren@cs.cmu.edu)

Jichuan Chang (cjc@cs.cmu.edu)

Abstract

In this report !e e"aluate se"eral #ueue management algorithms !ith respect

to their a$ilities of maintaining high resource utili%ation identif&ing and restricting

disproportionate $and!idth usage and their deplo&ment comple'it&. e comparethe performance of R*+ ,L-* , and CH/0e $ased on simulation results

using R*+ and +rop 1ail as the e"aluation $aseline. 1he characteristics of different

algorithms are also discussed and compared.

1. Introduction

1he ro$ustness of toda&2s Internet depends hea"il& on the 1CP congestion control mechanism.

Ho!e"er as more and more -+P applications (e.g. pac3et audio4"ideo applications) are deplo&edon the Internet people cannot rel& on end users to incorporate proper congestion control. Router

mechanisms must $e pro"ided to protect responsi"e flo!s from non5responsi"e ones and pre"ent6Internet meltdo!n7. e"eral methods ha"e $een proposed for the management of shared

resources on the Internet acti"e #ueue management is one of the major approaches.

1raffic on the Internet tends to fluctuate and to $e greed&. Ideall& a router #ueue management

algorithm should allo! temporar& $urst& traffic and penali%e flo!s that persistentl& o"eruse

$and!idth. 8lso the algorithm should pre"ent high dela& $& restricting the #ueue length a"oid

underutili%ation $& allo!ing temporar& #ueueing and allocate resource fairl& among different

t&pes of traffic 9:;. In practice most of the routers $eing deplo&ed use simplistic +rop 1ail

algorithm !hich is simple to implement !ith minimal computation o"erhead $ut pro"ides

unsatisfactor& performance.

1o attac3 this pro$lem man& #ueue management algorithms are proposed such as Random*arl& +rop (R*+) 9; tochastic air ,L-*

(,) 9>; and CH/0e (CH/ose and 0eep for responsi"e flo!s CH/ose and 0ill for

unresponsi"e flo!s) 9?;. ost of the algorithms claim that the& can pro"ide fair sharing among

different flo!s !ithout imposing too much deplo&ment comple'it&. ost of the proposals focus

on onl& one aspect of the pro$lem (!hether it is fairness deplo&ment comple'it& or

computational o"erhead) or fi' the imperfections of pre"ious algorithms and their simulationssetting are different from each other. 1hese all ma3e it difficult to e"aluate and to choose one to

use under certain traffic load.

1his project aims at a thorough e"aluation among these algorithms and illustrations of their

characteristics $& simulation. e compare the performance of R*+ ,L-* , and CH/0e

using R*+ and +rop 1ail as the e"aluation $aseline. or each of these algorithms three aspects

are discussedA (:) resource utili%ation (!hether the lin3 $and!idth is full& utili%ed) (B) fairness

among different traffic flo!s (!hether different flo!s get their fair share) and (

7/25/2019 744 Report

2/15

2. Queue Management Algorithms

2.1 RED (Random Early Drop)

R*+ 9

7/25/2019 744 Report

3/15

New flow?

Calculate avg & maxq

Non-adaptive?

N

Y

minthfreeze_time)Pm = Pm-d2;

Last_update = now;

Upon packet loss event:

if ((nowlast_updatte)>freeze_time)Pm = Pm+d1;

last_update = now;

2.4 SFB

,ased on ,L-* #tochastic $air %lue (,) is a no"el techni#ue for protecting 1CP flo!s

against non5responsi"e flo!s. , is a I/ #ueuing algorithm that identifies and rate5limits

non5responsi"e flo!s $ased on accounting mechanisms similar to those used !ith ,L-*. ,

maintains accounting $ins. 1he $ins are organi%ed in & le"els !ith N$ins in each le"el. In

addition , maintains & independent hash functions each associated !ith one le"el of theaccounting $ins. *ach hash function maps a flo! into one of the accounting $ins in that le"el. 1he

accounting $ins are used to 3eep trac3 of #ueue occupanc& statistics of pac3ets $elonging to a

particular $in. 8s a pac3et arri"es at the #ueue it is hashed into one of the N$ins in each of the&

le"els. If the num$er of pac3ets mapped to a $in goes a$o"e a certain threshold (i.e. the si%e of

the $in)the pac3et dropping pro$a$ilit&Pmfor that $in is increased. If the num$er of pac3ets inthat $in drops to %ero Pmis decreased. 1he o$ser"ation is that a non5responsi"e flo! #uic3l&

dri"esPmto : in all of the &$ins it is hashed into. Responsi"e flo!s ma& share one or t!o $ins

!ith non5responsi"e flo!s ho!e"er unless the num$er of non5responsi"e flo!s is e'tremel&

large compared to the num$er of $ins a responsi"e flo! is li3el& to $e hashed into at least one

$in that is not polluted !ith non5responsi"e flo!s and thus has a normal "alue. 1he decision to

mar3 a pac3et is $ased onPminthe minimumPm"alue of all $ins to !hich the flo! is mapped into.

IfPminis : the pac3et is identified as $elonging to a non5responsi"e flo! and is then rate5limited.

B[l][n]: L N array of bins(L levels, N bins per level)

Enque()

7/25/2019 744 Report

4/15

Calulate !as! funtion "alues !#$!1$%$!L-1; &pdate 'ins at ea! le"el or i =# to L-1

f(*i,!i,.Len> 'in_size) *i,!i,Pm += delta; /rop pa0et; lse if (*i,!i,.len ==#) *i,!i,Pm - = delta; Pmin = min(*#,!#,Pm%*L,!L,Pm);

f(Pmin==1)

atelimit();lse

3ar04drop wit! pro'a'ilit5 Pmin;

1he t&pical parameters of , algorithm are '&en %in"#i!e d1 d2 ree!e"time N &

%oxtime (interval. %in"#i!e is the $uffer space of each $in. 'len is the actual #ueue length of

each $in. or each $in d1 d2andree!e"timeha"e the same meaning as that in ,L-*. ,esides

N and& are related to the si%e of the accounting $ins for the $ins are organi%ed in & le"els !ithN

$ins in each le"el.%oxtimeis used $& penalt& $o' of , as a time inter"al used to control ho!

much $and!idth those non5responsi"e flo!s could ta3e from $ottlenec3 lin3s. (interval is the

time inter"al used to change hashing functions in our implementation for the dou$le $uffered

mo"ing hashing. ,ased on those parameters the $asic , #ueue management algorithm is

sho!n in the a$o"e ta$le.

2.5 CHOK

8s a #ueue management algorithm CH/0e 9?; differentiall& penali%es non5responsi"e and

unfriendl& flo!s using #ueue $uffer occupanc& information of each flo!. CH/0e calculates the

a"erage occupanc& of the I/ $uffer using an e'ponential mo"ing a"erage just as R*+ does. It

also mar3s t!o thresholds on the $uffer a minimum threshold minthand a ma'imum threshold

maxth. If the a"erage #ueue si%e is less than minth e"er& arri"ing pac3et is #ueued into the I/

$uffer. If the aggregated arri"al rate is smaller than the output lin3 capacit& the a"erage #ueuesi%e should not $uild up to minth"er& often and pac3ets are not dropped fre#uentl&. If the a"erage

#ueue si%e is greater than maxth e"er& arri"ing pac3et is dropped. 1his mo"es the #ueue

occupanc& $ac3 to $elo! maxth. hen the a"erage #ueue si%e is $igger than minth each arri"ing

pac3et is compared !ith a randoml& selected pac3et called drop candidate packet from the I/

$uffer. If the& ha"e the same flo! I+ the& are $oth dropped. /ther!ise the randoml& chosenpac3et is 3ept in the $uffer (in the same position as $efore) and the arri"ing pac3et is dropped

!ith a pro$a$ilit& that depends on the a"erage #ueue si%e. 1he drop pro$a$ilit& is computed

e'actl& as in R*+. In particular this means that pac3ets are dropped !ith pro$a$ilit& : if the&

arri"e !hen the a"erage #ueue si%e e'ceeds maxth. 8 flo! chart of the algorithm is gi"en in

igure B. In order to $ring the #ueue occupanc& $ac3 to $elo! maxthas fast as possi$le !e still

compare and drop pac3ets from the #ueue !hen the #ueue si%e is a$o"e the maxth. CH/0e has

three "ariantsA

8. Ba!"# CHOK (CHOK)$It $eha"es e'actl& as descri$ed in the a$o"e that is choose one

pac3et each time to compare !ith the incoming pac3et.

,. %&l'"drop CHOK (%CHOK)$In 5CH/0e m pac3ets are chosen from the $uffer to

compare !ith the incoming pac3et and drop the pac3ets that ha"e the same flo! I+ as the

incoming pac3et. *as& to understand that choosing more than one candidate pac3et impro"esCH/0e2s performance. 1his is especiall& true !hen there are multiple non5responsi"e flo!sEindeed as the num$er of non5responsi"e flo!s increases it is necessar& to choose more drop

candidate pac3ets. ,asic CH/0e is a special case of 5CH/0e !ith mG:.

C. dap'"* CHOK (CHOK)$ 8 more sophisticated !a& to do 5CH/0e is to let

algorithm automaticall& choose the proper num$er of pac3ets chosen from $uffer. In 85

CH/0e it is to partition the inter"al $et!een minthand maxth into kregions)1* )2* +* )k.

hen the a"erage $uffer occupanc& is in)i m is automaticall& set as Bi ,i 1* 2* +* k..

=

7/25/2019 744 Report

5/15

#"ag minth

8dmit ne! pac3et

end

+ra! a pac3et randoml&

from the #ueue

,oth pac3et fromhe same #ueue

#"ag ma'th+rop $oth pac3ets

end

endend

8dmit pac3et !ith

pro$a$ilit& p

+rop the ne! pac3et

)igure B. )lo! chart for ,asic CH/0e

3. Simulation and Comparison

In this section !e !ill compare the performances of R*+ ,L-* , and CH/0e. e use

R*+ and +rop 1ail as the e"aluation $aseline. /ur simulation is $ased on ns5B 9;. ,oth R*+ and

R*+ ha"e implementation for ns5B. ,L-* and , are originall& implemented in a pre"ious"ersion of ns ns5:.: and are re5implemented in ns5B. ,ased on the CH/0e paper 9?; !e

implemented CH/0e in ns5B. In our simulation *CN support is disa$led and 6mar3ing a

pac3et7 means 6dropping a pac3et7.

3.1 S"m&la'"on S''"n+!

8s different algorithms ha"e different preferences or assumptions for the net!or3 configuration

and traffic pattern one of the challenges in designing our simulation is to select a t&pical set ofnet!or3 topolog& and parameters (lin3 $and!idth R11 and gate!a& $uffer si%e) as !ell as load

parameters (num$ers of 1CP and -+P flo! pac3et si%e 1CP !indo! si%e traffic patterns) as the

$asis for e"aluation. Currentl& !e ha"en2t found s&stematic !a& or guidance information to

design the simulation. o !e ma3e the decision $& reading all related papers and e'tracting and

com$ining the 3e& characteristics from their simulations.

J J

:K@$ps >ms :K@$ps >ms

:@$ps =Kms

L

L

L

L

1CP src4dst

-+P src4dst

igure K pac3ets (the pac3ets si%e for $oth 1CP and -+P are :KKK

$&tes). or R*+ !e also need to choose "alues for minth and maxth !hich are t&picall& set as

BKM and KM #ueue $uffer si%e. In the follo!ing !e set them as >K and :KK pac3ets.

>

7/25/2019 744 Report

6/15

3.2 %'r"#!

/hroughput and queue si!e are the t!o major metrics in our simulations. 1he throughput of each

flo! is used to illustrate the fairness among different flo!s and the total throughput can $e

compared !ith the $ottlenec3 $and!idth as an indicator of resource utili%ation. ueue si%e is a

direct indicator of router resource utili%ation. 1he a"erage #ueue si%e of each flo! illustrates the

fairness of router resource allocation !hich also sho!s the different characteristics of different

algorithms. e calculate the a"erage #ueue si%e using e'ponentiall& !eighted a"erage (*8)

and the aging !eight is set to K.KKB.

3.3 l+or"',m -aram'r!

Ho! to configure different algorithms for the simulation is also an issue. irst !e !ant to sho!

the $est performance of each algorithm under the same net!or3 topolog& and traffic load. or the

$est performance !e need to fine5tune these algorithms for the fi'ed setting (as descri$ed a$o"e)

to achie"e the fairest sharing !ith a high utili%ation "alue. 1he result !ill $e presented in ection

;. urther more since%oxtime indirectl& determines the total $and!idth that

those non5responsi"e flo!s could ta3e in the $ottlenec3 lin3 it is fine5tuned according to

different policies to treat those non5responsi"e flo!s. o in , ideal parameters for one casemight not necessaril& good for other cases.

3.3.4 CHOKe

*'cept the parameters from R*+ (minth* maxth etc) our implementation maintains three

parameters specific for CH/0eA

adapti"e_A control !hether or not 85CH/0e should $e applied set adapti"e_ = 1

!ill ena$le 85CH/0eE

D

7/25/2019 744 Report

7/15

and_num_6effecti"e !hen adapti"e_is not set !hen and_num_ = 1 it is $asic

CH/0e other!ise it is 5CH/0e and and_num_ is the num$er of pac3ets to $e

selected from the #ueueE

inter"al_num_6effecti"e !hen adapti"e_is set and this parameters determines the

num$er of inter"als to $e derided

ith our e'perience on running CH/0e 85CH/0e has the $est performance. o in the

follo!ing simulation !e choose adapti"e_G : and inter"al_num_G >.

3.4 Compar"!on

igure = and igure > sho! the major result of the simulation. 1he total throughput "alues of all

1CP and -+P flo!s are not sho!n here. or all the simulations the total throughputs arereasona$l& high (a$out K5DM of a"aila$le $and!idth) indicating that all these algorithms pro"ide

high lin3 utili%ation.

igure =5: sho!s the -+P throughput and #ueue length under simulations using :K 1CP flo!s

: -+P flo! !hen -+P sending rate changes from K.:$ps to $ps :. 8ccording to this diagram

+rop 1ail is the !orst in terms of unfairness !hich pro"ides no protection for adapti"e flo!s and

&ields the highest -+P throughput. R*+ and ,L-* do not !or3 !ell under high -+P sending rate.

hen -+P sending rate is a$o"e the $ottle lin3 $and!idth -+P flo! #uic3l& dominates the

transmission on the $ottlenec3 lin3 and 1CP flo!s could onl& share the remaining $and!idth. /n

the other hand R*+ , and CH/0e properl& penali%e -+P flo! and 1CP could achie"e theirfair share.

/ne interesting point in igure =5: is the $eha"ior of CH/0e. -+P throughput decreases !ith

the increase of -+P rate from B$ps to $ps. 1his is $ecause !ith the increase of -+P rate the

total num$er of pac3ets selected to compare increases !hich !ill increase the dropping pro$a$ilit&

for -+P pac3ets and decrease -+P flo! throughput as a result.

igure =5B illustrates the si%e of #ueue $uffer occupied $& -+P flo!. It seems that $uffer usage

is a good indicator of lin3 $and!idth utili%ation. imilar to igure =5: +rop 1ail is the !orst in

fairness. 8lthough R*+ and ,L-* are similar in permissi"e to non5responsi"e flo!s ,L-* uses

much less $uffer. R*+ and , are also the fairest.

%

%&'

%&(

%&)

%&*

+

%&+ %&' %&( %&* + ' ( * U! "ate #M$ps%

U!&hpt

#M$ps%

DropTail

RED

FREDBLUE

SFB

CHOKe

igure =5:. -+P flo! throughput

%

(%

*%

+'%

+)%

%&+ %&' %&( %&* + ' ( * U! "ate #M$ps%

U!QueueSi'e

#pac(et%

Drop#ail

R!D

$R!D

,-.!

/$,

C012e

igure =5B. -+P flo! #ueue si%e

igure > illustrates the a"erage #ueue si%e for -+P and 1CP flo!s as !ell as the a"erage total

$uffer usage. 1he difference of algorithms is clearl& captured in the $uffer usage plots. e can see

for +rop 1ail R*+ and ,L-* most of the pac3ets in the #ueue are -+P flo! pac3ets !hile onl&

:+ue to the method for changing the -+P rate in ns5B the sample inter"als !e choose are not uniform $ut

the& !ill not affect our anal&sis

?

7/25/2019 744 Report

8/15

a small percentage $elongs to 1CP flo!s. R*+ , and CH/0e effecti"el& penali%e -+P flo!and allo! 1CP flo!s to achie"e a higher throughput.

It is also interesting to notice the difference among the total #ueue si%es. ince +rop 1ail onl&

drops pac3ets !hen the #ueue $uffer is full at most time its total #ueue si%e is the ma'imum #ueue

$uffer si%e. or R*+ although it $egins to pro"ide congestion notification !hen the #ueue si%e

reaches minth it onl& affects 1CP flo!s !hile -+P flo! !ill 3eep the same sending rate !hich

dri"es the total #ueue si%e to maxth#uic3l& after !hich all the incoming pac3ets !ill $e dropped

and the total #ueue si%e !ill $e 3ept at maxth. In CH/0e ho!e"er the random pac3et selectionmechanism effecti"el& penali%es -+P flo! after the a"erage #ueue si%e reaches minth. hat2s more

-+P dropping rate is proportional to its incoming rate !hich !ill effecti"el& 3eep the total #ueue

si%e around minth as illustrated in igure >f. R*+ ,L-* and , are not directl& affected $&

minth and maxthsettings so their total #ueue si%es ha"e no o$"iousl& relation !ith these t!o

parameters in igure >.

In some of the figures in igure > !here 1CP flo! #ueue si%e is "er& small -+P flo! #ueue

si%e is the same as that of the total #ueue si%e $ut the corresponding #ueue si%e for 1CP flo!s are

not %ero !hich seems to $e a contradiction. 1he reason is that !e dra! these figures using the

*8 "alue of the #ueue si%e. 8lthough !e calculate the #ueue si%e e"er& time !e get a ne!

pac3et onl& *8 "alue (!eight G K.KKB) is plottedB.It is *8 that eliminates the difference

$et!een -+P flo! #ueue si%e and total #ueue si%e !hen 1CP flo! #ueue si%e is "er& small.

(a) +rop 1ail ($) R*+ (c) R*+

(d) ,L-* (e) , (f) CH/0e.

igure >. ueue si%e in different algorithms (Notice that the total #ueue si%es of different algorithms are different)

). Algorithm Characteristics

4.1 FREDR*+ algorithm focuses on the management of per5flo! #ueue length. 1he parameter qlen is

compared !ith minqand maxq and used as a traffic classifier. ragile flo!s are those !hose qlen

G minq ro$ust flo!s are those !hose minqqlenmaxqE and non5responsi"e flo!s are those

!hose qlen !as once larger than maxq. 1he minqis set to B or = $ut can adapt to a"erage #ueue

length !hen there are onl& fe! ro$ust flo!s (for e'ample in a L8N en"ironment !ith small R11

and large $uffer si%e).

B1he figures of the real #ueue si%e has a lot of jitters and difficult to read.

7/25/2019 744 Report

9/15

R*+ is "er& ro$ust in identif&ing different 3ind of traffic and protecting adapti"e flo!s.igure >c sho!s the #ueue length of : -+P flo! and the sum of :K 1CP flo!s. 1he -+P #ueue

length !as effecti"el& limited !ithin :K pac3ets !hich is appro'imatel& the a"erage #ueue

length. 1he single -+P flo! is isolated and paneli%ed !ithout harming the adapti"e 1CP flo!s.

0

0.25

0.5

0.75

1

10 20 40 45 50 60 70

Bufer i!e "#$ a%&e'(

TC$)T*p'

UD$)'*p'

igure D. Impact of $uffer si%e to R*+ fairness

igure D sho!s the impact of $uffer si%e to R*+ algorithm (!ithout 6t!o5pac3et5mode7). It

is clear that R*+ !or3s !ell onl& !hen the $uffer si%e is larger (larger than => pac3ets in this

case) enough to hold minqpac3ets for each acti"e flo!. hen the a"erage #ueue length is larger

than maxth R*+ degrades into +rop 1ail and can2t preser"e fairness. 1his pro$lem is discussedin 9=; and can $e partl& sol"ed $& using 6man& flo! support.7

1he fairness of R*+ is also illustrated in 1a$le :. 1he shares of -+P flo!s and 1CP flo!s do

not change "er& much as the $ottlenec3 $and!idth increases from K.> $ps to $ps. 8fter the

$and!idth of $ac3$one lin3 is large enough the -+P flo! gets its full share and 1CP flo!s $egin

to compete !ith each other.

*ottlenec( *+ #Mp$s% ,.- 1 2 ) 1, 2,

#C34#hpt 56bp7 %&(' %&*% +&)+ 8&+( 9&:8 :&(+ +8&;(

.D34#hpt 56bp7 %&%) %&+9 %&'; %&)) +&*' +&*9 +&*)

#C3 /hare 5;. igure ? sho!s the a"erage and actual #ueue length of the $ottlenec3 lin3 in our

simulation $ased on the follo!ing settingsA = 1CP flo!s !ith 1CP !indo! si%e

7/25/2019 744 Report

10/15

flo!s. 1he other B4< $uffer space allo!s room for a $urst of pac3ets remo"ing $iases against$urst& sources.

igure ?. ,L-* #ueue length for 1CP flo!s igure . ,L-* #ueue length for 1CP and -+P flo!s

Ho!e"er things get !orse !hen non5responsi"e flo!s appear. igure sho! the actual and

a"erage #ueue length of the $ottlenec3 lin3 in our simulation !hen a =K$ps -+P flo! joins

those = 1CP flo!s. In this case the total throughput (1CP and -+P) achie"ed is K.= $ps

among !hich K.K:$ps $and!idth is ta3en $& = 1CP flo!s !hile the -+P flo!2s throughput is

as high as K.;. 8s one set of $ins is $eing used for #ueue management a

:K

7/25/2019 744 Report

11/15

second set of $ins using the ne't set of hash functions can $e !armed up. In this case an& time aflo! is classified as non5responsi"e it is hashed using the second set of hash functions and the

mar3ing pro$a$ilities of the corresponding $ins in the !armup set are updated. hen the hash

functions are s!itched the $ins !hich ha"e $een !armed up are then used. Conse#uentl& non5

responsi"e flo!s are rate5limited right from the $eginning. igure and :K sho! the t&pical

performance of , !ith 1CP and -+P flo!s. 1he t!o simulation settings are the same as that

in ,L-* e'cept the $uffer si%e of $ottlenec3 lin3 is set as small as :>K0,. igure sho!s the

1CP flo! #ueue length of the $ottlenec3 lin3 !hen there is no -+P flo!. In this case the = 1CPflo!s2 throughput is K.=$ps. hile igure :K sho!s the case !hen a =K$ps -+P flo! joins.

In this case the -+P flo!2s throughput is onl& K.KBD $ps !hile the = 1CP flo!s2 throughput

is still #uite large !hich consumes K.B>$ps $and!idth of the $ottlenec3 lin3. 1he -+P #ueue

length is 3ept "er& small (a$out =5>0,) all the time. o !e could see that due to effect of ,2s

dou$le $uffered mo"ing hash those non5responsi"e flo!s are effecti"el& detected and rate5

limited $& ,.

(a) Large%oxtime ($) mall%oxtimeigure ::. Impact of%oxtimeon a"erage #ueue si%es of 1CP and -+P flo!s

(a) -nfairness of -+P flo!s !hen rate5limited ($) airness of -+P flo!s !hen rate5limitedigure :B. 1hroughput of flo!s

(2) mpro*"n+ ', /a"rn!! o/ UD- /low!$

In , all the non5responsi"e flo!s are treated as a !hole. Ho! much $and!idth those non5

responsi"e flo!s could ta3e depends mainl& on the parameter%oxtime. 1he%oxtimeis the time

inter"al in !hich no pac3ets from non5responsi"e flo!s can enter the #ueue. hen a pac3et froma -+P flo! comes if it is detected as a pac3et from a non5responsi"e flo! , !ill compare the

current time !ith the most recent time !hen a pac3et from an& non5responsi"e flo!s en#ueued. If

the time inter"al of these t!o e"ents is greater than the %oxtime the pac3et !ill $e en#eued.

/ther!ise it !ill $e dropped. If it is en#ueued the current time is recorded for the ne't compare.,& this !a&%oxtimeindirectl& controls ho! much $and!idth those non5responsi"e flo!s could

ta3e.igure :: (a) and igure :: ($) illustrate the impact of%oxtime on the a"erage #ueue si%e of

1CP and -+P flo!s. In these simulations the parameter setting is the same as the simulations

illustrated $& igure and igure :K e'cept the "alue for %oxtime. 1he a"erage #ueue si%es of

1CP and -+P flo!s !ith a large %oxtime (K.>s) are illustrated in igure :: (a). ince large

::

7/25/2019 744 Report

12/15

%oxtimemeans that non5responsi"e flo!s can onl& achie"e a lo! throughput the a"erage #ueuelength of those -+P flo!s is "er& small in igure ::(a). In this case the -+P flo!2s throughput

is K.K:< $ps !hile the throughput of 1CP flo!s is as large as K.BD$ps. /n the contrar& if

the "alue of%oxtime is set small the a"erage #ueue length of those -+P flo!s is #uite large as

illustrated in igure ::($) !hen %oxtimeis e#ual to K.KB seconds. It is reasona$le for the small

"alue of %oxtimeleads to a high throughput for those Non5responsi"e flo!s. In this case the

throughput of -+P flo! is K.B?$ps !hile the throughput of those 1CP flo!s is K.DD$ps.ince

%oxtime is a static parameter !hich can onl& $e set manuall& and is hard to configureautomaticall& the suita$le "alue of%oxtimein one case might not appl& to other cases. 1his is the

main dra!$ac3 of ,.

*"en !orse this rate5limited scheme can2t guarantee fairness among -+P flo!s all the time.

igure :B(a) illustrates this case !here > -+P flo!s !ith sending rate =$ps and :K 1CP flo!s

compete the :$ps $ottlenec3 lin3 in our standard scenario. /ne -+P flo! (flo! id K) consumes

more $and!idth than other -+P flo!s (flo! id :5=) although the fairness among 1CP flo!s

(flo! id >5:=) is o$"ious. 1o enhance the fairness among -+P flo!s the method !e proposed is

to ma3e%oxtimea $it randomi%ed. igure :B($) sho!s the throughput of 1CP flo!s and -+P

flo!s after%oxtime is randomi%ed. 1he fairness among the -+P flo!s is impro"ed. Ho!e"er

this method onl& impro"es the fairness of none5responsi"e flo!s !hen the& are rate5limited to a

fi'ed amount of $and!idth across the $ottlenec3. ometimes it is reasona$le to rate5limit non5

responsi"e flo!s to a fair share of the lin32s capacit&. 8s suggested $& 9>; this could $e achei"ed$& estimating $oth the num$er of non5responsi"e flo!s and the total num$er of flo!s going

through the $ottlenec3 lin3.

4.4 CHOK

(1) Ba!"# CHOK #,ara#'r"!'"#!$

Here !e !ant to manifest the effect of CH/0e specific parameters. /ur simulation setting is the

same as that in section K

pac3ets minth >K maxthG :KK. igure :< and igure := illustrate the performance of 5CH/0e

and 85CH/0e !ith different parameters setting (and_num_ and inter"al_num_). rom

these t!o figures !e can see increased and_num_4inter"al_num_ !ill effecti"el&

increase the penali%ation for -+P flo!s. 1his effect is most distinct !hen their "alues are small

(for e'ample !hen and_num_changes from : to B inter"al_num_changes from : to >).

0

0.05

0.1

0.15

0.2

0.25

1 2 5 10 15

Candidate /um$er

U!0lo1&

hroughput

#M$ps%

0

0.1

0.2

0.+

0.4

0.5

0.6

0.7

2 1.6 1 0.,

U! rate #M$ps%

U!0lo1&hroughput

#M$ps%

num > + num > 9

num > +% num > +9

igure :

7/25/2019 744 Report

13/15

R*+ 3eeps the #ueue si%e $elo! maxthmost of the time -+P rate is so high that most of #ueue$uffer is occupied $& -+P flo! !hich ma3es 1CP flo!s throughput "er& lo! !hich is the result

of that R*+ does not distinguish different t&pes of flo!s. igure :> tells that CH/0e could

achie"e much $etter fairness than R*+.

%

'%

(%

)%*%

+%%

+'%

%+ %' %( %* + ' ( *U! rate #M $ps%

QueueSi'e#p

ac(et%

RED UD$ - o. /ueue i!e

RED TC$ - o. /ueue i!e

CHOKe UD$ - o. /ueue i!e

CHOKe TC$ - o. /ueue i!e

igure :>. 1CP4-+P #ueue si%e in R*+ and CH/0e

(3) E//#' o/ d"//rn' n&m0r C- and UD- /low!

CH/0e can adapt to the change of the num$er of 1CP and -+P flo!s. 1he simulation setting isthe same as a$o"e e'cept that !e change the num$er of 1CP ( m) and -+P (n) flo!s !ith (m* n)

G (: :) (:K :) and (:K >). rom igure :Da !e can see the more 1CP flo!s the more penalt&

-+P flo!(s) get. It is $ecause !ith the increase of num$er of 1CP flo!s it !ill $e less pro$a$lefor the selected pac3et to match !ith the incoming 1CP pac3et that is dropping of 1CP pac3ets

$& CH/0e decreases correspondingl& increase the throughput of 1CP flo!s. 1his result could

also $e confirmed $& the #ueue $uffer occupation anal&sis (igure :D$).

Increasing the num$er of -+P flo!s has similar effect as increasing the num$er of 1CP

flo!s. ith more -+P flo!s the percentage of -+P pac3ets in the incoming pac3ets !ill

increase !hich !ill decrease the pro$a$ilit& to drop 1CP pac3ets. 8nother result is that -+P

throughput decreases !ith increasing of -+P rate !hich has $een discussed in section

7/25/2019 744 Report

14/15

%

%+

%'%8

%(

%9

%)

%:

%*

%;

+

%+ %' %( %* + ' ( *U! rate #M$ps%

U!&hroughput#M$ps%

1TC$ 1UD$

10 TC$ 1UD$

10 TC$ 5 UD$

0

20

40

60

,0

100

120

0.1 0.2 0.4 0., 1 2 4 ,U! rate #M $ps%

U!Que

ueSi'e#pac(et%

1TC$ 1UD$

10 TC$ 1UD$

10 TC$ 5 UD$

(c) 1hroughput $& R*+ (d) ueue si%e $& R*+

igure :D. Interaction of different num$er of 1CP flo!s and -+P flo!s

(4) RED rla'd param'r!

e ha"e done some simulations tr&ing to illustrate the effect of R*+ related parameters on theperformance of CH/0e. e find the results compl& !ith the characteristics illustrated $& the

a$o"e data !hich is #uite predicta$le. or e'ample the throughput and #ueue si%e occupied $&

CH/0e changes proportionall& !ith the setting of minth and maxth. 8nd the effect of otherparameters could also $e e'plained $& the anal&sis in 9

7/25/2019 744 Report

15/15

4 +. Lin and R. orris.