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

[Preethi Natarajan <[e-mail]>]

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.
Preethi