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

[Naeem Khademi <[e-mail]>]

On Wed, Nov 13, 2013 at 12:56 AM, Preethi Natarajan
<[e-mail]>wrote:

>
>
> From: Michael Welzl <[e-mail]>
> Date: Friday, November 8, 2013 5:30 PM
>
> To: Preethi Natarajan <[e-mail]>
> Cc: Naeem Khademi <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
> Thanks for the link. My point was just (along with Naeem) that it would be
> useful to compare PIE (or CoDel) against something else except CoDel and
> RED. When I just look at the graphs in the HPSR paper (sorry, didn't get to
> read it yet), again I see only PIE, CoDel, RED.
>
> We tried ARED and were surprised to see how good it works - which is not
> to say that it is the ideal - but it was surprisingly often better than
> these newer schemes, despite its age of 10+ years... as we all know, there
> are many schemes out there, quite often designed with the goal of removing
> RED's dependence on parameters.
>
>
>
Hi Preethi and Rong

replies follow inline


> Michael, Naeem:
>
> This is just a follow-up to better understand the ARED results presented
> at AQM WG (http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-4.pdf
> ).
>
> Could you please clarify whether the ARED parameters for the tests were
> set as specified in the 2001 paper? I.e., when average queueing delay
> target = 1ms, the min and max thresholds would translate to 0.5ms and
> 1.5ms, and for 5 ms target the min and max thresh will be 2.5ms and 7.5ms,
> respectively, right? Can you confirm?
>

Copy/pasting from Section 3.1.3 of http://urn.nb.no/URN:NBN:no-38868
<http://urn.nb.no/URN:NBN:no-38868>

*"In case of ARED, the parameters are calculated based on the
recommendations in [19]*
*except when target delay=1 ms where th_min and th_max are set to 1 MTU*
*and 2 MTUs accordingly."*

*[19] S. Floyd, R. Gummadi, and S. Shenker. Adaptive RED: An Algorithm for*
*Increasing the Robustness of RED’s Active Queue Management. Technical*
*report, 2001.*

This means "yes" for all values of target delay except for 1 ms cases where
the thresholds become smaller than a single MTU transmission time on the 10
Mbps bottleneck link used in this case.  The recommendations in Sally
Flyod' s ARED 2001  (th_max=3*th_min; target=(th_max+th_min)/2) are used in
all other cases.


> Assuming ARED logic is intact, ARED drops all packets when average queue
> size goes above max_thresh  (max_thresh = 1.5ms or 7.5ms etc.); this
> would be semantically similar to a drop tail queue with shallow buffer (can
> be confirmed by looking at cumulative packet drops by ARED).
>

Similar but not identical as ARED (and any other *RED) does averaging
instead of using instantaneous queue size (e.g. that being employed in
DCTCP AQM)


> This is probably why the delay values are tight for ARED, and why ARED
> translates to poor utilization, especially for the lower target delay
> values, as seen in your slides (#8, #11, #13).
>

True!


> Also,  wondering if bursty traffic was considered for evaluations, since
> semantics of drop tail with shallow buffering doesn't accommodate bursty
> traffic.
>

No, we did not consider bursty traffic (e.g. multimedia, etc) for this work
as this was our first (initial) fundamental step to understand in a
systematic way how AQMs work in real-life with long-lived TCP traffic
(which is the most common type of traffic that fills up any buffer and
consistently contributes to excessively long latencies experienced on the
Internet (a.k.a bufferbloat)).

The fact that AQMs *should* absorb sub-RTT bursts (due to rate mistmatch,
etc) does not diminish the basic requirement for AQMs that they should
control the latency induced by bulk (long-lived) TCP traffic in a well
manner. Any other type of traffic on the access links will most likely to
coexist with bulk TCP traffic when latency is observed to grow high. In
other words, if an AQM can't control the latency of (not so bursty as
others-) TCP traffic, it probably won't be able to do so for bursty traffic
as well.


> Thanks,
> Preethi & Rong
>
>
Cheers,
Naeem