[Ecn-sane] per-flow scheduling

[Jonathan Morton]

> [BB] The objective measure of famine/plenty that all congestion controls use is a combination of the loss level, ECN level, queue delay, etc. In the paper, I referred to BBRv2's distinction between famine and plenty (which is at 1% loss) and in a footnote I expressed a preference for a more gradual transition.

Coincidentally, 1% loss corresponds to about 1.5Mbps goodput at an Internet-scale 80ms RTT, assuming a Reno transport.  Obviously at different RTTs it corresponds to different goodputs, and you might argue that shorter RTTs are also common.  But now we have a common reference point.

Oh, and under similar conditions, 1% marking corresponds to about 30Mbps with L4S (ie. cwnd=200).  That's a 20:1 ratio versus Reno, which you might want to think about carefully when it comes to fair competition.

> The use of the two words famine and plenty wasn't intended to imply only two states. It's a continuum (like the spectrum between famine and plenty).

Okay.

I still happen to disagree with the argument, but single-queue AQMs are still a valid improvement over single dumb FIFOs.  They improve reliability by reducing losses and timeouts, and help to reduce lag in online games.  That's the practical problem facing most Internet users today, and that's where my solutions are focused.

>> Regardless, my assertion is not that FQ is required for ultra-low latency, but that flows requiring ultra-low latency must be isolated from general traffic…
>> 
>> 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.

> To enable SCE and RFC3168 in two queues rather than per-flow queues, if you required SCE packets to be identified by a DSCP, if the DSCP got wiped (which it often does), your SCE traffic would mix with 3168 traffic and starve itself.

Under certain simplifying assumptions, yes.  But those assumptions would include that the 3168 queue was also providing SCE marking in the FQ style, which might not be appropriate for what is effectively a single queue carrying mixed traffic.  It would be as if your DualQ was providing L4S-style signalling in its Classic queue, which I'm sure you would not advocate.

As a de-facto representative of the cable industry, I hope you are aware of the irony that it is chiefly cable ISPs who are bleaching Diffserv information out of consumer traffic?

The starvation problem can be eliminated entirely by providing SCE marking only on the queue intended for SCE traffic (so only CE marks on the 3168 queue).  Mis-marked traffic would then revert to purely 3168 compliant behaviour, which SCE does naturally when given only CE marks.  This option is an important advantage of having a clear distinction between the two signals; there is no ambiguity at the receiver about what type of signal it's receiving and thus which response is demanded.

As a reminder, we *also* have a solution specifically for single-queue AQMs implementing SCE.  It's not a knobs-free solution as the FQ version is, but it exists and it seems to work.  I expect we will need to explore its dynamic characteristics more thoroughly in the near future.

>> 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

> OK. Can you say whether you've tested this exhausitvely? Need to know before we all spend time reading it in too much depth.

To quote Knuth: "I have only proved the above code correct, not tried it."  But we may get time to quickly implement CNQ and/or LFQ, in between preparations for Friday.  (By which I mean implementing it in Linux.)  This stuff is not central to our work on SCE, since we already have Cake for running experiments.

I think Pete Heist wants to try putting CNQ in his offline simulator as well, which already has LFQ.  So that should provide an early sanity check.

 - Jonathan Morton