3 ms·
Can someone explain this to a layman? Because it seems to me the four solutions proposed are: 1. Seeing the future 2. Building a ten times higher capacity netw
by fmbb 2y ago
Can someone explain this to a layman? Because it seems to me the four solutions proposed are:
1. Seeing the future
2. Building a ten times higher capacity network
3. Breaking Net neutrality by deprioritizing traffic that someone deems “not latency sensitive”
4. Flood the network with more redundant packets
Or is the whole text a joke going over my head?
- DowsingSpoon 2y agoHi! I’m also a layman who doesn’t really know what he’s talking about. The article ends with “ I will leave you with a question: Are we trying to make end-to-end congestion control work for cases where it can’t possibly work?” So, it seems to me that there may not be any good solutions to latency spikes. The article is basically pointing out that you either pursue one of the unfortunate solutions mentioned, or be resigned to accept that no congestion control mechanism will ever be sufficient to eliminate the spikes. This seems a valuable message to the people who might be involved in developing the sort congestion control mechanisms they’re talking about.
- fmbb 2y agoHaha joke’s on me I guess, not reading the _headline_ and skimming the intro so not getting the point.
- Sohcahtoa82 2y agoI think the author is saying that there ARE solutions, but none of them are really viable. Seeing the future obviously can't happen. Building a higher capacity network is just wasted money. Breaking NN is going to be unpopular, not to mention determination of "not latency sensitive" is going to be difficult to impossible unless there's a "not latency sensitive" flag on TCP packets that people actually use in good faith. And flooding the network with more redundant packets is just going to be a colossal waste of bandwidth and could easily make congestion issues worse.
- travisb 2y agoDSCP already exists, but there's never been an Internet-wide incentive to use it correctly. It is theoretically plausible that end-users could mark their packets 'latency/jitter sensitive' or 'high throughput'. If there was an Internet-wide consensus that those two options made useful trade-offs then there would be an incentive to use it correctly. That would be as NN-safe as any other scheme. For example, maybe 'latency/jitter sensitive' buffers less, but at a 25+% throughput penalty. 'High throughput' would then be faster, but have much higher latency/jitter. The trick would be ensuring fairness without requiring too much hardware at scale.
- sulandor 2y agocorrect. if dscp would work, we would not need l4s. but treating the "importance" of flow inversely to their bandwidth usage works astonishingly well (flow-queuing/fair-queuing)
- sulandor 2y agoIt's a political debate between industry and 'the people' whether control over network utilization is exercised by components/bottom-up or endpoints/top-down. both sides claim fairness/net-neutrality and performance on their side but one is deployed and working while the other one is standardized and looking for an application. presumably there is room for a compromise but defining "queue building flow" w/o regard to link capacity seems like a step in the wrong direction
- sambazi 2y agoprobably also marketing, since "dumb-pipes" may seem outdated when all and everything is getting "smart"