[tsvwg] feedback and thoughts L4S / SCE

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 20 November 2020 13:33 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AEAB13A07D1 for <tsvwg@ietfa.amsl.com>; Fri, 20 Nov 2020 05:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H3=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Z7NGQDsy4s1C for <tsvwg@ietfa.amsl.com>; Fri, 20 Nov 2020 05:33:45 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se []) (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 9B6E53A07DE for <tsvwg@ietf.org>; Fri, 20 Nov 2020 05:33:45 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9BC54B9; Fri, 20 Nov 2020 14:33:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1605879222; bh=y2Hc+BzlbPKITI4vrl1Fjv5fQsZIu4DzqKU9gnBBjOI=; h=Date:From:To:Subject:From; b=ysGqsrDho4GHy1k4j+uN7IsQxaYE0LS8KdkxvaMrDNyWmKL6JsG+6/GPAtDCBxZgf b8MmVDxCCB/u6opGzipjwrWv6IFl0xl21/k6Kz0EHdJqWaldqJ+mejRRgv5Hy8RDdU XUP4Jj050B3t/EUs7iJWVt4Eh5VmJqztnhnfHcqA=
Received: from localhost (localhost []) by uplift.swm.pp.se (Postfix) with ESMTP id 985CCB8 for <tsvwg@ietf.org>; Fri, 20 Nov 2020 14:33:42 +0100 (CET)
Date: Fri, 20 Nov 2020 14:33:42 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: tsvwg@ietf.org
Message-ID: <alpine.DEB.2.20.2011201413100.26384@uplift.swm.pp.se>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3hDbu1Wa8kML8CzKIJVOVu0b80o>
Subject: [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: Fri, 20 Nov 2020 13:33:49 -0000


I'm trying to catch up on the work has been done, but I thought I'd give 
some thoughts / feedback on what I see:


"L4S transports experience intra-flow latency spikes at RFC3168 
bottlenecks, particularly with the widely deployed fq_codel"

FQ_CODEL isn't widely deployed. Yes, it's enabled in the linux kernel but 
very seldom at the bw chokepoint of the connection. I do not agree with 
the above statement at all. Thus any benchmarking vs FQ_ anything is 
invalid. What's mostly used today are typically simple FIFOs, sometimes 
diffserv enabled with multiple FIFOs.

This means the tunnel argument against any FQ or non-FQ AQM is invalid. 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).

"Deployments of fq_codel
The fq_codel qdisc has been in the Linux kernel since version 3.6 (late 
2012) and is now in widespread use in commercial routers (e.g. Ubiquiti 
EdgeMAX and UniFi products)"

This is misleading. Yes, EdgeMAX supports FQ_CODEL if you turn off 
hw_acceleration, bringing down the performance to 10% or less of what the 
hw acceleration yields. I do not agree that it's in "widespread" use.

I'd gladly take data to prove me wrong, that FQ_CODEL is in widespread use 
at Internet bw chokepoints. I'd be surprised if it was enabled on more 
than 1% of residential connections.

On to L4S.

Now, taking above statement and looking at what L4S is doing, for 1-2 
decades going forward L4S enabled transport will often encounter FIFOs, 
mostly without ECN capability at all. They need to be proven safe in this 
operational reality. From what I can see, this is still not the case?

Going forward:

In order to progress to a solution, we need to have participants agree on 
what the world looks like right now, what's doable in the next few years, 
and what's required to handle existing/near term reality. SCE proponents 
have to stop arguing that we'll have FQ_ anything near term, or that this 
is in wide use. It's not. L4S proponents need to prove that their 
proposals are safe in a world of FIFOs, and accept that this is going to 
be a reality for years to come. AQMs aren't deployed in a hurry, we're 
talking many years to deploy on the wider Internet.

We're spending the last bit in the IP header and we'd better get it right. 
In order to do that, I'd like to see realism and pragmatism in the 

Mikael Abrahamsson    email: swmike@swm.pp.se