Subject: Re: [tsvwg] L4S related activity in 3GPP
From: Sebastian Moeller <[email-masked]>
To: Ingemar Johansson S <[email-masked]>
Cc: "Holland, Jake" <[email-masked]>, Ingemar Johansson S <ingemar.s.johansson=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 10 Nov 2019 11:45:48 +0100
List-Id: Transport Area Working Group <tsvwg.ietf.org>

> On Nov 10, 2019, at 11:02, Ingemar Johansson S <[email-masked]> wrote:
> 
> Hi Jake, please see inline
> 
>> -----Original Message-----
>> From: Holland, Jake <[email-masked]>
>> Sent: den 9 november 2019 23:45
>> To: Ingemar Johansson S
>> <ingemar.s.johansson=[email-masked]>; Sebastian Moeller
>> <[email-masked]>
>> Cc: [email-masked]; [email-masked]; [email-masked]; Ingemar Johansson S
>> <[email-masked]>; [email-masked]
>> Subject: Re: [tsvwg] L4S related activity in 3GPP
>> 
>> On 2019-11-09, 11:24, "Ingemar Johansson S"
>> <ingemar.s.johansson=[email-masked]> 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