From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id E3BCB21F2F9 for ; Wed, 21 May 2014 09:03:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D2FFF40117; Wed, 21 May 2014 12:03:09 -0400 (EDT) X-Virus-Scanned: OK Received: from app55.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 595CE400EB; Wed, 21 May 2014 12:03:08 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app55.wa-webapps.iad3a (Postfix) with ESMTP id 42EC38006D; Wed, 21 May 2014 12:03:08 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Wed, 21 May 2014 12:03:08 -0400 (EDT) Date: Wed, 21 May 2014 12:03:08 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140521120308000000_79217" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <006001cf7478$804951e0$80dbf5a0$@riepnet.com> <006b01cf74e9$c9edf190$5dc9d4b0$@com> <1400683893.25854395@apps.rackspace.com> Message-ID: <1400688188.27216078@apps.rackspace.com> X-Mailer: webmail7.0 Cc: Frits Riep , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration. X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:03:11 -0000 ------=_20140521120308000000_79217 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AIn reality we don't disagree on this:=0A =0AOn Wednesday, May 21, 2014 1= 1:19am, "Dave Taht" said:=0A> =0A=0A> Well, I disagre= e somewhat. The downstream shaper we use works quite=0A> well, until we run= out of cpu at 50mbits. Testing on the ubnt edgerouter=0A> has had the inbo= und shaper work up a little past 100mbits. So there is=0A> no need (theoret= ically) to upgrade the big fat head ends if your cpe is=0A> powerful enough= to do the job. It would be better if the head ends did it,=0A> of course..= ..=0A>=0A =0AThere is an advantage for the head-ends doing it, to the exten= t that each edge device has no clarity about what is happening with all the= other cpe that are sharing that head-end. When there is bloat in the head-= end even if all cpe's sharing an upward path are shaping themselves to the = "up to" speed the provider sells, they can go into serious congestion if th= e head-end queues can grow to 1 second or more of sustained queueing delay.= My understanding is that head-end queues have more than that. They certa= inly do in LTE access networks.=0A ------=_20140521120308000000_79217 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

In reality= we don't disagree on this:

=0A

 =0A

On Wednesday, May 21, 2014 11:19am, "Dave Ta= ht" <dave.taht@gmail.com> said:

=0A

=0A

> Well, I disagree somewhat. The downstream shaper we use= works quite
> well, until we run out of cpu at 50mbits. Testing on= the ubnt edgerouter
> has had the inbound shaper work up a little = past 100mbits. So there is
> no need (theoretically) to upgrade the= big fat head ends if your cpe is
> powerful enough to do the job. = It would be better if the head ends did it,
> of course....
&g= t;

=0A

 

=0A

There is an advantage for the head-ends doing it, to the exten= t that each edge device has no clarity about what is happening with all the= other cpe that are sharing that head-end. When there is bloat in the head-= end even if all cpe's sharing an upward path are shaping themselves to the = "up to" speed the provider sells, they can go into serious congestion if th= e head-end queues can grow to 1 second or more of sustained queueing delay.=  My understanding is that head-end queues have more than that.  = They certainly do in LTE access networks.

=0A

 

=0A ------=_20140521120308000000_79217--