Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - kasten

#1
QuotePart of this is that ECN bits be transferred from end to end.

ECN bleaching is a problem, but seems this is pretty low, 88% keep the flag over internet traffic, according to Catchpoint's tests.


QuoteAlso lets not forget here for ISP to implement something like that takes ages. A lot of the ISPs didn't yet even implement LibreQos.... Or any AQM/SQM for that matter, just running FIFO with BW limitations.

Ya the bandwidth limit enforced by the ISP is almost always going to be the default bottleneck, since we are always trying to get the most out of the bandwidth we are paying for. Since we can't control the ISP's queueing logic what I believe is done with basically all the AQM/SQM strategies at the router level is to go under the bandwidth provided by your ISP so it's more effective. So while it would be helpful if L4S was also implemented by the ISP I don't think it is needed to get most of the benefits of L4S; as long it the app, its server, and the main bottleneck all support L4S.
#2
FreeBSD 14 supports some of the more important parts of L4S, such as AccECN. It is missing "TCP Prague" but having L4S support for UDP is really the bigger use-case.

I wasn't able to find out if FreeBSD has added any of the new AQM implementations L4s refers to, such as DualPI2, so maybe we have to wait on that part to land in FreeBSD first?

Anyway, based on the white paper listed below L4S provides much better queueing delays than the AQM implementations available in OPNSense today and interested in trying it out soon.


References
FreeBSD 14 supports parts of L4s:
https://freebsdfoundation.org/our-work/journal/browser-based-edition/networking-10th-anniversary/updates-on-tcp-in-freebsd-14/

L4S White Paper:
https://www.bell-labs.com/institute/white-papers/l4s-low-latency-low-loss-and-scalable-throughput/