Re: [tsvwg] L4S related activity in 3GPP

Sebastian Moeller <> Sun, 10 November 2019 10:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD3A612003E; Sun, 10 Nov 2019 02:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rLdUdDzIgJ4e; Sun, 10 Nov 2019 02:46:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BC3E1200BA; Sun, 10 Nov 2019 02:46:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1573382757; bh=MQNXkE+7Erdo3+UgR8OuABz1iDI/SSmy65Re4hN/wHs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=LH3SkbI8UPS1ese4MLpYL54vmAReV8SrRu2Wno1xU+4A8fgBJ2nfYmFIp0s2KPmeM DMHFQ0t07PD1WZSDju6auZ5pVvgINm0Y7qNJBFZtY9NriKCfW3XqHECuPviPpd4/yS yNMBlyw8QBr9bheJVjGJSSkNc0AxbZoHeiYr7Wx4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1MEm6L-1iiIec1Oah-00GLsH; Sun, 10 Nov 2019 11:45:57 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Sun, 10 Nov 2019 11:45:48 +0100
Cc: "Holland, Jake" <>, Ingemar Johansson S <>, "" <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:prLFeoF5c7/7T8S7lmCicN7UX3MjDpmGTOFYsZtQGxkh9HNAkSx l/JdH1P/EUQg6Du7/urSfm5eFhaoorW9cLzi6AOqrJeSdHuvTM60+o+HcgiqbrQxuJ4St8+ KtF6H+HVkEiOtIfpJB2lLL7gWVGe/xyEOXR3D76i3ksdFpYvu9PQHiz7qosj81gwPNSC1FO oRltcsejJuDipwBiLA9kw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:xl4psjJ1Ykw=:3s7R/CZRvhxM0bkjBARR/s 1P4pwJmIvmnCB4RcVgJaHOcEgtxrK26GjrrJid74sE5bgUJuf/F+CwZbY0GqcM46kKrbqKmn5 OsY86Za6Bm+wdzUNuA0Y8YBsLCmRNXwbqo+SAoww29kmx04roPd2ki7TmxPQ63GlFozCFYAP1 m9sQIXjxpoDtUD2QWFQE99HmGuep+WxHKa/1SPEjLNtiDm1JeoXGT1cUonHL7fxNCCCK6mz2L IRwp94sVwZdvCPQo36i+RiEuu4Zjf8DaKovxm913q0ovb4pz+pSi5P9NR6O7YImSgCgE8ow9G TAt5hiqJC1lmA3qNLg9ZHHPL4leo35asLd3rHBRRQH/LluFQHjGpHsEmJPWxKt2tAGMFVIYFV QF6wX9NNrIElf8tSZj2h8glV3s+HjY2ps9hpxTufucIP/FyUK/5LZQC+l9/QrVEwRsLVFrK8Q y2OiTCZTvAsSRKhrhlNvJ0wWHreMPuWuVCHI28MvKRsJBhyb3Ls6M81z7pyZe0WgZoQNoWmzw m7Xa05V8bvMWCXkCZxudTNtx0/2yYC23qx+e93At+jcVvq5Ssif2ATZ5NHxg8lvnfuo8uyt4S 7dpPILAHMFj5Qxr3w3ZfYmVyXHBUNqHtyGghi1/P0a1mvn00j5lPxrYm5KlK0ZXrn+aC6CaYu U/jd0rYKnf0jpdXdmWl6t6Yi0bgtwKaVIaw909jKmVsZT2WbRMq5l9W+yTOnPpppIfpNJyKjn TDFQAFb3dz9vZk5EeKXlvTxRdStKnFB25nuLAJL77yR9c7HDPAcmnmsERAvIm9ofeDKaIbEWD w8o/VeG4JpCtLox+GhOxJG4zgDxZngBtp3GCk0Ql0glPipxrBDh5Sl7LytuTMivOHXzuHQgQF 8bIe0lW6krEEMIkLz9DXxekWBj0z0WMDnMBktDVPnIBU3Xh85aeM//seadMANvY0oOTqQ2H8Q Ua0HXvwF2sXBR+4+v9AAPmXVG/7N7CgSj/vWOz2GWwV7hkDGdtErlZahyGapRwyEAMJHewxYP 3JHXbSHv7BrB8kjm+J1svbImTZWMboKY6DSe+MzkB0cGQIuFJUwBx9BPV7HaqNIm6n17F+ABn bnL9uQ8VXeSsJ3r/nhga1O3JXlDGyfm1lSvAhCKLwIcljsuCCf0RbUQAH2mvoJ2tUlxGorrq7 +t8ZcISQlLNe2k/Dq2iMhWauHbvVGJ00amr/PMXKfVRwLOAP2xSBUkuCFOjIVYakF4+m4+6Nm Yg1bnKxuu0CqGjxMBhBTIiuaLVkHK1Ugg+x5Ja1J4phb49ApgFJ3c++8CcNg=
Archived-At: <>
Subject: Re: [tsvwg] L4S related activity in 3GPP
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, 10 Nov 2019 10:46:14 -0000

