Re: [tsvwg] FQ & VPNs

Jonathan Morton <> Sun, 21 February 2021 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4851F3A1301 for <>; Sun, 21 Feb 2021 15:24:52 -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 ZF0YO3d2r7Iz for <>; Sun, 21 Feb 2021 15:24:51 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB00F3A1307 for <>; Sun, 21 Feb 2021 15:24:50 -0800 (PST)
Received: by with SMTP id y7so50850893lji.7 for <>; Sun, 21 Feb 2021 15:24:50 -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=zQ02REdyTJhFsusW+qkxYKtGsQ0Lc1x9LuabNDcWvWA=; b=HgjwP+NeGgXnRG0+BW01FXWAnseJLZr20EKjKHyiD6YJtF6/0x3utScQ9QpFnIq1Iv Vc4OtofErzvC8ICgpyGeVo8sbyu61lLH2xnsTrSj7j+lW9y0EMThKCwhp4qiZkEmUGNz ldnXK1581j0cAKvsI1n/T58B5Kntnx+fCU/SZVSTL+9SNpPPp2avCkyTZIc6Ce7YJ6mu N5hWod9xE+18F7hrSEo42ZSeSSlwZj+FqZAyQjqF6T12UvKIV2WyfcvfOqEVvrJN81CD m/tMrwWQkvl6EdVsazU1zaWWp3zzQaf5WxUHoukXzd06ODfGYXge9QDK0RXeafW9nU6q 4v1Q==
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=zQ02REdyTJhFsusW+qkxYKtGsQ0Lc1x9LuabNDcWvWA=; b=aMRf4F7Ol5j06ag15pcbzd8Kmbp9n66PYuW25DqIhsOr9vyQfUOhNMPY+023Se2rHy q3zBqP2tEbBrs4Fr/FR9hNi3YCPULfjGDKirJ8M1SJDo/aSgxFUelkUkNJMG7QSOMCko dgBns0dGSIxEIrGdAJ63mHptweTGJDhej7j7WySJ5Pi2XALto9WtDy8eJINdN4FA6RJz RCylGjHpWrcYpz9NIxy8WxnRzekifb1zM01gLRHxZQkxn/yUG6EOArgOax9WSKOVVRuO KbjwXzlYePhZNpsOzHA/Z/HhLY2mG4/c1ZdCnyaxeGy1391CEM7f+0GsOdordzeC03/L B/UQ==
X-Gm-Message-State: AOAM532GTga47YWEpuNkHrgmy17D/rfc1foVpev+JFeO5cIaZZZlP1+y JTSavk4uZgu5C8Ny5VcbvhY=
X-Google-Smtp-Source: ABdhPJzFTzcSWZBOflECvLX/NQriMYKdqa9q1937j24MUsGaIVl/EDiIvBy4OOqSvUtk6Ojz0ZXFAA==
X-Received: by 2002:ac2:58d5:: with SMTP id u21mr3524457lfo.564.1613949888573; Sun, 21 Feb 2021 15:24:48 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id u30sm1708535lfk.31.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Feb 2021 15:24:48 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Mon, 22 Feb 2021 01:24:46 +0200
Cc: Tom Henderson <>, Dave Taht <>, TSVWG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] FQ & VPNs
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: Sun, 21 Feb 2021 23:24:52 -0000

> On 21 Feb, 2021, at 11:23 pm, Ingemar Johansson S <> wrote:
> Help me to understand this right. 
> You argue that Tom's suggestion is not possible because it requires that the
> group agrees to start an L4S experiment that stipulates an alternate
> interpretation for the ECT(1) codepoint (as per RFC8311). 
> And further you point at the problem that RFC3168 AQMs cannot distinguish
> between ECT(0) and ECT(1) as evidence that the L4S experiment cannot be
> (safely) run, and consequently the L4S experiment should not run.
> Do I understand right?, I am really confused. It all sounds like a catch-22
> situation to me ?

It's not a Catch 22.  It's just the heart of the problem with L4S.

L4S cannot safely be deployed on existing networks - that is axiomatic in its current form.  Therefore, you have to prepare the network as fully L4S-aware before you can safely deploy your first endpoints - on Internet scale, that is not really feasible within a decade.  It would be easier to start deployment if you had a good way of containing L4S traffic to a small portion of the network (eg. a CDN and an associated ISP) in which dealing with the network preparation is actually feasible in the short term.

Using a DSCP as the L4S identifier would be such a method, permitting fencing off the L4S traffic at the network boundaries, and because the network needs to be prepared anyway, there should be no problem with DSCP bleaching.  Therefore there is actually no reason to consume ECT(1) as the L4S ID.

Until you figure out the above, you will not get a published Experimental RFC, which is what RFC-8311 requires to override that requirement in RFC-3168.  But there *is* a path forward to success, and therefore it is not a Catch 22.  It's just going to be a very difficult and drawn-out process to deploy L4S, unless some relatively significant design change occurs (which we haven't seen in the past two years) to cure some of the deficiencies.

Conversely, let's look at SCE from the same perspective.  Remember, SCE is capable of achieving the same performance as L4S, given similar marking and response algorithms.  The difference is in backwards compatibility.

SCE is specifically designed to be compatible with existing networks, and to behave identically to conventional traffic in that case.  Instead of identifying itself to the network and trusting that the network understands that message, the network distinguishes the SCE signal from the existing ECN signal unambiguously, and trusts that existing receivers will merely ignore a signal that is currently specified to be ignored.  This means SCE endpoints and middleboxes can be deployed safely on independent schedules, and it is not necessary to eliminate old equipment, nor to fence off the edges of networks to contain SCE traffic.

It is of course possible to label SCE traffic with a DSCP at source, and thus use the simplest possible two-queue AQM structure that can run at a bajillion packets per second.  It doesn't cause any safety problems if the DSCP is bleached en route, because the receiver can still distinguish the intent of the marks.  In practice, most people are likely to use flow-aware AQM or none at all, just as they do today, and this does not require a DSCP.

SCE also requires an Experimental RFC to be published before its new use of ECT(1) is permitted in public networks.  This is no different from the situation with L4S.  But because there are few if any safety concerns of the type that L4S raises (in particular, SCE's failure modes tend to *reduce* its load on the network, not increase it), this should not be a big obstacle - if only the WG would adopt it.  Currently L4S stands in the way of that.

But that is why we proposed SCE as an alternative to L4S in the same problem space.  It works just as well in the ideal case, and is much easier to deploy.

 - Jonathan Morton