[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