David Lang wrote: > On Wed, 25 Feb 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. >> >>> anyone please tell me in simple words here only,because i don't want to >>> read any paper like "RED in a different light". >> >> These issues are not simple. There are several presentations/talks >> available on Youtube on the issues if you want it in presentation form. >> Search for "Dave Taht", "Jim Gettys", "bufferbloat" and other such topics >> and you'll find excellent presentations from different forums. >> >>> (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. > > more importantly (as I understand it), if you use RED while the rest of > the users on the network stick with stock systems, you will keep yielding > to them and only get to use a fraction of the available bandwidth.
I suspect you're conflating RED with delay-based congestion-control algorithms such as Vegas. _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
