Of course. Users also pay for that bandwidth, and it should be there if a subscriber needs it for whatever they choose.
bump for later read
In the RFC's comprising the internet standards, when a machine sends a packet from point A to point B, there are some things intermediate machines are allowed to do (including dropping the packet altogether, or holding it a few seconds), some they are required to do (NAT firewalls must remap source port numbers), and some they are forbidden (delivering packets that are modified in ways not expressly permitted, or forging packets in ways not expressly permitted). There are means within the RFC's to limit bandwidth utilization of any particular subscriber with a well-functioning protocol stack, and to limit the useful bandwidth utilization of any particular subscriber regardless of their protocol stack.
If a subscriber's computer wants to jabber away and send out oodles of packets without regard for whether they are delivered or not, dropping the subscriber's packets isn't going to prevent network congestion. On the other hand, most subscribers send data because they want it to be delivered. If a carrier limits the number of packets per second that will be delivered on behalf of each subscriber, the subscriber will achieve optimal performance by avoiding excess retries. Controlling the rate at which data can be delivered will effectively control the rate at which it's put onto the network, at least for any subscriber who isn't trying to flood the network.
Time Warner Cable finally appears to have fixed their hiccups. I would have to constantly reset the modem because the connection would just die and I’d suspect there was network overload or maybe someone trying to hack in. Still by the sound of things Comcast has them beat for bad service.
Thank God for the EFF