Slashdot Mirror
Enabling Bittorrent at the University Level?
Sorthum asks: "I'm a network administrator for a small university (approximately 5000 students all told). We're running NAT in the dorms, which obviously restricts BitTorrent traffic. We do an annual student survey, on which 'Residential Network' is listed as the number 2 complaint. This translates more or less into 'Bittorrent is slow here.' My boss is in a frenzy to appease the users at virtually any cost, but it seems to me from my research that the only real way to improve Bittorrent speeds is to start assigning public IPs to the dorms. Add to that the potential liability of making a service that by most reports has upward of 90% of its traffic fall into a 'legally questionable' gray area, how can I win in this situation?"
BitTorrent, like any other technology, protocol, or tool, can be used for things that are legal, illegal, or questionable in various jurisdictions. Are you prepared to continue quashing a protocol or service simply because it may be abused?
On the other hand, almost all (or at least a great deal) of the BitTorremt traffic may be currently used for sharing copyrighted materials. We all know that to be the case. Is it responsible to open up the pipes for what you know is almost exclusively illegitimate usage, within the context of the law (regardless of how you or anyone else feels about copyright infringement, and so on)?
On yet another hand, what happens if BitTorrent usage becomes largely legitimate because some large legitimate service begins using it? (And yes, to those reading this, I'm more than aware BitTorrent is used for a variety of legitimate large downloads.) In that event, can you afford to continue treating any protocol or service as if it's illegitimate, just because some level of it is now?
During the heyday of Napster (1999-2000), UW-Madison estimated that Napster accounted for over half (!) of our inbound and outbound traffic. There was a lot of talk about how to deal with this. Ultimately, UW-Madison decided that as a large public research university, we can't afford to police a particular kind of traffic wholesale: any network protocol can be abused, used for illegal purposes, and so on. We felt that the academic arguments and responding to usage demands of the campus trumped making judgment calls about the appropriateness of the use. Granted, the appropriate use policy of the university forbade some of the things people were using the network for, but we didn't actively police (or restrict) traffic. In the end, this provided the university with the impetus to examine ways of meeting increased demand and come up with novel solutions to our neverending bandwidth needs. One interesting example is that we now locally host a collection of Akamai's servers on our own network, which serves UW-Madison, the 25 other UW System Schools, and WiscNet. However, some of the smaller schools couldn't afford to make those same determinations: they either restricted or blocked Napster (and other things, like Gnutella) completely.
Today, the university does shape and restrict traffic to the residence halls in various ways; but it's designed to do so in a way such that users almost always won't notice any impact and allows equal access for all. All of our residence halls feature 100mbit ethernet, and that full pipe may be taken advantage of. Some users do use the network for inappropriate purposes, and those cases are dealt with individually when needed. Still, there is no proactive policing unless there are clear abuse/misuse issues. For what it's worth, BitTorrent (and all other protocols) are fully usable here.
If you can afford it, politically and financially, I'd say you should be looking into opening this up. The school does not bear responsibility for the actions of its users unless there is a lack of good faith attempts to stop abuse when requested by, e.g., copyright holders. There always is the argument of customer satisfaction, as well, that must be responded to - whether some students' use is appropriate or not.
I know on small, home networks, many routers now support the Internet Gateway Device (UGD) protocol of UPnP, which allows dynamic configuration of port-forwarding for applications running through NAT. I'm not sure how well-suited the protocol is for large networks, but perhaps that's something you could consider?
i ce
http://en.wikipedia.org/wiki/Internet_Gateway_Dev
This space intentionally left blank.
They should be glad BitTorrent works at all. Students can wait a little while longer to steal movies/games/whatever.
1) Implement public IPs and face the consequences, namely either knock on issues of them hammering your internet pipe, or as you said the otherwise potential legal issues surrounding it.
2) There was an article a little while back on rate shaping
You do have to question why the network is really there. Maybe you just need to tell your boss to get a grip.
I hate to say it, but does bittorrent (For non-uni use) really fall into the "supported" category? I know it's going to be something that everyone is going to try to find a way around as most uni networks have pretty good internet connections, but on a large scale like this you have to get an official statement from your boss as to say whether it's supported or not.
Sorry I can't give you better news.
Curiosity was framed; ignorance killed the cat. -- Author unknown
Assess the need of services to provide to students, webmail, directory services, course pages etc.
Make the services available over net.
Kick residential networks completely away from university network.
Then you won't have to worry about what students do in their network, since it's operated by third party operator, not by university.
Third-party operators here are student unions etc, which partly/entirely own the housing which students rent,
and network policies are set at student level.
There are no atheists when recovering from tape backup.
Give them public ip addresses, but make them dynamic, possibly make each user connect using PPoE, so there is a username and password, limit the bandwidth, block inbound windows SMB/LSH/NetBIOS ports such as port 139, 137 incoming to each user, etc.
Keep logs of what user logs in to what ip address. As an ISP you aren't responsible for the details of exactly they do online, you have no idea about the nature of their activities, or if they're legal or not: make sure you stay within the DMCA safe harbour, and clearly document the contact information as required, so the ISP can receive DMCA letters.
ISP responsibilities should be mostly met by being able to match an ip address to an individual who is responsible for that node.
That's the key question. When I was in college, the network and internet access were provided "for academic use". Obviously, when you have thousands of people living on the campus 24/7 for 8 months out of the year, there will be plenty of non-academic use, but that's understood and accepted, as long as you're keeping it reasonable. Call up the helpdesk and complain that your Quake(World) ping times are slow or you're lagging, and they aren't going to work much at "fixing" it. Run a high-volume server (web or game), and they'll come shut you down, unless it's directly related to something you're doing academically. If you're having trouble downloading something from MIT for a research paper, and they'll take care of it.
Are the students using BT for legitimate academic purposes, or are they using it to download entertainment? Don't even get into the "gray area" of judging whether the content being downloaded is legal or not. If they have educational needs that are being met by BT, then there's an argument for "improving" that service. If not, why spend the time and bandwidth money on it?
If it's about Linux ISOs, set up a local mirror for the student body and ask them to use that. Bonus being that they'll download it faster than they ever could with BT.
It all depends upon how you limit the bandwidth.
#1. Shrink the individual pipes to total_bandwidth/number_of_students? So you always get sucky performance?
#2. Cap the daily/weekly/monthly download/upload? So you get sucky performance during the first half of that period, but great performance once everyone else has hit their caps. And what happens when you have a legit need to go to a site after you've hit your cap?
#3. Do it like Frame Relay where you can "burst" to the available bandwidth? But if everyone is try to burst, you get sucky performance anyway.
#4. "Shape" the bandwidth based upon protocol and use one of the above methods to share that bandwidth? This works as long as there's no way to masquerade as a different protocol.
Each way has its own problems.
Well, yes and no. If the university has a clear $50/month charge on the bill then I'd say yes. I'm not sure all of them do though. If students really want ISP level internet access then they'd better be willing to pay for it, but I'm not sure that just because you're paying several thousand per year for tuition means that you get top-rate internet service. I really don't see internet access any different than dorm, food, or phone service.
If you don't want crime to pay, let the government run it.
I got a little box that would go between the phone body and the handset. This little box provided an analog phone jack. It had a way to adjust for 4 different power levels, to be set according to your digital phone. I think it needed a wall wart for power.
Procedure:
1. take handset off hook
2. tell modem to dial (any number will do)
3. dial the real number using buttons on the phone
4. enjoy the 9.6 kb/s connection
Azerus supports the use of the Joltid peer cache for downloads. Someone suggested dynamic, public IP's. You could use IPv6. Although it doesn't make sense: Bittorent works through NAT's very well. But if there are bandwith issues then use a cache.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
When I was in uni residences in 2005, we were assigned public, static, IP addresses which were fine for bittorrent. The IP is permanent and tied to both your university username and MAC address, and they were quite tough if the RIAA or MPAA reported abuse to them.
PocketGamer.org - For the gamer on the go!
Yes it does. Let me explain, for your benefit and for the benefit of the topic submitter.
If your client does not accept incoming external connections and share torrents (if your client is not on an externally accessible device and you don't have port forwarding configured), all other peers will assign you a priority lower than every other peer that is sharing.
This doesn't just mean you will be last in line to receive the requested torrent. It means that all other clients will relegate your request to the small segment of bandwidth configured to be set aside for non-sharing peers.
While it is possible for you to still obtain a fast download speed in the case that your request is fielded by such a large number of peers either whose bandwidth is under utilized or collectively whose non-sharing peer bandwidth allocation gives you an acceptable transfer rate, in most every case your download speed will be only a fraction of what it would be were you sharing.
And while I have not used BitTorrent in a long time now, it would not surprise me if clients were to implement logic to completely cut off "deadbeat" peers (freeloaders) such as yourself. Clients are by default configured to share with non-sharing peers not out of the goodness of their hearts, but because it is advantageous to allow peers who did not previously have anything to share to get a footing in the network on the premise that some of those peers may go on to become outstanding sharers. If however a peer downloads a great deal of data but fails to begin sharing within a reasonable period of time, that peer is probably a freeloader and can be safely blacklisted.
The "little extra time for things to get up to speed" you are seeing is the wait for all other leechers ahead of you to finish, opening up room in peers' non-sharing peer bandwidth to accomodate you.
Which I hope speaks to the question of why on earth would this university network administrator want to allow his users to use university bandwidth to get bonus points with copyright infringers so that they themselves can infringe copyright more effectively...
If you must do something, why don't you quietly encourage them to setup their own torrents on the local intranet? Surely between an entire campus of students there is enough shareable music to keep them occupied.
Many BitTorrent clients support reporting a different IP to the tracker than the one actually held by the computer. This is useful for routing INCOMING connections through a third party.
Essentially what you need to do is have students connect to a server with a public IP via SSH, and set their BitTorrent client to report that server's IP to the tracker. The idea is that you set up an SSH tunnel that accepts connections on the remote end and forwards it over SSH. Most SSHv2 clients (such as PuTTY) support this functionality.
Assign each user a specific port on the server (There are over 65 thousand ports, and each person needs just one), and provide them with a nice little automated solution to set up the tunnel. PuTTY has a command-line version called "plink" that makes this super easy. Just write a short VisualBasic application that does nothing but show a window with a button to start up and connect plink to the server, and shut down the process when the user is done. This way, all a user has to do if he wants to use bittorrent is run the application and click a button. Or better yet, just write a short batch script that the user can launch when they want to do torrent-related stuff.
This is only one of the possible methods. As you can see, a computer doesn't need a public IP address in order to accept incoming connections via BitTorrent, since you can tunnel them. It should be noted that many BitTorrent clients also support proxies. uTorrent even supports proxies for peer-to-peer connections. And you may also want to look into P2P caching solutions, which could potentially significantly reduce the impact of BitTorrent on your university's connection.