In the enterprise world, Frame Relay was such a big success not so much because it was technically the best solution, though it was not bad, but because its mechanism for limiting bandwidth was entirely predictable (a subscriber paid for a fraction of the total access bandwidth each month, say 500 kbps on a 1.544 Mbps T1), and bills for the service were identical every month. The rate for the service was enforced for every second, so at 500 kbps, a subscriber had about 1/3 of the T1s bandwidth available for every second.

A similar model would work well in residential broadband. If the subscriber has a physical rate of say 100 Mbps, they could buy 20 Mbps, 50 Mbps, whatever, and the carrier could easily adjust the rate with a software setting change. The rate could even vary over time of day/day of week, but the key is that the performance and the billing are predictable. Subscribers want to worry about other things, not how much bandwidth they are consuming and how much their bill will be this month.

Also, why do many of the providers keep touting increased data rates to the house when they already supposedly can’t handle what’s there without artificial limits?

Sorry.. I’m not buying it.

Even if it’s just a few hundred connections per P2P client, the argument is the same – a single user trying to do IM, email, light web pages, etc, will try to get more bandwidth for their connection through TCP’s normal window-increase model, but any packet loss imposed on the competing P2P client is only ‘felt’ by one of its TCP connections, so the 50% reduction that a typical TCP-friendly app would make is more like 50% x 1/300 (for 300 connections), i.e. less than 1%. Hence the P2P app basically hogs bandwidth, relinquishing it very slowly if at all, compared to TCP-friendly applications like email, IM, browsers, etc, which open far fewer connections.

Youtube style video downloads are not a problem in this way – while they consume a lot of bandwidth, each video uses only one or two connections at most and will react like other TCP-friendly apps. They are still an issue for bandwidth usage generally, but could be addressed with caps or pricing, whereas P2P apps with many connections must also be addressed with shaping, particularly with next-gen 10-100 Mbps broadband.

I thought the most interesting finding was that light users who don’t frequently use apps like online gaming or video downloads/uploads were less accepting of caps than power users who have more to lose. The sheer volume that said they would seek another provider if a cap was instituted, was key, this plays to strategies that go beyond network planning and begin to impact the battle for broadband subscribers and ultimately the entire bundled relationship.

Which p2p client actually opens “thousands” of connections? uTorrent, one of the more popular bittorrent clients opens a few hundred at most, and then only if you tell it that you have a fairly big pipe. For reasonably hefty (US) dsl (6M/768k), it opens even less.

Note that the number of connections is something of a red herring. Each connection will get a certain amount of bandwidth. After “enough” connections, the bottleneck is full and additional connections don’t affect much of anything. (Well, they do slow down the local PC, but ….)