Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi <[e-mail]>]

Hi Preethi

Please see comments inline

On Thu, Nov 14, 2013 at 2:17 AM, Preethi Natarajan <[e-mail]>wrote:

>
>
> From: Naeem Khademi <[e-mail]>
> Date: Wednesday, November 13, 2013 12:14 PM
>
> To: Preethi Natarajan <[e-mail]>
> Cc: Michael Welzl <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
> Very true, though that's what ARED *is* with very low thresholds (e.g.
> resonate between 1 or 2 packets on the average in the queue). Indeed there
> can possibly be some future work on ARED's (or any other similar AQM) burst
> allowance but I don't think e.g. letting a 100 ms burst of packets to pass
> through can be a good way of fixing it as this can lead to massive variance
> in overall RTT distribution.
>
>
> If you are referring to the burst_allowance parameter in PIE, this
> parameter allows burst to go through when a system goes from an idle state
> into some congestion state. The one we are talking about is accommodating
> bursts when the system is in equilibirum
>

I wasn't referring to a PIE's parameter named "burst allowance" but rather
in a generic term.


> -- how does the AQM scheme accommodate bursts when already operating
> around target delay or congestion?
>

AFAIK all three studied AQMs (CoDel, PIE, ARED) have a parameter named
"target delay" or "target queuing". Judging based on the (param) name, they
supposedly try to maintain the queue delay/length around/at a certain value
although "target delay/queuing" has different semantics in each AQM and the
response to crossing that threshold/value is also different from one AQM to
another. Moreover, It is favorable for an AQM that tries to fix bufferbloat
problem to have a predictable delay distribution, most favorably around
(e.g. mean, median, max) a certain value. PIE uses it, CoDel has it and
ARED in fixed BW setups has it too. So, I'm not quite sure, why it
shouldn't be possible to allow a certain size of burst in such
threshold-based mechanisms (AFAIK (A)RED's Linux implementation already has
a "burst" param that can be tuned, although its semantics may not be
identical to the way CoDel or PIE handle bursts).


> Delay-based ARED behaves similar to tail drop at max threshold. This is
> unacceptable of an AQM even for max thresholds around 50ms.
>

I'm not sure if I understand this part correctly or even if I agree with
the conclusion it makes, assuming that I understood it correctly :-). If
I'm not mistaken, you're saying that "(delay-based) ARED  acts similar to
DropTail when the average queue size/delay grows beyond the th_max". If
that's the case, then I disagree since ARED uses a (delay-based) AIMD
function to tune the maximum drop probability and therefore it uses the AI
factor to increase its P_MAX when queue size/delay grows beyond the th_max
and on top of that, it does averaging, so nothing really similar to
DropTail.


> Clearly delay-based ARED needs significant and careful redesign. I
> suppose one can argue this task is as laborious as designing a new AQM
> scheme as opposed to previous notions that delay-based ARED would work
> right out of the box.
>

it's probably not accurate to say "redesign" as delay-based ARED doesn't
exist as of know. AFAIK given our latest results with ARED, we raised
the possibility of modifying ARED to use delay-based thresholds instead of
size-based thresholds during the ICCRG talk and in the TR, and declared it
as future work. I'm not aware of any other implementation/proposal of
delay-based ARED to exist as of now. We never claimed or speculated on how
this future delay-based AQM might perform and left it to when the future
work is done and the outcome is properly investigated and therefore we
never said that "it would work right out of the box" :-).


> Preethi
>

Cheers,
Naeem