Yes, it's enabled by default. I think I'm just measuring the wrong thing. ECN seems to be about reducing TCP RTT and jitter, not increasing throughput per se. I'll rather compare packet captures with it on and off to look for an improvement in the TCP RTT spikes typically associated with drops.

On 17 Feb 2019, at 14:02, Sebastian Moeller <moeller0@gmx.de> wrote:

Did you use SACK?

On February 17, 2019 12:26:51 PM GMT+01:00, Pete Heist <pete@heistp.net> wrote:
Attached are some scripts that run two simple tests of ECN with veth devices, with and without ECN. The topology is:

client - middlebox (20Mbit htb+fq_codel egress both ways) - net (40ms netem delay both ways, i.e. 80ms RTT) - server

Here are some results from the APU2 with Debian 9 / kernel 4.9.0-8:

Test 1 (“One vs one”, two clients uploads competing, one flow each for 60 seconds, measure total data transferred):

No ECN, 63.2 + 63.5 transferred = 126.7MB
ECN, 63.2 + 61.5 transferred = 124.7MB

Test 2 (“One vs pulses”, client #1: upload for 60 seconds, client #2: 40x 1M uploads sequentially (iperf -n 1M), measure client #1 data transferred):

No ECN, 63.2 MB transferred
ECN, 65.0 MB transferred

Can anyone suggest changes to this test or a better test that would more clearly show the benefit of ECN? I guess we’d want more congestion and the cost of each lost packet to be higher, meaning higher RTTs and more clients?

Pete

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.