Re: [Bloat] RED against bufferbloat

[Alex Elsayed <eternaleye@gmail.com>]

Bob Briscoe wrote:

> Sahil,
> 
> At 06:46 25/02/2015, Mikael Abrahamsson wrote:
>>On Tue, 24 Feb 2015, sahil grover wrote:
>>
>>>(i) First of all,i want to know whether RED was implemented or not?
>>>if not then what were the reasons(major) ?
>>
>>RED has been available on most platforms, but it was generally not
>>turned on. It also needs configuration from an operator, and it's
>>hard to know how to configure.
> 
> About a decade ago my company (BT) widely deployed RED in the
> upstream 'head-end' of our global MPLS network, i.e. the likely
> bottleneck in the customer edge router where the customer's LAN
> traffic enters their access link. We deployed it as WRED, i.e.
> different configurations of RED across the various diffserv classes,
> in order to minimise queuing latency in all the classes, including
> the lowest priority class. A configuration calculator was developed
> to help the engineers during set up. We still use this setup
> successfuly today, including for all our particularly latency
> sensitive customers in the finance sector.
> 
> We did not deploy RED on our broadband platform (ie public Internet),
> altho in retrospect we should have done, because any AQM is much
> better than none. We're fixing that now.
> 
>>>(ii)Second, as we all know RED controls the  average queue size from
>>>growing.
>>>So it also controls delay in a way or  we can say  is a solution to
>>>bufferbloat problem. Then why it was not considered.
>>
>>It was designed to fix "bufferbloat" long before the bufferbloat
>>word was even invented. It's just that in practice, it doesn't work
>>very well. RED is configured with a drop probability slope at
>>certain buffer depths, and that's it. It doesn't react or change
>>depending on conditions. You have to guess at configure-time.
>>
>>What we need are mechanisms that work better in real life and that
>>are adaptive.
> 
> If you were prepared to read a paper, I would have suggested:
> "The New AQM Kids on the Block: An Experimental Evaluation of CoDel and
> PIE" <http://infocom2014.ieee-infocom.org/GI14-slides/GI14-s2-3.pdf>
> 
> This compares CoDel and PIE against Adaptive RED, which was a variant
> of RED proposed by Sally Floyd & co-authors in 2001 and available
> since Linux kernel version 3.3. ARED addressed the configuration
> sensitivity problem of RED by adapting the parameters to link rate
> and load conditions.
> 
> The paper convinced me that ARED is good enough (in the paper's
> simulations it was often better than PIE or CoDel), at least for
> links with fixed rate (or only occasionally varying rate like DSL).*
> This is important for us because it means we can consider deploying
> AQM by adding soft controls on top of the RED implementations we
> already have in existing equipment. This could reduce deployment
> completion time from decades to a few months.
> 
> * I'm not sure ARED would be able to cope with the rapidly changing
> rate of a wireless link tho.

One thing that was brought up on the CoDel list (which Sahil's original 
question was cross-posted to) by Dave Taht is that much of this testing 
utterly fails to account for two crucial factors:

1.) Asymmetric paths. When the uplink is considerably smaller than the 
downlink, he's seen significant behavioral differences - and that's 
_exactly_ the case of DSL.

2.) Elephants, mice and ants - response of mixed (and latency-sensitive) 
traffic under load. The RRUL (Realtime Response Under Load) toolkit he 
created is explicitly designed to test this case... which is a close match 
to common use cases like watching a Youtube video, but still needing things 
like DNS to be responsive. Or the bursty traffic of web browsing while a 
VoIP call is occurring.

The former is completely ignored by the presentation you linked to, and the 
latter is a one-line mention under "future work":

"More realistic traffic types (here, only bulk TCP traffic) including
bursty traffic"

Considering those, that slide deck convinces me of very, very little indeed.