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

[" Ilpo Järvinen " <[e-mail]>]

On Thu, 14 Nov 2013, Preethi Natarajan 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. 

IIRC, the Linux burst parameter is taken into account in frontend tc-tool 
only to calculate parameters for the kernel. I think its meaning was quite 
close to what L is in formula 3 [1] but it's like ten years ago when I 
read that bit of code. As such, its value only applies to the case where 
the queue average is zero before the burst occurs.

However, the real problem with these "burst" parameters is that they 
do not specify a limit for the burst. Instead, they are only used to set a 
minimum burst they allow but by no means give a way to specify a hard 
deadline when the burst has to be stopped at latest. By no means 
drops/marks typically occur soon after the "burst" threshold is crossed 
because the drop probability will be extremely small.

I've shown this lack of control with a typical RED setup [2] (ARED is 
actually worse than RED because of auto-tuning makes it even slower than 
typical RED setup but I didn't go to prove that). It also talks about 
th_max cutter and tail-drop fallback, which both seemed to be already 
mentioned in this thread. Based on how timers work in CoDel and PIE it is 
pretty obvious that the lack of control problem is present in them too 
(I've a paper coming up very soon on these issues too).


-- 
 i.


[1] Random Early Detection gateways for Congestion Avoidance.
Floyd, S., and Jacobson, V.
IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.

[2] Ilpo Järvinen, Aaron Yi Ding, Aki Nyrhinen, Markku Kojo, "Harsh RED: 
Improving RED for Limited Aggregate Traffic", In Proc. IEEE International 
Conference on Advanced Information Networking and Applications (IEEE AINA 
2012), Fukuoka, Japan, March 2012.
[http://www.cs.helsinki.fi/group/wibra/aina12.pdf]