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

[Neal Cardwell <[e-mail]>]

On Fri, May 8, 2020 at 6:37 PM Jonathan Morton <[e-mail]> wrote:
>
> > On 9 May, 2020, at 1:04 am, Neal Cardwell <ncardwell=[e-mail]> wrote:
> >
> >> Current practice is not to mix DCTCP-like traffic (1/p-class congestion
> >> control) with TCP-like traffic (1/sqrt(p)-class congestion control, e.g.,
> >> NewReno) in the same queue because the DCTCP-like traffic outcompetes the
> >> TCP-like traffic to the point of starvation of the latter.
> >
> > For my education, does someone have a pointer to the experiments
> > underlying that description of DCTCP outcompeting Reno/CUBIC? I'm not
> > aware of that being a fundamental property of DCTCP. The DCTCP
> > algorithm specifies a Reno-style response to loss -
> > https://tools.ietf.org/html/rfc8257#section-3.5 - and has Reno-style
> > increase functions as well. So the algorithm should be Reno friendly,
> > AFAIK.
>
>
> 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.

best,
neal