<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 17, 2019, at 10:07 PM, Sebastian Moeller <<a href="mailto:moeller0@gmx.de" class="">moeller0@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>But in your test, a reduced TCP RTT should result in a higher throughput, no?<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>Note that at <a href="https://en.wikipedia.org/wiki/Explicit_Congestion_Notification#Effects_on_performance" class="">https://en.wikipedia.org/wiki/Explicit_Congestion_Notification#Effects_on_performance</a>, 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”.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class="">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).</div></div></blockquote><div><br class=""></div></div><div class="">That may be, but my simple simulation doesn’t reproduce that case. I’ve updated it and made some TCP RTT graphs, which does show a clearer difference with ECN. All the files and pcaps are here:</div><div class=""><br class=""></div><div class=""><a href="https://www.heistp.net/downloads/veth_ecn/" class="">https://www.heistp.net/downloads/veth_ecn/</a></div><div class=""><br class=""></div><div class="">Compare these two one-vs-one RTT graphs and the difference with ECN enabled can be seen:</div><div class=""><br class=""></div><div class=""><a href="https://www.heistp.net/downloads/veth_ecn/client_one_vs_one_noecn_rtt.png" class="">https://www.heistp.net/downloads/veth_ecn/client_one_vs_one_noecn_rtt.png</a></div><div class=""><br class=""></div><div class=""><a href="https://www.heistp.net/downloads/veth_ecn/client_one_vs_one_ecn_rtt.png" class="">https://www.heistp.net/downloads/veth_ecn/client_one_vs_one_ecn_rtt.png</a></div><div class=""><br class=""></div><div class="">Similar for one-vs-pulses:</div><div class=""><br class=""></div><div class=""><a href="https://www.heistp.net/downloads/veth_ecn/client_one_vs_pulses_noecn_rtt.png" class="">https://www.heistp.net/downloads/veth_ecn/client_one_vs_pulses_noecn_rtt.png</a></div><div class=""><br class=""></div><div class=""><a href="https://www.heistp.net/downloads/veth_ecn/client_one_vs_pulses_ecn_rtt.png" class="">https://www.heistp.net/downloads/veth_ecn/client_one_vs_pulses_ecn_rtt.png</a></div><div class=""><br class=""></div><div class="">The graphs of TCP window are also more appealing in the ECN case, at least.</div><div class=""><br class=""></div><div class="">Now, re-reading Dave’s posts about why the ECN-sane project was started, there appear to be some pathological cases. This simple test doesn’t get to those. For now just wanted to get in touch with some basics. :)</div><div class=""><br class=""></div></body></html>