Re: [tsvwg] Gorry Fairhurst Individual thoughts on choosing whether/how to advance ECN work.

[Gorry Fairhurst <[e-mail]>]

I do not think this relates to the topics I raised in the subject line. You see. To have cut my points and started a new thread.

To be clear, I don’t see how the impact of a non-conformant flow, is a topic that concerns whether the ECN work can progress. I agree it is a design issue for transports irrespective of ECN  - since I also expect TCP Reno v. A non-Reno flow can do poorly in a loss-based queue, not just an ECN queue.

Gorry

Sent from my iPad

> On 15 May 2020, at 23:53, Jonathan Morton <[e-mail]> wrote:
> 
> 
>> 
>>> On 16 May, 2020, at 1:14 am, Pete Heist <[e-mail]> wrote:
>>> 
>>> Conversely, it is straightforward to demonstrate a case in L4S where lying gains a significant advantage for the liar: a sender may mark its traffic ECT(0) but then implement DCTCP-style congestion control.  The demonstrated in-network component of L4S does not protect against this, and at least some existing networks are also vulnerable to it.
>> 
>> For a test result along these lines, the plot below shows CUBIC vs Prague when:
>> 1) disabling bottleneck detection (a module parameter) and
>> 2) using an iptables rule to change ECT(1) to ECT(0) on outgoing TCP segments without the SYN flag sent
>> 
>> http://sce.dnsmgr.net/results/ect1-2020-05-15T235113-s10-gaming-ect1-ect0/l4s-s10-gaming-ect1-ect0/l4s-s10-gaming-ect1-ect0-ns-cubic-vs-prague-dualpi2-20ms_tcp_delivery_with_rtt.svg
> 
> Exactly.  What you see here is a simulated lying sender on a 20ms, 50Mbps path, starting up shortly after a TCP CUBIC flow that is not lying.  There is a DualQ AQM at the bottleneck which would normally be able to distinguish the Prague flow from CUBIC and apply the different congestion signalling that it needs.  Since that distinguishing identifier has been deliberately removed, everything reverts to DCTCP behaviour in which the CUBIC flow is squeezed out of the network, and the lying Prague sender gets 95%+ of the throughput.
> 
> - Jonathan Morton