From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by huchra.bufferbloat.net (Postfix) with SMTP id 679FA21F0AC for ; Tue, 15 May 2012 22:31:32 -0700 (PDT) Received: (qmail 10994 invoked by uid 0); 9 May 2012 13:04:51 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 9 May 2012 13:04:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=8zDGOOHz6jozfQUiEldXY/IKGFuDTnwNIrGPMzrAUq4=; b=baHHgy4nPW5HA+1pf1sS5225J0HPfRMbTo8ucLGENEylunXqCprwe08zd9HJruJhKQlrBCer+GnnnZhFTigGj3B7rPcWZsvW59F5sR7dfQ06xIbhZmCLpWhAn28FpHe1; Received: from mail-wg0-f41.google.com ([74.125.82.41]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SS6ZW-0004m1-KA; Wed, 09 May 2012 07:04:50 -0600 Received: by wgbds1 with SMTP id ds1so1641555wgb.4 for ; Wed, 09 May 2012 06:04:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.194.195 with SMTP id m45mr50270wen.8.1336568688895; Wed, 09 May 2012 06:04:48 -0700 (PDT) Received: by 10.223.2.13 with HTTP; Wed, 9 May 2012 06:04:48 -0700 (PDT) In-Reply-To: <4FA9FDC0.9010600@superduper.net> References: <4FA9FDC0.9010600@superduper.net> Date: Wed, 9 May 2012 07:04:48 -0600 Message-ID: From: Kevin Gross To: Simon Barber Content-Type: multipart/alternative; boundary=0016e6d77ee2eb688504bf9a2510 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.41 authed with kevin.gross@avanw.com} Cc: codel@lists.bufferbloat.net, bloat Subject: Re: [Codel] [Bloat] The challenge X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 05:31:32 -0000 --0016e6d77ee2eb688504bf9a2510 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >From the paper (figure 7), you can see that CoDel still leaves spikes of buffer occupancy when network conditions change. These will still be disruptive to real-time traffic. Many networks that need QoS now will still need QoS. Networks that do not have QoS will be much more usable with CoDel. Kevin Gross On Tue, May 8, 2012 at 11:16 PM, Simon Barber wrote: > 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 exampl= e > - or are the further reductions that can be had with traffic classificati= on > 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=92s 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? >> >> ______________________________**_________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/**listinfo/bloat > --0016e6d77ee2eb688504bf9a2510 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >From the paper (figure 7), you can see that CoDel still leaves spikes of bu= ffer occupancy when network conditions change. These will still be=A0disrup= tive=A0to real-time traffic. Many networks that need QoS now will still nee= d QoS. Networks that do not have QoS will be much more usable with CoDel.
Kevin Gross

= On Tue, May 8, 2012 at 11:16 PM, Simon Barber <simon@superduper.net= > wrote:
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, ga= ming and Skype for example - or are the further reductions that can be had = with traffic classification and smart queuing algorithms necessary? The nic= est part about codel on it's own is that it works on opaque packets - i= t will handle VPNs and traffic within them nicely. It gets away from all th= e 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! =A0I 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:

ht= tp://www.readwriteweb.com/enterprise/2012/05/good-news-for-so= lving-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-o= f-the-end-for-bufferbloat/

He closes with:

"My advice to Cisco, Netgear, D-Link and others is that this could be<= br> an important moment in their businesses if they choose to approach it
correctly. It=92s 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?

_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/bloat

--0016e6d77ee2eb688504bf9a2510--