From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by huchra.bufferbloat.net (Postfix) with SMTP id 070F821F09E for ; Tue, 15 May 2012 20:02:23 -0700 (PDT) Received: (qmail 19426 invoked by uid 0); 9 May 2012 02:02:23 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy1.bluehost.com with SMTP; 9 May 2012 02:02:23 -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=qMbQOb0cRM/rCJd8taadzq91nHX7wTcqs+N2yA2Zes4=; b=IdPwnoYTEYpN2OPBUT81o60G66ROZnd05LefeT74fGzkXv68onpaY/A1TiiUEHDeWFVcJeD9mM7pnSNBsmUtAmHJ/rYxj7Y6LNPF4octt5vs6o4EFKPFkdIGq6ye0gjR; Received: from mail-we0-f171.google.com ([74.125.82.171]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SRwEQ-0005sB-Pp; Tue, 08 May 2012 20:02:23 -0600 Received: by wejx9 with SMTP id x9so8285461wej.16 for ; Tue, 08 May 2012 19:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.79.72 with SMTP id h8mr2280475wix.1.1336528941266; Tue, 08 May 2012 19:02:21 -0700 (PDT) Received: by 10.223.2.13 with HTTP; Tue, 8 May 2012 19:02:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 May 2012 20:02:21 -0600 Message-ID: From: Kevin Gross To: Dave Taht Content-Type: multipart/alternative; boundary=f46d0442827ac6b5f004bf90e40b X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.171 authed with kevin.gross@avanw.com} X-Mailman-Approved-At: Tue, 15 May 2012 20:29:26 -0700 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 03:02:24 -0000 --f46d0442827ac6b5f004bf90e40b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The decision the algorithm is trying to make is when to drop packets. RED drops packets when the maximum queue level rises. CoDel drops packets when the minimum queue level rises. If the queue is never (nearly) empty, the interface is oversubscribed and packet drops are in order. But because it looks at minimum, not maximum, CoDel will not drop packets in bursts so long as those bursts pass within the (5 ms) interval used to measure minimum queue level. 1/sqrt bit controls how many packets get dropped as a function of time and I gather it is control loop tuning used to strike a good balance between responsiveness, stability and do no harm. Kevin Gross On Tue, May 8, 2012 at 7:04 PM, 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-buff= erbloat-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? > > -- > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://www.bufferbloat.net > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --f46d0442827ac6b5f004bf90e40b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The decision the algorithm is trying to make is when to drop packets. = RED drops packets when the maximum queue level rises. CoDel drops packets w= hen the minimum queue level rises.=A0If the queue is never (nearly) empty, = the interface is oversubscribed and packet drops are in order. But because = it looks at minimum, not maximum,=A0CoDel will not drop packets in bursts s= o long as those bursts pass within the (5 ms) interval used to measure mini= mum queue level.=A0

1/sqrt bit controls how many packets get dropped as a f= unction of time and=A0I gather it=A0is control loop tuning used to strike a= good balance between responsiveness, stability and do no harm.

Kevin Gross

On Tue, May 8, 201= 2 at 7:04 PM, Dave Taht <dave.taht@gmail.com> 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-solving-bufferbl= oat-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-e= nd-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?

--
Dave T=E4ht
SKYPE: davetaht
US Tel: 1-239-829-560= 8
http://www.bufferb= loat.net
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat

--f46d0442827ac6b5f004bf90e40b--