L4S is not really an express lane. It is a way for applications to know when their traffic is congested, enabling them to scale DOWN their traffic to alleviate the congestion. Less congestion means less latency.
TCP congestion control relies on packets being dropped to signal that a link is congested.
L4S actually includes an extra bit of information in IP packets that routers can mutate to explicitly say when they are congested.
This means that you (a) don't need to play exponential backoff games, (b), don't need to re-send redundant packets, and (c) don't need big buffers in routers.
You need big buffers in routers because otherwise exponential backoff goes crazy. But when you add big buffers, you get latency, which is another kind of suck.
In order to avoid latency, you need to avoid buffers, which is hard unless you avoid exponential backoff. To avoid exponential backoff, you need routers to actually communicate their congestion, by sending more information. L4S does that by using an unallocated bit in IP packets.
I'll need to read up on this, but one potential misuse of this is to just always/often set that bit on traffic you want to suppress.
Which feels much easier and much less heavy-handed than what you can to today. Which technically is a great thing but just wondering about misuse aspect.
This signals congestion explicitly, by a device declaring the link congested and asking others to slow down. TCP congestion control works by detecting when packets are dropped because devices can't keep up.
Also, when the congestion signal disappears you can try to push the transfer speed up immediately, rather than slowly ramping back up like with TCP.
The slowest part is likely to be the network component, and there you can look at the experimental deployment by Comcast, that others have linked to in comments. So far I have not heard of moves by other network providers. Apple already has experimental L4S support for QUIC and TCP: https://developer.apple.com/documentation/network/testing_an...
Congestion control with TCP will eventually still need to send the same number of bytes down a pipe, albeit with added latency. After a while an application could notice and make a change, but it would be long enough for a user to notice poor service.
They already did that, L4S or no. "Fast lanes" usually come in the form of peering links or colocated cache servers, both of which involve actual new capacity. Prioritizing individual flows of traffic over ordinary transit links based on monetary value is something IP is uniquely ill-suited to do.
> "Not sure where this leads but I guess ISPs will start charging toll for express lanes"
Doubtful IMO. I think latency becomes another competitive differentiator, much like throughput/speed is today. (this is a personal comment but I work at Comcast)