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

[Naeem Khademi <[e-mail]>]

On Wed, Nov 13, 2013 at 7:25 PM, Preethi Natarajan <[e-mail]>wrote:

> Please see inline…
>
> From: Naeem Khademi <[e-mail]>
> Date: Wednesday, November 13, 2013 5:01 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
>
>
>
>> 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!
>
>
>
> Thanks for clarifying. That definitely clears the air about why ARED's
> delay values were so tight; trying to maintain the average queue delay
> between such a narrow band between min and max thresholds (0.5ms to 1.5ms
> or 2.5ms to 7.5ms) would naturally result in tighter delay values at the
> cost of utilization. Of course, ARED works on the average queue size, but
> when it comes to such a narrow band between min and max thresholds, we
> suspect there wouldn't be much difference between ARED and drop tail.
>

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.


>
>
> 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.
>
>
>
> I would not limit an AQM design to absorb just sub-RTT bursts.
>

Neither do I. What I said was that we don't necessarily need to have a very
long distribution tail for long-lived TCP traffic (as observed with PIE and
slightly with CoDel in the results presented at ICCRG, IETF88) to be able
to absorb the bursts.


> A robust AQM scheme should be able to handle any kind of bursts
> irrespective of RTT, traffic patterns etc., since these bursts are quite
> common in deployments today.
>

Agreed only in general terms -- but what would be considered as "packet
burst" and how would it be defined? This will probably have a subjective
answer e.g. one can argue that a size of TCP sawtooth of data is a burst
and therefore we need a BDP of buffering for that (that's what had actually
happened implicitly over the past decade). On the other hand, the
definition of the "burst" may likely to correspond to the application
generating it (e.g. video frames, IW10, etc) and therefore its size (and
even pattern) is application/transport dependent somehow. There are sub-RTT
and larger than one RTT bursts that the network (AQM node) has no clue
about their size (at least for the existing AQMs studied). In case of CoDel
for instance, the whole idea of "100 ms interval time" plus "dropping mode"
with packet drops with sqrt function of "TCP throughput vs. loss model" is
designed to absorb the sub-RTT TCP packet bursts (see CoDel paper @ ACM
Queue) and it assumes that a 100 ms interval works almost fine for most
ranges of RTTs. There's nothing explicit that I can find about bursts
bigger than an one RTT in CoDel's design. I'm curious to know how an AQM
can identify a burst and let it through without the implicit knowledge of
RTT or the transport/application behind it and I'm not sure if it's ever
supposed to? (note: I'm not saying AQM should know at all, just curious how
would it be possible to fulfill the goal you're stating above otherwise?)


Hopefully you or some people on the list can possibly help me with that
:-).

Thanks,
> Preethi
>

Cheers,
Naeem