From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3530F3CB36 for ; Sun, 17 Feb 2019 16:07:50 -0500 (EST) Received: from hms-beagle2.lan ([77.12.39.45]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MDQI1-1gpjxs120z-00Gp2Y; Sun, 17 Feb 2019 22:07:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 17 Feb 2019 22:07:42 +0100 Cc: ecn-sane@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <09043521-6078-42D3-A32E-CCAC94011F2C@gmx.de> References: <9FCA2304-8511-4AF6-B860-D42F124A5A32@gmx.de> To: Pete Heist X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:pn8CdQN+48AqFFJJ+q3W+TabiwCuKUibOmOlpX3usv8GMbTccP1 1LD2QmDuVWSgodkB2N82a0WCXTBqB6Bo5+0L0MJl6o9PBm6AZNJcnntOtsuisjqQ2VVonOC R/Zin1du2rBBBkqNFgQoeOycjrwVMIkPe9gIlPbN61RIuap/KFzSB7nI64uMx03hMiUj7x3 Eb/IiZxG3ze2PgVnNNE7A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Ha9jaysILzM=:BYTA5+vEdq3k3ecqtMvOhj WhiWzug+TWZTYrn6Ntepja5AwAugKKPYBfKMNVJReY/EKVUZwogWTzQoPe8ZxV0tv36fCp0Dn Im2UjXrDvRtxx+kU5IMmkXvKeYdulfPB0m2TIvynVL9o5J9VVjxbyngfFctQk80aGAyCaQyMH FG4Ga2QAghhBeGi2Aq61KMgfrBSCGQNsF+zoCZeUpCtxFL6rJ5Z7eg0y4zjWgSzUVzRfwF4FU oDYwZFk7ikvvBXcv/zf7BdKNWUzvby0bsLmM+JZ4wH2l4cp4CQLVLLjPKPKG/QHGtFXrhbqa6 nApouqRid0Auuwn1D+TgNXZT1hFsEPe4LLst+6Q5EX6L3EOdN5d69ytwUHtF/O+5K0hBNBKSM W4Pjlx5AVua4JiOmaoJWdpPF+EwcV6uqx51LNK33tghsWGa9fmCK0zJrsSN4CvYtheGv7BqZ1 R7u4z/PmZNn/+iGaojSovclqA3bdBIdsk2Cjf8GyJMSvoOmlagACCJBP4MX93PxhpO89k1iQ3 8AQ++Cw3y+6xhXfuKegwkG4ggWSZQqvun4WbbmM/silTt10YLJ0mMTj6ILxAYXqgXfM+O2PF1 TSQHVcKgjTMxjoaIXozSbzYDWGfywpTRrou0Uv9mxdwup3PjAAT4f0QVXL0vy3rVKwlKZTC2k xrc+08XERBFR6T2JQ32Upmp/zf9lkfd0X34RE3y1tnEA/0QJXeDofcLyTbbSwQT7CP2oooCXv 6W/p7/AVyZYJ9LEZC11A6QNNRcriMU+bBdYrFQrYbWd7aI0Qavugks/cd/vPi2A5Hjmb/Pi3l F/5aABtWQJzNpqX/nx7uN+kBKyiK0y7ZUwiH09nCVnBCPAYH/51g+IRIhHZAnsWkqV5CyxtTv YbgiInF70/lB1T+pD5YO7vrO2DTzSClIvXIdMLCNsNxzZBghtyxshxphNmG3kkxHF32wGuFLg E09JKrfmXjA== Subject: Re: [Ecn-sane] results of two simple ECN tests X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 21:07:50 -0000 Hi Pete, > On Feb 17, 2019, at 21:57, Pete Heist wrote: >=20 > 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. But in your test, a reduced TCP RTT should result in a higher = throughput, no? > 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). For post-bottleneck shaping there is also the = issue that ECN-marking an incoming packet will at least not have wasted = the "transmit-slot" that was occupied for the transmit. But given that = TCP was designed to interpret lost packets as a sign of having exceeded = capacity I am not that amazed that it still does a decent job doing so = ;) I believe there is an argument for giving ECN capable flows a lower = marking probability than non-ECN flows would get a drop probability, but = since that is easily gamed (end-points negotiating ECN but simply not = slowing down on receiving marks) it is not an option for the = wide-internet and hence ECN should not give much improvement in = throughput (although it will reduce the number of retransmitted = packets). I wonder how this would change if you would reconfigure the = shaper to half the bandwidth in the middle of the=20 >=20 > On 17 Feb 2019, at 14:02, Sebastian Moeller wrote: >=20 >> Did you use SACK? >>=20 >> On February 17, 2019 12:26:51 PM GMT+01:00, Pete Heist = wrote: >> Attached are some scripts that run two simple tests of ECN with veth = devices, with and without ECN. The topology is: >>=20 >> client - middlebox (20Mbit htb+fq_codel egress both ways) - net (40ms = netem delay both ways, i.e. 80ms RTT) - server >>=20 >> Here are some results from the APU2 with Debian 9 / kernel 4.9.0-8: >>=20 >> Test 1 (=E2=80=9COne vs one=E2=80=9D, two clients uploads competing, = one flow each for 60 seconds, measure total data transferred): >>=20 >> No ECN, 63.2 + 63.5 transferred =3D 126.7MB >> ECN, 63.2 + 61.5 transferred =3D 124.7MB >>=20 >> Test 2 (=E2=80=9COne vs pulses=E2=80=9D, client #1: upload for 60 = seconds, client #2: 40x 1M uploads sequentially (iperf -n 1M), measure = client #1 data transferred): >>=20 >> No ECN, 63.2 MB transferred >> ECN, 65.0 MB transferred >>=20 >> Can anyone suggest changes to this test or a better test that would = more clearly show the benefit of ECN? I guess we=E2=80=99d want more = congestion and the cost of each lost packet to be higher, meaning higher = RTTs and more clients? >>=20 >> Pete >>=20 >> --=20 >> Sent from my Android device with K-9 Mail. Please excuse my brevity.