Re: [tsvwg] L4S related activity in 3GPP

Sebastian Moeller <moeller0@gmx.de> Sun, 10 November 2019 10:46 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 CD3A612003E; Sun, 10 Nov 2019 02:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
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: 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 rLdUdDzIgJ4e; Sun, 10 Nov 2019 02:46:12 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BC3E1200BA; Sun, 10 Nov 2019 02:46:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; 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 ([77.3.68.102]) by mail.gmx.com (mrgmx004 [212.227.17.190]) 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 <moeller0@gmx.de>
In-Reply-To: <HE1PR07MB4425AC20F458B38EB3AF12C9C2750@HE1PR07MB4425.eurprd07.prod.outlook.com>
Date: Sun, 10 Nov 2019 11:45:48 +0100
Cc: "Holland, Jake" <jholland@akamai.com>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "iccrg@irtf.org" <iccrg@irtf.org>, "koen.de_schepper@nokia.com" <koen.de_schepper@nokia.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <577095C3-EE27-40D6-9A8C-662DACEA1A5C@gmx.de>
References: <HE1PR07MB4425A148B5BB1E6FD8E5A3FBC27A0@HE1PR07MB4425.eurprd07.prod.outlook.com> <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de> <HE1PR07MB4425DD6FE15DB130B24BCEA1C27A0@HE1PR07MB4425.eurprd07.prod.outlook.com> <764B1E43-7B86-4BAE-9FA2-CA5B56A73047@akamai.com> <HE1PR07MB4425AC20F458B38EB3AF12C9C2750@HE1PR07MB4425.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
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: <https://mailarchive.ietf.org/arch/msg/tsvwg/PyfpnQenULKAusrO_kWJi7xRHKI>
Subject: Re: [tsvwg] L4S related activity in 3GPP
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, 10 Nov 2019 10:46:14 -0000


> On Nov 10, 2019, at 11:02, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> Hi Jake, please see inline
> 
>> -----Original Message-----
>> From: Holland, Jake <jholland@akamai.com>
>> Sent: den 9 november 2019 23:45
>> To: Ingemar Johansson S
>> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>rg>; Sebastian Moeller
>> <moeller0@gmx.de>
>> Cc: tcpm@ietf.org; tsvwg@ietf.org; iccrg@irtf.org; Ingemar Johansson S
>> <ingemar.s.johansson@ericsson.com>om>; koen.de_schepper@nokia.com
>> Subject: Re: [tsvwg] L4S related activity in 3GPP
>> 
>> On 2019-11-09, 11:24, "Ingemar Johansson S"
>> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> 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.
>> https://protect2.fireeye.com/v1/url?k=5f1e4a97-03ca43f1-5f1e0a0c-
>> 8610d8a762ca-aeefb3a777d636fc&q=1&e=e1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&u=https%3A%2F%2Fl4s.cablelabs.com%2F
>> 
> [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
> https://github.com/L4STeam/linux/blob/testing/net/ipv4/tcp_prague.c
> 
> 
>> 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:
>> https://protect2.fireeye.com/v1/url?k=6f13dc09-33c7d56f-6f139c92-
>> 8610d8a762ca-a748163f08dce827&q=1&e=e1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&u=https%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
>> testing%2Fkey_plots%2Fbatch-l4s-s6-1-prague-50Mbit-80ms_var.png
>> 
>> Without the fix:
>> https://protect2.fireeye.com/v1/url?k=5bfc2d0a-0728246c-5bfc6d91-
>> 8610d8a762ca-05cd77703d5d8069&q=1&e=e1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&u=https%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
>> 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
	Sebastian


> 
>> 
>> Cheers and HTH,
>> Jake