Re: [tsvwg] [Ecn-sane] CNQ cheap-nasty-queuing (was per-flow queuing)

[Luca Muscariello <[e-mail]>]

Starting a new thread as it looks like this new proposal can be
integrated in a modular way with several other loosely coupled
components by just using two hardware queues, which are
already available in current HW.

Modifications would just be in the ingress  enqueue time “self-classifier”.

It also looks like possible to append different optional packet droppers
to the backlogged queue such as AFD or others to provide
some level of flow protection to backlogged flows as well.



On Tue, Jul 23, 2019 at 7:01 AM Jonathan Morton <[e-mail]>
wrote:

>
> 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.
>
> I have also drawn up, as a straw-man proposal, CNQ - Cheap Nasty Queuing:
>
>
> https://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-00
>
> 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.
>
> 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.
>
> 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.
>
>  - Jonathan Morton
>
> _______________________________________________
> Ecn-sane mailing list
> [e-mail]
> https://lists.bufferbloat.net/listinfo/ecn-sane
>