From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 475443CB36 for ; Mon, 18 Feb 2019 05:33:09 -0500 (EST) Received: by mail-wr1-x433.google.com with SMTP id w17so17691115wrn.12 for ; Mon, 18 Feb 2019 02:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TuhGpveFNrFgObOYIqlmt67QP9X85snj66cQ9M+FZQo=; b=aKGdWqfm2/KZKHCOHpvhfRtRe2rHiMM51EbEA+CAXNkSthNXkxTFr6K/A01ialKiUO REyO20Cp3z8+o/WBR/qN0kmMl11NrAOZXaYsoNIJVp6Tmv2VV5Efj3x2J11+H2slDcOW /bbJheJjScz4ar8qC3burIA5EXL7VnzQGN6XHG6dAPaweQN8+5QUkwrwJlwS3bfAQ/hi eRF1vz/QjMyRnSuvznHVZ5fzRRzNg4hxvrQjw/O05KF8yv4on67urDOmxH7NPw3iYnbe jDcLSvvzWIJn3PCQr8Ow51YAd2+KzCVpBohVqPZJiLvGtkd3cU0nL/9pnhT6cxMq/yyw Zx+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TuhGpveFNrFgObOYIqlmt67QP9X85snj66cQ9M+FZQo=; b=FLR28VBkulsSQ7Cy8GsWwXqZ61W6/3x7NuWsn48Wb/djpzFUzSGBmSGRHDEnPUoe1Q tNxRB+ykmkQVK4sGqlC04ENgklp704N8vxdwtpLWscDS2M7duLWJHcFRmMVbUYYPbvfu /jwP4EvMY0hXoDweRTZ2yFnnMlhgZNmotHDd3gKxfEEXmqi3KtV0QLvifGP9ds7QVomo MbDRt7osk2TAvsK+Sm2nGcb6SjNHF10WkauqB3DHAldvSFVHLcJo7wPXhxiXZj5bBYK/ LSkGRVfdSIJdqitL4bZ210HpvradMmhBxgA2AjLEwolt9eL2LJg2nO2Vk1I6lUCKtpKH +AHg== X-Gm-Message-State: AHQUAuaDfyYmyYy3rwe6Y8MSuJ6sS81Kq1vOQINA/lrgsYspAKd/E6TU wThAenuDGntALLeB+s+k+Ws2mg== X-Google-Smtp-Source: AHgI3IYugm8gp/uAAaqrQ964tPCojKASOlJPVjZkwif7vDDiDWsl58GDgYQjKOg1eJPxBpq8UvDd6Q== X-Received: by 2002:adf:f690:: with SMTP id v16mr16275273wrp.139.1550485988313; Mon, 18 Feb 2019 02:33:08 -0800 (PST) Received: from tron.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id u12sm9621678wrt.2.2019.02.18.02.33.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 02:33:07 -0800 (PST) From: Pete Heist Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_542569AD-524B-48F4-9B72-ADE525A8436A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 18 Feb 2019 11:33:06 +0100 In-Reply-To: <09043521-6078-42D3-A32E-CCAC94011F2C@gmx.de> Cc: ecn-sane@lists.bufferbloat.net To: Sebastian Moeller References: <9FCA2304-8511-4AF6-B860-D42F124A5A32@gmx.de> <09043521-6078-42D3-A32E-CCAC94011F2C@gmx.de> X-Mailer: Apple Mail (2.3445.9.1) 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: Mon, 18 Feb 2019 10:33:09 -0000 --Apple-Mail=_542569AD-524B-48F4-9B72-ADE525A8436A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 17, 2019, at 10:07 PM, Sebastian Moeller = wrote: >=20 > 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 =E2=80=9Cone vs = one=E2=80=9D iperf test, 23770 segments are sent and only 9 are dropped. = ECN saves those 9 segments, but that=E2=80=99s only 13626 bytes = (0.038%), plus what ever side effects there may be. My current test with = iperf isn=E2=80=99t 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=E2=80=9D, which references a 2003 paper "Marek Malowidzki, = Simulation-based Study of ECN Performance in RED Networks=E2=80=9D. >> 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. >=20 > 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). That may be, but my simple simulation doesn=E2=80=99t reproduce that = case. I=E2=80=99ve updated it and made some TCP RTT graphs, which does = show a clearer difference with ECN. All the files and pcaps are here: https://www.heistp.net/downloads/veth_ecn/ = Compare these two one-vs-one RTT graphs and the difference with ECN = enabled can be seen: = https://www.heistp.net/downloads/veth_ecn/client_one_vs_one_noecn_rtt.png = https://www.heistp.net/downloads/veth_ecn/client_one_vs_one_ecn_rtt.png = Similar for one-vs-pulses: = https://www.heistp.net/downloads/veth_ecn/client_one_vs_pulses_noecn_rtt.p= ng = = https://www.heistp.net/downloads/veth_ecn/client_one_vs_pulses_ecn_rtt.png= = The graphs of TCP window are also more appealing in the ECN case, at = least. Now, re-reading Dave=E2=80=99s posts about why the ECN-sane project was = started, there appear to be some pathological cases. This simple test = doesn=E2=80=99t get to those. For now just wanted to get in touch with = some basics. :) --Apple-Mail=_542569AD-524B-48F4-9B72-ADE525A8436A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 =E2=80=9Cone vs one=E2=80=9D iperf test, 23770 segments are sent = and only 9 are dropped. ECN saves those 9 segments, but that=E2=80=99s = only 13626 bytes (0.038%), plus what ever side effects there may be. My = current test with iperf isn=E2=80=99t 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=E2=80=9D, which references a 2003 paper "Marek = Malowidzki, Simulation-based Study of ECN Performance in RED = Networks=E2=80=9D.

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).

That may be, but my simple simulation doesn=E2=80=99t = reproduce that case. I=E2=80=99ve updated it and made some TCP RTT = graphs, which does show a clearer difference with ECN. All the files and = pcaps are here:

https://www.heistp.net/downloads/veth_ecn/

Compare these two = one-vs-one RTT graphs and the difference with ECN enabled can be = seen:

https://www.heistp.net/downloads/veth_ecn/client_one_vs_one_noe= cn_rtt.png

https://www.heistp.net/downloads/veth_ecn/client_one_vs_one_ecn= _rtt.png

Similar for one-vs-pulses:

https://www.heistp.net/downloads/veth_ecn/client_one_vs_pulses_= noecn_rtt.png

https://www.heistp.net/downloads/veth_ecn/client_one_vs_pulses_= ecn_rtt.png

The graphs of TCP window are also more appealing in the ECN = case, at least.

Now, re-reading Dave=E2=80=99s posts about why the ECN-sane = project was started, there appear to be some pathological cases. This = simple test doesn=E2=80=99t get to those. For now just wanted to get in = touch with some basics. :)

= --Apple-Mail=_542569AD-524B-48F4-9B72-ADE525A8436A--