From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2E5FB21F2AC for ; Wed, 25 Feb 2015 03:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk Sender: toke@toke.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1424862276; bh=Lv+UvWc01Dy5nrc7iH0WlDY57KWSSGiVo3E14j9CEoA=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=FBRnmmZ+0PL3ULaXD2A5C4QOrQxw49o4xyfGF1i63ycx83pwIpm2VcdmGs0Ds8Q6g hJ2oWwfxmWTUV7Nr4RP/CEBq8a4i3Okq/Ot7Crc7XQnbA7lBdJis4g85c0f5DObXmo g2n8KcDF2OnZ/R0d1HpKW/mzpvVvsfJkh/jlx2kE= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id CE5973E35DF; Wed, 25 Feb 2015 12:04:35 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Mikael Abrahamsson 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> Date: Wed, 25 Feb 2015 12:04:35 +0100 In-Reply-To: (Mikael Abrahamsson's message of "Wed, 25 Feb 2015 11:47:53 +0100 (CET)") Message-ID: <87pp8yfe0s.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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 11:05:13 -0000 Mikael Abrahamsson writes: > To me, FQ is important especially for lower speeds. This also maps > well into the CPU based nature of FQ (that it's hard to do in > "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 depending on the size of the box. In these cases, fq_codel adds no measurable 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 > designed to push 100 gigabit/s of traffic, at least not in any > interesting price point. Maybe not; but note that recent work in the Linux kernel makes it quite capable 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 > basically zero loss in the AR policer for any normal kind of use > 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, but 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, > we're not going to see high speed FQ on higher end ISP aggregation > 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_codel 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 instance). -Toke