Re: [tsvwg] FQ & VPNs

Pete Heist <> Mon, 22 February 2021 10:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E3573A1265 for <>; Mon, 22 Feb 2021 02:27:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, 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 wuu86mI3wmLr for <>; Mon, 22 Feb 2021 02:27:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C96A3A1260 for <>; Mon, 22 Feb 2021 02:27:50 -0800 (PST)
Received: by with SMTP id l30so2782695wrb.12 for <>; Mon, 22 Feb 2021 02:27:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=vGNjomzixu+6XTYapr8m0Bq3SxQOiC8WM+ti223TkYQ=; b=j3CGoZEbyvzhJ8TIyv+qWK4MrGCnxCfni77ErR9B/LTl8unbdFkJBnJyi/o6pKeU72 CvIgh9c/XhAfEfYVDkaBoV3X3MSPxyqm7zjUhr5MJRXQIptj3KDQ1/fFLwEC2m4KCSzU A9bnv+SEDjZdwAr5j7lLNgFIWpUKS1ucsL5fYji+UQqT8EI9mFKjIUisrCvnAs9OgvDw M52KHmZaxTQSpD1cfeaIM/aa9GMEPfI7oXPhXSOzqwqgvM7oEHgMi1A+c/RRddIOFIIg iG2ll6Vt4d4YdtbrATuwWdSMFw0DgMxTxILXy4B93eJB/ASIyzd4MKpvuwlHiedLv4Q0 FzFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=vGNjomzixu+6XTYapr8m0Bq3SxQOiC8WM+ti223TkYQ=; b=cNed7ozps4IEFATpYJXkJRTFthkH3HqqQZSJldmvP74ugkLwk8UzaNnx1AA5XfFh4z R1Gn0Zs8aBHfgFVGJF/9oSJoHnACYl+sOl/UgmTFDM2mpK53UzqIAGJK0oMspBqXyVNE VyOztr8OiYovG7z1hBIe59qVxIvWZf1zqocVVXxjsRbNBomnwPJxbygJyKW8RFKUQegU q5mozvBqlXUJldqBwDuOn8FW3UPUC4/vievoUYLKQQRa86R7lhZetK0ncho4yCpfVO6D 5yAZxtyFjduXZi1rr/P8eF+jf6eHGKX5k4pu8kgPNgRRMuRcwzSXZI5KzCr99Y1nBgt2 LtVw==
X-Gm-Message-State: AOAM533zSzCKR15UgYzLCsUC1NdbmtaBJD+RAenooehFCuPhri3AJBlR hCHGMgrJZ1xGKbxzVOj7KDM3sQ==
X-Google-Smtp-Source: ABdhPJznQYEUTooXwmPb4qwp5m7WgEgDiPq9V9co208lbIKy9hPwgQNg46eyLwcNs3y2DoKoHv5xMg==
X-Received: by 2002:adf:a2d3:: with SMTP id t19mr13911903wra.299.1613989668826; Mon, 22 Feb 2021 02:27:48 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id x12sm2300806wrq.84.2021. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Feb 2021 02:27:48 -0800 (PST)
Message-ID: <>
From: Pete Heist <>
To: Greg White <>
Cc: TSVWG <>, Jonathan Morton <>
Date: Mon, 22 Feb 2021 11:27:46 +0100
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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: Mon, 22 Feb 2021 10:27:53 -0000

Hi Greg, some comments below [PH].

On Sun, 2021-02-21 at 23:49 +0000, Greg White wrote:
> On 2/21/21, 4:25 PM, "tsvwg on behalf of Jonathan Morton" <
> on behalf of> wrote:
>     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.
> [GW] This is blatantly false. In the vast majority of paths, L4S is
> considered safe for deployment today.  In a minority of paths there
> exists the rare possibility of L4S flows achieving more than their
> "fair" share of the bottleneck link bandwidth, and an extremely rare
> possibility that this unfairness results in a significant temporary
> degradation of classic traffic performance.  In these paths there is
> almost certainly only one network element that will need to be
> updated in order to prevent any possibility of such degradation, and
> as far as anyone can discern at the moment those network elements are
> largely prosumer grade home routers that are increasingly being
> actively patched already. 

[PH] In regards to the proportion of paths with RFC3168 AQMs deployed,
referring to section 3.2 in our recent draft, and cautioning that this
is not authoritative:

If we remove the IP addresses that I had an influence on, leaving only
the unknown sources of AQM marking, then the proportion of IPs that
successfully negotiated ECN and saw CE or ECE, i.e. apparently had an
AQM on the path, is (90-38)/382 = 0.14.

I also noticed during a few script runs, as it was refined, that as we
let it run longer, more IP addresses appeared that saw CE or ECE. AQMs
are only visible to us when flows both negotiate ECN and experience
congestion at those AQMs. It takes time for detection when 1.44% of
SYNs had ECN capability, so we may have missed some.

The 1.44% ECN SYN proportion may also make it more difficult to detect
ECN traffic within tunnels, because now we have the product of ECN
capable traffic with traffic that's traversing a tunnel. However, that
product does not apply to the potential for induced harm, since that
occurs to both ECN and non-ECN capable flows.

[PH] As to the level of harm induced when traffic winds up in the same
queue, it appears that in the presence of a "long-running" L4S flow,
short flows as well as long flows, ECN capable or not, may be affected.
As flows start up, there can be "good" cases:

and "not as good" cases:

It might be useful to have a histogram of FCT vs flow length, to
project what the user experience might be like for web browsing or
other applications in the presence of long-running L4S flows.


> [snip]
>     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.
> [GW] The WG considered SCE and has decided against it.  You seem to
> be repeating the same arguments (with the same transparent hyperbole)
> that led to that conclusion in hopes that the outcome somehow
> changes. 
> [snip]