Re: [tsvwg] Reasons for WGLC/RFC asap

Pete Heist <> Fri, 20 November 2020 06:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63E4B3A1956 for <>; Thu, 19 Nov 2020 22:51:43 -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 0tkJb9uB2IJ3 for <>; Thu, 19 Nov 2020 22:51:42 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C558F3A1954 for <>; Thu, 19 Nov 2020 22:51:41 -0800 (PST)
Received: by with SMTP id j7so8922431wrp.3 for <>; Thu, 19 Nov 2020 22:51:41 -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=MSgcn0l0XFXFN7w5/PD4AMzm5eL6RfUE6BhqPzZ2T6Y=; b=JT/6lfIZBMZTicY4B0aEDG4ltPfl4YOCMds4wyIo6eRs/6zX4M2nKH0d+d0GpehLx9 0Oxsl0ISUMDr9hSBIetgKAUB48MrHyfJNWfdX1Vkffb+2qFYQLW1n3/7YmQbr9ejm8bC VvxBzXJMY7XUjuQIDa+ilZw0mdWdcVthFmyzxmEigkVeOsAaHDKg0/Bp6piDcX8hA7+9 HaE3FJLFTUbzSJdtgTbvY+xQ+sNlMs+ji4CfgYX3ODb9vvf8durip/tlnMg7lBcO2kYu Q8z/NrKtwqMNBcsjHGVb6H+CN2DunpkQKODCLjAfNcX+4LOvucENtLSgNZSeJc/XGhgD s0Bw==
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=MSgcn0l0XFXFN7w5/PD4AMzm5eL6RfUE6BhqPzZ2T6Y=; b=MwxBq8FXoCePimitLWiEZLw+C4sYurDEzVxLzhpnD44W9D7E97HYourbWQ1m5k0Aa4 8MAFsInyMYhQmnbqLg7kL5hSVvkY2RYmn2K6NKcTGiWd9Wg/2Wc+IL5qYH9/qtoIwHUy pGTw59GTflfqYBB2MBZeWDRXp7rZnj5tPFb9209vNI+QTQBnI/pmHbmb6jxuPNoGy+F2 WujVpTOK6311gFMf8Zwhy51dM1eR9YqvPVjt8vXFLRZsYAdPAMkqppAeVRElyTL5ARnf 5o4aI5ZRgy8bUIxZ3go7Gl9ZdaSzp6BhA355gNuMOv818LxgVOcKZa7XpXDwt8G4MYDS gDHQ==
X-Gm-Message-State: AOAM531bQdouhQD+L6Gh3r7oe/Pd/mYFuvzZMhmTEI9Y3Hj5rR3PqbzI rKWkfGCrZ2rgXC4TmMMu8SLo8n0QUsgZ9Q==
X-Google-Smtp-Source: ABdhPJxp6jbTmK15RRCVrNT3k+U9IuCb6oP+N/NRzDhn4H9lnwsqh6dZN2u0eXFSIH6rdkmaXIMCGQ==
X-Received: by 2002:a5d:5308:: with SMTP id e8mr13913344wrv.299.1605855099907; Thu, 19 Nov 2020 22:51:39 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id u203sm3239456wme.32.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Nov 2020 22:51:39 -0800 (PST)
Message-ID: <>
From: Pete Heist <>
To: Jonathan Morton <>, Greg White <>
Cc: Gorry Fairhurst <>, tsvwg IETF list <>
Date: Fri, 20 Nov 2020 07:51:38 +0100
In-Reply-To: <>
References: <> <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [tsvwg] 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, 20 Nov 2020 06:51:43 -0000

One add below...

On Fri, 2020-11-20 at 03:38 +0200, Jonathan Morton wrote:
> > On 20 Nov, 2020, at 2:42 am, Greg White <>
> > wrote:
> > 
> > Is it possible that in these software implementations, the LSB of
> > the ECN field can be added to the FQ flow identifier, thus allowing
> > the FQ to segregate the L4S traffic in the tunnel from the Classic
> > traffic?  If so, would that solve this problem?  Is that an
> > experiment that you’d be willing to try?  
> It's technically possible.  But a problem that immediately comes to
> mind is that incoming CE-marked packets would then get sorted into a
> separate queue from ECT(0) packets.  They would thus likely be
> reordered relative to the rest of the flow, and it increases total
> occupancy of the flow hash table which increases the risk of hash
> collisions.  Overall, it just seems a bit inelegant.
> And then there's the possibility of tunnels which don't properly
> handle propagating ECN to the outer header.  I don't know how
> prevalent these are, but that has the potential to disable this
> workaround, putting you back in the same position.
> Finally, I really think you overestimate the chances of getting
> software updates out to a lot of these devices.  In many cases, we
> consider ourselves lucky to get software updates past the first year
> after hitting the shelves, and we have to manually check and click
> through the wizard to make the update actually happen - it is *not*
> automatic for most CPE devices (imagine if the user unwittingly cut
> the power during one, corrupting the firmware).  So fq_codel as it
> exists today will be a feature of the Internet for the foreseeable
> future.

I have some experience with Ubiquiti's EdgeRouter products, and its
Smart Queueing feature with fq_codel. Their mainline code is still on a
3.10 series kernel, apparently because the offloads support for the SoC
platform was a licensed kit that's hard to get upgraded. The upgrade
cycles on these products are very slow relative to desktop and server
Linux distributions.

> In general, you should consider me skeptical of any proposed solution
> to L4S' coexistence problems that relies heavily on changing existing
> features of the internet.
>  - Jonathan Morton