Also, you might even want to see how many connections your "high bandwidth" users are generating, and instead of throttling them limit the number of connections per user. Contention for bandwidth will decrease if your users are generating a reasonable number of requests/second. Plus you will have the very legitimate excuse of "we limit connections per user in order to prevent possibly malicious activity".

Oh yeah...and actually put yourself in the shoes of the customer by attempting to use the same pipe at peak times. See how bad the problem really is. Not knowing how much bandwidth you are actually working with I really can't tell how bad it would be. If you have less than 10Mbits/sec total my notion of crappy service is probably very accurate. If you have 100Mbits/sec or more it probably isn't so bad at all.

Don't just accept that notion that P2P will suck up all available bandwidth and drown out other apps. It's a free for all right now, and it all depends on how much bandwidth you are working with, the number of connections actually being made, your equipment, and the applications being used. Unless you have surveyed your usage you don't even know what you need to shape for. I doubt you will have a Packetshaper or Sandvine appliance to work with so discovery by your shaper isn't an option.

I think you need to make sure the traffic you are seeing is actually P2P. I would highly doubt it given your subscriber to bandwidth ratio. The majority of "normal" long flow traffic is actually http. Mostly flash video or http downloads. That said, you have such a high ratio that it's possible its not even downloads hitting up against your cap. If you have as flat a usage pattern as you say you have, it likely already sucks to be your customer doing anything at all at peak times. People would do better on dial-up....at least it would be consistent and they wouldn't get stuck with nil at certain intervals.

Confirm you have a P2P problem before you start shaping. If you tell your boss the traffic is mostly http no amount of packetshaping is going to fix this problem to anyone's satisfaction(unless it actually is all http downloads).

Since you're on a tight budget already, I recommend running nTop on a box connected to a mirror or span port. That would be an easy way to determine what's actually going on.

When presented with the fact that shaping is pointless your boss will either buy more bandwidth or do nothing at all. Either way you aren't forced to shape. If he chooses the second option your customers should make him uncomfortable or fix the problem altogether by moving to dial-up.

There is nothing new about this to anyone with any familiarity with the BitTorrent protocol. The hash is available whenever peers negotiate connections for a torrent. Snort rules have existed for this forever. Encryption is only a problem if you don't know the encrypted hash...which SURPRISE is available as long as the torrent is still being served from the tracker. Peers use the same encrypted hash to communicate.

Using packet sampling and Snort you can do this on over 150 1gig links TODAY. What do these people think a copysense appliance does with a 100Mbit mirror port? 1Gbit isn't even that difficult with today's commodity hardware.

Nothing pisses me off more then a bogus "new development". Should expect it from Slashdot I guess.