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

["Scheffenegger, Richard" <[e-mail]>]

Hi Jonathan,

A small nitpick:

 > In particular, to obtain the 50% reduction to a single CE mark that
NewReno implements, an entire congestion window's worth of segments must
be marked CE by the AQM.

The DCTCP sender has to believe that one window's worth of segments was
received with CE set; This is incidentally the backwards compatibility
mode of DCTCP against RFC3168 receivers, which will latch ECE until an
(acceptable) CWR has been received. (And based on the readily available
DCTCP / RFC3168 implementations, this is something that tends to happen
frequently).

You are, of course, correct in stating that shallow-threshold CE marking
is detremental to 1/sqrt(p) CC. But I can also support Neal's claim from
independent findings, that hardware is being deployed which only
supports 1/p marking in heterogeneous environments today (well, since 2
years ago).

Having an classifier which is more persistent across the internet than
DiffServ is IMHO key, if a consistent low-latency service is something
we strive for.

(And yes, L4S as it currently stands, may have issues to varying degrees
in certain scenarios. Nevertheless, I remain convinced, that those
problems can be resolved in a feasible way.

Richard



Am 09.05.2020 um 00:37 schrieb Jonathan Morton:
>> 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.
>
> Assume that a single queue exists at the bottleneck, with a single ECN AQM which does not discriminate between flows and classes of traffic.  This queue and AQM are shared by diverse traffic flows, some of which adhere to RFC3168 and RFC-8511, some of which are Not-ECT, and some of which are DCTCP.  The Not-ECT packets will, in accordance with RFC-3168, be dropped if they would have been marked CE.
>
> The steady state for both Not-ECT and RFC-3168/8511 transports (which include NewReno and CUBIC) is multiple RTTs between CE marks.  Each round-trip containing a CE mark (or a packet loss) causes a Multiplicative Decrease to between 50% and 85% of the previous congestion window, as defined by RFC-8511 and earlier well-known specifications.  It then takes several RTTs to grow the congestion window to its previous value, where a further congestion signal can be expected.
>
> The steady state for DCTCP is two CE marks per round-trip.  Each CE mark causes half a segment to be subtracted from the congestion window, on average.  This is qualitatively different from the response specified by RFC-8511.  In particular, to obtain the 50% reduction to a single CE mark that NewReno implements, an entire congestion window's worth of segments must be marked CE by the AQM.
>
> Two results should be obvious from the above.  First, an AQM response that causes RFC-8511 compliant transports to back off substantially may cause very little response from DCTCP.  Second, an AQM response that produces the steady state in DCTCP will also apply CE marks (or packet loss) to almost every round-trip of other competing flows, which will cause conventional TCPs' congestion windows to collapse to very small values.
>
> That is why DCTCP is specified for deployment only in controlled environments where its interactions with conventional TCP can be strictly managed.
>
>   - Jonathan Morton
>