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

[Jonathan Morton <[e-mail]>]

> On 12 May, 2020, at 6:01 pm, Scheffenegger, Richard <[e-mail]> wrote:
> 
> > 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).

I'm perfectly aware of that, but I was referring to the case where DCTCP senders are matched with DCTCP receivers, as that is both the intended deployment scenario for DCTCP, and the one which exposes the problem.  In engineering it is necessary to consider the worst case, not merely the best case, and risk-assess the consequences of that worst case occurring in practice.

In fact, this particular backwards-compatibility mode has a hidden danger to it.  A sender may select DCTCP behaviour and see no detriment at first, because all the receivers observed behave conventionally and this backwards compatibility mode is in effect.  And a receiver may select DCTCP behaviour and see no detriment at first, because all the senders observed also behave conventionally.  But the behaviour then changes dramatically when the two happen to meet, and by this time both the sender's and receiver's operators have stopped paying attention.

That's why protocol standards exist to be followed.  I really shouldn't have to spell that out in the context of an IETF WG debate.

> hardware is being deployed which only
> supports 1/p marking in heterogeneous environments today

This is irrelevant, as I noted before.  An AQM does not enforce 1/p behaviour or otherwise.  When faced with mixed traffic types, both types of AQM will trigger the unfair behaviour, unless this is explicitly mitigated.

An AQM may be *optimised* for a particular traffic type, of course - in the case of 1/p behaviour on a short path, the optimisation is to mark at a shallower depth and a higher frequency than for 1/sqrt(p) behaviour on a longer path.  But if it is optimised for the wrong thing, then the AQM is badly deployed.  And, to state the obvious, currently all RFC-compliant traffic on the Internet is 1/sqrt(p) on a relatively long path.

 - Jonathan Morton