[e2e] Re: queue averaging introduces delay

[Ramakrishna Gummadi]

> I am, however, sympathetic to the implied concern about what it is
> which AQM schemes pick as control parameters.  I'd personally prefer
> not to have to pick a target average queue length, since this seems
> of only secondary relevance.  

For RED (and adaptive RED) at least, the EWMA average queue length turns
out to be a pretty good approximation to the true mean-averaged queue
length (this was true in all simulations we did). Of course, the EWMA
queue length may not capture the variance in true queing delay, but is not
intended to for that purpose, anyway (RED intentionally allows large
bursts to pass through with low drop rate, but one can configure buffers
for worst case guarantees if one so desires).

I think whether one uses an averaged queue length or not depends on the
control model used---for PI, it may turn out good not to use averaging,
but for RED we found that a non-averaged queue gives lower performance
(delay-bw) than an averaged one. In fact, as we point out, it is better to
choose a queue weight dependent on the link capacity, which means that the
default w_q in RED of 0.002 turns out approximately a magnitude larger
than what, from simulation, is apparaently best for a 15Mbps
link---0.00027. 0.002 turns out better if link capacity is 1.5Mbps. And
w_q decreases further for higher speed links. The RED code in ns now
automatically selects w_q if set to 0 in the simulation script.


thanls,
ramki