From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by huchra.bufferbloat.net (Postfix) with ESMTP id DB38E201AF7 for ; Fri, 6 May 2011 08:09:15 -0700 (PDT) Received: from pd6ml2no-ssvc.prod.shaw.ca ([10.0.153.163]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 06 May 2011 09:14:13 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=Mj7okGGiyvljez8nourwAOSCyIXzraNcHEi86Qy5a+Y= c=1 sm=1 a=y7JCWN07UVIA:10 a=QmdwtOVf3dEA:10 a=BLceEmwcHowA:10 a=wPDyFdB5xvgA:10 a=xqWC_Br6kY4A:10 a=5cEFxojLHbSazGx3ptQdfQ==:17 a=3dZX8JWgAAAA:8 a=b7SLfKwVAAAA:8 a=6jOGtOWoEiDRqB9c4JsA:9 a=Fw8iwiUKpeAA:10 a=TphoKWqS9HQA:10 a=TzHDmpukvkgl-Q4T:21 a=UqiNBpTVqu3r0twW:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO amd.pacdat.net) ([96.48.80.31]) by pd6ml2no-dmz.prod.shaw.ca with ESMTP; 06 May 2011 09:14:13 -0600 Received: from localhost ([::1]) by amd.pacdat.net with esmtp (Exim 4.69) (envelope-from ) id 1QIMjM-0002d0-VS; Fri, 06 May 2011 08:14:13 -0700 From: richard To: Fred Baker In-Reply-To: <1EA9A6B3-F1D0-435C-8029-43756D53D8FD@gmail.com> References: <4DB70FDA.6000507@mti-systems.com> <4DC2C9D2.8040703@freedesktop.org> <1EA9A6B3-F1D0-435C-8029-43756D53D8FD@gmail.com> Content-Type: text/plain Date: Fri, 06 May 2011 08:14:12 -0700 Message-Id: <1304694852.29492.16.camel@amd.pacdat.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- 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 15:09:16 -0000 I'm wondering if we should look at the ratio of throughput to goodput instead of the absolute numbers. Yes, the goodput will be 100% but at what cost in actual throughput? And at what cost in total bandwidth? 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 ??? Hmmm... maybe inverting the ratio and calling it something flashy (the bloaty rating???) might give us a lever in the media and with ISPs that is easier for the math challenged to understand. Higher is worse. 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. richard On Thu, 2011-05-05 at 21:18 -0700, Fred Baker wrote: > There are a couple of ways to approach this, and they depend on your network model. > > In general, if you assume that there is one bottleneck, losses occur in the queue at the bottleneck, > and are each retransmitted exactly once (not necessary, but helps), goodput should approximate 100% > regardless of the queue depth. Why? Because every packet transits the bottleneck once - if it is > dropped at the bottleneck, the retransmission transits the bottleneck. So you are using exactly > the capacity of the bottleneck. > > the value of a shallow queue is to reduce RTT, not to increase or decrease goodput. cwnd can become > too small, however; if it is possible to set cwnd to N without increasing queuing delay, and cwnd is > less than N, you're not maximizing throughput. When cwnd grows above N, it merely increases queuing > delay, and therefore bufferbloat. > > If there are two bottlenecks in series, you have some probability that a packet transits one > bottleneck and doesn't transit the other. In that case, there is probably an analytical way > to describe the behavior, but it depends on a lot of factors including distributions of competing > traffic. There are a number of other possibilities; imagine that you drop a packet, there is a > sack, you retransmit it, the ack is lost, and meanwhile there is another loss. You could easily > retransmit the retransmission unnecessarily, which reduces goodput. The list of silly possibilities > goes on for a while, and we have to assume that each has some probability of happening in the wild. > snip... richard -- Richard C. Pitt Pacific Data Capture rcpitt@pacdat.net 604-644-9265 http://digital-rag.com www.pacdat.net PGP Fingerprint: FCEF 167D 151B 64C4 3333 57F0 4F18 AF98 9F59 DD73