From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D2EEE21F30A for ; Wed, 21 May 2014 09:30:13 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so3575400qcx.41 for ; Wed, 21 May 2014 09:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1VIyvXHDOCom56nANtAJ2BHNQkHjucFq+1Er3g8sGcI=; b=TyGxZsMjmqLwJ7qcwwCCIkr1jVccjjw+ybyBpMrUvVVaW6b9jLO3Mbv30PStbY10zN hL99C9N2aRU8pToNLk50QU4DcXtLdc/xdYVOlTJrKmhndJRWS6KmN2nGWKm6YykmHWur h0p7XrxPTHkGfT9t267WS3YVduEBJ9JEM/04EHerAycMjHGSuz2xv0yGHn7m55I8UIzC uNZNGG5enoqPhzhq5hq4JGX41yT18HTAKd6R1mEPr3hBkHqeCCO2wauKlOegmq6FLyOr lMUk6TSn718n6ZZohAejSzyvZ9/olMcICZD4QDWadZUId8tguCoqog6Di+mQzukuOlGj mEaQ== MIME-Version: 1.0 X-Received: by 10.140.102.166 with SMTP id w35mr5323786qge.97.1400689812944; Wed, 21 May 2014 09:30:12 -0700 (PDT) Received: by 10.140.37.133 with HTTP; Wed, 21 May 2014 09:30:12 -0700 (PDT) In-Reply-To: <1400688188.27216078@apps.rackspace.com> References: <006001cf7478$804951e0$80dbf5a0$@riepnet.com> <006b01cf74e9$c9edf190$5dc9d4b0$@com> <1400683893.25854395@apps.rackspace.com> <1400688188.27216078@apps.rackspace.com> Date: Wed, 21 May 2014 09:30:12 -0700 Message-ID: From: Dave Taht To: David Reed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:30:14 -0000 On Wed, May 21, 2014 at 9:03 AM, wrote: > In reality we don't disagree on this: > > > > On Wednesday, May 21, 2014 11:19am, "Dave Taht" sai= d: > >> > >> 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 i= t, >> of course.... >> > > > > There is an advantage for the head-ends doing it, to the extent 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" sp= eed > the provider sells, they can go into serious congestion if the 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 certainl= y > do in LTE access networks. Compelling argument! I agree it would be best for the devices that have the most information about the network to manage themselves better. It is deeply ironic to me that I'm arguing for an e2e approach on fixing the problem in the field, with you! http://en.wikipedia.org/wiki/End-to-end_principle > > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article