Re: [tsvwg] FW: path forward on L4S issue #16

Steven Blake <> Mon, 08 June 2020 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E9603A0FD5 for <>; Mon, 8 Jun 2020 13:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v7Lry2cQx6GK for <>; Mon, 8 Jun 2020 13:38:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FD883A0FD3 for <>; Mon, 8 Jun 2020 13:38:56 -0700 (PDT)
X-Sender-Id: totalchoicehosting|x-authuser|
Received: from (localhost []) by (Postfix) with ESMTP id 205EF21AED; Mon, 8 Jun 2020 20:38:52 +0000 (UTC)
Received: from (100-96-137-11.trex.outbound.svc.cluster.local []) (Authenticated sender: totalchoicehosting) by (Postfix) with ESMTPA id E75C7213F5; Mon, 8 Jun 2020 20:38:50 +0000 (UTC)
X-Sender-Id: totalchoicehosting|x-authuser|
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.8); Mon, 08 Jun 2020 20:38:51 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: totalchoicehosting|x-authuser|
X-MailChannels-Auth-Id: totalchoicehosting
X-Occur-Reaction: 0c612bd114347c06_1591648731764_2951251985
X-MC-Loop-Signature: 1591648731764:3933705091
X-MC-Ingress-Time: 1591648731764
Received: from [] (port=55610 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1jiOXe-0003VM-In; Mon, 08 Jun 2020 16:38:46 -0400
Message-ID: <>
From: Steven Blake <>
To: "Black, David" <>, "" <>
Date: Mon, 08 Jun 2020 16:38:47 -0400
In-Reply-To: <>
References: <> <> <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4 (3.34.4-1.fc31)
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tsvwg] FW: path forward on L4S issue #16
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, 08 Jun 2020 20:39:00 -0000

On Mon, 2020-06-08 at 13:32 +0000, Black, David wrote:

> As an alternative, I suggest starting from Neil Cardwell's network
> and operator perspective (from 
> 	- L4S flows potentially causing unfairness in RFC3168 ECN bottlenecks has
> 	been mentioned as a potential concern. However, a robust RFC3168 ECN
> 	bottleneck should already have a mechanism to avoid unfairness caused by
> 	flows that are marked as ECT(0|1) and yet not performing RFC3168 responses.
> 	In particular, many of the large sources of known deployments of  RFC3168
> 	--  Linux fq_codel and cake -- are already deployed with fair queueing. In
> 	such bottlenecks L4S traffic should not cause harm to other non-L4S flows.
> 	Furthermore, if there really are ISPs with deployments of RFC3168
> 	bottlenecks that have neither FQ nor any other protection from
> 	non-RFC3168-ECT(1) flows, then they can bleach incoming ECT(1) code points
> 	to Not-ECT and treat L4S as Not-ECT (ISPs typically already transform the
> 	DSCP byte at their ingress anyway). So I do not see harm to RFC3168 ECN
> 	bottlenecks as a prohibitive concern.

My cursory examination turned up zero evidence that any major vendor
has implemented any sort of AQM/ECN "penalty box" fairness enforcement
mechanisms in carrier gear, at least above the access edge. If anyone
has some evidence, please speak up.

> 	- More generally, if there is any problem discovered with the L4S
> 	experiment, either the algorithm or particular implementations, bottlenecks
> 	can easily identify L4S traffic and bleach it into Not-ECT, and treat it
> 	like Reno/CUBIC traffic.

If there is even a non-trivial probability that this could be the
outcome, how can anyone argue in good faith that L4S traffic should not
be classified by DSCP?


// Steve