Re: [tsvwg] feedback and thoughts L4S / SCE

Mikael Abrahamsson <> Sun, 22 November 2020 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B49DD3A179F for <>; Sun, 22 Nov 2020 06:56:50 -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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KzUVKt3nkPbj for <>; Sun, 22 Nov 2020 06:56:48 -0800 (PST)
Received: from ( [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBF4B3A179E for <>; Sun, 22 Nov 2020 06:56:48 -0800 (PST)
Received: by (Postfix, from userid 501) id 1F860B3; Sun, 22 Nov 2020 15:56:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1606057006; bh=Bx5nxRVz+rwenwoHsLc0Rbe7pZemLBSJ9D+eImZ85ZI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UEeAjpr9eDDbbq1U2fIct6A8o0H54vnRhyIPQsYXqW9K8/Qr1VVTwCleR8DngceGJ aEY8NG/nJMqdfdKtyPYPYB/0ciJamg50LI3nO65hcHxWDYHOf3BotpsB554WXpofhw AMBPd7W7rkW4IpxgAI1KJ4/+AIj4selC9ufvOMao=
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A574B1; Sun, 22 Nov 2020 15:56:46 +0100 (CET)
Date: Sun, 22 Nov 2020 15:56:46 +0100 (CET)
From: Mikael Abrahamsson <>
To: Sebastian Moeller <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <>
Subject: Re: [tsvwg] feedback and thoughts L4S / SCE
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, 22 Nov 2020 14:56:51 -0000

On Sun, 22 Nov 2020, Sebastian Moeller wrote:

> just as a data point, OpenWrt switched to fq_codel as default qdisc on all interfaces some years ago.

And how often is this fq_codel the slowest link in the chain?

> I have no numbers how many OpenWrt devices are in the wild, and how many 
> commercial home router OSes are based on sufficiently modern OpenWrt, 
> but that is some use. The OpenWrt project also has no official counter

Most of the commercial openwrt based devices will not use CPU based 
forwarding (required to make fq_codel work) but instead has hardware 
accelerator (which does not do fq_codel).

> of running instances but for example Qualcomm's QCA Software Development 
> Kit (QSDK) is based on OpenWrt, so OpenWrt is more pervasive than one 
> would naively assume. That said, the QDSK kernel seems to be quite old 
> (at least Kernel major version 2 seems dead now), and I have no insight 
> which features are back-ported to it.

If you're using QCA hw-accelerated forwarding then you're not doing 

> 	[SM] Again a prediction, not a fact, as I said reasonably recent 
> OpenWrt defaults to fq_codel on all interfaces (that support it) as well 
> as on WiFi which with inceasing access rates more and more often becomes 
> the true bottleneck (no numbers, as that is my prediction, based on my 
> own experience).

If you're using HW acceleration, then fq_codel isn't used also on wifi.

> 	[SM] Given our lack of hard numbers that is telling more about your  judgement than about reality.

Do you have numbers? How many ISP provided routers out there actually use 
fq_* ? ISP provided router is the most common in use.

> 	[SM] And that is pretty harsh. Also unhelpful teminology, "irrelevant" I would accept, but invalid is simply the wrong quality to argue about.


> 	[SM] And here we are again at our lack of numbers... As before I share your intuition, but it is not a fact.
> "Fun" fact TCP Prague really is not at all suited to a FIFO world at all, as Pete demonstrated.

Do you have better numbers?

>> I also doubt we'll see widely deployed FQ going forward because of the cost of doing this in hw (and most devices are hw accelerated).
> 	[SM] An often heard claim that suffers from the fact that that has 
> simply never been tried at scale, so the cost argument reflects the 
> status quo not necessarily actual economic "laws", no?

Do you know of a FQ_* implementation in hardware?

> 	Also "wide-spread" use is again a claim that should be based on numbers (which cuts both ways, so applies to Pete's claim as well).

Thanks for ack:ing that.

> QUESTION: Where do you think most choke points live, at the ISP-end-user 
> boundary, deeper in the ISP's network, or even at exchange points? My 
> own limited experience points to the ISP-end-user edge, but that is 
> purely anecdotal.

The choke point is most often the customer last-mile access line or the 
wifi hop.

Mikael Abrahamsson    email: