Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)

Jonathan Morton <> Fri, 04 December 2020 10:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B40F3A08B0 for <>; Fri, 4 Dec 2020 02:38:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D96u70oNhfdn for <>; Fri, 4 Dec 2020 02:38:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16C683A08AE for <>; Fri, 4 Dec 2020 02:38:53 -0800 (PST)
Received: by with SMTP id s27so7004898lfp.5 for <>; Fri, 04 Dec 2020 02:38:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sz9cdLVbb3D5nG2/flMlDi9boNWA+L4L53kf5m6Nj/0=; b=omtIN+46207kn8IPAbJ4N1AX4wv9YQmk/o2Djzw/LweAYsvaUOEYzOPsBRHVilnr3p rPTjZQOk1rGlhTbKRLy67c+gI9LCQgfzJ5Lg/lazIX5Md0B/lsoTnpVPKaNPWJIWD84c 7k00w7bFfQIEgON9bEo7bH5fcH3j48k4Y6P9m6pq5aBoOiFhzllyTD6iBUEKaROPw/8N Flp/VuFT2T3MAbAWlnidEftto3D7jGYQbW1VPfT0WGeXBg+jaH96E2jeHhyCz5yad6bi zu/ZsCmXloBY5j1MA614DybenonM9WdbUK2g0W18G207KACahKKTTQREQSuMMt/4jSRq 2RXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sz9cdLVbb3D5nG2/flMlDi9boNWA+L4L53kf5m6Nj/0=; b=Hd6udnytW6bM66MSrd2y1lo3g7bMwF8aziDMH01eZxcGO+qCRueFbXo0f+sp4JtkBw Lh4/+mqNdWdMAhhgDorCbKwRMB5V8BwRtnQKUstj0nIoPILazg2fqwlX0sn2rLwexkpO k+eeMytWw0fNLqfhODK9Nhxcsv5tXc84ZFkNx/EgoPUcSzH/voSt8pQGDbqzTjWAL6oK 3zUWruRnNrYXj5P3xU/RSK8kQlMAb5z7cehUgiFI2+zihSCufjYv2r/Snz3xDzRZxlkM 4FW4n2MroahgtL7fqmnXqkVNcisjKoDuZnbjxZo4gVBzt6tbe8TOuwLi3fWpMd1jKEnh Nj/Q==
X-Gm-Message-State: AOAM5328vLEiYOGkzSeYpYPu1ecE9ngLL2dBjzJDaxjd4T0DU2U2CHLw yxrkd/BkuHL/s+1EBNZM6Sw=
X-Google-Smtp-Source: ABdhPJyxcidaWAK/AfYrQ8fQYtbaAf+vOAAc7QLFauMcXcaDjo0x6G4w0zMv5ekZ40KtXWV/Ojgryw==
X-Received: by 2002:a19:3806:: with SMTP id f6mr2876714lfa.43.1607078331101; Fri, 04 Dec 2020 02:38:51 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id d20sm1535659lfe.174.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 02:38:50 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Fri, 04 Dec 2020 12:38:48 +0200
Cc: Wesley Eddy <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Michael Welzl <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Dec 2020 10:38:55 -0000

> On 4 Dec, 2020, at 11:08 am, Michael Welzl <> wrote:
> Imagine a scenario where L4S is deployed on some hosts feeding into a bottleneck, yet some other hosts don’t participate in the L4S experiment (e.g., these hosts could run a different OS). Now assume that the non-L4S-participating hosts want to try out 3168-style ECN **at this point in time** - and they find it performing terribly poor, worse than without using ECN, concluding that 3168-style ECN isn’t even worth trying. Then, the only possibility for improvement is to also participate in the L4S experiment - and what if this, then, also doesn’t hold its promises (e.g., because the only existing end system implementation doesn’t work well) ?   Won’t this lead to an overall conclusion that ECN isn’t worth it, and never has been?

In this situation, the effects would be seen by the non-L4S hosts even *before* they enabled ECN.  Here's an example of what they might encounter, noting that a Not-ECT CUBIC flow is involved here:

For insight into this, consider that RFC-3168 AQMs are required to drop Not-ECT packets at the same rate as they mark ECT traffic.  That is, the decision to apply a congestion signal to a packet is made independently of its ECT status, and the latter only determines whether it can be a mark, or must be a drop.  The L4S traffic still looks like ECT packets (because RFC-3168 treats ECT1 as equivalent to ECT0), so the marking and dropping rates still go up in concert and the conventional traffic still gets squashed - only now it also has to perform retransmissions, so the goodput actually suffers a bit more than with ECN enabled.

The conclusion that a user or ISP (who isn't familiar with L4S but is simply trying to roll out ECN) might draw from this is that AQM is bad and unreliable, rather than ECN per se; they would actually see a slight improvement from enabling ECN at the endpoint, but a much bigger one from disabling the AQM.  This runs contrary to the established wisdom that AQM reduces latency (which is good) without having too much effect on throughput (which would be bad).

Another possible conclusion that a more paranoid network operator could draw is that ECN *in general* is a potential DoS attack vector and must therefore be blackholed.  That would be bad for *everyone* including L4S, and would also prevent reverting to RFC-3168 deployment upon failure of the L4S experiment.  I think that is a substantial risk that must also be weighed.

 - Jonathan Morton