
@ Zoltan Kelemen, re DSCP, QoS would be an 'easy' fix
Trust boundaries are indeed the issue, and I wouldn't trust a user much further than I could throw them. But ISPs could offer a QoS / VOIP service, by establishing inbound policers.
Run it through a per-flow policer, and say that your customer can get 128kb of EF traffic (VOIP) grade. Give them a larger amount of regular service, which would be any other traffic- and you'd remark that down to DSCP 0. Put a cap on this traffic at various levels depending on pay scale- and then above that, mark traffic down to DSCP1 (scavenger class), which guarantees that if there's any congestion, this overflow traffic is what's going to get binned first.
This would theoretically allow users to have their 8Mb pipes, and use them to the fullest- as long as there's no congestion. If there is congestion, the heavy users are the ones that are going to drop some packets, and it's going to be up to TCP (or the application using UDP, in this case) to retransmit as necessary.
The big problem with UDP flows is going to be with WRED- this is a discard algorithm that starts to sense when a pipe is getting full. It'll look at TCP flows and start picking one flow at random, and discarding some traffic. This causes just one flow to have to throttle back, rather than ending up in a situation where a bunch of flows get simultaneously dropped, and then a pattern of synchronized congestion starts up.
Getting the internets to be QoS aware across ISPs is a pretty impossible task though. Now you've got inter-company trust boundaries, and that's going to be a pretty major sticking point.