<div dir="ltr"><div dir="ltr">We've had this discussion multiple times.<div><br></div><div>- You do not need FQ everywhere and depending on <div>the case you can do approximations of that.</div><div><br></div><div>- What I believe you always need is flow-awareness.<br></div><div><br></div><div>- There are already implementations of dual-queue systems in DC switches such as the Cisco nexus 9k.</div><div><br></div><div>- The dualQ system in docsis is the wrong way to implement a flow-aware system with two queues. </div><div>For many reasons including, but not limited to the fact that dualQ to work makes assumptions about the behaviour of the end-points.</div><div>A flow aware queuing system should not be sensitive to some sort of compliancy of the end-points.</div><div>You cannot trust the end-points and the protection system should not discriminate good vs bad based on a badge carried by the packets.</div><div><br></div><div>- I also believe dualQ fails to achieve its goal under current and future traffic patters.</div><div><br></div><div>- The approach described in this paper also works for 2 queues only and makes no assumption about the end-points.</div><div>It does not require marking at all.</div><div><br></div><div><span style="color:rgb(0,0,0);font-family:tahoma,arial,verdana,sans-serif;font-size:12px">James Roberts et al.</span></div><div><span style="color:rgb(0,0,0);font-family:tahoma,arial,verdana,sans-serif;font-size:12px">Minimizing the overhead in implementing flow-aware networking. </span></div><div><span style="color:rgb(0,0,0);font-family:tahoma,arial,verdana,sans-serif;font-size:12px">In </span><span style="box-sizing:border-box;color:rgb(0,0,0);font-family:tahoma,arial,verdana,sans-serif;font-size:12px">Proceedings of the 2005 ACM symposium on Architecture for networking and communications systems</span><span style="color:rgb(0,0,0);font-family:tahoma,arial,verdana,sans-serif;font-size:12px"> (ANCS '05). </span></div><div><span style="color:rgb(0,0,0);font-family:tahoma,arial,verdana,sans-serif;font-size:12px">DOI: <a href="https://doi.org/10.1145/1095890.1095912">https://doi.org/10.1145/1095890.1095912</a></span><br></div><div><a href="https://team.inria.fr/rap/files/2013/12/KMOR05a.pdf">https://team.inria.fr/rap/files/2013/12/KMOR05a.pdf</a><br></div><div><br></div><div>- There is not one TCP, there is no one single transport in the wild. There are many and there will be many more.</div><div>The docsis specs makes the assumption that to be a good guy you must be part of one Church. The one specified.</div><div>This is a very religious assumption about end-points' behaviour.</div><div>All the others are bad guys. I'm the only one who sees this as deeply wrong?</div><div><br></div><div>- Almost 10 years ago I built a FQ prototype on an NPU based on Cavium with Alcatel-Lucent (the team was based in Paris). </div><div>That was supposed to be an ALU7750 target. The problem was that not a single ISP was even aware of the topic. Nobody was asking for it.</div><div>It's a chicken and egg problem Mikael. If you do not ask loudly nobody builds it.</div><div><br></div><div>- I also built with Ikanos in 2010, a FQ prototype in their MIPS based SoC. 32 queues for the France Telecom livebox</div><div>and it worked. Ikanos was later acquired by Qualcomm and that SoC is not used anymore in favour of Broadcom.</div><div><br></div><div>Hope this helps to make progress in the discussion</div><div><br></div><div>Luca</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2019 at 8:55 AM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I don't really have time to debate this today.<br>
<br>
Since you forked this conversation back to FQ I need to state a few things.<br>
<br>
1) SCE is (we think) compatible with existing single queue AQMs. CE<br>
should not be exerted in this case, just drop. Note that this is also<br>
what L4S wants to do with the "normal" queue (I refuse to call it<br>
classic).<br>
<br>
2) SCE is optional. A transport that has a more agressive behavior,<br>
like dctcp, should fall back to being tcp-friendly if it<br>
sees no SCE marks and only CE or drop.<br>
<br>
3) At 100Gbit speeds some form of multi-queue oft seems needed. (and<br>
this is in part why folk want to relax ordering requirements). So some<br>
form of multiple queuing is generally the case. At the higher speeds,<br>
DC's usually overprovision anyway.<br>
<br>
4) The biggest cpu overhead for any of this stuff is per-tenant (in<br>
the dc) or per customer shaping. This benefits a lot from a hardware<br>
assist. (see senic). I've done quite a bit of DC work in the past 2<br>
years (rather than home routers), and have had a hard look at the<br>
underlying substrates for a few multi-tenant implementations....<br>
<br>
4) "dualq" hasn't tried to address the fact that most 10Gbit and<br>
higher cards have 8 or more hardware queues in the first place.<br>
<br>
5) Companies like preseem are shipping transparent bridges that do<br>
fq_codel/cake on customer traffic.<br>
<br>
I've long been in periodic negotions with makers of "big iron" like,<br>
for example, the new 128 core huwei box and others I cannot talk about<br>
at the moment, to get so far as an existence proof.<br>
<br>
So I'd like to kill the meme that SCE requires FQ, at least, for now,<br>
until after we do more tests.<br>
<br>
As for FQ everywhere, well, I'd like that, but it's not needed in<br>
devices that already have sufficient multiplexing.<br>
<br>
<br>
<br>
<br>
<br>
On Mon, Mar 25, 2019 at 8:16 AM Mikael Abrahamsson <<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>> wrote:<br>
><br>
> On Sun, 24 Mar 2019, Sebastian Moeller wrote:<br>
><br>
> > From my layman's perspective this is the the killer argument against the<br>
> > dualQ approach and for fair-queueing, IMHO only fq will be able to<br>
><br>
> Do people on this email list think we're trying to trick you when we're<br>
> saying that FQ won't be available anytime soon on a lot of platforms that<br>
> need this kind of AQM?<br>
><br>
> Since there is always demand for implementations, can we get an ASIC/NPU<br>
> implementation of FQ_CODEL done by someone who claims it's no problem?<br>
><br>
> Personally I believe we need both. FQ is obviously superior to anything<br>
> else most of the time, but FQ is not making itself into the kind of<br>
> devices it needs to get into for the bufferbloat situation to improve, so<br>
> now what?<br>
><br>
> Claiming to have a superior solution that is too expensive to go into<br>
> relevant devices, is that proposal still relevant as an alternative to a<br>
> different solution that actually is making itself into silicon?<br>
><br>
> Again, FQ superior, but what what good is it if it's not being used?<br>
><br>
> We need to have this discussion and come up with a joint understanding of<br>
> the world, otherwise we're never going to get anywhere.<br>
><br>
> --<br>
> Mikael Abrahamsson email: <a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a><br>
> _______________________________________________<br>
> Ecn-sane mailing list<br>
> <a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/ecn-sane" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a><br>
<br>
<br>
<br>
-- <br>
<br>
Dave Täht<br>
CTO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: 1-831-205-9740<br>
_______________________________________________<br>
Ecn-sane mailing list<br>
<a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/ecn-sane" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a><br>
</blockquote></div>