> L4S pulls this off by giving internet packets an indicator that lets them know if they’ve run into congestion or queueing along any of the hops in their trip between a user and whatever they’re connecting to.
Sounds a lot like ECN (RFC 3168) which was specified in 2001.
> It uses the Explicit Congestion Notification (ECN) protocol... Because ECN support is essential for L4S, senders use the ECN field as the protocol that allows the network to identify which packets are L4S and which are Classic.
> The IETF's Transport Area Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents describe a new architecture and protocol for deploying low latency networking.
I am rarely limited by the speed of light, even considering that it's much lower in fibre than in vacuum. On a good day I get pings twice as high in most online games; playing with friends on the other side of the Atlantic (which should be ~90ms for a round trip but often is 200) results in at least 10 additional frames worth of latency at 120Hz. Reducing the delay down to merely the speed of light would be a dramatic improvement!
(I'd still lose, but at least I wouldn't be able to blame it on lag any more... maybe not an improvement after all, hm.)
Most of the time is still in the hops. Every machine along the route and transitions into fibre and electrical cables is what is adding the time. In theory we can do drastically better than we do today with faster routing machines but latency hasn’t really improved very much for long connections despite all the advancements in the past 30 years.
Even electric signals are plenty fast enough. The issue as always is all the processing like modulation and demodulation. And ofc routing. Fibre does help with this as you can do longer distance without doing it.
> I'm no network expert but I thought it was relatively solved and problems are due to underprovisioning.
Protocols like TCP will ramp up to use all available bandwidth, ensuring there's congestion somewhere along the path. So you cannot simply blame everything on "underprovisioning". Bufferbloat is mostly solved in theory by AQMs like CoDel, but is still a problem in practice due to spotty deployment, especially for wireless links where congestion management is more complicated, and sometimes backbone links that are fast enough any congestion management needs to be implemented in hardware.
Read the article "As Mitchell explains, it can’t bend the laws of physics to make data travel faster than the speed of light, but it can reduce the extra delays in the middle that have been slowing your connections down."
Your latency issues aren't due to the speed of light
Most latency isn't caused by SOL restrictions. It's usually the repeaters, firewalls, routers, and packet queues that slow things down. It only takes 103ms for light to circumnavigate the globe. However, latencies at only half that distance are over 500ms due to router latency.
Starlink is pretty good for communicating with the other side of the globe because of their routing over laser comms. I've known professional gamers that use it to reduce latencies to servers in Asia and the Middle East.
> I thought it was relatively solved and problems are due to underprovisioning.
You are right, ~universally so. However, the author is trying his middle-school best to convince us otherwise.
While bandwidth upgrades (ex: d/u to broadband) have increased the amount of information transmitted, this change will actually make the internet feel faster for once.
What made my home internet feel faster was going from cable to fiber. Because fiber is faster in capacity and latency. And my fiber is faster all the time, not just "for once".
Comcast's technical side does a lot of interesting work: they were one of the first big ISPs to roll out IPv6, for instance. Not saying they're on the whole a benevolent (or even trustworthy) corporation, but these sorts of things don't need to warrant immediate suspicion.
No, it's just some incremental improvement. Anyone forwarding traffic needs some kind of congestion control system. This is just another implementation of it.
This was the engineering explanation for repealing net neutrality that my Networking Professor in University explained to me. You want to ship some cargo over plane, some over ships, and some over trains - so why wouldn't network packets be any different?
> explanation for repealing net neutrality ... You want to ship some cargo over plane, some over ships, and some over trains - so why wouldn't network packets be any different?
To make this analogy fit better, let's re-imagine each transport method as having similar cost.
The answer is that neutrality would prohibit cargo corp from rerouting cargo over slower ship...
1) when there is no logistical necessity to do so
2) because there is loads of available air-transport capacity.
Even if doing so yields fatter dividends for stockholders and execs.
>Disclosure: Comcast is an investor in Vox Media, The Verge’s parent company.
I have no idea why Comcast gets to take the credit for "fixing the internet", whatever definition they use for that. Among several other companies, Comcast Innovation "partly funded" the work that went into the RFC (https://datatracker.ietf.org/doc/rfc9330/), and that's it.
Nokia, Vodafone, Apple, Intel, and others have been pushing for L4S (and implementing it in some areas) for a bit now. Comcast isn't even the first.
Sounds a lot like ECN (RFC 3168) which was specified in 2001.
reply