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 1372C201253 for ; Thu, 26 Feb 2015 03:26:30 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8B6F35D8A5F; Thu, 26 Feb 2015 12:26:29 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 823175D8474; Thu, 26 Feb 2015 12:26:29 +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 12:26:28 +0100 Message-ID: <54EF02F0.1050607@orange.com> Date: Thu, 26 Feb 2015 12:26:40 +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: 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> <54EEE0D2.1060606@orange.com> 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 11:26:59 -0000 On 02/26/2015 11:39 AM, Mikael Abrahamsson wrote: > On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote: > >> 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. > > Well, it would help if operators tried to buy CPEs taht were not only > bare-minimum for what they need today. I think the problem is a bit more complex. For what concerns queuing the chipcos do a lot of offloading in silicon. This is an entire industry choice and that silicon is programmable but opaque and not open. If chipcos made that choice there is a reason. > > Right now I hear more about "virtualised CPE" to save cost (ie move > part of the CPE implementation to the data center) than to spend more > money on features in the CPE. That won't solve the problem discussed in this list. I like the approach though. > > My hope is still on the mobile phone SoCs trickling down to the home > gateway space so we get more CPU power there at decent price point. > > Also possibly that the whole SDN movement means hardware will get > standardized APIs so in case there is hardware acceleration on the > CPE, this can be handled by any kernel and not just the kernel that > the vendor has modified to work with their special hardware. I don't how SDN would help for queuing. DPDK, netmap instead would help but we are far from having that kind of support in CPEs.