Re: [tsvwg] Bi-directional asymmetric link test results, and Prague self-starvation

[Sebastian Moeller <[e-mail]>]

Hi Pete, hi list,

Thank you very much for this comprehensive set of tests that constitute a ton of work.


I have been claiming that L4S offer relatively little over the status quo in AQM for home networks and I want to point the lists attention at comparing the performance of different solutions for a traffic scenario that I consider important, bi-directional traffic on an asymmetric link at saturation (call it, the corona test). I will restrict myself to the 10/200 Mbps tests at 80ms RTT as these seem to be typical values for end-users accessing servers over the internet (as compared to a "highway to the nearest data center").

1) http://sce.dnsmgr.net/results/ect1-2020-05-08T084306-s8-s9/l4s-s8-bidir-asym/l4s-s8-bidir-asym-ns-cubic-dualpi2-10Mbit-200Mbit-80ms_all_scaled_delivery.svg
testing dualpi2's classic queue

2) http://sce.dnsmgr.net/results/ect1-2020-05-08T084306-s8-s9/l4s-s8-bidir-asym/l4s-s8-bidir-asym-ns-prague-dualpi2-10Mbit-200Mbit-80ms_all_scaled_delivery.svg
testing  dualpi2's LL queue

3) http://sce.dnsmgr.net/results/ect1-2020-05-08T084306-s8-s9/sce-s8-bidir-asym/sce-s8-bidir-asym-ns-cubic-cake-10Mbit-200Mbit-80ms_all_scaled_delivery.svg
testing cake with cubic flows


Comparing 1) with 3) makes it clear that L4S' classic side AQM performance is underwhelming, both for aggregate download though-put as well as latency under load increases.

Comparing 2) with 3) demonstrates that L4S' LL queue with its own preferred reference transport protocol manages to keep latency under load increase in the same range as standard fq-cake can with cubic, and that interflow differences in 2) approach starvation levels (@team L4S have you ever tested that, like at all?). 

Looking at the same plots with an RTT of 20ms, dualpi2's classic queue still performs considerably worse, and dualpi2's LL queue looks at best equal to what cake can do with bog-standard CUBIC.


	In summary under these conditions and assuming the tests correct (which I have zero reason to doubt) L4S offers little to no advantage over the state of the art. I dare say it, "the emperor has no clothes".

	Now, I would wish that everybody here proposing that L4S considerable side-effects are acceptable, clarifies in their own mind what gains in L4S justify that trade-off. And since the trade-offs are real, please consider actual L4S performance and not descriptions from L4S' RFCs (unless demonstrated to be achievable in the real world these are really just promises).

Best Regards
	Sebastian

P.S.: I note again, that my claims do not involve SCE at all, this is really comparing L4S against existing tested AQM technology and against its own claims. At the current time I personally see zero rationale to permit L4S with any side-effects at all.