[muxamilian]

While it's a step in the right direction, there's a problem if there's at least one 'malicious' actor, who ignores the congestion feedback and just wants a larger share of bandwidth. Then all other actors will retreat and the unfair actors get what they want. Unfortunately it is hard to know for a good actor if the other actors are playing nicely or not. Only if a good actor knows that there's fair queuing, they can trust L4S to treat them fairly.

This can be solved by complementing L4S with fair queuing (e.g. fq_codel) and by making sure that congestion control can detect the presence of fair queuing (https://github.com/muxamilian/fair-queuing-aware-congestion-...).

[ajb]

To clarify this - most ISPs implement per customer bandwidth allocation, so a malicious actor should not be able to take share from other customers.

The FQ thing is a part of a larger dispute. Without FQ is is already the case that, irrespective of L4S, fairness is implemented by end hosts, and an end host (eg a server) can ignore congestion responses and take more than a fair share. This is not an issue which L4S introduces, but some argue that L4S "makes it easier" to take a larger share.

The people behind FQ argue that the network should guarantee fair sharing, but not everyone believes they have chosen the right fairness metric. In particular one of the main proponents of L4S does not, as can be seen from his paper linked here: https://news.ycombinator.com/item?id=38598023

[qmarchi]

> most ISPs implement per customer bandwidth allocation

This really should have an asterisk (*). There is generally a limit on what an ISP will advertise, and what they will provide (usually ~110% of advertised).

However, it's also extremely common that they overprovision segments on their network.

In the case of a Coax network like Comcast, or Spectrum, they will overprovision the actual last-mile capacity so that _most_ times of the day, you'll receive your ~110% of advertised speeds, but during peak (mid-evening), it's extremely unlikely that you're going to receive even your advertised speeds, usually only ~70%.

In the case for L4S, it would absolutely help "perceptively" resolve these kinds of congestion points, but the "evil take" would be that ISPs can extend their network upgrades further.

[ajb]

That's a different issue though. I should have been more precise with my terminology. The way it usually works is that there is a scheduler at the bottleneck. Let's for simplicity assume that the customers at a particular bottleneck have all got the same advertised rate, but the bottleneck is less than the sum of these. Say there are 10 customers with 100Mbps each but the bottleneck is only 500Mpbs. Then if each of the 10 customers are maxing out their usage, they will each only get 50Mbps, which is less than the advertised rate on their service. What I meant was, playing games with congestion control won't reduce any other customer below that. (There are different options for how the scheduler could work if the customers have different limits; it could just cap them to their limit, or it could weight their share according to their limit).

I guess you are right that buffer bloat problems could pressure ISPs to avoid overprovisioning, and any solution to bufferbloat could take the pressure off. But you can also get bufferbloat and other latency issues without overprovisioning, so it doesn't seem to me to be a good reason to hold off implementing solutions to them.

[Hikikomori]

Where do they implement this?

[ajb]

Sorry, I've referred to multiple things in that comment - which are you asking about?