Re: [tsvwg] Dual-Q Pol[i]cing

["Rodney W. Grimes" <[e-mail]>]

> On Mon, May 25, 2020 at 8:50 AM Paul Vixie wrote:
> > On Monday, 25 May 2020 10:00:30 UTC Sebastian Moeller wrote:
> > > ... Is everybody else convinced that L4S offers a sufficiently
> > > safe design and was tested with the to be expected level of adversarial
> > > traffic patterns to confirm the design's safety in the real-world?
> >
> > so, no, i am not convinced, but that doesn't matter. what matters is that
> > if there is an input signal marked on a flow, datagram, packet, or segment
> > which would cause my routing or switching equipment to behave differently,
> > such as choosing one of two "dual queues", then i will likely never enable
> > it, and if i do enable it i will bleach that mark out of inbound traffic
> > from the WAN.
> 
> Because it may inform the conversation, is your current policy to disable ECN
> marking and/or to bleach ECN bits out of inbound traffic from the WAN? Per
> RFC 3168, those bits are intended to affect drop vs mark behavior of routers.

Unsolicited, but useful data.

Netflix says they shall not turn on ECN in there services because they do
not trust the network, which is another case of the issue stated above.

Yandex says they shall not turn on ECN due to an unfairness issue, which
I am now starting to fully understand.  ECN can be gamed, plain and simple,
so ECN without a FQ or some other form of protection can lead to network
abuse.  It is rather simple to create a transport that claims to support
RFC3168 marking, and then have it simply ignore ECE.  Pete Heist, I believe,
has posted data on this, and no one has even responded to it.

So in answer to your question Mike, for me, I would feel at liberty to bleach
ECN entering my AS should I find it being gamed, and might just do so
out of safety until I can be sure that proper protections are in place.

IMHO, this WG should take a serious hard look at some of these issues
and possibilities, nothing in L4S removes those status quo's, and again
IMHO, this dooms it to the same fate as ECN in some rather large parts
of the internet.  SCE suffers from this less so in that it is almost
always coupled with either a FQ or AFQ AQM which does infact at least
mitigate the above issues.

It appears to me that one can not safely deply any ECN system without
some form of queue protection.   And yes, including RFC3168.

> Mike Heard
-- 
Rod Grimes                                                 [e-mail]