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 C7ECA21F262 for ; Thu, 26 Feb 2015 07:18:00 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EC2BA5D8A7D; Thu, 26 Feb 2015 16:17:58 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id E500D5D8A7A; Thu, 26 Feb 2015 16:17:58 +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 16:17:58 +0100 Message-ID: <54EF3932.6020007@orange.com> Date: Thu, 26 Feb 2015 16:18:10 +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> <1D438EDC-358D-4DD5-9B8D-89182256F66C@gmx.de> <54EDD951.50904@orange.com> <54EE07C0.60703@orange.com> <54EF2877.8030302@orange.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050800010704070503000702" 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 15:18:30 -0000 --------------050800010704070503000702 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 02/26/2015 03:18 PM, Mikael Abrahamsson wrote: > On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote: > >> Done with the vendor itself with related NDA etc. It takes longer to >> set the agreement than coding the system. The problem is that this >> process is not ok. An ISP cannot maintain someone else product if it >> is closed. > > Do you have a requirement document that makes sense to the people > programming these ASICs for vendors? When I try to explain what needs > to be done I usually run into very frustrating discussions. > I think there are people in this list that should be able to answer to this question better than me. AFAIK the process is complex because even vendors use network processors they don't build and traffic management is developed by the chipco in the chip. Especially for the segment we are considering here. In the end the dequeue process is always managed by someone else and mechanisms and their implementations opaque. You can do testing on the equipment and do some reverse engineering. What a waste of time... This is why single queue AQM is preferred by vendors, because it does not affect current product lines and the enqueue is easier to code. FQ requires to recode the dequeue or to shadow the hardware dequeue. My experience is not based on providing a requirement document, well we tried that first, but on joint coding with the chipco because you need to see a lot of chip internals. --------------050800010704070503000702 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 02/26/2015 03:18 PM, Mikael Abrahamsson wrote:
On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:

Done with the vendor itself with related NDA etc. It takes longer to set the agreement than coding the system. The problem is that this process is not ok. An ISP cannot maintain someone else product if it is closed.

Do you have a requirement document that makes sense to the people programming these ASICs for vendors? When I try to explain what needs to be done I usually run into very frustrating discussions.


I think there are people in this list that should be able to answer to this question better than me.

AFAIK the process is complex because even vendors use network processors they don't build and
traffic management is developed by the chipco in the chip. Especially for the segment we are considering here.
In the end the dequeue process is always managed  by someone else and mechanisms and their implementations opaque.
You can do testing on the equipment and do some reverse engineering. What a waste of time...

This is why single queue AQM is preferred by vendors, because it does not affect current product lines
and the enqueue is easier to code. FQ requires to recode the dequeue or to shadow the hardware dequeue.

My experience is not based on providing a requirement document, well we tried that first,
but on joint coding with the chipco because you need to see a lot of chip internals.
 --------------050800010704070503000702--