David Maynor has pointed to an interesting development on the BitTorrent scene in a new "selfish" BitTorrent client called BitTyrant. Speaking of poisoning the well, BitTyrant requires Java 1.5 to run which means you have to tolerate Java version conflict hell and massively bloated and inefficient software which is the complete opposite of something like uTorrent. Maynor goes on to explain some of his past P2P experiments where he would game the system by cherry picking he fastest uploaders and only uploading to them which - according to Maynor - seems to be something that BitTyrant is doing as well. But Maynor goes on to show that uploading bogus but highly compressible ZERO data would yield large quantities of downloads before the other party figures out they're being gamed.
The inventor of BitTorrent Bram Cohen doesn't want to enforce upload ratio policies at the protocol level; and I think he might have a point. You can't mandate 1:1 ratios because people simply won't want to or be able to use it because of the asymmetric low-speed upload nature of broadband links. The problem with anti-leach mechanisms if enforced too rigidly is that it will turn off users since most people can't upload as much as they download because of their Internet connection. If download speed was capped at upload speeds in a tit for tat peer to peer exchange, the experience will be unbearable for most users. In my experience, BitTorrent can be very healthy if everyone at least uploads 20% of what they download since there is a small generous minority that will leave their connections open and seed their files long after they've completed downloading.
Most Torrents can be healthy if people will use an honest client and put a reasonable upload cap of 70% of their peak upload bandwidth. This avoids over saturating their upstream Internet connection and allows their VoIP/Skype applications and their general Internet responsiveness to remain reasonable. Of course this doesn't work if there are 2 clients set to 50% of peak upload if they're both uploading at the same time since they will saturate the entire Internet connection and brutalize other less agressive applications. When I teach people how to set cap their upstream bandwidth and tell them to set a reasonable cap of 70% of their peak upload speeds, many people will simply decide set their upload to zero or near zero and rationalize their selfish behavior that no one else is entitled to their bandwidth. Obviously they're forgetting where their FREE downstream bandwidth is coming from and if everyone decides to do this, BitTorrent simply won't work.
This illustrates the need for "Enhanced QoS" bandwidth shaping mechanisms ESPECIALLY on your own broadband router which allows you to leave all of your BitTorrent clients on full throttle and still allow games, VoIP, and other latency sensitive applications to work well. This even allows BitTorrent to work at higher speeds than the less-than-always effective voluntary 70% upstream cap while an IP voice call is in session. So if you have a 512 kbps peak upload speed, having a QoS enabled router (tutorial here) will allow your BitTorrent client to operate at full speed when nothing else is happening but still operate at around 430 kbps while your VoIP/Skype stream maintains low latency and high quality. Add a game session to that SIP or Skype VoIP call and your BitTorrent upload will simply be capped to 380 kbps while the responsiveness for your game and voice call remains high.
The stupid network that Net Neutrality proponents espouse where "all packets are treated equal" simply falls on its face in the real world because there is no better way to foster a better network experience. Net Neutrality proponents in Congress are seeking to ban the sale of Enhanced QoS all over the Internet in the name of saving the Internet. They subscribe to the nonsense of the stupid network that will say "bandwidth solves all latency problems". But even throwing ten times more bandwidth at the problem won't prevent traffic-bursting applications like BitTorrent, HTTP, FTP, and other web applications from simply swallowing up any additional bandwidth given while starving low-bandwidth latency-sensitive applications like Voice over IP or online gaming.