From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from deliverator5.gatech.edu (deliverator5.gatech.edu [130.207.165.165]) by huchra.bufferbloat.net (Postfix) with ESMTP id E6FCB201A3A for ; Sat, 7 May 2011 19:58:53 -0700 (PDT) Received: from deliverator5.gatech.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4D3AE18267E; Sat, 7 May 2011 23:04:34 -0400 (EDT) Received: from mail3.gatech.edu (mail3.gatech.edu [130.207.185.163]) by deliverator5.gatech.edu (Postfix) with ESMTP id BC664180108; Sat, 7 May 2011 23:04:33 -0400 (EDT) Received: from [192.168.1.1] (adsl-98-66-183-182.asm.bellsouth.net [98.66.183.182]) (Authenticated sender: kd108) by mail3.gatech.edu (Postfix) with ESMTPSA id 98DB0149281; Sat, 7 May 2011 23:04:33 -0400 (EDT) Message-ID: <4DC6083F.1080105@cc.gatech.edu> Date: Sat, 07 May 2011 23:04:31 -0400 From: Constantine Dovrolis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Hemminger References: <4DB70FDA.6000507@mti-systems.com> <4DC2C9D2.8040703@freedesktop.org> <1EA9A6B3-F1D0-435C-8029-43756D53D8FD@gmail.com> <1304694852.29492.16.camel@amd.pacdat.net> <20110506151003.2d2a4af3@nehalam> <20110507171555.240f9f8f@nehalam> In-Reply-To: <20110507171555.240f9f8f@nehalam> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Sun, 08 May 2011 02:58:54 -0000 Hi, I suggest you look at the following paper for a more general version of this formula (equation 3), which includes the effect of limited capacity and/or limited receive-window: http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/Papers/f235-he.pdf The paper also discusses common mistakes when this formula is used to predict the throughput of a TCP connection - the basic idea is that we cannot use the loss rate *before* the start of a TCP connection to predict what its throughput will be. A large TCP connection that is not limited by its receive-window can of course cause an increase in the loss rate of the path that it traverses (see sections 3.2 - 3.4) regards Constantine On 5/7/2011 8:15 PM, Stephen Hemminger wrote: > On Sat, 7 May 2011 19:39:22 +0300 > Jonathan Morton wrote: > >> >> On 7 May, 2011, at 1:10 am, Stephen Hemminger wrote: >> >>> 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. >> >> So if the loss rate is 1.0 (100%), the throughput is MSS/RTT. If the loss rate is 0, the throughput goes to infinity. That doesn't seem right to me. > > If loss rate is 0 there is no upper bound on TCP due to loss. > There are other limits on TCP throughput like window size but not limits > because of loss. > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Constantine -------------------------------------------------------------- Constantine Dovrolis, Associate Professor College of Computing, Georgia Institute of Technology 3346 KACB, 404-385-4205, dovrolis@cc.gatech.edu http://www.cc.gatech.edu/~dovrolis/