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

[Greg White <[e-mail]>]

On 4/4/19, 1:28 AM, "Jonathan Morton" <[e-mail]> wrote:
[...]    
    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.
    
[GW] Has any progress been made on a variant of Cake that utilizes the L4S ECT(1) semantic?  It would be useful for comparison purposes.  

[...]    
    > 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?  

[GW] Well, a goal would be for FQ AQMs to provide appropriate high-fidelity congestion signals to L4S flows so that they can achieve all four Ls and the S.  Failing that, to not provide weaker congestion signals for L4S flows as compared to classic TCP.  It isn't a problem from a fairness perspective, but the goal is low latency after all.    This seems like a fairly simple change to FQ.

    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.
    
[GW] I don't believe that the RFCs are on your side here.   RFC 3168 contemplates, and rejects, that definition of ECT(1), so I'm not sure how you read it as supporting the use. RFC 3168 explicitly defines ECT(1) as being a transport sender signal that it is "ECN Capable Transport".  I don't see how you can claim adherence to RFC 3168, yet use ECT(1) to mean (S)CE.  Moreover, RFC 3168 has been updated by (Standards-Track) RFC 8311, which enables the L4S experiments, and which the SCE approach also violates.  

[...] 
    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).  

[GW] We have worked very closely with all of the DOCSIS equipment vendors to ensure that Low Latency DOCSIS (including dual-queue) is implementable via a firmware update to ALL existing DOCSIS 3.1 CMs and CMTS that are in the field today.  In some markets that is more than 90% of deployed CMTSs. I obviously can't speak to other access network technologies, but to the extent that forwarding architectures are similar, I would presume that doubling the number of queues is significantly simpler than multiplying by 1000.

    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.

[GW] The concern would be single-queue *ECN* AQMs. Single-queue packet drop AQMs do exist.
    
    Meanwhile, work continues.

[GW] Why?  It seems to me that the L4S approach can be implemented easily in fq_codel and CAKE, as well as in systems that can only realistically support dual-queue.  It has been demonstrated to provide scalable throughput and ultra-low loss and queuing delay (which, I think, is the goal of SCE as well), and has quite a bit of support and momentum behind it. The philosophical debate as to which is better, dualq-coupled-aqm or FQ, can continue and implementers can choose whichever they like.  I don't doubt that the SCE signaling method could be used in a variant of DCTCP, but the *huge* downside is that it can only work on bottleneck links that are able (or willing) to support FQ, which will be precious few.  In 2-3 years' time, 10s of millions of actual bottleneck links in broadband networks will be supporting dual-queue.  It seems that the only real argument in favor of the SCE signaling method is the fallback in presence of single-queue classic ECN (unless you think blocking implementers from supporting dual-queue is some kind of perverse benefit).  Help analyzing (and addressing if need be) that situation would be the most effective way of achieving the shared goal of low latency scalable congestion control.  Continuing to push for (or worse, deploy) an incompatible solution just increases the risk that no one will be able to achieve that goal.