From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 6347D3BA8E for ; Sun, 17 Feb 2019 08:02:26 -0500 (EST) Received: from [192.168.42.133] ([77.12.39.45]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LuP19-1h5dNY44vf-011f94; Sun, 17 Feb 2019 14:02:24 +0100 Date: Sun, 17 Feb 2019 14:02:19 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----JJZIF1C86OF3YFREBLJGES5CPFB5TZ" Content-Transfer-Encoding: 7bit To: ecn-sane@lists.bufferbloat.net,Pete Heist From: Sebastian Moeller Message-ID: <9FCA2304-8511-4AF6-B860-D42F124A5A32@gmx.de> X-Provags-ID: V03:K1:gOpYakhbnekyXOy5i45eDUnnXUoI0FjqQaeHOOZ5DrkU1XQxRk+ SirK7O8i3R6i23KbXJ6UrxdlyRc5/jtSTk7W6iaFec00sjTVfPmFuQkib2fp2IJiJdcsIRD HY+D7RUFbJAkMGoz8zryHZm5d8YEXWrbVCyYzSUlWQWHS6DAGIM4XPlcE5fIFoIaqDqHfpL P4oxZSAvA8VqSZOu7Umrw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Iffm6OVOfTs=:VShp81oGf4cBICa4nm05/6 R65/xGaV2hTHSoIHWiSMdG7j1AUh/AzMwIKpCD9INyQy3Oye2qmnDEiNrmWgRVl6ujnOmalWE 7YBFY1NFWZRdxTNWBv3MKgaqMKTYwIzhe90jzDuLlnKICyyim9YyhVRN5nKXS0BdonWbx2Hwl dPA7fNY/2uYX20MRMKAvVOFgn53QDIMVIYmRlHOvYIWmBZeSk4xOLUErqFw+bWt5MLcQ6jcO2 +xB6qVgSzevpI4Jx+4AEkGZD5I4Qc2EbgyaprPMR4QVY+oEmFkDf6Mx0fEAAfwwFGAE4eH8D/ kkjWBAbZCfv9bYIvkweevOkjR3c14Dq2K3mHzHXTOGDbEMQD0ogi3R8Z63hv/Sfj3aIc59buW CN445/ia4gqbMVXV8aOSdB7qgyA4Gj1jfA9KKup56ZpIPdyf2DbZk+WGzeAljmW211u4NVjD6 CYFRlS/+4jA6qUegphT/My26IB2++yJikL+GwjDIltRII2onfep7P9kYjPbVikpRNulisWnER q22WBFEjEvlVZeu02i5E7cj+UdHi7Fs+HUoi1K1GZPRM4tvMIWya6iR+4UMp1yjHd+t4SGpsc Ymzomflvd3dKDH4rZgqsSlfOx5oaSjH4KLIlLShe4f+A0AGyl5ETONPZeGKaV9xLKpqcV6/XT zxtZLhlOxJnWmeZ0SgQXkWB0bqVAj0cmwZSrvsHFd0rerHDIXsSzwlcr7aHrxsklrDDXwS0in zZgjlpFz7B0f9HK4iiys5fuYmxxiznWquE0p2+WZrRCrROkREiNGQEk5+izI9WW5+zkvdo5CP +/Xfs+9f+O95BdxAPA6JUc5XrArSsdC2TYjPeO6KxJSDZ+qcYDbyaK99KSs+MooimOqJrtvn2 Cbzi8vMjjsHX9kUXEC4XTs8pso0p8HyJgiaetSEbJMGL6Eo/JJABuTMVyAUAT7dp3zBUOdJrL rtqKt8/ZQsA== 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 13:02:26 -0000 ------JJZIF1C86OF3YFREBLJGES5CPFB5TZ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Did you use SACK? 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=2E The topology is: > >client - middlebox (20Mbit htb+fq_codel egress both ways) - net (40ms >netem delay both ways, i=2Ee=2E 80ms RTT) - server > >Here are some results from the APU2 with Debian 9 / kernel 4=2E9=2E0-8: > >Test 1 (=E2=80=9COne vs one=E2=80=9D, two clients uploads competing, one = flow each for >60 seconds, measure total data transferred): > > No ECN, 63=2E2 + 63=2E5 transferred =3D 126=2E7MB > ECN, 63=2E2 + 61=2E5 transferred =3D 124=2E7MB > >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): > > No ECN, 63=2E2 MB transferred > ECN, 65=2E0 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=E2=80=99d want more cong= estion >and the cost of each lost packet to be higher, meaning higher RTTs and >more clients? > >Pete --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------JJZIF1C86OF3YFREBLJGES5CPFB5TZ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Did you use SACK?

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

c=
lient - middlebox (20Mbit htb+fq_codel egress both ways) - net (40ms netem =
delay both ways, i=2Ee=2E 80ms RTT) - server

Here are some results f=
rom the APU2 with Debian 9 / kernel 4=2E9=2E0-8:

Test 1 (=E2=80=9COn=
e vs one=E2=80=9D, two clients uploads competing, one flow each for 60 seco=
nds, measure total data transferred):

	No ECN, 63=2E2 + 63=2E5 trans=
ferred =3D 126=2E7MB
	ECN, 63=2E2 + 61=2E5 transferred =3D 124=2E7MB
=

Test 2 (=E2=80=9COne vs pulses=E2=80=9D, client #1: upload for 60 secon=
ds, client #2: 40x 1M uploads sequentially (iperf -n 1M), measure client #1=
 data transferred):

	No ECN, 63=2E2 MB transferred
	ECN, 65=2E0 M=
B transferred

Can anyone suggest changes to this test or a better te=
st that would more clearly show the benefit of ECN? I guess we=E2=80=99d wa=
nt more congestion and the cost of each lost packet to be higher, meaning h=
igher RTTs and more clients?

Pete

--=
Sent from my Android device with K-9 Mail=2E Please excuse my brevity= =2E ------JJZIF1C86OF3YFREBLJGES5CPFB5TZ--