From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-31-ewr.dyndns.com (mxout-096-ewr.mailhop.org [216.146.33.96]) by lists.bufferbloat.net (Postfix) with ESMTP id 1DAAA2E015C for ; Fri, 11 Mar 2011 10:01:04 -0800 (PST) Received: from scan-32-ewr.mailhop.org (scan-32-ewr.local [10.0.141.238]) by mail-31-ewr.dyndns.com (Postfix) with ESMTP id 66B3E6FAEB0 for ; Fri, 11 Mar 2011 18:01:04 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.215.171 Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) by mail-31-ewr.dyndns.com (Postfix) with ESMTP id 528886FA86C for ; Fri, 11 Mar 2011 18:00:59 +0000 (UTC) Received: by eydd26 with SMTP id d26so1177157eyd.16 for ; Fri, 11 Mar 2011 10:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=W/MEBFGNLxo/EX0CN2uQRsLYtHmzIN+Teca46tGUtHQ=; b=o2Tv/37tosXAcfEmlXJyt57eIaAzrD5AXwPcd4fStNr0vk1UQmQ1hbjaul+KfW0E20 fbdXPW4vX4aamzzXGAer6sGQULd+bnGUEERVfM3fV8Fn/aXQkCt73grWqwuaRHKD5BaO LHLUmrKzwCBjMpKx3tWrl5cgANS8g5ZjQhjOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gc4t9vOH4f6T8y9roirXVLnaHX53NXJx+ClaV06DdbjquX0X9fLO4h86fghoybVGlC LZ2nbH3z/dlqK6iO/bOJ/QitZqlYm62u7ogKYX4cIfv0y/Z5wwliQxffkLX4QWTquL4B uv2A6U3pXDKZ1FuKc8baMYP7jBjSZ2WqBEPZ0= Received: by 10.213.26.148 with SMTP id e20mr198865ebc.17.1299866458663; Fri, 11 Mar 2011 10:00:58 -0800 (PST) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id b52sm3676144eei.7.2011.03.11.10.00.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2011 10:00:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <20110311092157.23dea5e8@nehalam> Date: Fri, 11 Mar 2011 20:00:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6210AF7E-3EB3-4199-A87B-A54B0F73A106@gmail.com> <20110311092157.23dea5e8@nehalam> To: Stephen Hemminger X-Mailer: Apple Mail (2.1082) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Taxonomy of various sender-side TCPs 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, 11 Mar 2011 18:01:05 -0000 On 11 Mar, 2011, at 7:21 pm, Stephen Hemminger wrote: >> 2: Illinois, Compound > (Add in Yeah, Veno, and TCP-NV ) >> Strategy: Fill the pipe quickly, then probe the buffer slowly to = avoid being outcompeted. I separated Veno to put it with Westwood, because there is almost no = difference between Veno and Westwood, and they do not advance more = rapidly than Reno in the uncongested regime. I consider those two more = aggressive than Reno only because they back off less if they believe the = link is not congested, and that belief has a chance of being incorrect. Meanwhile I considered Illinois and Compound to be less aggressive than = Reno because they explicitly advance less rapidly in the congested = regime, and back off at least as effectively as Reno does (well, the = Linux implementation of Compound - it seems M$ screwed up their = version). I haven't read up on Yeah and NV (or TCP-fit) yet, so I can't classify = them. I'm also aware that a number of other aggressive TCPs designed = for LFN throughput exist, but I can't be bothered enumerating them = because they are useless - obsoleted by CUBIC in their intended = application, and too aggressive for the wider Internet. I do agree that TCPs which attempt to probe for minRTT have a weakness = in this area, and Vegas is particularly weak because it relies very = heavily on minRTT and is also very timid. If the whole Internet used = Vegas this wouldn't be a problem, but it gets outcompeted badly by = literally everything else, especially the extra-aggressive TCPs like = CUBIC. So simply changing the send-side TCP congestion algorithm is = insufficient to solve the whole problem, though some classes of users = are seeing benefits from using Vegas despite it's flaws. - Jonathan