Subject: Re: [tsvwg] L4S related activity in 3GPP
From: "Holland, Jake" <[email-masked]>
To: Ingemar Johansson S <ingemar.s.johansson=[email-masked]>, Sebastian Moeller <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Ingemar Johansson S <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 9 Nov 2019 22:44:54 +0000
List-Id: Transport Area Working Group <tsvwg.ietf.org>

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://l4s.cablelabs.com/

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://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s6-1-prague-50Mbit-80ms_var.png

Without the fix:
https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s6-prague_alpha-prague-50Mbit-80ms-alpha0_var.png

Cheers and HTH,
Jake