<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>Sure. I am waiting to see the data sheet of that chip.
<div><br>
</div>
<div>Feasibility is of course not a problem. Availability is my problem. HTB is already in asic so no reason why FQ shouldn't. </div>
<div><br>
</div>
<div>DSL is not an issue at all. It works in software. Fiber is my problem. </div>
<div><br>
</div>
<div>BNG maybe in ten years. </div>
<br>
<br>
<div>-------- Message d'origine --------</div>
<div>De : Dave Taht </div>
<div>Date :2015/02/26 18:04 (GMT+01:00) </div>
<div>À : MUSCARIELLO Luca IMT/OLN </div>
<div>Cc : Mikael Abrahamsson , bloat@lists.bufferbloat.net </div>
<div>Objet : Re: [Bloat] RED against bufferbloat </div>
<div><br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Thu, Feb 26, 2015 at 7:18 AM, MUSCARIELLO Luca IMT/OLN<br>
<luca.muscariello@orange.com> wrote:<br>
> On 02/26/2015 03:18 PM, Mikael Abrahamsson wrote:<br>
><br>
> On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:<br>
><br>
> Done with the vendor itself with related NDA etc. It takes longer to set the<br>
> agreement than coding the system. The problem is that this process is not<br>
> ok. An ISP cannot maintain someone else product if it is closed.<br>
><br>
><br>
> Do you have a requirement document that makes sense to the people<br>
> programming these ASICs for vendors? When I try to explain what needs to be<br>
> done I usually run into very frustrating discussions.<br>
><br>
><br>
> I think there are people in this list that should be able to answer to this<br>
> question better than me.<br>
><br>
> AFAIK the process is complex because even vendors use network processors<br>
> they don't build and<br>
> traffic management is developed by the chipco in the chip. Especially for<br>
> the segment we are considering here.<br>
> In the end the dequeue process is always managed by someone else and<br>
> mechanisms and their implementations opaque.<br>
> You can do testing on the equipment and do some reverse engineering. What a<br>
> waste of time...<br>
><br>
> This is why single queue AQM is preferred by vendors, because it does not<br>
> affect current product lines<br>
> and the enqueue is easier to code. FQ requires to recode the dequeue or to<br>
> shadow the hardware dequeue.<br>
<br>
OK, I need to dispel a few misconceptions.<br>
<br>
First, everyone saying that fq_codel can't be done in hardware is<br>
*wrong* See my last point far below, I know I write over-long<br>
emails...<br>
<br>
YES, at the lowest level of the hardware, where packets turn into<br>
light or fuzzy electrons, or need to be tied up in a an aggregate (as<br>
in cable) and shipped onto the wire, you can't do it. BUT, as BQL has<br>
shown, you CAN stick in enough buffering on the final single queue to<br>
*keep the device busy* - which on fiber might be a few us, on cable<br>
modems 2ms - and then do smarter things above that portion of the<br>
device. I am perfectly willing to lose those 2ms when you can cut off<br>
hundreds elsewhere.<br>
<br>
Everybody saying that it cant be done doesnt understand how BQL works.<br>
Demonstrably. On two+ dozen devices. Already. For 3 years now.<br>
<br>
On the higher end than CPE, people that keep whinging about have<br>
thousands of queues are not thinking about it correctly. This is<br>
merely a change in memory access pattern, not anything physical at<br>
all, and the overall reduction in queue lengths lead to much better<br>
cache behavior, and they should, um, at least try this stuff on a<br>
modern intel processor - and just go deploy that. 10GigE was totally<br>
feasible on day one, ongoing work is getting up to 40GigE (but running<br>
into trouble elsewhere on the rx path which jesper can talk to in<br>
painful detail)<br>
<br>
Again, if you do it right, on any architecture, all the smarts happen<br>
long before you hit the wire. You are not - quite - dropping from the<br>
head of the queue, but we never have, and I really don't get why<br>
people don't grok this.<br>
<br>
EVERY benchmark I ever publish can show the intrinsic latency in the<br>
system as hovering around Xms due to the context switch overhead of<br>
the processor and OS - and although I don't mind shaving that figure,<br>
compared to the gains of seconds elsewhere that can come from using<br>
these algorithms - I find getting those down more satisfying.<br>
(admittedly I have spent tons of time trying to shave off a few<br>
hundred us at that level too, as has jonathon and many others in the<br>
linux community)<br>
<br>
I also don't give a hoot about core routers, mostly the edge. I *do<br>
care deeply* about FQ/AQMing interconnects between providers,<br>
particularly in event of a disaster like earthquake or tsunami when<br>
suddenly 2/3s the interconnects get drowned. What will happen in that<br>
case, if an earthquake hit california the same size as the one that<br>
hit japan? It worries me. I live 500 meters from the intersection of<br>
two major fault lines.<br>
<br>
Secondly, I need to clarify a statement above:<br>
<br>
"This is why single queue AQM is preferred by vendors *participating<br>
publicly on the aqm mailing list*, because it does not affect current<br>
product lines, and the enqueue is easier to code. "<br>
<br>
When fq_codel landed, the next morning, I said to myself, "ok, is it<br>
time to walk down sand hill road? We need this in switch chips and<br>
given the two monopolistic vendors left, it is ripe for disruption".<br>
<br>
After wrestling with myself for a few weeks I decided it would be<br>
simpler and easier if I tried to pursuade the chipmakers making packet<br>
co-processing engines (like octeon, intel, tilera) that this algorithm<br>
and htb-like rate control would be a valuable addition to their<br>
products. Note - in *none* of their cases did it have to reduce to<br>
gates, they have a specialized cpu co-processor that struggles to work<br>
at line rate (with features like nat offloads, etc) - with specialized<br>
firmware that they write and hold proprietary, and there were *no*<br>
hardware mods needed - Their struggle at line rate was not the point,<br>
I wanted something that could work at an ISPs set rate, which is very<br>
easy to do...<br>
<br>
I talked to all these chipmakers (and a few more startup-like ones in<br>
particularly the high speed trading market).<br>
<br>
The told me there was no demand. So I went talked to their customers...<br>
<br>
and I am certain that more than one of the companies I have talked to<br>
in the last 3 years is actually doing FQ now, and certain that codel<br>
is also implemented - but I cannot reveal which ones, and for all I<br>
know the ones that are not talking to me (anymore) are off doing. And<br>
at least one of the companies doing it in their packet co-processor,<br>
was getting it wrong, until I straightened 'em out, and for all I know<br>
they didn't listen.<br>
<br>
I figured whichever vendor shipped products first would have a market<br>
advantage, and then everybody else would pile on, and that if I<br>
focused on creating demand for the algorithm (as I did all over the<br>
world, and with ubnt in particular I went to the trouble of<br>
backporting it to their edgerouter personally), demand would be<br>
created for better firmware, from the chipcos and products would<br>
arrive.<br>
<br>
and they have. Every 802.11ac router now has some sort of "better" QoS<br>
system in it. (and of course, openwrt and derivatives). There is a ton<br>
of stuff in the pipeline.<br>
<br>
The streamboost folk were pretty effective in spreading their meme,<br>
but I am mad at them about quite a few things about their<br>
implementation and test regimes, so I'll save what they have done<br>
wrong for another day when I have more venom stored up, and have<br>
acquired stuff I can say publicly about their implementation via a bit<br>
more inspection of their GPL drops and testing the related products.<br>
<br>
...<br>
<br>
"FQ requires to recode the dequeue or to shadow the hardware dequeue."<br>
<br>
Well this statement is not correct.<br>
<br>
*Lastly*: IF you want to reduce things to gates, rather than use a<br>
packet co-processor:<br>
<br>
1) DRR in hardware is entirely doable. How do I know this? - because<br>
it was done for the netfpga.org project *7* years ago. Here is the<br>
project, paper, and *verilog*:<br>
<a href="https://github.com/NetFPGA/netfpga/wiki/DRRNetFPGA">https://github.com/NetFPGA/netfpga/wiki/DRRNetFPGA</a><br>
<br>
It is a single define to synthesize a configurable number of queues,<br>
and it worked on top of the GigE Xilinx virtex-2 pro FPGA, which is<br>
like so low-end now as I am not even sure if they are made anymore.<br>
<a href="http://netfpga.org/2014/#/systems/4netfpga-1g/details/">http://netfpga.org/2014/#/systems/4netfpga-1g/details/</a><br>
<br>
They never got around to writing a five-tuple packet inspector/hasher<br>
but that is straightforward.<br>
<br>
2) Rate management in hardware is entirely doable, also: Here is the<br>
project, paper, and verilog: <a href="https://github.com/gengyl08/SENIC">https://github.com/gengyl08/SENIC</a><br>
<br>
3) I long ago figured out how to make something fq_codel-like work (in<br>
theory) in hardware with enough parallization (and a bit of BQL).<br>
Sticking points were a complete re-org of the ethernet device and<br>
device driver, and a whole lot of Xilinx IP I wanted to dump, and I am<br>
really too busy to do any of the work, but:<br>
<br>
Since I am fed up with the debate, I am backing this kickstarter<br>
project. I have had several discussions with the people doing it -<br>
they are using all the same hardware I chose for my mental design -<br>
and I urge others here to do so.<br>
<br>
<a href="https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking">https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking</a><br>
<br>
I am not entirely broke for a change, and plan to throw in 1k or so.<br>
Need to find 25k from other people for them to make their initial<br>
targets.<br>
<br>
That board meets all the needs for fixing wifi also. They already have<br>
shipping, more complex products that might be more right for the job,<br>
as working out the number of gates needed is something that needs<br>
actual work and simulation.<br>
<br>
But I did like this:<br>
<br>
<a href="https://github.com/MeshSr/wiki/wiki/ONetSwitch45">https://github.com/MeshSr/wiki/wiki/ONetSwitch45</a><br>
<br>
I will write a bit more about this (as negotiations continue) in a<br>
less long, more specialized mail in the coming weeks, and perhaps, as<br>
so often happens around here (I am thinking of renaming this the<br>
"bufferbloat/stone soup project"), some EEs will show up eager to do<br>
something truly new, and amazing, as a summer project. If you got any<br>
spare students, well, go to town.<br>
<br>
I really, really like chisel in particular,<br>
<a href="https://chisel.eecs.berkeley.edu/">https://chisel.eecs.berkeley.edu/</a> and the openrisc folk could use a<br>
better ethernet device.<br>
<br>
> My experience is not based on providing a requirement document, well we<br>
> tried that first,<br>
> but on joint coding with the chipco because you need to see a lot of chip<br>
> internals.<br>
><br>
> _______________________________________________<br>
> Bloat mailing list<br>
> Bloat@lists.bufferbloat.net<br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat">https://lists.bufferbloat.net/listinfo/bloat</a><br>
><br>
<br>
<br>
<br>
-- <br>
Dave Täht<br>
Let's make wifi fast, less jittery and reliable again!<br>
<br>
<a href="https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb">https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb</a><br>
</div>
</span></font>
<PRE>_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
</PRE></body>
</html>