3 ms·
There's a way to do it in a way that doesn't completely violate net neutrality. Make some mechanism that programs can use to mark connections as bulk-rate or pr
by traverseda 5y ago
There's a way to do it in a way that doesn't completely violate net neutrality. Make some mechanism that programs can use to mark connections as bulk-rate or priority. Limit people's priority bandwidth to maybe 10% of their rated max throughput.
That requires some new technology, but letting the user choose when a connection should be considered a low-latency priority is important to keep this kind of system from turning into a bunch of consumer-unfriendly back-room dealing. Creating an opaque system with unclear rules about what connections are classified as what priority level will also make it very difficult for new businesses to get their start, as eventually I think you'll probably only be considered high priority if you're a big business or you're mimicking the characteristics of some big businesses application.
- willcipriano 5y agoMost people don't use the whole pipe, I doubt I use 10% of my total available traffic each month and I'm a power user. At 100 Mbit/s you'd have 100 GB per day of high priority traffic to use.
- traverseda 5y agoI mean I think imagining it as 100GB of high priority traffic per day is the wrong way to think about it. I know that in some places in the US for some reason you pay for the bandwidth you use, instead of for the capacity of your line. Personally I think that's silly. With a 100Mbits/s connection you'd have 10Mbits/s of high priority traffic, per second. I feel like an ISP should be able to not completely oversubscribe to the point where you can't even use 10% of your connection at low-latency.
- dtaht 5y agoby multiplexing better, you generally need to not differentiate between high and low priority. Being that I've been trying to convince people of this for years - all I can do is try to point at resources that demonstrate how we think about how packets work is frequently wrong, and/or try to provide a demonstrable example. Let's take voip vs netflix over 60ms - netflix, like most DASH video traffic from most video services, is very bursty. It tries to grab a chunk of video, and over the course of 1-2 seconds, fills the pipe, and voip sends one tiny packet every 20ms, which kind of looks like this: What you want: NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN -> you V V V What you get: VVVNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN -> you What AQM does is keep that induced queue short (roughly 16ms with DOCSIS-PIE). The netflix "pulse" goes away and you end up with NNNNNNNNNNNVNNNNNNNNNNNNNN -> you Netflix loads the next segment a tiny fraction slower, but your voip call doesn't get the jitter and latency side-effect anymore.
- dtaht 5y agoI've given more than a few lectures on how packets and queues and aqm are supposed to work, with very physical demos, using "packets as people", such as this one: https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/ https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-... I'm cited in the article, participated in the study, and have been trying to counter this mis-impression about "priority" vs filling the pipes, not the queues, as the answer to better network latency for many, many years now. It's still a tough slog, it seems, and I fear this will be a long day on reddit for me! But with comcast's now enormous and deployed existence proof, perhaps more will deeply grok it, and we'll see movement by other isps to apply the same technologies so all their users would benefit.
- dtaht 5y agoKeeping the queues short with AQM makes every application share more fairly. Low rate applications like gaming and zoom benefit. QoS, as you describe, has been tried (see diffserv and intserv), and fell down because mostly everyone felt "their" application had priority. Being fair, instead, and improving statistical multiplexing in particular lets 'packets be packets'.