Please see inline From: Naeem Khademi <[email protected]> Date: Wednesday, November 13, 2013 5:01 AM To: Preethi Natarajan <[email protected]> Cc: Michael Welzl <[email protected]>, "[email protected]" <[email protected]> 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. >> 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. 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. Thanks, Preethi
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
