From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp121.dfw.emailsrvr.com (smtp121.dfw.emailsrvr.com [67.192.241.121]) (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 432A621F27C for ; Mon, 26 May 2014 08:31:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id D09953C034C; Mon, 26 May 2014 11:31:14 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp12.relay.dfw1a.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id 3CD353C0340; Mon, 26 May 2014 11:31:14 -0400 (EDT) User-Agent: K-@ Mail for Android X-Priority: 3 In-Reply-To: References: <1401048053.664331760@apps.rackspace.com> <1401079740.21369945@apps.rackspace.com> <1401112879.32226492@apps.rackspace.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----NFI2WJA14TPUXPCG7D5C3Z78HCJ00N" Content-Transfer-Encoding: 8bit From: "David P. Reed" Date: Mon, 26 May 2014 08:31:12 -0700 To: Mikael Abrahamsson Message-ID: Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Ubiquiti QOS 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: Mon, 26 May 2014 15:31:16 -0000 ------NFI2WJA14TPUXPCG7D5C3Z78HCJ00N Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Codel and PIE are excellent first steps... but I don't think they are the best eventual approach. I want to see them deployed ASAP in CMTS' s and server load balancing networks... it would be a disaster to not deploy the far better option we have today immediately at the point of most leverage. The best is the enemy of the good. But, the community needs to learn once and for all that throughput and latency do not trade off. We can in principle get far better latency while maintaining high throughput.... and we need to start thinking about that. That means that the framing of the issue as AQM is counterproductive. On May 26, 2014, Mikael Abrahamsson wrote: >On Mon, 26 May 2014, dpreed@reed.com wrote: > >> I would look to queue minimization rather than "queue management" >(which >> implied queues are often long) as a goal, and think harder about the >> end-to-end problem of minimizing total end-to-end queueing delay >while >> maximizing throughput. > >As far as I can tell, this is exactly what CODEL and PIE tries to do. >They >try to find a decent tradeoff between having queues to make sure the >pipe >is filled, and not making these queues big enough to seriously affect >interactive performance. > >The latter part looks like what LEDBAT does? > > >Or are you thinking about something else? -- Sent from my Android device with K-@ Mail. Please excuse my brevity. ------NFI2WJA14TPUXPCG7D5C3Z78HCJ00N Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Codel and PIE are excellent first steps... but I don't think they are the best eventual approach.  I want to see them deployed ASAP in CMTS' s and server load balancing networks... it would be a disaster to not deploy the far better option we have today immediately at the point of most leverage. The best is the enemy of the good.

But, the community needs to learn once and for all that throughput and latency do not trade off. We can in principle get far better latency while maintaining high throughput.... and we need to start thinking about that.  That means that the framing of the issue as AQM is counterproductive.

On May 26, 2014, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Mon, 26 May 2014, dpreed@reed.com wrote:

I would look to queue minimization rather than "queue management" (which 
implied queues are often long) as a goal, and think harder about the 
end-to-end problem of minimizing total end-to-end queueing delay while 
maximizing throughput.

As far as I can tell, this is exactly what CODEL and PIE tries to do. They 
try to find a decent tradeoff between having queues to make sure the pipe 
is filled, and not making these queues big enough to seriously affect 
interactive performance.

The latter part looks like what LEDBAT does?
<http://tools.ietf.org/html/rfc6817>

Or are you thinking about something else?

-- Sent from my Andro id device with K-@ Mail. Please excuse my brevity. ------NFI2WJA14TPUXPCG7D5C3Z78HCJ00N--