Subject: [tsvwg] unresponsive traffic tests

From: Pete Heist <[email-masked]>
Date: Wed, 20 May 2020 17:15:23 +0200

Below are some tests of unresponsive traffic, to illustrate an important part of the thinking behind using ECT(1) as an output.

All of the tests involve two flow competition where both flows have advertised ECN support, but only one is responding to CE signals (note: we’d get similar results if the responsive flow did not support ECN). This could happen due to a rogue transport implementation, or a broken or malicious network configuration. This is not a problem unique to HFCC signaling, so we use CUBIC vs CUBIC in all of the tests, except for two tests that include Prague, only so we can compare behavior in the C and L queues. 

The point of the tests is not to show any unexpected behavior, but to show that the expected behavior when flows are unresponsive only results in effective congestion control when the AQM has some form of unresponsive flow mitigation, or fair queueing, or both.

In our view, signaling via ECN adds a MUST for the network to handle unresponsive flows, because it's too easy for the ECN bits to be wrong, either intentionally or unintentionally. Effective mitigation of unresponsive flows requires at least *some* level of flow awareness to identify the offending traffic. Once you have flow awareness, it becomes possible to add fairness steering, which allows you to use ECT(1) as a new output signal so CE doesn’t have to be redefined, and helps the variety of available CC mechanisms interoperate, across RTTs and under varying network conditions.

-----

* First, we test RED, to see what happens in a single queue AQM. We can see that the “CE unresponsive” flow dominates the responsive flow, but the random drop behavior does allow some responsive traffic through:

http://sce.dnsmgr.net/results/ect1-2020-05-20-s11-ce-unresponsive/sce-s11-ce-unresponsive/sce-s11-ce-unresponsive-ns-cubic-vs-cubic-red_400000_-20ms_tcp_delivery_with_rtt.svg

* In a single Codel queue, since no packets marked ECT(0) are dropped, the competing responsive flow is starved:

http://sce.dnsmgr.net/results/ect1-2020-05-20-s11-ce-unresponsive/sce-s11-ce-unresponsive/sce-s11-ce-unresponsive-ns-cubic-vs-cubic-fq_codel_1q_-20ms_tcp_delivery_with_rtt.svg

* With fq_codel, flow isolation via FQ prevents the responsive flow from being starved by the unresponsive one, but the unresponsive flow does build its own queue, presumably until the memory limit is reached:

http://sce.dnsmgr.net/results/ect1-2020-05-20-s11-ce-unresponsive/sce-s11-ce-unresponsive/sce-s11-ce-unresponsive-ns-cubic-vs-cubic-fq_codel-20ms_tcp_delivery_with_rtt.svg

* Cake is similar to fq_codel, but adds a BLUE drop response for unresponsive flows:

http://sce.dnsmgr.net/results/ect1-2020-05-20-s11-ce-unresponsive/sce-s11-ce-unresponsive/sce-s11-ce-unresponsive-ns-cubic-vs-cubic-cake-20ms_tcp_delivery_with_rtt.svg

* cnq_codel_af is a single queue, which only uses differential signaling, to tend towards approximate fairness:

http://sce.dnsmgr.net/results/ect1-2020-05-20-s11-ce-unresponsive/sce-s11-ce-unresponsive/sce-s11-ce-unresponsive-ns-cubic-vs-cubic-cnq_codel_af-20ms_tcp_delivery_with_rtt.svg

* lfq_cobalt handles bulk flows in a single queue, but avoids the need for full FQ by using a pull operation, and uses BLUE to keep the unresponsive flow under control:

http://sce.dnsmgr.net/results/ect1-2020-05-20-s11-ce-unresponsive/sce-s11-ce-unresponsive/sce-s11-ce-unresponsive-ns-cubic-vs-cubic-lfq_cobalt-20ms_tcp_delivery_with_rtt.svg

* With dualpi2, there are three combinations of flows in the C, C/L and L queues. In each case the responsive flow is nearly starved by the unresponsive one, while a drop response at least controls the queue of the unresponsive flow:

http://sce.dnsmgr.net/results/ect1-2020-05-20-s11-ce-unresponsive/l4s-s11-ce-unresponsive/l4s-s11-ce-unresponsive-ns-cubic-vs-cubic-dualpi2-20ms_tcp_delivery_with_rtt.svg

http://sce.dnsmgr.net/results/ect1-2020-05-20-s11-ce-unresponsive/l4s-s11-ce-unresponsive/l4s-s11-ce-unresponsive-ns-prague-vs-cubic-dualpi2-20ms_tcp_delivery_with_rtt.svg

http://sce.dnsmgr.net/results/ect1-2020-05-20-s11-ce-unresponsive/l4s-s11-ce-unresponsive/l4s-s11-ce-unresponsive-ns-prague-vs-prague-dualpi2-20ms_tcp_delivery_with_rtt.svg

-----

Pete