From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 56239201A5D for ; Sun, 8 May 2011 20:01:32 -0700 (PDT) Received: by wwk4 with SMTP id 4so4946259wwk.28 for ; Sun, 08 May 2011 20:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :x-priority:in-reply-to:date:cc:content-transfer-encoding:message-id :references:to:x-mailer; bh=/v4KFog6+lWGzkyYXeuxlKIRL06llJgVra00P7uV8CU=; b=heX2JO4v2mOkWxd9wASr+sjy/NYgZDocB0M1Y/Lohsq58yaNejQmdIddUrBExvMod6 mnc+du3y/CzE2BWlb+cPk9wWIm1KcxlRKDBISyJImV+pCvO5jfSREeN+Z2qWreFKESa+ Hp7a1/t2axT3I5BGDOz0S4KgXdXFoYSgoe9RI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=vugmbT1DoLtaZTbnb0ZgNd6dz3+mjjYNM7unQri4wuxmzU7erpq85gAza/WJEg5e1Y xle/ySUJ5VXBYTY2eBKDSgQlXsW0m3UPs0qIVths0li7j8Fqm+lG7tyruyFGzP/R15ms jzZGbzDw1/cDrBzl2vj9oeoqoepXa9TMQw/Rc= Received: by 10.227.207.144 with SMTP id fy16mr6656997wbb.46.1304910458997; Sun, 08 May 2011 20:07:38 -0700 (PDT) Received: from [127.0.0.1] (wsip-98-173-193-12.sb.sd.cox.net [98.173.193.12]) by mx.google.com with ESMTPS id b20sm3470709wbb.33.2011.05.08.20.07.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 20:07:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker X-Priority: 3 In-Reply-To: <77252BEA3E694F5092DA205BE5E691A1@srichardlxp2> Date: Sun, 8 May 2011 20:07:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <866DFCDD-08FA-437D-8DDD-AAB039236A5E@gmail.com> References: <4DB70FDA.6000507@mti-systems.com><4DC2C9D2.8040703@freedesktop.org> <1EA9A6B3-F1D0-435C-8029-43756D53D8FD@gmail.com> <77252BEA3E694F5092DA205BE5E691A1@srichardlxp2> To: Richard Scheffenegger X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 13 May 2011 12:08:23 -0700 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: Mon, 09 May 2011 03:01:32 -0000 On May 8, 2011, at 5:34 AM, Richard Scheffenegger wrote: > Goodput can really only be measured at the sender; by definition, any = retransmitted packet will reduce goodput vs throughput; In your example, = where each segment is retransmitted once, goodput would be - at most - = 0.5, not 1.0... IMHO defining the data volume after the bottleneck by = itself as goodput is also a bit short-sighted, because a good fraction = of that data may still be discarded by TCP for numerous reasons, = ultimately (ie, legacy go-back-n RTO recovery by the sender)... Actually, I didn't say that every packet was retransmitted once. I said = that every dropped packet was retransmitted once. And Goodput will never = exceed the bit rate of the bottleneck in the path, apart from = compression (which in effect applies a multiplier to the bottleneck = bandwidth). > But back to my original question: When looking at modern TCP stacks, = with TSO, if the bufferbloat allows the senders cwnd to grow beyond = thresholds which allow the aggressive use of TSO (64kB or even 256kB of = data allowed in the senders cwnd), the effective sending rate of such a = burst will be wirespeed (no interleaving segments of other sessions). As = pointed out in other mails to this thread, if the bottleneck has then = 1/10th the capacity of the senders wire (and is potentially shared among = multiple senders), at least 90% of all the sent data of such a TSO = segment train will be dropped in a single burst of loss... With proper = AQM, and some (single segment) loss earlier, cwnd may never grow to = trigger TSO in that way, and the goodput (1 segment out of 64kB data, = vs. 58kB out of 64kB data) is obviously shifted extremely to the = scenario with AQM... Again, possibly, but not necessarily. If we have a constrained queue and = are using tail drop, it is possible for a single burst sent to a full = queue to be entirely lost. The question is, in the course of a file = transfer, how many packets are lost. Before you make sweeping = statements, I would strongly suggest that you mock up the situation and = take a tcpdump.