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?
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.
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.
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.
but treating the "importance" of flow inversely to their bandwidth usage works astonishingly well (flow-queuing/fair-queuing)
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