From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 A508E21F2C5 for ; Tue, 27 May 2014 15:00:55 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id bs8so2649737wib.12 for ; Tue, 27 May 2014 15:00:53 -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=KsT2u6O7CmqoPLkGsZdODfgrOCPyv2vJ7j8kYoUfreI=; b=CLhWlpk0f+gCcryarPAHeGHGllT31FXmPpJ/Jr/Uo9X3jPf26P/d5ILqCSMXpOMN/6 QL6LRAaTzISmuxjiZcJmxMJoKFMkgUX0GJ70EI7xsgKbZkE+4iAgBhJYQOfXTtm+tORw OjSiilzRW3zYGOjVyS5OGcF3ahQlxq4E9cM07cO+Cpfm9fbvY0k4eVejJAvQkLm6s7et G/1pC7s4MAkI4lgcp7b9L0OZNxF0OBrMpglOR+Ng4bFnIK6JeuCo2pMNyl84B9O+xMfS /wIfg0rtc3BK9qlVqjFHZAj8aNMsJ7JXTY9Yt4nXKAvj1EoDo/VE4BOEEqADqvgnLRzM wzlQ== MIME-Version: 1.0 X-Received: by 10.180.19.201 with SMTP id h9mr42558242wie.17.1401228053785; Tue, 27 May 2014 15:00:53 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Tue, 27 May 2014 15:00:53 -0700 (PDT) In-Reply-To: References: <1401048053.664331760@apps.rackspace.com> <1401079740.21369945@apps.rackspace.com> <1401112879.32226492@apps.rackspace.com> Date: Tue, 27 May 2014 15:00:53 -0700 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 22:00:56 -0000 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. 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.... low latency makes recovery from a loss in an in-order stream much, much fas= ter. 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 n= ot > 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 y= our > 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 th= e >> 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 t= he >> far better option we have today immediately at the point of most leverag= e. >> 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 whi= le >> 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 > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article