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 8A91421F2D8 for ; Tue, 27 May 2014 16:27:48 -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 s4RNRj7F008571; Tue, 27 May 2014 16:27:45 -0700 Date: Tue, 27 May 2014 16:27:45 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht 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: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 23:27:48 -0000 On Tue, 27 May 2014, Dave Taht wrote: > There is a phrase in this thread that is begging to bother me. > > "Throughput". Everyone assumes that throughput is a big goal - and it > certainly is - and latency is also a big goal - and it certainly is - > but by specifying what you want from "throughput" as a compromise with > latency is not the right thing... > > If what you want is actually "high speed in-order packet delivery" - > say, for example a movie, > or a video conference, youtube, or a video conference - excessive > latency with high throughput, really, really makes in-order packet > delivery at high speed tough. the key word here is "excessive", that's why I said that for max throughput you want to buffer as much as your latency budget will allow you to. > You eventually lose a packet, and you have to wait a really long time > until a replacement arrives. Stuart and I showed that at last ietf. > And you get the classic "buffering" song playing.... Yep, and if you buffer too much, your "lost packet" is actually still in flight and eating bandwidth. David Lang > low latency makes recovery from a loss in an in-order stream much, much faster. > > Honestly, for most applications on the web, what you want is high > speed in-order packet delivery, not > "bulk throughput". There is a whole class of apps (bittorrent, file > transfer) that don't need that, and we > have protocols for those.... > > > > On Tue, May 27, 2014 at 2:19 PM, David Lang wrote: >> 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. >> >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > >