From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by huchra.bufferbloat.net (Postfix) with ESMTP id 3890A21F262 for ; Thu, 26 Feb 2015 01:00:55 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C91335D8A79; Thu, 26 Feb 2015 10:00:54 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id C1B785D8604; Thu, 26 Feb 2015 10:00:54 +0100 (CET) Received: from [172.31.0.14] (10.193.116.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Thu, 26 Feb 2015 10:00:54 +0100 Message-ID: <54EEE0D2.1060606@orange.com> Date: Thu, 26 Feb 2015 10:01:06 +0100 From: MUSCARIELLO Luca IMT/OLN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Bill Ver Steeg (versteb)" , =?ISO-8859-1?Q?Toke_?= =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , 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> <87pp8yfe0s.fsf@toke.dk> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 Reply-To: MUSCARIELLO Luca IMT/OLN List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 09:01:25 -0000 On 02/25/2015 07:39 PM, Bill Ver Steeg (versteb) wrote: > Regarding the statement >> 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. > There are two points under the covers here. I would say a 2 more accurate statements would be - > > 1- "We are unlikely to see any AQM scheme that includes many queues in a core 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. I agree and at the same time it is not the core the segment where this would be useful. If we have the same understanding of core. > 2- "There are several AQMs under consideration for use in a core router. There 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 de-queue time, but that is simply not how the current designs operate. I am not familiar with CMTS, but I guess it is not much larger than an OLT. I do not know the maximum rates neither in cable modems but these equipments might be incapable to guarantee very high rates and proper QoS when dealing with 1Gbps to the customer. If the target is up to 100Mbps the story is different but honestly at this rate this can be done in software today for such a small fanout. I wonder when we'll have software routers in residential networks to innovate a little faster than what happens today just like how already happens in some data centers.