[e2e] Re: queue averaging introduces delay

Wu-chang Feng wuchang at cse.ogi.edu
Tue Aug 7 14:10:54 PDT 2001


I agree that most of these algorithms will not work well if your queue 
draining rate is non-constant due to the way you schedule link access 
over multiple queues.  Someone here must be working on that problem. :)

Blue is decoupled in the sense that the probability is not as directly 
tied to the queue length as with RED which roughly uses a marking 
probability of
  maxp* (Qave - minth)/(maxth-minth).  
I'd definitely recommend trying it out (versus taking my word for it).

As far as an ideal control parameter to use to manage congestion, for 
TCP sources, you could construct something more exact in the form of....

 p = [(N * MSS * C)/(L * RTT)]^2 + (higher order terms from Padhye et. 
al. SIGCOMM98)

where N is the instantaneous number of active connections, MSS is an 
"effective" segment size across all of the active connections, L is the 
link bandwidth, and RTT is an "effective" round-trip time of all of the 
active connections across the link.  It's easy to get N which is the 
biggest variant.  An "effective" MSS and an "effective" RTT probably 
wouldn't change too much and could be adaptively measured and calculated 
over time.  I twiddled with something like this a bit, but couldn't get 
it to yield enough of a performance improvement to warrant the 
complexity over the simpler, less optimal Blue algorithm.

Wu




More information about the end2end-interest mailing list