Re: [tsvwg] feedback and thoughts L4S / SCE

Mikael Abrahamsson <swmike@swm.pp.se> Sun, 22 November 2020 14:56 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49DD3A179F for <tsvwg@ietfa.amsl.com>; Sun, 22 Nov 2020 06:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzUVKt3nkPbj for <tsvwg@ietfa.amsl.com>; Sun, 22 Nov 2020 06:56:48 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF4B3A179E for <tsvwg@ietf.org>; Sun, 22 Nov 2020 06:56:48 -0800 (PST)
Received: by uplift.swm.pp.se (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; d=swm.pp.se; 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 [127.0.0.1]) by uplift.swm.pp.se (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 <swmike@swm.pp.se>
To: Sebastian Moeller <moeller0@gmx.de>
cc: tsvwg@ietf.org
In-Reply-To: <9B5474B3-4384-4A20-81C3-5251246AA594@gmx.de>
Message-ID: <alpine.DEB.2.20.2011221548210.26384@uplift.swm.pp.se>
References: <alpine.DEB.2.20.2011201413100.26384@uplift.swm.pp.se> <9B5474B3-4384-4A20-81C3-5251246AA594@gmx.de>
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: <https://mailarchive.ietf.org/arch/msg/tsvwg/pu3MFayxyevfT_GVBqCTluAyZOQ>
Subject: Re: [tsvwg] feedback and thoughts L4S / SCE
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=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 
fq_codel.

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

Fine.

> 	[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: swmike@swm.pp.se