We apparently touched upon a subject which generates a lot of emotion, seeing the comments and reactions.
So let's get some things straight.
One of the undesirable side-effects of a congested link is the increase in latency.
Latency sensitive applications like voice (Skype like over Internet, not the dedicated VOIP which simulates PSTN and has a separate channel) will be affected by congestion, quite badly sometimes.
The point is not that overbooking in the link is a bad thing. But somehow we have
to find a reasonable way of dealing with the limitations (which will always be
there) and fairness (Congestion Neutrality) in it. The video over Internet thing
will force us to do that. And data caps is the wrong method.
Some commenters point to the unfairness of TCP/IP: the more sessions you have, the bigger your share of a congested link.
The straightforward implementation of TCP will lead to a more or less equal distribution of bit-rates per TCP/IP session. How many sessions do you create as a user? Very few with email, maybe (but not necessarily) a lot more by using Bit-Torrent or by surfing the web.
That having said, a more complex implementation of TCP might do it differently and reduce the bitrate for all sessions coming from one IP-adress.
It is all a design choice.
A design choice of the vendor of equipment and the ISP, as you can see in the different implementation in cable access networks.
So why blame the user for your own design choices?
Herman, you're seriously confused. This is not a matter of emotion, it's a factual matter regarding the claims you've made about TCP that don't happen to be remotely true.
In the first place, TCP is an end-to-end protocol which happens to be implemented outside the carrier network; to change the behavior of TCP, you need to alter the implementation in Windows, Linux, and MacOS. The network operator cannot do this, the only control he has is over the packet drop strategy that drives TCP backoff behavior. Most carriers use a tail-drop algorithm inside their first/last mile networks and a WRED at the border router. Neither is user-oriented, they're packet-oriented procedures that simply respond to congestion by dropping packets more or less randomly at or near the point of overload.
If carriers want to allocate bandwidth fairly across all users, they will have to buy specialized equipment that goes beyond the TCP spec and implements algorithms that are not defined by the IETF's definition of TCP behavior. Carriers do various things to ensure fair access to network resources, but this is not a part of TCP, it's actually a layer 2 behavior.
It is not the case that "overbooking the link is a bad thing." Overbooking the link - which is to say, allowing each user to take advantage of 100% of the link for the duration of each packet - is a good thing, the very capability that makes packet switching more suitable for human/computer interaction than circuit switching. Over-booking is the reason that residential broadband is so much less expensive (and generally faster) than commercial broadband sold according to SLAs.
Packet-switching has great economics because it's a statistical system. If each user has dedicated bandwidth, and there's no sharing allowed across the entire pipe, you're back in the circuit-switching world and paying much higher prices to build a network. The problem that arises in provisioning a network is the prediction of the mix of applications, because that guides the models about provisioning and underlies the economics of network operation. And predicting is hard: three years ago, it looked like P2P was going to take over the world, and it demands symmetrical links; but today, streaming is growing much faster, and it works best with asymmetrical ones. So what's the ISP to do?
Your analysis of TCP was wrong at the start, and now you're arguing that if TCP were different, it might be fair. But it's not, and the ISP is not the implementer. So just admit you were wrong and we can move on. No emotion, just fact.