From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 E41943CB36 for ; Sun, 17 Feb 2019 15:57:26 -0500 (EST) Received: by mail-wm1-x329.google.com with SMTP id d15so15368229wmb.3 for ; Sun, 17 Feb 2019 12:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=DIbeu9QKqt0WZqp91kb8xQAx1RtpGJp/ElNCO+jkC8k=; b=YrerOV2srTcYnMgVBUnVATLywhNJLmEy/Pi2+375jWvrJNuhTc+KqIef8hbaA4/F9B YBOKeCdim24hhzoEJkxPKvokac1VxEGCwzsMVV+Dqrx5ip3Poqdjja5pcnqE2XTzKrpG 1vdQtJUJobIdXfoLd5LkI5c9mZ5z6DBNegmqnXYBQSaNmUdYhzDe/3EIqceIgSs/68cj wKiJJwaQsWZcS7hDG3V6a0Vh1VnQIHkOaHiCZ+ydjeMgqON63zBUmSLARo1EuFuoxP/6 N8pqo+dENbpY2T9sDfp0mLfYggSDSDeOkGMkWC1+86qIArrAKmhBo9iJQ93/XEJFVuw9 Vsrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=DIbeu9QKqt0WZqp91kb8xQAx1RtpGJp/ElNCO+jkC8k=; b=BTN9MdMhinHi5nEOhTO1kixWTQs1ulfllEiBeDLp6+j+yiNfmkAkAwUvZ0ihmw6dUg OXGTHpZHbWbDrbEw2/6E1KEG70v++Hj6s0tcCnrnMDkJkCRXigBomKCNa2fhinzp0Zkr XuT7vVsdgeUunntaN6kUJBCaCZqIFACpcPFk1lBXtnu/gIYS7l59r0TkFLCmmk0A3yWu npdu+fHC/1pj2hVJSoAQPiifbmf3kbJPAPprDPhpzC2ce/dyOckYX+gt0+CGZ8hynWBU fhPQZ/Sn3JEl2hWMfCF2VDvFT4UUaiPwyLOintauEbvSUQrLZFhqUIOT8RvXllT+HAzL TFMw== X-Gm-Message-State: AHQUAuaFPh1qLSo0IzicteJxHjL0EfPrKxl69+3DRhTi03/pnMBdSRSP o9b88LWequlAIpBMgHjTFUU9TA== X-Google-Smtp-Source: AHgI3IYJ3MHjiuL0eGDfx0PAe2X2X+wMozsCkhpadGtUBiyR/n0L1HORqZaPE6tv1q+6O4Ygey9SJw== X-Received: by 2002:a1c:2985:: with SMTP id p127mr13011206wmp.63.1550437045711; Sun, 17 Feb 2019 12:57:25 -0800 (PST) Received: from [10.72.0.133] (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id o18sm41939195wrg.40.2019.02.17.12.57.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Feb 2019 12:57:24 -0800 (PST) References: <9FCA2304-8511-4AF6-B860-D42F124A5A32@gmx.de> In-Reply-To: <9FCA2304-8511-4AF6-B860-D42F124A5A32@gmx.de> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-54FA89C8-2A1A-4EAD-BB49-D5BC571016E2 Message-Id: Cc: ecn-sane@lists.bufferbloat.net X-Mailer: iPad Mail (14G60) From: Pete Heist Date: Sun, 17 Feb 2019 21:57:22 +0100 To: Sebastian Moeller 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 20:57:27 -0000 --Apple-Mail-54FA89C8-2A1A-4EAD-BB49-D5BC571016E2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, it's enabled by default. I think I'm just measuring the wrong thing. EC= N seems to be about reducing TCP RTT and jitter, not increasing throughput p= er 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 wrote: >=20 > Did you use SACK? >=20 >> On February 17, 2019 12:26:51 PM GMT+01:00, Pete Heist w= rote: >> Attached are some scripts that run two simple tests of ECN with veth devi= ces, with and without ECN. The topology is: >>=20 >> client - middlebox (20Mbit htb+fq_codel egress both ways) - net (40ms net= em 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 f= low 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 da= ta 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 c= learly show the benefit of ECN? I guess we=E2=80=99d want more congestion an= d the cost of each lost packet to be higher, meaning higher RTTs and more cl= ients? >>=20 >> Pete >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. --Apple-Mail-54FA89C8-2A1A-4EAD-BB49-D5BC571016E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, it's enabled by default. I think I= 'm just measuring the wrong thing. ECN seems to be about reducing TCP RTT an= d jitter, not increasing throughput per se. I'll rather compare packet captu= res with it on and off to look for an improvement in the TCP RTT spikes typi= cally 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 b=
oth ways, i.e. 80ms RTT) - server

Here are some results from the APU2=
 with Debian 9 / kernel 4.9.0-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.2 + 63.5 transferred =3D 126.7MB=

	ECN, 63.2 + 61.5 transferred =3D 124.7MB

Test 2 (=E2=80=9COn=
e vs pulses=E2=80=9D, client #1: upload for 60 seconds, client #2: 40x 1M up=
loads 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 mor=
e 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?

Pete

--
Sent from my An= droid device with K-9 Mail. Please excuse my brevity.
= --Apple-Mail-54FA89C8-2A1A-4EAD-BB49-D5BC571016E2--