Re: [tsvwg] feedback and thoughts L4S / SCE

Sebastian Moeller <moeller0@gmx.de> Fri, 20 November 2020 20:02 UTC

Return-Path: <moeller0@gmx.de>
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 809103A1083; Fri, 20 Nov 2020 12:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 6W18VH5aMKWE; Fri, 20 Nov 2020 12:02:00 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 99ED23A13E0; Fri, 20 Nov 2020 12:01:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605902466; bh=I1h3pldvfnYyyi0Znm0RfZA63IviWya+37uG3u4Kpbc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=U9evXvasXSgjJs6fsDuFCxh8PODehFjm51xFCjap33FHw2Jst3N0+UpzbnYRWpTOm LW6P/cQGkjKbv4H18NtGqmwwwviw8TpSUpddTb9wHPUH0oXN8trfhDOGluFINtHCwO cwJ77xLXLm1Wqwwb2IeaGvlMlZwgg7ZYeHe8Wt/8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.42.229] ([95.112.53.208]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MC34X-1kWYcp1sQH-00COe8; Fri, 20 Nov 2020 21:01:06 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <1837E430-3CC1-4C90-A1B4-EAC5062FB609@cablelabs.com>
Date: Fri, 20 Nov 2020 21:01:03 +0100
Cc: Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <68BAC380-1BB6-46FB-85B7-4887C177B906@gmx.de>
References: <alpine.DEB.2.20.2011201413100.26384@uplift.swm.pp.se> <1837E430-3CC1-4C90-A1B4-EAC5062FB609@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:AJ5ixrKFgNE9lVEzwJx2AcXS1+u++fESCh1PX6vbt0eG6KHZYvf Vq0x8Xt1ZpxBazLnl3IY71qnpoieBWGfvo1x2P30K02G/cLs4ckuKsh1BT8js/xELnivlJS eleuzFRZ6a7Qb3dOusXX1ml13iwtMakXFXjA3ftkkgYJpyL/BV8LPEOfQOhYlLcqrAagY1f Gvp2fNHyxDN2nLDybhWIA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:l+GCYf/mQ8o=:DGED1gLMfVKiA9h4JBRpD7 yR1cZE4sRtQ3Ca9fKh7I8ZvCfWE2RWTQGLyNV21kMLV+hMfCFzhPuLHewjcSBpWqv9W7zkAGu eqsZGmQOOPJPUtuFq6jTz1zaj/QJl7cDrN23FVkRcRMZbBxxze3tu+kBIpp/hGxE7DWC+x7Yk npomh86dVVf/t+/I1MT3wd3wJ2w33AN17GKEiVHiE1fjoLuxBXjZQFOKJDUWOrdSQJzTeOCSs iXObLpJlXEkKFIF6ZDovGf7N4Sus0qr5SVhE/COiLe5JRcp+GVCVLGZ8JEyIN3fUry0HhNjU6 R8uj9xtEa+iZZ+2Xs4sVG40HoebVNaGy6KO8S7oI8ciLiEPMewbs0ZsRun9Er9pNg484HnJOn K9ccEkuRPrWokVfvNaSvGccLVt/QmehHy1ufoli/neizjLfS+PnU8rRBXSJ2GhQ9S7t5LCtPV jLw9YRPRgJEG0a+bwtsE/oxZU9qSSxjQRUkmElxAvy0t5jP8/g8WKyKXn5PUNAFE5NajUoH7k CBwX8WEruthJR9urG8XcplgjWX8nJB3rsan45CJbSQiQ1cmpN6JerWXqZNPIE0QK2kvgkxGRj lhATIMeDmug9j9ViBMo12UQ2mfusbWU4KxuujmgYocKSjPmTgOx37SPrHCw9oJjUUJsGPEqP/ WSlRQil+76WE/MS4nIE5Hes5x78SDYEK1Drp9UAjhy/xYVUkB1TYLCHyDdG+pBUInUbPIvz0t SnFhuyK880szSc3atFYxjjTWxcndnUACmcSZDzqKoHBHz+fAxocs5/oTQYUPvaT3wwt3HJQhM 2Y8oIDrvmHasarAudNQeYbkja4+OdHR3rlQ3KJO9mD9rzQ5JjfmdrKqh/YeJm4Hkrsn5zrV1s /OKmUNtSr2yHkkm74tRg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/kArTfqairsgUtWzsbF-k3b831mU>
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: Fri, 20 Nov 2020 20:02:03 -0000

Hi Greg,



> On Nov 20, 2020, at 20:38, Greg White <g.white@CableLabs.com> wrote:
> 
> Hi Mikael,
>  
> On your point about L4S in non-ECN FIFOs, I agree that these will dominate in the Internet for quite some time. But, I don’t believe there has been any evidence of lack of safety for L4S-compatible CCs in those bottlenecks.

	[SM] Correct, that is not s much a case for not being safe but rather for TCP Prague not delivering on its promises:

http://sce.dnsmgr.net/_archive/l4s-2020-11-17T164559-s1-rtt-update/l4s-s1-rttfair/l4s-s1-rttfair-ns-cubic-vs-prague-pfifo_1000_-50Mbit-160ms-10ms_tcp_delivery_with_rtt.svg

http://sce.dnsmgr.net/_archive/l4s-2020-11-17T164559-s1-rtt-update/l4s-s1-rttfair/l4s-s1-rttfair-ns-prague-vs-cubic-pfifo_1000_-50Mbit-160ms-10ms_tcp_delivery_with_rtt.svg

Cubic wiping out (but not "completely starving") TCP Prague in a FIFO with one flw @160ms RTT the other at 10ms. So TCP Prague in a non-ECN fifo gets ~1:4 of the available bandwidth. Let's not talk about latency, since without an L4S AQM TCP Prague is not a low latency transport protocol, to be generous.

That is less of a safety concern and more of a can L4S actually deiver on its promises issue.

Mind you Koen's proposed solution is to make TCP Prague automatically switch to a CUBIIC like CC response once RTTs are >= 80 ms, a clear sign of defeat if any. L4S is a short fast-lane, not more (and not less) in spite of being marketed as the "future" of the internet...






>  It is, in fact, a requirement in the ECN-L4S-ID draft that CCs respond to loss in a Reno-safe way.
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-12#section-4.3

	[SM] Sure and in the FIFO TCP Prague at least does no harm to CUBIC, but the ask by Lars was show do no harm AND deliver on its promises. For a change, with FiFO is not L4S being to aggressive.


>  
> What has been argued is that the current TCP Prague prototype CC responds to loss *exactly* like Reno, and so is outcompeted by Cubic in these bottlenecks (see the pfifo results in https://github.com/heistp/l4s-tests#network-bias ).

	[SM] Basing TCP Prague on DCTCP was a conscious choice of team L4S, with data indicating than basing on Linux' defsau;t TCP might have been a better approach, but it is what it is.


>  
> If you attended Bob & Koen’s talk in ICCRG (https://datatracker.ietf.org/meeting/109/materials/slides-109-iccrg-prague-congestion-control-00) you saw that they mention (slide 9) “faster than additive increase” as an aspect that is not currently included in the Prague CC.  They also mention (slide 15) “Integration with BBR/Cubic instead of Reno” as a possible area for others to contribute. 

	[SM] So also "not tested" at all. Or put differently, not clear if actually achievable,  like RTT-independence.... (which generically is no achievable from a connections end-points)

Best Regards
	Sebastian

>  
> -Greg
>  
>  
>  
> From: tsvwg <tsvwg-bounces@ietf.org> on behalf of Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org>
> Organization: People's Front Against WWW
> Date: Friday, November 20, 2020 at 6:34 AM
> To: "tsvwg@ietf.org" <tsvwg@ietf.org>
> Subject: [tsvwg] feedback and thoughts L4S / SCE
>  
> Hi,
>  
> 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:
>  
> https://github.com/heistp/l4s-tests
>  
> "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 
> reasoning.
>  
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se