<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/26/2015 03:18 PM, Mikael
Abrahamsson wrote:<br>
</div>
<blockquote
cite="mid:alpine.DEB.2.02.1502261517230.4007@uplift.swm.pp.se"
type="cite">On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
<br>
</blockquote>
<br>
<font size="-1">I think there are people in this list that should be
able to answer to this question better than me. <br>
<br>
AFAIK the process is complex because even vendors use network
processors they don't build and <br>
traffic management is developed by the chipco in the chip.
Especially for the segment we are considering here.<br>
In the end the dequeue process is always managed by someone else
and mechanisms and their implementations opaque. <br>
You can do testing on the equipment and do some reverse
engineering. What a waste of time...<br>
<br>
This is why single queue AQM is preferred by vendors, because it
does not affect current product lines<br>
and the enqueue is easier to code. FQ requires to recode the
dequeue or to shadow the hardware dequeue.<br>
<br>
My experience is not based on providing a requirement document,
well we tried that first, <br>
but on joint coding with the chipco because you need to see a lot
of chip internals.<br>
</font>
</body>
</html>