Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague presentation

[Jonathan Morton <[e-mail]>]

> On 4 Apr, 2019, at 2:28 am, Greg White <[e-mail]> wrote:
> 
> It will be the case that many such "equivalent devices" can (and will) support a dual-queue AQM (not fq), which (where available) will eliminate the need for ingress shaping, and provide a better result.    If fq_codel (or CAKE) were updated to utilize the L4S-style of ECN (or even just treat ECT(1) as non-ECT), this would be a non-issue.   How feasible would that be? 

The present out-of-tree version of Cake supports an L4S-style high-fidelity ECN marking method, simultaneously with conventional ECN marking.  It does so using the SCE signalling method, with ECT(1) being an output rather than an input.  This is, in fact, the running code we had at the time of our TSVWG presentation.

Since then we have adapted a pair of FreeBSD endpoints to understand this new signal and respond appropriately to it (using a response function very similar to DCTCP).  Crucially, they continue to respond normally, with TCP-friendly semantics, to non-SCE middleboxes and/or when conversing with non-SCE endpoints.  These are early results from early code, but they prove the concept.  

This bears repeating: we have effectively *rehabilitated* DCTCP.

It took three developers one week to do this, amidst many distractions.

> In fq_codel/CAKE currently, does the AQM switch from CE mark to packet drop at some higher threshold of sojourn time?

Technically yes, there is a failsafe intended for handling flows unresponsive to ECN (eg. due to blackholes) or insufficiently responsive to Codel-induced drops on Non-ECT flows.  However, this only kicks in when the queue backlog limit is reached.  It is a simple implementation of the BLUE algorithm, which ignores ECN and just drops, and is self-resetting.

> If so, would this provide for a faster fall-back to Reno than you considered in your analysis?

Not normally; the backlog limit is typically set to many RTTs' worth of queuing delay.  The mechanism has been carefully tested and works well, but rarely activates in practice.

> Alternatively, if fq_codel/CAKE were to treat ECT(1) as non-ECT (or implement the L4S style ECN) this would again not be an issue, I believe.

Perhaps, but I thought FQ AQMs weren't much of a problem to begin with - aside from the ingress-queuing problem?  I'm also reluctant to interpret ECT(1) or CE incompatibly with RFC-3168, unless given very good reason - and I currently have a good counter-argument.  If I may quote from that document, it does specifically contemplate use of the fourth codepoint to signal "mild congestion":

>    One possibility might have been for the data sender to use the fourth
>    ECN codepoint to indicate an alternate semantics for ECN.  However,
>    this seems to us more appropriate to be signaled using a
>    differentiated services codepoint in the DS field.
> 
>    A second possible use for the fourth ECN codepoint would have been to
>    give the router two separate codepoints for the indication of
>    congestion, CE(0) and CE(1), for mild and severe congestion
>    respectively.


It goes on to suggest problems with incremental deployment of such a scheme, but I believe SCE overcomes those problems elegantly.  As I have previously pointed out, the remaining benefits of L4S can be realised through assigning a DSCP to a PHB with the desired characteristics, and having something like DualQ implement that PHB.

I can't help noticing, meanwhile, that DualQ seems to be designed for use wherever a single-queue AQM would normally fit (though I have my doubts that it will work on much hardware already deployed at crucial locations).  Yet at the same time, you claim such single-queue AQMs are presently (and will remain) so rare that you haven't even developed a method of reliably detecting them.  This seems like an important discrepancy.

Meanwhile, work continues.

 - Jonathan Morton