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. _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