> On Nov 10, 2019, at 11:02, Ingemar Johansson S <> wrote:
> Hi Jake, please see inline
>> -----Original Message-----
>> From: Holland, Jake <>
>> Sent: den 9 november 2019 23:45
>> To: Ingemar Johansson S
>> <>rg>; Sebastian Moeller
>> <>
>> Cc:;;; Ingemar Johansson S
>> <>om>;
>> Subject: Re: [tsvwg] L4S related activity in 3GPP
>> On 2019-11-09, 11:24, "Ingemar Johansson S"
>> <> wrote:
>>> One being that it can enable congestion control algorithms to quickly
>>> grab free capacity. 5G access can have large variations in link
>>> throughput for example related to dual connectivity and L4S can be
>>> helpful here as well.
>> Hi Ingemar,
>> Not sure how closely you've been following, but the L4S team recently 
>> reported
>> fixing a bug in their implementation that might change this conclusion, and 
>> you
>> probably should be aware of it if that's part of the driver here. 
>> Specifically the
>> alpha was set to 1 instead of 0.
>> 8610d8a762ca-aeefb3a777d636fc&q=1&e=e1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&
> [IJ] That is the initial alpha and AFAIK, alpha is used in a similar way to 
> how it is used with DCTCP. i.e. dictates how much CWND is reduced on CE marks. 
> It does therefore not affect the ramp-up when more capacity becomes available
>> Changing this to avoid some problematic behavior also causes a  more gradual
>> throughput ramp instead, so you might want to re-test your conclusions about
>> how fast it can converge on the fluctuating capacity after that bug-fix is 
>> applied.
>> The charts show some example differences on startup throughput (along with
>> the problematic RTT response that was fixed by this).
>> With the fix:
>> 8610d8a762ca-a748163f08dce827&q=1&e=e1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&
>> testing%2Fkey_plots%2Fbatch-l4s-s6-1-prague-50Mbit-80ms_var.png
>> Without the fix:
>> 8610d8a762ca-05cd77703d5d8069&q=1&e=e1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&
>> testing%2Fkey_plots%2Fbatch-l4s-s6-prague_alpha-prague-50Mbit-80ms-
>> alpha0_var.png
> [IJ] This looks like the normal exit from slowstart to me. With an initial 
> alpha=1.0 the congestion window is reduced by 50%, whereas in the initial 
> alpha=0.0 it takes a few round trips for alpha to increase sufficiently to 
> reduce the congestion window. In the alpha=1.0 the congestion controls enter 
> congestion avoidance and Additive Increase applies. I see that the current TCP 
> Prague code does not implement the novel paced chirping (please correct) and 
> that can change the behavior a lot.

	[SM] has any one actually tested paced chirping (PC) over real-life bonded links? As far as I can see PC pretty much relies on a) little to no re-ordering of packets (weird given that L4S also wants to allow larger re-ordering tolerance by recommending/mandating the use of RACK) and b) that the packet delivery time of each packet reflects a common path characteristic (which is less true for a bonded link).
	IMHO this just another piece of insufficiently tested technology thrown into the hodgepodge that is L4S. The way I see it, L4S combined a number of clever ideas, that might work out in reality, but might also be "too clever" for the internet.

Best Regards

>> Cheers and HTH,
>> Jake