<div dir="ltr"><div>Starting a new thread as it looks like this new proposal can be</div><div>integrated in a modular way with several other loosely coupled</div><div>components by just using two hardware queues, which are </div><div>already available in current HW.</div><div><br></div><div>Modifications would just be in the ingress  enqueue time “self-classifier”.</div><div><br></div><div>It also looks like possible to append different optional packet droppers</div><div>to the backlogged queue such as AFD or others to provide</div><div>some level of flow protection to backlogged flows as well.</div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 23, 2019 at 7:01 AM Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@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"><br>It is true that SCE doesn't inherently carry a label distinguishing its traffic from the general set, and thus DualQ cannot be directly applied to it.  But there is a straightforward way to perform this labelling if required, right next door in the Diffserv field.  The recently proposed NQB DSCP would likely be suitable.  I don't think that the majority of potential SCE users would need or even want this distinction (the primary benefit of SCE being better link utilisation by eliminating the traditional deep sawtooth), but the mechanism exists, orthogonally to SCE itself.<br>
<br>
I have also drawn up, as a straw-man proposal, CNQ - Cheap Nasty Queuing:<br>
<br>
        <a href="https://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-00" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-00</a><br>
<br>
This is a single-queue AQM, plus a side channel for prioritising sparse flows, although the definition of "sparse" is much stricter than for a true FQ implementation (even LFQ).  In essence, CNQ treats a flow as sparse if its inter-packet gap is greater than the sojourn time of the main queue, and does not attempt to enforce throughput fairness.  This is probably adequate to assist some common latency-sensitive protocols, such as ARP, SSH, NTP and DNS, as well as the initial handshake of longer-lived bulk flows.  You will also notice that there is support for SCE in the application of AQM, though the AQM algorithm itself is only generically specified.<br>
<br>
In common with a plain single-queue AQM, CNQ will converge to approximate fairness between TCP-friendly flows, while keeping typical latencies under reasonable control.  Aggressive or meek flows will also behave as expected for a single queue, up to a limit where an extremely meek flow might fall into the sparse queue and thus limit its ability to give way.  This limit will relatively depend on the latency maintained in the main queue, and will probably be several times less than the fair share.<br>
<br>
I hope this serves to illustrate that I'm not against single-queue AQMs in an appropriate context, but that their performance limitations need to be borne in mind.  In particular, I consider a single-queue AQM (or CNQ) to be a marked improvement over a dumb FIFO at any bottleneck.<br>
<br>
 - Jonathan Morton<br>
<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></div>