From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "alln-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id AB1DE21F324 for ; Wed, 25 Feb 2015 10:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4347; q=dns/txt; s=iport; t=1424889571; x=1426099171; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AQySsox5nY4gvK1HYDobSeaoF6/FUmKrpG6n5mNGbT8=; b=bxPUUoNXfcrzvK7OmiNUn57trlAFl1DVjI+WcDdiSVQ7msveK65SVMPw 3zFCrMa34fOkBT2sPvsPtuNn7GQfOPM6Yk7Ckno0UnNk6F3z4Ra2fL/eq OuVbbZFd4joGlVVwf9caj/9ZlIVvXvfUjmT6LM1jORBljeioLw4z3yFgP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B0BQDjFe5U/5ldJa1bgwJSWgTBXoE8CoVwAoEoOBQBAQEBAQEBfIQPAQEBAwEBAQFrCwUHBAIBCBEEAQELHQcnAQoUCQgCBAENBQgSBIgJCA3WGgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEihV+hD0xBwaDEYEUBYoghTyDYINGlV0jggEBBReBUG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,646,1418083200"; d="scan'208";a="126825911" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 25 Feb 2015 18:39:01 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1PId21x028399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 18:39:02 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.172]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 12:39:01 -0600 From: "Bill Ver Steeg (versteb)" To: =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= , "Mikael Abrahamsson" Thread-Topic: [Bloat] RED against bufferbloat Thread-Index: AQHQUOrWou8yN6f/akWDRV/hth0HI50Brh+w Date: Wed, 25 Feb 2015 18:39:01 +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> <87pp8yfe0s.fsf@toke.dk> In-Reply-To: <87pp8yfe0s.fsf@toke.dk> 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:39:32 -0000 Regarding the statement > We're not going to see FQ_CODEL on a 200 interface large router=20 > designed to push 100 gigabit/s of traffic, at least not in any=20 > interesting price point. There are two points under the covers here. I would say a 2 more accurate s= tatements would be - 1- "We are unlikely to see any AQM scheme that includes many queues in a co= re router." This includes FQ_CODEL, FQ_PIE, and any other scheme that uses = a statistical hashing of flows into a large number of queues. The required = silicon to support so many queues is simply too expensive. There may be new= silicon designs that make this more feasible, but this is non-trivial. 2- "There are several AQMs under consideration for use in a core router. Th= ere are advantages to at enqueue time rather than dequeue time= , and this may drive some designs." In other words, AQM algorithms that are= similar to PIE are likely to be in large aggregation devices (like a CMTS)= and core routers. You could probably design new silicon that did work at d= e-queue time, but that is simply not how the current designs operate.=20 The good news is that as we debate the relative merits of the new AQM schem= es, they are all MUCH better than the legacy algorithms. Putting FQ_XXX (wh= ere XXX=3D=3D CODEL today, and perhaps other algorithms in the future) into= devices that do queue management in software is a big win. Putting CODEL/P= IE (using a handful of QOS mapped queues, using microcode running on curren= t generation silicon) into the big iron is also a big win. So, let's get modern AQM pushed into all of the devices. One design will no= t fit all devices........ 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 Toke H=F8iland-J=F8rgensen Sent: Wednesday, February 25, 2015 6:05 AM To: Mikael Abrahamsson Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] RED against bufferbloat Mikael Abrahamsson writes: > To me, FQ is important especially for lower speeds. This also maps=20 > well into the CPU based nature of FQ (that it's hard to do in=20 > "silicon"). Well my research has been mainly focused on the consumer / edge case. I.e. things a Linux box can drive in hardware, so up to 100Mbit to a Gbit d= epending on the size of the box. In these cases, fq_codel adds no measurabl= e overhead compared to the CPU load of just pushing the packets. > We're not going to see FQ_CODEL on a 200 interface large router=20 > designed to push 100 gigabit/s of traffic, at least not in any=20 > interesting price point. Maybe not; but note that recent work in the Linux kernel makes it quite cap= able of pushing 40GigE, and I believe sched_fq (which does 'real' fairness queueing with a queue per flow, not hash buckets as fq_codel does) has been shown to scale to millions of concurrent flows. > Can we do bidirectional traffic FQ_CODEL on the CPE to try to achieve=20 > basically zero loss in the AR policer for any normal kind of use=20 > scenario using TCP. I have not seen any simulations looking at this. Well this is basically what we're doing with the SQM scripts in CeroWRT: put a software rate limiter in the CPE and configure it to a slightly lower= value than whatever the cable/DSL modem runs at. This works quite well, bu= t the software rate limiter is fairly CPU hungry, so small boxes struggle. = I had to substitute a full x86 box for my Netgear router to run at 100Mbit = for my home connection. > Because my belief is that even though we might say we love FQ here,=20 > we're not going to see high speed FQ on higher end ISP aggregation=20 > routers. So if we want FQ, we're going to have to do it in the CPEs. Well OpenWRT turns on fq_codel by default now. :) And yeah, I'm not holding by breath for big iron vendors to include fq_code= l in their products. But that doesn't mean it can't go into CPEs. And end hosts and access points. And inside tunnels (VPN daemons for instan= ce). -Toke _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat