_xeno_'s Journal: The Problem with BitTorrent

If you've been reading Slashdot for any length of time, you'll have run across mentions of BitTorrent, a P2P content distribution system. Basically, it's a method of spreading the bandwidth allocation across multiple clients.

This is all well and good - BitTorrent is very useful to a content distributer since it moves bandwidth restrictions off of their server and on to those who want the file. It allows people to help share the burden of distributing something.

Unfortunately, BitTorrent is a little too good at utilizing clients bandwidth. In fact, it quite happily takes up all the bandwidth that it can. Since BitTorrent is an "always on" system (since it does uploads/downloads at the same time) it can easily completely fill up an Internet connection up to the bandwidth available on most PCs. Since most new PCs and modern networks use the 100Mbit/s standard, this makes it quite possible for a single BitTorrent user to completely flood most Internet connections.

The average broadband user has an internet connection of around 1MBit/s if they're lucky. Many larger sites (like educational institutions and buisnesses) will have connections with larger pipes, some of which may exceed 100MBit/s, but even if a site has a 300MBit/s connection to the Internet at large all that means is that three BitTorrent users can completely flood that connection. And with sites that require more bandwidth, more users can be expected, easily reaching the critical mass required to completely flood the local network.

To state it simply, BitTorrent is a bandwidth hog just like most other P2P services. And because of this, many sites have found it necessary to block BitTorrent to ensure bandwidth for other uses. (Blocking BitTorrent is fairly simple - you only need to block connections to the tracker, and then the system cannot connect to peers. The site I'm at blocks BitTorrent connections to/from peers.)

This defeats BitTorrent's purpose - actually making it cause the problem it was supposed to solve. (BitTorrent was supposed to allow a server to survive many users wanting the same file - but it instead swamps the local network, acting as an effective DDOS system against all other users on the network.)

The solution can be stated simply: BitTorrent needs to allow throttling. This is not an easy task, a router would need a software update to allow "intelligent" throttling of BitTorrent connections to a reasonable percentage of total bandwidth usage. If it were possible to simply tell BitTorrent that it cannot exceed a given download rate for a given network, then it could be safely unblocked without worrying about it flooding the network. (A given client can set a bandwidth cap for themselves - the problem is forcing all users on a network to set a reasonable cap. Some user will likely decide to remove such a restriction; other users might not know about the restriction when they start using BitTorrent for the first time.)

A better plan then might be to set up a "proxy" for a given network, creating a server on the network edge that handles BitTorrent connections out to the Internet and throttles them to a reasonable amount but encourages peers within the local network to utilize each other and not the Internet link. (This still has the problem of flooding the internal network, but bandwidth on an internal network is usually cheaper than to the Internet at large. This problem can be solved using internal infrastructure.)

The proxy solution is probably the best solution if it can do so transparently. This allows internal connections to remain at full speed and external connections not to flood the system. (At the very least, it creates a "choke point" where BitTorrent connections cannot progress beyond the bandwidth alloted to the proxy.) It also prevents clients from finding ways of circumventing controls on the network, since they are automatically routed through the proxy regardless of their actions.

There is another problem, though: the BitTorrent tracker sends "random" peers back to the client. For the proxy to work optimally, it needs to know about all clients on the network currently linked to a given tracker. This can probably be solved as well, given some sort of smart proxy.

BitTorrent is a worthy project and has a good goal. It is unfortunate that it has an unintended side effect of flooding the local network, and this problem needs solving in some fashion. If it can be done through the client, that would be great. However, unscrupulous people likely would try and maximize the bandwidth they receive, so a solution would most likely need to be forced upon all users so that all clients must obey the restrictions. If this problem is not solved, though, more and more sites will find it necessary to block BitTorrent to prevent their networks from being flooded by only a few computers.

Erm... it *can* throttle uploads

[Dave2 Wickham]

[dave@tc4 ~]$ btdownloadheadless.py|grep upload
--max_uploads
the maximum number of uploads to allow at once. (defaults to 7)
--upload_rate_fudge
--max_upload_rate
maximum kB/s to upload at, 0 means no limit (defaults to 0)
--min_uploads
the number of uploads to fill out to with extra optimistic unchokes

This is from the stock latest "Official" client...

Re:Erm... it *can* throttle uploads

[_xeno_]

Actually, I mention that:

(A given client can set a bandwidth cap for themselves - the problem is forcing all users on a network to set a reasonable cap. Some user will likely decide to remove such a restriction; other users might not know about the restriction when they start using BitTorrent for the first time.)

For my personal use at home, those options are fine. The problem is that at the college I attend the network administrators blocked BitTorrent completely because just a few users on a widely re

Re:Erm... it *can* throttle uploads

[Dave2 Wickham]

Ah, sorry about that, evidently I didn't read very well. Yeah, I can see how that would easily pose a problem :-/.

Just me being an idiot and/or not fully R'ingTFP before posting as normal.

Re:Erm... it *can* throttle uploads

[shird]

This can be done on your local gateway. Many ISPs throttle certain applications automatically. Based on the port and some 'smart' monitoring etc, they just automatically adjust the window size to throttle it at the gateway, thus all users behind the gateway are automatically throttled for upload/download at a predetermined rate. Also allows you to priortise web browsing bandwidth etc, so you get the best of both worlds.

QoS to the rescue?

[Minna Kirai]

A possible way to alleviate some of these problems is to get a modified TCP/IP protocol that recognizes some packets are fundamentally more valuable than others. Quality of Service, QoS, they call it.

A smartly-designed QoS scheme could allow users to run BitTorrent without flooding their local networks. For example, each user could be allocated 1 MB/s high-priority, 9 MB/s medium and 90 MB/s low. With applications that are modified to set the priority of streams as they open them.

However, correctly imp

Re:QoS to the rescue?

[_xeno_]

That was basically my thought too, but I think that can only be done right now over IPv6. My other thought was that routers might be able to detect when a BitTorrent packet was being sent to the Internet at large and decide based on current bandwidth usage to drop it. But that places too much "intelligence" into a router - I think - and I'm not sure there really is any way to determine that a given packet is a BitTorrent packet - other than forcing the router to worry about maintaining state across packet

Another problem with BT

[shird]

Re-posted here for the record:

Another problem with BT is it doesn't work through egress firewalls which allow outgoing for the proxy only, and the proxy is configured for port 80 only. This is a very common setup because it is good practice security wise where all that is meant to be allowed is web browsing. For this reason, BT should never be used as the only distribution method when you want people who can only 'browse the net' to be allowed to download.