[e2e] Re: queue averaging introduces delay

[Wuwei]

Hi,Ramakrishna Gummadi

Maybe in RED, C*q_w should be a constant value, which can determine the
responsiveness of RED actually. So higher capacity C is, the less q_w should be...

Best Regards
Wei Wu
wuwei at sdp.ee.tsinghua.edu.cn
|=====================================================================|
| Wei Wu, Complexity Engineering System Labs (CESL)                   |
| Electronics Engineering Department, Tsinghua University             |
| Beijing, P.R.China                                                  | 
|                                                                     | 
| Office:Room 401 Division 10,Eastern Main Building of Tsinghua Univ. |
|       (tel) 86 10 6277 3228                                         |
| Dorm  :Room 300 Apartment 14, Tsinghua Univ.                        |
|       (tel) 86 10 6277 8632                                         |
|=====================================================================| 

In your letter 2001-8-7 12:15:00 
>> 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