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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/PyfpnQenULKAusrO_kWJi7xRHKI>
Subject: Re: [tsvwg] L4S related activity in 3GPP
Precedence: list



> On Nov 10, 2019, at 11:02, Ingemar Johansson S =
<ingemar.s.johansson@ericsson.com> wrote:
>=20
> Hi Jake, please see inline
>=20
>> -----Original Message-----
>> From: Holland, Jake <jholland@akamai.com>
>> Sent: den 9 november 2019 23:45
>> To: Ingemar Johansson S
>> <ingemar.s.johansson=3D40ericsson.com@dmarc.ietf.org>; Sebastian =
Moeller
>> <moeller0@gmx.de>
>> Cc: tcpm@ietf.org; tsvwg@ietf.org; iccrg@irtf.org; Ingemar Johansson =
S
>> <ingemar.s.johansson@ericsson.com>; koen.de_schepper@nokia.com
>> Subject: Re: [tsvwg] L4S related activity in 3GPP
>>=20
>> On 2019-11-09, 11:24, "Ingemar Johansson S"
>> <ingemar.s.johansson=3D40ericsson.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.
>>=20
>> Hi Ingemar,
>>=20
>> Not sure how closely you've been following, but the L4S team recently=20=

>> reported
>> fixing a bug in their implementation that might change this =
conclusion, and=20
>> you
>> probably should be aware of it if that's part of the driver here.=20
>> Specifically the
>> alpha was set to 1 instead of 0.
>> https://protect2.fireeye.com/v1/url?k=3D5f1e4a97-03ca43f1-5f1e0a0c-
>> 8610d8a762ca-aeefb3a777d636fc&q=3D1&e=3De1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2F
>>=20
> [IJ] That is the initial alpha and AFAIK, alpha is used in a similar =
way to=20
> how it is used with DCTCP. i.e. dictates how much CWND is reduced on =
CE marks.=20
> 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
>=20
>=20
>> 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=20
>> applied.
>>=20
>> The charts show some example differences on startup throughput (along =
with
>> the problematic RTT response that was fixed by this).
>>=20
>> With the fix:
>> https://protect2.fireeye.com/v1/url?k=3D6f13dc09-33c7d56f-6f139c92-
>> 8610d8a762ca-a748163f08dce827&q=3D1&e=3De1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&u=3Dhttps%3A%2F%2Fl4s.cablelabs.com%2Fl4s-
>> testing%2Fkey_plots%2Fbatch-l4s-s6-1-prague-50Mbit-80ms_var.png
>>=20
>> Without the fix:
>> https://protect2.fireeye.com/v1/url?k=3D5bfc2d0a-0728246c-5bfc6d91-
>> 8610d8a762ca-05cd77703d5d8069&q=3D1&e=3De1f0f0ad-9613-4463-9a7f-
>> a3b14a2b8481&u=3Dhttps%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=20
> alpha=3D1.0 the congestion window is reduced by 50%, whereas in the =
initial=20
> alpha=3D0.0 it takes a few round trips for alpha to increase =
sufficiently to=20
> reduce the congestion window. In the alpha=3D1.0 the congestion =
controls enter=20
> congestion avoidance and Additive Increase applies. I see that the =
current TCP=20
> Prague code does not implement the novel paced chirping (please =
correct) and=20
> 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


>=20
>>=20
>> Cheers and HTH,
>> Jake