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

[Naeem Khademi <[e-mail]>]

On Thu, Nov 14, 2013 at 8:46 PM, Preethi Natarajan <[e-mail]>wrote:

>
>
> From: Naeem Khademi <[e-mail]>
> Date: Thursday, November 14, 2013 5:32 AM
>
> To: Preethi Natarajan <[e-mail]>
> Cc: Michael Welzl <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
> 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).
>
>
> Of course. The question is how effective is the mechanism. As you note,
> whatever "burst" mechanism exists in Linux's ARED wasn't effective as
> evident from the low throughput in the plots.
>
>
>
>
>> 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" :-).
>
>
>
> Great. Thanks for confirming this point that ARED as is does not work well
> for the scenarios considered. What is required is new AQM design, not just
> plugging delay into ARED.
>

Agreed with all your points though to complete it, developing new AQMs
without looking back at and learning from what we have had available leads
to inventing things that improve utilization instead of delay for instance
:-). Again to emphasis we never recommended that people should turn on RED
or ARED (or any future variant of ARED) on their edge devices, but rather
we experimentally demonstrated that it worked better than CoDel and PIE is
most of the scenarios we studied except in very few. We thought it was
important to have more basic understandable experimental results (with
long-lived TCP flows) available before we indulge in looking at more
complex traffic scenarios.

What I would probably choose to investigate e.g. why PIE performs with a
very long upper distribution tail of RTTs with common long-lived TCP
traffic more specifically for lower target delay values even though we know
TCP isn't a very bursty type of traffic? Could that be related to the way
it handles bursts?  or any other reason?  The technical report provides a
very first insight into such issues that need to be explored like this one
but then the story doesn't stop here and ARED was only a benchmark that was
close enough to IETF-documented RED and could work with a certain target
delay (in our scenarios).


> Preethi
>

Naeem