[Bloat] The challenge

[Simon Barber]

One question now remains - will codel AQM be sufficient on it's own in 
getting delays down to levels that users are happy with for the common 
latency sensitive interactive traffic - VoIP, gaming and Skype for 
example - or are the further reductions that can be had with traffic 
classification and smart queuing algorithms necessary? The nicest part 
about codel on it's own is that it works on opaque packets - it will 
handle VPNs and traffic within them nicely. It gets away from all the 
complexity required to classify traffic in a world where traffic is 
often trying to hide.

Simon

On Tue 08 May 2012 06:04:50 PM PDT, Dave Taht wrote:
> Both the acm queue article and jim's blog entry this morning were way
> above mensa's standards.
>
> Nobody has attempted to explain the elegant simplicity of the
> algorithm itself in the inverse sqrt however!  I have a good grip on
> it, and am trying, but can barely explain it to myself. Anyone else
> care to dig through the codel code and try to put it into english?
>
> Nice bit in ReadWrite News:
>
> http://www.readwriteweb.com/enterprise/2012/05/good-news-for-solving-bufferbloat-codel-provides-no-knobs-solution.php
>
> Bob Cringley lays down the challenge for us here on the bloat list,
> and details the opportunity.
>
> http://www.cringely.com/2012/05/beginning-of-the-end-for-bufferbloat/
>
> He closes with:
>
> "My advice to Cisco, Netgear, D-Link and others is that this could be
> an important moment in their businesses if they choose to approach it
> correctly. It’s a chance to get all of us to buy new routers, perhaps
> new everything. Think of the music industry bonanza when we all
> shifted our record libraries from vinyl to CDs. It could be the same
> for networking equipment. But for that to happen the vendors have to
> finally acknowledge bufferbloat and use their marketing dollars to
> teach us all why we should upgrade ASAP. Everybody would win.
>
> Take our money, please."
>
> With the cerowrt project, at least, I've hoped to make that shift
> possible, and to some extent... happen.
>
> We have *working code*, and *proof of concept*. What's next? Where do
> we go from here?
>