Bandwidth and latency are two separate but equally important network considerations. An ideal network will have high bandwidth and low latency. The real world is rarely so obliging. For some applications, we don't care about latency. It doesn't really matter how long the packets in an FTP file transfer take to get from A to B, …
here's a plan
1. you give each client equal minimum share of the bandwidth
2. you let clients have equal share of un-used bandwidth (the share that other clients aren't using).
3. within their share, you prioritise latency sensitive traffic
That way my video conferencing can't oust someone else's emails.
"tc" with "htb" on linux can do this. I don't know if it can cope with the number of customers that ISP's have but I was working on site shaping solutions using this a few years ago and it works very well.
A standard configuration "mended" networks when 10x the bandwidth couldn't.
Doubling the bandwidth might halve the time a large email contends with voip - but it doesn't remove the contention.
Shaping lets voip packets jump to the front of the queue but doesn't actually increase the total time to send the email.
Most amazing thing
IPv4 already has a "type of service" field that you could use to give low-latency desiring packets what they want, and the bulk transfers what they want. Don't need to look into the packets, just look at what they ask for. Of course, the moment someone tags their bittorent onslaught of big bulk pipes with "needs low latency", you'll have to stamp that sort of thing out. But as long as it's in everyone's interest to play nice together, they will.
What's more annoying is network operators simply not caring about any of these things and treating their network like, well, some sort of ethernet lan or something. No guarantees or anything, if the packet vanishes in transit, then oh well who cares anyway. This leads to retransmissions and poor service and unsatisfied customers.
I used to live in a city with a sizeable student population, many with a connection to $ISP; instead of having all that traffic go through the national IX, they had a private peering with the local university exactly because it was a good idea. It's not rocket science, we know how to do this.
If the locals in Alberta prefer to provide bad service instead, well. Nothing much you can do about that through technology. But maybe there's something else you could do. Start your own ISP instead? Or simply an IX, invite them to peer there? What else?
"stamp out that sort of thing"
You looked at any Microsoft Software generated packet headers?
This is precisely why it is not used!
Google says NO!
MS is a practical issue to overcome for implementing QoS/CoS on Internet connections. Then voice could be sent EF, video/delay sensitive data as AF and everything else BE. Just like it's done for business VPN's via private IP/MPLS networks. But that breaks the holy rule of 'net neutrality', and media companies like Google are strongly opposed to anything but everything on the Internet being best efforts.
Was that article an attempt to improve SEO?
Did not say anything new, even prosumers in shared homes have been using management techniques for years so people can game and then do downloads without affecting each other.
Somebody Break Out The CCITT Specs
X.25 and friends- problem solved.
It is worth noting that high latency increases dead time in TCP-based operation due to ack packet delays. This can drastically decrease throughput of bulk file transfer protocols like FTP.
If I was king, I would have all ISPs respect ToS/diffserv packet marks, but build such consideration into caps and pricing. So, for example, I could by a three- or four-tier package that includes a small bundle of high-priority data transfer allotment, larger bundles of moderate priority data transfers, and unlimited low-priority transfer. Overages allowed with premium rate surcharge, but strictly capped within limits that assure service quality for all. Peering exchange fees would work similarly..
And keep the fuck out of my packets otherwise. I will be encrypting much content anyway.