From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-32-ewr.dyndns.com (mxout-119-ewr.mailhop.org [216.146.33.119]) by lists.bufferbloat.net (Postfix) with ESMTP id 634502E00B9 for ; Thu, 17 Mar 2011 05:05:59 -0700 (PDT) Received: from scan-32-ewr.mailhop.org (scan-32-ewr.local [10.0.141.238]) by mail-32-ewr.dyndns.com (Postfix) with ESMTP id A956C6F92D8 for ; Thu, 17 Mar 2011 12:05:58 +0000 (UTC) X-Spam-Score: -15.5 (---------------) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 171.71.176.117 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mail-32-ewr.dyndns.com (Postfix) with ESMTP id 5163A6F8CFA for ; Thu, 17 Mar 2011 12:05:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3005; q=dns/txt; s=iport; t=1300363554; x=1301573154; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=IB4rEL1lbisTzaxARzrdurJNOj2ZijNOj5NKmhzQs/E=; b=h4dMJG6esFUosoHEUyg1JwTJIeMY0T9YeTiSvff7LubopnHmVTHHazpG QvvF+sO9enhXL5oii2Ho0ogrqjacprx9NjxOrWdbjWIbtsA3I5oiB0ca9 UFJkOX9no9fswMeeuO88KfqjufHUx5WnXGI/zEABniq4+lyKSs/qurUzj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI+VgU2tJV2c/2dsb2JhbAClTneoJJwuhWMEhS+HL4NN X-IronPort-AV: E=Sophos;i="4.63,198,1299456000"; d="scan'208";a="668053604" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-6.cisco.com with ESMTP; 17 Mar 2011 12:05:52 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2HC5j9j011563; Thu, 17 Mar 2011 12:05:50 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 17 Mar 2011 05:05:51 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 17 Mar 2011 05:05:51 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker X-Priority: 3 In-Reply-To: Date: Thu, 17 Mar 2011 05:05:35 -0700 Message-Id: <3F2F5E9B-C710-4C2F-AF99-CDF7C314A50A@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> 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: Thu, 17 Mar 2011 12:05:59 -0000 On Mar 16, 2011, at 3:22 PM, Richard Scheffenegger wrote: > Heretical question: Why must the congestion notification implemented = as a (distributed) function of the network itself, and take the reaction = of the end hosts into consideration. If the signaling would only = indicate the local congestion state, but then move the reaction to that = into the end hosts, i think the design would be much more simple. >=20 > If the network would let the (reactive) senders know the extent of the = current congestion, the end hosts can use more smarts and react to it = properly. That's not heretical at all. You might be interested to look at Dina = Katabi's XCP and Nandita Dukipati's RCP. Both work from the assumption = that if a smallish information element is added to the network layer = header by the transport and updated by routers en route, the end systems = can calculate the correct window value and simply set it. Work on these = protocols was done at MIT, USC/ISI, and Stanford over the past decade. The problem is that it might have worked reasonably well in the 1990 = Internet (although the "everything runs on IP" model didn't quite work = there either), but doesn't reflect today's network. Think about various = forms of tunnels (IP/IP, GRE, L2TP, ...), encrypted tunnel-mode VPNs = such as the one I use every day to go to work, MPLS LSPs, Ethernet = switches and especially Metropolitan Ethernet, and the today's broadband = networks. In terms of modeling the network, the "Network of Networks" = model is actually a pretty good one: IP tells the network *what* needs = to be done, but the network then uses a vast array of underlying = technologies to accomplish it. So saying "no problem, let the network = update the IP header..." - the places that need to do so often can't see = or can't change the IP header. 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 There is also a needed educational effort. My company is unlikely to = turn AQM or ECN on by default because we don't have customers asking us = to do so, and my company's customers tend to think that loss is an = indication of errors in the network. =20=