<div><div dir="auto">To me there is substantial difference from something like fq_codel or fq_pie where service differentiation is largely implicit</div></div><div dir="auto">and approches largely based on explicit marking. </div><div dir="auto"><br></div><div dir="auto">Approaches based on marking face technical and non technical challenges that have been largely mentioned in these lists.</div><div dir="auto"><br></div><div dir="auto">Fq_codel has a ton of litterature behind both theoretical and experimental and it is something very close to optimality, in terms of completion time and latency.</div><div dir="auto"><br></div><div dir="auto">Fq_codel also incentivizes the development of better congestion control as the reward is immediate. It also makes  Internet performance </div><div dir="auto">predictable.</div><div dir="auto"><br></div><div dir="auto">Once we know that, the logical approach would be to try to approximate that thing when the full mechanism is not possible because of a variety of limitations.</div><div dir="auto"><br></div><div dir="auto">This is the case in some DC switches that implement AFD+priority fair queueing at 40Gbps.</div><div dir="auto"><br></div><div dir="auto">Fq_codel has an outstanding footprint in terms of deployment.</div><div dir="auto">Iliad deployed SFQ in 2005 nation wide and Fq_codel as soon as it was available in France and is the second largest ISP. </div><div dir="auto">Iliad/Free  controls the development of both the home GW and the DSLAM. </div><div dir="auto">They have recently started to commercialize 10Gbps to the home using switched Ethernet.</div><div dir="auto">I’m very tempted to test it.</div><div dir="auto"><br></div><div dir="auto">Kudos to them for being able to prove it is possible as long as you control the development of your equipment.</div><div dir="auto"><br></div><div dir="auto">A logical next step  to me seems to push chipcos to build fq_codel in silicon.</div><div dir="auto">It is totally feasible. </div><div dir="auto"><br></div><div dir="auto">If on the other hand we say that we can achieve all fq_codel provides with current chipsets we’ll never create the incentives to make progress.</div><div dir="auto"><br></div><div dir="auto">My2c</div><div dir="auto">Luca </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun 17 Mar 2019 at 15:06, Mikael Abrahamsson <<a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 16 Mar 2019, Holland, Jake wrote:<br>
<br>
> Granted, it still remains to be seen whether SCE in practice can match<br>
> the results of L4S, and L4S was here first.  But it seems to me L4S comes<br>
> with some problems that have not yet been examined, and that are nicely<br>
> dodged by a SCE-based approach.<br>
<br>
I'm actually not that interested in an academic competition about what <br>
solution gives the ultimate "best" outcome in simulation or in a lab.<br>
<br>
I am interested in good enough solutions that are actually deployable and <br>
will get deployed, and doesn't have any pathological behaviour when it <br>
comes to legacy traffic.<br>
<br>
Right now the Internet is full of deep FIFOs and they're not going away, <br>
and they're not getting FQ_CODEL or CAKE.<br>
<br>
CAKE/FQ_CODEL is nice, but it's not being deployed at the typical <br>
congestion points we have in real life. These devices would have a much <br>
easier time getting PIE or even RED, if it was just implemented.<br>
<br>
-- <br>
Mikael Abrahamsson    email: <a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a><br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div></div>