Re: [tsvwg] David Black (individual) on safety of L4S for the Internet

[Jonathan Morton <[e-mail]>]

> On 9 May, 2020, at 5:02 am, Neal Cardwell <[e-mail]> wrote:
> 
>> The problem with DCTCP is not its response to loss, though there was a serious
>> bug that apparently went unnoticed for a long time. Rather, it has to do with
>> the response to CE marks applied by an AQM. We can analyse this qualitatively
>> and show a clear difference which will always result in severe unfairness. This
>> is also easy to confirm by experiment.
> 
> I see. Thanks for clarifying. I'm aware of the issues with DCTCP
> operating in an RFC3168 AQM. The sentence introducing this thread
> ("DCTCP-like traffic outcompetes the TCP-like traffic") did not
> specify an AQM (RFC3168 or RFC8257), so absent the mention of an AQM I
> was imagining this was referring to the default case of a non-ECN
> single-queue drop-tail FIFO.
> 
> However, I suppose I should have been able to deduce from the
> structure of the argument that there was implicitly an RFC3168 AQM in
> this scenario, so my apologies for not deducing that.

It's a bit more subtle than that: the unfairness exists regardless of the type of AQM, so long as it cannot distinguish a DCTCP flow from a conventional flow (for which FQ is sufficient).  The unfairness stems from a different interpretation of the common congestion signal, and is ultimately caused by DCTCP, not by the AQM.

And that is the case for the "shallow marking" switches you mentioned earlier.  Even though they were designed with DCTCP in mind, they are not designed to provide fairness between DCTCP (or a transport that resembles it, as TCP Prague does) and conventional TCP (or a transport that resembles it, such as TCP-SCE or QUIC).  So while a conventional TCP passing through such a switch my merely experience poor utilisation due to the shallow buffer, a conventional TCP crossing DCTCP traffic in that same switch may find itself completely starved.

It's crucial that everyone in this debate fully understands this point, because DCTCP-like behaviour underpins every aspect of L4S.

A consequence of that is that L4S expects the network to be upgraded, in full, to either understand its classification signal or implement FQ.  The *whole Internet*, from datacentre to CDN to core to backhaul to last-mile to third-world farmer just trying to check his e-mail.  That is not going to happen within any reasonable timeframe.

There are alternatives which recognise the existence of AQMs already deployed, and explicitly distinguish the high-fidelity and conventional congestion signals so that they aren't confused with each other upon receipt.  The SCE team has proposed one, and I now see that Jake Holland has proposed another.  I think both of these alternatives should be given serious consideration.

 - Jonathan Morton