Re: [iccrg] [tsvwg] L4S related activity in 3GPP

[Sebastian Moeller <[e-mail]>]

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