From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.vyatta.com (mail.vyatta.com [76.74.103.46]) by huchra.bufferbloat.net (Postfix) with ESMTP id 3F0E5201AFD for ; Fri, 6 May 2011 15:04:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.vyatta.com (Postfix) with ESMTP id C5DB018297A9; Fri, 6 May 2011 15:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at tahiti.vyatta.com Received: from mail.vyatta.com ([127.0.0.1]) by localhost (mail.vyatta.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGKnsQIZS3pD; Fri, 6 May 2011 15:10:04 -0700 (PDT) Received: from nehalam (static-50-53-80-93.bvtn.or.frontiernet.net [50.53.80.93]) by mail.vyatta.com (Postfix) with ESMTPSA id 852441829749; Fri, 6 May 2011 15:10:04 -0700 (PDT) Date: Fri, 6 May 2011 15:10:03 -0700 From: Stephen Hemminger To: Fred Baker Message-ID: <20110506151003.2d2a4af3@nehalam> In-Reply-To: References: <4DB70FDA.6000507@mti-systems.com> <4DC2C9D2.8040703@freedesktop.org> <1EA9A6B3-F1D0-435C-8029-43756D53D8FD@gmail.com> <1304694852.29492.16.camel@amd.pacdat.net> Organization: Vyatta X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Goodput fraction w/ AQM vs bufferbloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 22:04:59 -0000 On Fri, 6 May 2011 14:56:01 -0700 Fred Baker wrote: > > On May 6, 2011, at 8:14 AM, richard wrote: > > If every packet takes two attempts then the ratio will be 1/2 - 1 unit > > of googput for two units of throughput (at least up to the choke-point). > > This is worst-case, so the ratio is likely to be something better than > > that 3/4, 5/6, 99/100 ??? > > I have a suggestion. turn on tcpdump on your laptop. Download a web page with lots of imagines, such as a google images web page, and then download a humongous file. Scan through the output file for SACK messages; that will give you the places where the receiver (you) saw losses and tried to recover from them. > > > Putting a number to this will also help those of us trying to get ISPs > > to understand that their Usage Based Bilking (UBB) won't address the > > real problem which is hidden in this ratio. The fact is, the choke point > > for much of this is the home router/firewall - and so that 1/2 ratio > > tells me the consumer is getting hosed for a technical problem. > > I think you need to do some research there. A TCP session with 1% loss (your ratio being 1/100) has difficulty maintaining throughput; usual TCP loss rates are on the order of tenths to hundredths of a percent. There is some good theoretical work which shows relationship between throughput and loss. http://www.slac.stanford.edu/comp/net/wan-mon/thru-vs-loss.html Rate <= (MSS/RTT)*(1 / sqrt{p}) where: Rate: is the TCP transfer rate or throughputd MSS: is the maximum segment size (fixed for each Internet path, typically 1460 bytes) RTT: is the round trip time (as measured by TCP) p: is the packet loss rate. It is interesting that longer RTT which can be an artifact of bloat in the queues, will hurt throughput in this case.