[e2e] Re: queue averaging introduces delay

[Wuwei]

Hi,Dennis Ferguson

I think there have been some algorithms existed for your purpose, such as 
BLUE, proposed by Feng et al, AVQ, proposed by Kunniyur and Srikant. Actually,
AVQ is trying to control the utilization by a PI controller. The difference 
between it and PI controller proposed by C.V.Hollt et al, is just the control 
target from my point of view. According to my simulation of PI controller, 
PI controller is really sensitive to the buffer limit and can't work well 
when the target queue size is small. The performance of PI controller, 
including the queue size fluctuation and convergence speed,especially the latter
deteriorates seriously when the buffer limit is small or the target queue size 
is close to 0. From Sigcomm2001 paper, it seems AVQ has solved such a problem
to some extent by introducing virtual queue. The use of virtual queue extends
the control range of the actual queue size. 


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 10:56:00 
>Hello,
>
>>  From queuing theory, only when the sources have a Poisson arrival rate 
>> does the length of the queue directly relate to the number of sources 
>> (and thus the appropriate congestion response).
>> 
>> Both the TCP request arrival rate and the inter-packet arrival rate of a 
>> single TCP connection are decidedly non-Poisson.  This makes placing 
>> queue length (and especially instantaneous queue length) at the heart of 
>> AQM schemes dubious.  
>> 
>> Decoupling queue length from AQM schemes can provide significant 
>> improvements in packet loss, queuing delay, and link utilization.  If 
>> you try setting w_q in RED to something extremely small or try using 
>> Blue QM, you can see this difference directly.....
>
>I may be missing something obvious, but it is hard for me to see how
>an AQM scheme which makes adjustments to its control parameter when
>the queue length is instantaneously zero (a "link idle event") or
>when the queue length is instantaneously beyond some limit (a "packet
>loss event") could be said to be decoupled from the instantaneous
>queue length.
>
>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.  I think I'd instead prefer the
>control algorithm to keep the output circuit as close to 100% full
>as possible under sustained congestion, with the control algorithm
>on its own finding the minimum average queue length for which full
>output circuit utilization can be maintained.  This, of course, may
>require magic.
>
>I'd also note that most AQM proposals seem to leave half of the current
>problem on the table.  Most routers now implement multiple output queues
>per circuit in support of differentiated services.  This means that, from
>the point of view of any individual queue, the queue drain rate is not
>necessarily a constant but rather depends on the amount of traffic through
>the other queues.  Since most analyses seem to assume that there is a
>simple fixed relationship between queue length and queuing delay, it
>leaves a non-trivial exercise to the reader to determine the applicability
>of the results to situations where this relationship is violated.
>
>Dennis Ferguson