Re: [tsvwg] Reasons for WGLC/RFC asap

Jonathan Morton <> Fri, 20 November 2020 01:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F3F13A153F for <>; Thu, 19 Nov 2020 17:38:42 -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 nVbsitq3dM0L for <>; Thu, 19 Nov 2020 17:38:40 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94DD43A153D for <>; Thu, 19 Nov 2020 17:38:40 -0800 (PST)
Received: by with SMTP id v144so11107184lfa.13 for <>; Thu, 19 Nov 2020 17:38:40 -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=bb5wvrCMGmw9wm//9oj0wRnO3DjmkP24yteBjRc5Q38=; b=qytYjzEIf6ap0FRmDOx9qlSk64nvL5ZAR8JmCUBYV/KefRKegMTe5NCO0YYbTlE1wv jLC/uuPEhxBS9wfLuu0WxIng43eaGnFlq6MpWSZzX8k39sZJgAgttpZ7UkFZ9002RnBZ CyUSntUwCRAORJlaXAfprTAV8cd3KL4tEFil2otSAyr0Xc81z0X23svJO3Sc4Rks4cLh iDSa77F80w6wnbclMtFtUzdsny9qJgVUZzTZWRh3l2XXiuYLVbt9Nw/181n3huK2lL8p BbpB07eqAouW03zIrSIhJ8Xkk0LfCQPvDtVcEhL08xO+gSD6itnufFJRCNURRYQBk01f ARGA==
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=bb5wvrCMGmw9wm//9oj0wRnO3DjmkP24yteBjRc5Q38=; b=Tb3GySoxnq4cmhaL2rOc/wGO7IO8CgDwGez1OrXTF4CoTSNa21hbjvPhBah39t5j/Q ixK8juKH6VflpwjBEJp5B8rPys1Zzwy9OOULoj5O3ppoS89TL7IFa3gPjOQyP4/L+Jqi XXUCiONx/2/V1RKanKCA3s3NgLDLT6sUbVUrfb5QchKvPL3zB3cA/sWAvxsaIEjvSaep Rl0CCYVM03+EdFN1kUaQs6BM4oqT6MwDOgZhxY1R1oB/rPMW6tSA+hid6ciePVZOpkU7 5sGbpLm9ucDrS0LJBVD/+Gys6dKKaJMfYH/BNu9IzyDbu8FGZYI4VVflsUtS3vZ5ogQ+ TfLA==
X-Gm-Message-State: AOAM531Ykzy9wiPZCRaf1son0sNPHi6upi7aVnzimU5uRkxZ5z7kd2sF jn8eWs/ru6JVcGv9xXSG00Zmla+hCYY=
X-Google-Smtp-Source: ABdhPJyr8KPZtl4vAi+NE4rz2w07GJbW+hKr0nhJPVerJxiH6LrKKCkaiAhOC1hMeQ459DjY7sQ7Lg==
X-Received: by 2002:ac2:442a:: with SMTP id w10mr6356500lfl.217.1605836318586; Thu, 19 Nov 2020 17:38:38 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id n130sm165106lfd.213.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 17:38:38 -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, 20 Nov 2020 03:38:36 +0200
Cc: Pete Heist <>, Gorry Fairhurst <>, tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Greg White <>
X-Mailer: Apple Mail (2.3445.9.7)
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 01:38:42 -0000

> 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.

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