From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 6E4F221F1FC for ; Wed, 25 Feb 2015 08:09:18 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B38F1A3; Wed, 25 Feb 2015 17:09:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424880554; bh=fksg/RTB34NYS5F1YNeCrSEHxtyXp6qsahE2m77xrlY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ZQzwJSj3DGZOX4z2sjmQqJe6WR4hZGn+Lf9/ORCph8/GQCp+PR23Q6CBWCCGoGmG7 gHU5Cpp7EFkat8hnTq87o7k6Ct7mJrT81j+a4t7z96oWYwi5HCFscTFPAlfK5GZqfV zcf/Qr6Y4y8TY97af2RXQkjWWjEz+2WG+pEEpHgk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AC27DA2; Wed, 25 Feb 2015 17:09:14 +0100 (CET) Date: Wed, 25 Feb 2015 17:09:14 +0100 (CET) From: Mikael Abrahamsson To: MUSCARIELLO Luca IMT/OLN In-Reply-To: <54EDD951.50904@orange.com> 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> <54EDD951.50904@orange.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 16:09:48 -0000 On Wed, 25 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote: > Doing FQ in silicon is easy. It must be very easy as I did myself in a > MIPS Ikanos Vx185 chipset and I am not an hardware expert. This was for > a CPE with a 5X1Gbps ports. I guess we have different definitions on what "silicon" is. Mine is "ASIC". If it has a MIPS CPU (and the CPU does forwarding), then it's not "silicon", then it's done in CPU. I keep hearing from vendors that queues are expensive. The smallest FQ implementation that seems to be reasonable has 32 queues. Let's say we have 5k customers per port on a BNG, that equates to 160k queues. Compare that to an efficient active ethernet p-t-p ETTH deployment without BNG at all, where the access L2 switch is the one doing policing. What would be the cost to equip this device with FQ per port? > If you go a little deeper in the network and you pick an OLT you won't I don't do PON. > find much intelligence. A little deeper and in a local aggregation > router (all vendors) you'll find what you would need to implement FQ. A If it's a BNG yes. These linecards with hundreds of thousands of queues are a lot more expensive than a linecard without these queues. Usually today there are 3-4 queues per customer, now we want to expand this to 32 or more. What is the cost increase for this? If you put a BNG in there with lots of intelligence then the cost of adding the FQ machinery might not be too bad. If you don't have the BNG at all, what is the cost then? I still believe it will be cheaper to try to do this in the CPE. > Some "positive" view: access with Gbps (up to 1Gbps) with a range of RTT > (1ms to 100ms) will need smarter mechanisms in the equipment as > inefficiencies will be crystal clear and business consequences will be > substantially different. Please elaborate. I'd say FIFO is less harmful at these speeds because of TCP inefficiencies meaning most end systems won't come up in high enough transfer rates to saturate that part of the network. Now the bottle neck will move elsewhere. -- Mikael Abrahamsson email: swmike@swm.pp.se