From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "rcdn-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9E12221F226 for ; Wed, 25 Feb 2015 10:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2743; q=dns/txt; s=iport; t=1424890305; x=1426099905; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fRG0apstDLFuq+TcPiiqBO/Qamp62BJSW2h9pNyNE/M=; b=V3fZcvrWqP0bvi8bHjNFsBS51ihDhX2toRC0PyzY21ap3lrxkSLH7H2x 5Tpv/Zv0+dXheM31p9m2snvYhYWaJxq43JWxxfQog41aKlvWUxxpvx/6G skAWTZ8kKS9YNC9R9XS5elIjdtNnscwIDvSz6TaEqqHmKzGdR8JhvKpjK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BVBQCqaeJU/5tdJa1bgwZSWgTCMoV7AoEYQwEBAQEBAXyEDAEBAQMBAQIkUgUHBAIBCA4DBAEBCx0HKAoUCQgCBAENBQgTiAoIzjUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiwyECxEBHzEHBoMQgRQBBIVbhDGFLIVqgS6DN443gz4ig25vgQs5fwEBAQ X-IronPort-AV: E=Sophos;i="5.09,646,1418083200"; d="scan'208";a="398894869" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 25 Feb 2015 18:51:16 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1PIpGgM020018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 18:51:16 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.172]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 12:51:16 -0600 From: "Bill Ver Steeg (versteb)" To: Mikael Abrahamsson , =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= Thread-Topic: [Bloat] RED against bufferbloat Thread-Index: AQHQUQBkou8yN6f/akWDRV/hth0HI50BytcA///oLRA= Date: Wed, 25 Feb 2015 18:51:15 +0000 Message-ID: References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> <4A80D1F9-F4A1-4D14-AC75-958C5A2E8168@gmx.de> <3F47B274-B0E4-44F2-A434-E3C9F7D5D041@ifi.uio.no> <87twyaffv3.fsf@toke.dk> <1D438EDC-358D-4DD5-9B8D-89182256F66C@gmx.de> <871tleqff6.fsf@toke.dk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.75.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] RED against 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: Wed, 25 Feb 2015 18:51:46 -0000 I have seen some (to date unpublished) studies that show a ~5% "guard band"= below the link rate can be enough to provide both good performance and blo= at resistance. Take that with a grain of salt, though. The real-world problem is that the anti-bloat proxy does not really know th= e bottleneck link rate. At 2 in the morning on an SP network (aka HFC, DSL = or FTTx) , you are quite likely to get your SLA rate. At 7PM on a Friday af= ternoon, the link rate will probably be degraded. If you shape to the SLA r= ate when the network is busy, you are very likely to not have the desired b= ehavior. Throw in some "turbo boost" (where the network operator allows a large spik= e of traffic if the subscriber has been idle for a while) and the problem g= ets even harder. Turbo boost has very favorable benefits for bursty HTTP br= owsing traffic, and you do not want to miss out on that benefit by having a= bump-in-the-wire doing rate shaping. IMHO, the correct answer is to run a modern AQM algorithm (take your pick, = they are all better than tail drop) on all devices. If the bottleneck link = has a variable link speed, it is in a position to manage the buffer effecti= vely. Until we get to that point, there may be some benefit in proxy solut= ions, but there are dragons here. Bill Ver Steeg DISTINGUISHED ENGINEER=20 versteb@cisco.com -----Original Message----- From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.buffe= rbloat.net] On Behalf Of Mikael Abrahamsson Sent: Wednesday, February 25, 2015 9:06 AM To: Toke H=F8iland-J=F8rgensen Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] RED against bufferbloat On Wed, 25 Feb 2015, Toke H=F8iland-J=F8rgensen wrote: > So you mean comparing the scenario where the AQM runs on both sides of=20 > the bottleneck to one where it runs as an ingress shaper on one side=20 > only? Yes. How much lower speed/rate would the CPE ingress (internet->CPE) AQM ha= ve to run at to have a reasonable low probability of traffic being delayed = by that shaper (or dropped by the policer). I realise this would be different depending on speed of the access, but som= e data points would be interesting. For instance, some ISPs I've heard will have a policer and 2 seconds worth = of burst, before they drop packets. Some others might have lower burst valu= es. Some will have a pretty decent FIFO shaper. There are some different sc= enarios, how much lower speed do I need to run my AQM at in order to try to= avoid this policer or shaper to affect my traffic? Gut feeling would be 10= -20% should be enough, but I don't know. --=20 Mikael Abrahamsson email: swmike@swm.pp.se