On Feb 17, 2019, at 10:07 PM, Sebastian Moeller <moeller0@gmx.de> wrote:

But in your test, a reduced TCP RTT should result in a higher throughput, no?

Theoretically, but I think the difference may be only marginal at modern bandwidths. For example, during my 20Mbit, 10 second “one vs one” iperf test, 23770 segments are sent and only 9 are dropped. ECN saves those 9 segments, but that’s only 13626 bytes (0.038%), plus what ever side effects there may be. My current test with iperf isn’t sensitive enough to measure a corresponding difference in throughput.

Note that at https://en.wikipedia.org/wiki/Explicit_Congestion_Notification#Effects_on_performance, it claims "Effects of ECN on bulk throughput are less clear”, which references a 2003 paper "Marek Malowidzki, Simulation-based Study of ECN Performance in RED Networks”.

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.

Well, the big danger of dropping packets is that you might stall a flow (say, by dropping enough consecutive packets to drive the flow into RTO) something much less likely with SACK (at least that is my understanding of one of SACKs promises).