From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-33-ewr.dyndns.com (mxout-053-ewr.mailhop.org [216.146.33.53]) by lists.bufferbloat.net (Postfix) with ESMTP id EAB942E00B9 for ; Thu, 17 Mar 2011 10:27:35 -0700 (PDT) Received: from scan-32-ewr.mailhop.org (scan-32-ewr.local [10.0.141.238]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id 3A74D6F6A53 for ; Thu, 17 Mar 2011 17:27:35 +0000 (UTC) X-Spam-Score: 0.1 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 75.145.127.229 Received: from gw.co.teklibre.org (75-145-127-229-Colorado.hfc.comcastbusiness.net [75.145.127.229]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id 4D82A6F691F for ; Thu, 17 Mar 2011 17:27:31 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:1::20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cruithne.co.teklibre.org", Issuer "CA Cert Signing Authority" (verified OK)) by gw.co.teklibre.org (Postfix) with ESMTPS id AB4785EA3C for ; Thu, 17 Mar 2011 11:27:30 -0600 (MDT) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id A7DE212086D; Thu, 17 Mar 2011 11:27:29 -0600 (MDT) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Fred Baker Organization: Teklibre - http://www.teklibre.com References: <4D7F4121.40307@freedesktop.org> <20110315175942.GA10064@goldfish> <1300212877.2087.2155.camel@tardy> <20110315183111.GB2542@tuxdriver.com> <29B06777-CC5F-4802-8727-B04F58CDA9E3@gmail.com> <20110315205146.GF2542@tuxdriver.com> <219C7840-ED79-49EA-929D-96C5A6200401@gmail.com> <20110315151946.31e86b46@nehalam> <1300228592.2087.2191.camel@tardy> <1300229578.2565.29.camel@edumazet-laptop> <87fwqo54n7.fsf@cruithne.co.teklibre.org> <823E2A7B-4F46-4159-8029-BD3B075CC4CE@gmail.com> <87bp1b6fo0.fsf@cruithne.co.teklibre.org> <87bp1b4yh4.fsf@cruithne.co.teklibre.org> <35010A85-C5A4-4133-8707-4E114C65A8C6@gmail.com> <3F2F5E9B-C710-4C2F-AF99-CDF7C314A50A@cisco.com> Date: Thu, 17 Mar 2011 11:27:29 -0600 In-Reply-To: (Fred Baker's message of "Thu, 17 Mar 2011 05:18:39 -0700") Message-ID: <87pqppirni.fsf@cruithne.co.teklibre.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stephen Hemminger , bloat Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps? 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: Thu, 17 Mar 2011 17:27:36 -0000 Fred Baker writes: > On Mar 17, 2011, at 5:05 AM, Fred Baker wrote: > >> I'm very much in favor of ECN, which in all of the tests I have done has proven very effective at limiting queues to the knee. I'm also in favor of delay-based TCPs like CalTech FAST and the Hamilton and CAIA models; FAST tunes to having a small amount of data continuously in queue at the bottleneck, and Hamilton/CAIA tunes to a small bottleneck. The problem tends to be that the "TCP Mafia" - poorly named, but a smallish set of people who actually control widely-used TCP implementations - tend to very much believe in the loss-based model, in part because of poor performance from past delay-based implementations like Vegas and in part due to IPR concerns. Also, commercial interests like Google are pushing very hard for fast delivery of content, which is what is behind Linux' recent change to set the initial window segments. > > I didn't say, and should have said: I'm also in favor of AQM in any form; I prefer marking to dropping, but both are signals to the end system. The issue is that we need the right mark/drop rate, and the algorithms are neither trivial nor (if the fact that after 20+ years Van and Kathy haven't yet published a red-lite paper they're happy with is any indication) well documented in the general case. A mea culpa from a former ASIC designer, which discusses the relationship between propagation delay, burstiness, and the real need for something like RED, and why ASIC designers didn't make it more of a priority. "Our biggest mistake was in making queue management optional, and making it scary." Really well explained, with good diagrams, too. http://codingrelic.geekhold.com/2011/03/random-early-mea-culpa.html -- Dave Taht http://nex-6.taht.net