MRIC and the peer-to-peer filesharing problem

File-sharing programs like Kazaa, Limewire, Morpheus and the now defunct Napster create serious challenges for the network administrator. The problem is very simple to understand, but difficult to control. This could be a text-book case of the tragedy of the commons on many networks.

There is a finite amount of bandwidth available to coop members, but the P2P programs can easily create exponential demand for that bandwidth (primarily the millions of other users on the internet who find the files they want shared on members hard drives... someone is always downloading something from you if your collection has popular items in it). Even one user with a sufficient amount of shared files can consume all available bandwidth through one of our two uplinks, 24x7x365. The end result is that all other coop members using that uplink would find their connections reduced to dialup speeds again. It is not possible to solve this problem by throwing more bandwidth at it. Unchecked, peer-to-peer file sharing software would probably destroy the coop, as other members become frustrated and decide that it's not worth it. Further, attempting to keep up with the bandwidth requirements would require continual increases in coop membership costs.

Up until a few months ago, there was a relatively simple solution to the problem. Until the most recent release of Kazaa, it was possible for network administrators to regulate bandwidth usage on a per-application basis. If this were still the case, we could simply restrict all combined peer-to-peer usage at a low level (maybe 25%). The most recent release of Kazaa intentionally tries to bypass these limitations, by mimicking regular web and e-mail traffic. Across the country university networks have been crushed by the demand created from the new Kazaa. Some schools have chosen to ban it completely. Most businesses have always done so.

What options do we have?

Because it is no longer possible to reserve bandwidth for the applications which members use most (web and e-mail), another approach is required. These are the options as I see them:

1) Do nothing and try to keep up with demand. As mentioned before, this will require continual increases in membership cost.

2) Completely ban all peer-to-peer traffic. This option is almost as unrealistic as #1, and would essentially require that the support staff spend their time policing users instead of making the network better.

3) Charge for excess usage. The reality is that there is no such thing as a free lunch.... or free mp3. The actual costs of bandwidth usage serve as an effective deterrent to abuse. If someone can afford a $500/month bandwidth bill, they can probably afford to buy the movies and music they are downloading (or simply get their own T1 and not have to share it). The primary disadvantage of this approach is that it creates extra work for the coop to track and bill users who exceed a baseline quota. A secondary disadvantage is that enough users running their program up to their baseline limit will still overwhelm the system (5 users can consume all available bandwidth on one T1 by each consuming 300kbps).

4) Purchase Packeteer's PacketShaper. This is an appliance which completely deconstructs every piece of data on the network. Kazaa cannot (yet) avoid it. It is the only solution of it's kind which I am aware of (certainly if there were any less expensive solutions they would be known). If I played the markets I would absolutely invest in Packeteer. There are many, many networks which are scraping their coffers to buy these devices because they have no other choice. This product starts at $10K.

5) Impose a quota and implement rate-limiting against individual members who are hogging bandwidth. While we cannot limit P2P traffic in general, we do have the ability to limit how much data any one member can send or receive. This solution has the same problem as #2 above- it turns the support team into police and requires ongoing vigilance. It may be possible to automate this solution to some degree (by measuring total bandwidth used and then turning on a limit when a quota is reached). Programming this solution will still take time away from the support team, but it is the most feasible. Further, to implement this requires a fundamental change in the premise of the Coop. As stated in the FAQ:

Second, MRIC does not cap your bandwidth.... As more subscribers sign up, more bandwidth 
will be purchased to make sure the average bandwidth per user does not degrade.

I believe that the above approach is naive in the face of P2P demand. I do not believe that the Coop can sustain itself by attempting to match demand for P2P applications without continually raising the costs of the whole to support the excess usage of a few. All ISPs must oversell services by necessity. For example, 100 users each guaranteed at least 512kbps (1/3rd of a T1), would need 33 T1s. Doing this would require charging members ~ $200/ea per month. It is not economically viable to operate an ISP in this manner- for that cost we can each get our own fractional T1.

6) Educate. If the survival of the Coop is of value to all members, and each strives to be responsible in their usage, the problem can be solved by self-policing. This doesn't necessarily that members can never use P2P software. I would recommend the following guidelines:

A) Do not run P2P software unattended. Members leaving their Kazaa turned on for the weekend while they are away have already caused noticeable slowdowns for other members. Is it fair to impinge on your neighbor's use of the service when you aren't even home?

B) Use the built-in rate-limiting features available in some software. Kazaa allows the user to restrict how fast other users can download from them. 128kbps is probably the highest value I would ever set. Remember that just 12 users sharing at this rate can consume a whole T1 of bandwidth.

C) Do not share any files at all. This approach has an additional benefit. If you share copyrighted material and the RIAA or MPAA sends a nasty-gram to MRIC demanding your name so they can take you to court, it is unlikely that we would have the resources to fight this (and no guarantee at all that we would win even if we did). Other ISPs are getting these types of notices, so this is not a hypothetical scenario. Is sharing your music collection with the world worth the tens of thousands of dollars in legal fees it could cost you?

D) Be conservative in what you download from other users. If you queue up 50 full length movies, you are going to slow everyone else around you down for the next 8 hours. The effect will be felt most strongly by your closest neighbors.

The approach that the makers of Kazaa have taken with their new release is very unfortunate, and will backfire on them in the end. While they may believe that they are helping their users to download faster, the reality is that they are causing grief and support nightmares for network administrators. Those administrators have the right to control what traffic is priority on their networks, and by circumventing this Kazaa will cause many networks to ban it outright, which in turn will mean less available material and less interest in the P2P network. It is not implausible that Kazaa is in fact a tool of the RIAA for this very purpose, given the end effects.

Security and Privacy concerns: Most P2P software comes bundled with a number of add-on packages. Many are not optional, if you want to install Kazaa you also have to accept programs which continually monitor your browsing habits and feed the data into a marketing database. Additionally, some of the software has potential security issues that could allow your computer to be misused without your knowledge.