IETF Logo Mail Archive

Re: [tsvwg] Gorry Fairhurst Individual thoughts on choosing whether/how to advance ECN work.

Jonathan Morton <chromatix99@gmail.com> Fri, 15 May 2020 22:52 UTC

Return-Path: <chromatix99@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131FD3A0A18 for <tsvwg@ietfa.amsl.com>; Fri, 15 May 2020 15:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOTC2_z8wMEa for <tsvwg@ietfa.amsl.com>; Fri, 15 May 2020 15:52:41 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A263A09F4 for <tsvwg@ietf.org>; Fri, 15 May 2020 15:52:41 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id x27so3033762lfg.9 for <tsvwg@ietf.org>; Fri, 15 May 2020 15:52:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nk/8CKO0LN8HJKSA7QAZW1d53yQ52KsjVJbJhHqNWks=; b=S6UNEO81Eu3pbRHjoIVxmT7lcQHXPwJfISn7bLK0qa8N2hh+eP58cEcnL7IV4aKw4W +fgsIbJ9WK3oW3dUj733ao43cLfgnzVa9RQvbdIW9KtQACDQxlrP+UBmyKiI+hsNRtXg qU6eIg6Rx2W5YSxXrSD/RbeP7xDibmZ3xO+CUn6K9qpsaGre70kgaA1PY4jKYyp50s25 hSLFaauRKEwjYfT3bUfWHfSFiRsSGm7sDGWSOiV8qnG58IS/wg457+6Ayqulk/QoSRH9 HZL9Rt/mnhotCpdNu/5Fma9uSmHq40kD9nMvbdxilER335rRvedZsPwIIMoxwGPJ5+9s x7qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nk/8CKO0LN8HJKSA7QAZW1d53yQ52KsjVJbJhHqNWks=; b=KE6KLUDDhP5aIArtA7cwgQhIllTl+X1A7fYbH0V0Z0QzqLM3HE33jPY4uyHlxaw3/P MQ1/uhmGya5hAOvUCoRaw0W96OT9x+UaHGLJwUZTl/o54iEUYPAGkRMbFc7flOEGLBE5 iRvBI3VblLqc/4cDJAG9Ec50fXrds+3ZbOmasiJAZUUpPx8dn6qBM664YAqXZ67pGidW sdt9DobR+hlpVhqFOOLzcSqK86JIxQlk2je20oSiNjHMLiMykSaWO8MXKUkgf40hWgtD 15+IlGjv8YkdlXCinE99ZlUD6IhWAo7PB4Kah4f6VKa8kszs1iu7IKB3qBRBTrurGNQ3 Av/Q==
X-Gm-Message-State: AOAM533NEj1reyvKr8kIO/jFlSjPtUVRv0ImhNh3+O8MHjyzbm56BAjT yN9fUKfUCO1+7j47N9EXPdY=
X-Google-Smtp-Source: ABdhPJwpBi6r++kkSfrAAZ7om0khtmjgztSXQkjk862kB160ND484+Leg7RwKaUVEjnmUTlYQBZdyA==
X-Received: by 2002:a19:c85:: with SMTP id 127mr3848476lfm.189.1589583159243; Fri, 15 May 2020 15:52:39 -0700 (PDT)
Received: from jonathartonsmbp.lan (83-245-235-192-nat-p.elisa-mobile.fi. [83.245.235.192]) by smtp.gmail.com with ESMTPSA id s7sm1848295ljm.58.2020.05.15.15.52.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2020 15:52:38 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <4B291AD4-FEDF-43CB-B69C-95A8EC7DD09F@heistp.net>
Date: Sat, 16 May 2020 01:52:36 +0300
Cc: Joseph Touch <touch@strayalpha.com>, paul@redbarn.org, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDBA6185-1267-4CDA-BE77-550AA57446F5@gmail.com>
References: <dbc71da6-70f1-7369-1d2d-f08fb3b08b69@erg.abdn.ac.uk> <999D213E-D708-4189-990E-1801F8C6E814@strayalpha.com> <3CD6E65D-3D28-49E3-B77C-4C3CCC155BA4@gmail.com> <EAA264BA-E9A5-4E1B-A934-6104A0976DF9@strayalpha.com> <08EBD982-0D17-4F75-97F8-F09D873AECDC@gmail.com> <4B291AD4-FEDF-43CB-B69C-95A8EC7DD09F@heistp.net>
To: Pete Heist <pete@heistp.net>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qk7Z_3hb5l3j1BeDPthRy2k06tc>
Subject: Re: [tsvwg] Gorry Fairhurst Individual thoughts on choosing whether/how to advance ECN work.
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2020 22:52:43 -0000

> On 16 May, 2020, at 1:14 am, Pete Heist <pete@heistp.net> wrote:
> 
>> Conversely, it is straightforward to demonstrate a case in L4S where lying gains a significant advantage for the liar: a sender may mark its traffic ECT(0) but then implement DCTCP-style congestion control.  The demonstrated in-network component of L4S does not protect against this, and at least some existing networks are also vulnerable to it.
> 
> For a test result along these lines, the plot below shows CUBIC vs Prague when:
> 1) disabling bottleneck detection (a module parameter) and
> 2) using an iptables rule to change ECT(1) to ECT(0) on outgoing TCP segments without the SYN flag sent
> 
> http://sce.dnsmgr.net/results/ect1-2020-05-15T235113-s10-gaming-ect1-ect0/l4s-s10-gaming-ect1-ect0/l4s-s10-gaming-ect1-ect0-ns-cubic-vs-prague-dualpi2-20ms_tcp_delivery_with_rtt.svg

Exactly.  What you see here is a simulated lying sender on a 20ms, 50Mbps path, starting up shortly after a TCP CUBIC flow that is not lying.  There is a DualQ AQM at the bottleneck which would normally be able to distinguish the Prague flow from CUBIC and apply the different congestion signalling that it needs.  Since that distinguishing identifier has been deliberately removed, everything reverts to DCTCP behaviour in which the CUBIC flow is squeezed out of the network, and the lying Prague sender gets 95%+ of the throughput.

 - Jonathan Morton

v2.23.0 | Report a Bug | By Email