From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 D75C321F2D5 for ; Tue, 27 May 2014 14:19:01 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id s4RLJ02G007925; Tue, 27 May 2014 14:19:00 -0700 Date: Tue, 27 May 2014 14:19:00 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: "David P. Reed" In-Reply-To: Message-ID: References: <1401048053.664331760@apps.rackspace.com> <1401079740.21369945@apps.rackspace.com> <1401112879.32226492@apps.rackspace.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============3436835895967204587==" 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: Tue, 27 May 2014 21:19:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============3436835895967204587== Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII the problem is that paths change, they mix traffic from streams, and in other ways the utilization of the links can change radically in a short amount of time. If you try to limit things to exactly the ballistic throughput, you are not going to be able to exactly maintain this state, you are either going to overshoot (too much traffic, requiring dropping packets to maintain your minimal buffer), or you are going to undershoot (too little traffic and your connection is idle) Since you can't predict all the competing traffic throughout the Internet, if you want to maximize throughput, you want to buffer as much as you can tolerate for latency reasons. For most apps, this is more than enough to cause problems for other connections. David Lang On Mon, 26 May 2014, David P. Reed wrote: > 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. --===============3436835895967204587== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel --===============3436835895967204587==--