Re: [tsvwg] L4S related activity in 3GPP

[Ingemar Johansson S <[e-mail]>]

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.

>
> Cheers and HTH,
> Jake
>