From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-01-iad.dyndns.com (mxout-101-iad.mailhop.org [216.146.32.101]) by lists.bufferbloat.net (Postfix) with ESMTP id B2B462E0923 for ; Fri, 18 Mar 2011 11:49:51 -0700 (PDT) Received: from scan-01-iad.mailhop.org (scan-01-iad.local [10.150.0.206]) by mail-01-iad.dyndns.com (Postfix) with ESMTP id 40AAE6D885 for ; Fri, 18 Mar 2011 18:49:52 +0000 (UTC) X-Spam-Score: -8.0 (-------) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 171.68.10.86 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail-01-iad.dyndns.com (Postfix) with ESMTP id B67796D872 for ; Fri, 18 Mar 2011 18:49:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3017; q=dns/txt; s=iport; t=1300474190; x=1301683790; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=RUbuVzMRtqgrQF5or+kJU3H9a2LSyoQu+lmLPApVDjA=; b=eLjiK5VgZysTPpEiw8s/FpPzyAAwDpUuFl0foJ3MEy9OS4d48kvw2tAR zKkjats7gyicZNJIPFBtIz6CsTetgMFQw1Rr68BRp2Iu2uvBKJT3GB1gX qTZPUjxssUZk5mJ8XqVZ5tvB4TnK1Mhn5CiA0rWyPhfLR8Ga21Lo8EBNj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkBAAVGg02tJXG//2dsb2JhbACYOo04d4hNniacF4VjBIUxhhSBHoNP X-IronPort-AV: E=Sophos;i="4.63,206,1299456000"; d="scan'208";a="277746698" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-4.cisco.com with ESMTP; 18 Mar 2011 18:49:49 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2IIniOP027438; Fri, 18 Mar 2011 18:49:48 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Fri, 18 Mar 2011 11:49:49 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Fri, 18 Mar 2011 11:49:49 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker X-Priority: 3 In-Reply-To: Date: Fri, 18 Mar 2011 11:49:35 -0700 Message-Id: <7480559F-1F3B-4CE5-939F-FD9FD3E68E52@cisco.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> To: "Richard Scheffenegger" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: Fri, 18 Mar 2011 18:49:52 -0000 On Mar 18, 2011, at 11:30 AM, Richard Scheffenegger wrote: >=20 > How about trying to push for a default, that the logical egress = buffers are limited to say 90% of the physical capacity, and only = ECN-enabled flows may use the remaining 10% when they get marked... Lots of questions in that; 90% of the buffers in what? In a host, in a = router, on a card in a router, in a queue's configured maximum depth, = what? One would need some pedagogic support in the form of simulations - = why 90% vs 91% vs 10% vs whatever? > Someone has to set an incentive for using ECN, unfortunately... Yes. =46rom my perspective, the right approach is probably more like = introducing a mark/drop threshold and a drop threshold. Taking the model = that every M time units we "do something" like if queue depth exceeds reduce M drop something else if queue depth exceeds reduce M select something if it is ECN-capable,=20 mark it congestion-experienced else drop it else is below increase M the advantage of ECN traffic is that it is less likely to be dropped. = That might be a reasonable approach. > Richard >=20 > ----- Original Message ----- From: "Fred Baker" > To: "Richard Scheffenegger" > Cc: "Stephen Hemminger" ; "bloat" = > Sent: Thursday, March 17, 2011 1:18 PM > Subject: Re: [Bloat] Random idea in reaction to all the discussion of = TCPflavours - timestamps? >=20 >=20 >=20 > On Mar 17, 2011, at 5:05 AM, Fred Baker wrote: >=20 >> 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. >=20 > 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.=3D=20