[Ecn-sane] l4s threats

[Sebastian Moeller]

Hi Dave.

Thanks a lot. I seems that the predicted "allergy" against bursty traffic indeed exists in L4S implementations in the field. This IMHO is problematic, given that some applications that are interested in low latency are also interested in sending bunches of packets ASAP, or put differently in bursts...

Happy that actual research is done on this by outside groups that have no pony in the race. However I am not sure that their stated goal of retrofitting detection of and counter measures against bursty flows is going to solve the problem that a number of bona-fide low latency use-cases are also bursty.

To put it bluntly, L4S seems having been developed without a deeper understanding of what kind of low latency service (at least some type of) applications actually desire/require. Puzzled as so often, on why this is being forced through the IETF process in spite of looking like it at best is half-baked.


Regards
	Sebastian


> On Jul 10, 2022, at 22:29, Dave Taht via Ecn-sane <ecn-sane at lists.bufferbloat.net> wrote:
> 
> https://assets.researchsquare.com/files/rs-1713495/v1_covered.pdf?c=1654295892
> 
> -- 
> FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane