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.

Ironic?

I really think people are on the wrong track if they are suggesting that the inbound (to your modem) is the problem here and can't be adequately shaped. In my experience when you have cable or dsl with a disproportionately low egress (outbound) in relation to the ingress(inbound), you will have the increased latency you describe.

I think the first step would be to upgrade to the highest level of service your ISP provides short of business class. If you have comcast, we are in the same boat and you should get the 8/768 plan as you are essentially doubling your upload speed.

If you don't have the money, then I would setup a simple test to see how well your connection performs under stress. Since you are testing for VOIP latency, I would use a UDP ping on a machine you give higher priority to, and run a simple speed test on a machine that would be running BitTorrent...it won't simulate the number of connections that machine will put out, but for the purposes of the test you want to see how well your router is shaping traffic when you reduce the upload cap by 60%, 50%, 40%, etc...and you want to get an approximation for the amount of bandwidth being received and sent out. Try adjusting your inbound bandwidth in the same manner.

Now you mentioned that you are prioritizing based on MAC address, and not based on protocol or service. This is not actually QoS, but rather CoS and is only layer2. CoS is really ineffecient at lower bandwidth rates...it's not really meant for that little traffic and if you throw a lot of connections at it, it will definitely screw up queueing.

Prioritize the VoIP traffic by port or application if you can, and try the different algorithms available to your router...I would definitely suggest as has been stated above to try different firmware images to see if you get better results...Tomato may have been the best suggestion given it's apparent inclusion of Layer 7 (Application) matching using the L7-filter projects signatures. If you can make BitTorrent the lowest possible priority that would be good too;)

Something that someone else might not have mentioned, is the number of connections that are allowed to be setup for either a given computer or application. Connection/Session limiting on your router would definitely help out QoS to prevent BitTorrent from opening more and more connections, and basically increasing overhead. That change can be made in iptables on any linux-based router running a modified image or full blown linux(has to be done from the command line).