Recently, the topic of traffic shaping and BitTorrent encryption was once again resurrected, this time by Wired News writer Michael Galore. In a recent post he explains that encrypting BitTorrent traffic is bad. But is this really the case?

The post over at the Wired blog, Monkey Bites concludes that encryption doesn’t fool many ISPs, and that it is a poor method of evading traffic shaping ISPs. I tend to disagree.

First of all, at this point, encryption is the only way to get around ISPs that throttle BitTorrent traffic. Sure, encrypting BitTorrent traffic is bad from an ISPs perspective, but most BitTorrent users with traffic shaping ISPs have no other choice.

Let’s take a look at the arguments that are supposed to support the claim that encryption is a bad thing. Most of these arguments come from a blog post that Bram Cohen, the inventor of the BitTorrent protocol wrote earlier this year.

1. A massive bi-direction file transfer, even when it’s encrypted, still looks like a massive bi-directional file transfer to sniffers and shapers. It doesn’t take a lot of deep science for an ISP to deduce that it’s BitTorrent traffic.

Well, this argument doesn’t really explain why you shouldn’t at least try encryption, if your ISP is throttling BitTorrent traffic. It says something about the effectiveness of encryption, but from a quick survey among friends that have to face up against packet shaping ISPs, I’ve learnt that encryption works excellently for most of them. And aren’t there more massive bi-direction transfers? VOIP for instance?

2. Obfuscation results in incompatibility between encrypting clients and non-encrypting clients.

True, but so does DHT, that was introduced in the official BitTorrent client by Bram Cohen, was implemented in other clients soon afterwards. You can always allow incoming and outgoing connections to non-encrypted clients (ensuring compatibility) as a milder form of encryption. Even Bram Cohen realized that it’s not all that bad, because the latest versions of the mainline client now support encryption.

3. Encryption damages any BitTorrent data caching efforts put forth by your ISP.

I haven’t heard of any ISP throttling and caching BitTorrent traffic at the same time. Caching essentially helps your downloads, so an ISP that’s caching BitTorrent traffic is not likely to throttle it as well.

4. By encrypting BitTorrent transfers, you’re just being hostile towards your ISP. Not to get all weepy over the poor ISPs, but it will only make them resent you more.

The ISPs are being hostile towards their customers if they start to limit BitTorrent traffic, often even without letting them know. Sure, encryption is probably not the best solution for both parties, but if my ISP was limiting my BitTorrent download speed to 10kb/s, they leave me with no other choice.

BitTorrent encryption is currently supported by the following BitTorrent clients, and a detailed article on how to encrypt BitTorrent traffic can be found here.

Clients supporting encryption:

Azureus: Windows – Linux – Mac OSX

Bitcomet: Windows

BitTorrent mainline: Windows – Linux – Mac OSX

KTorrent: Linux

rTorrent: Linux – Mac OSX

uTorrent: Windows

BitTornado (in v0.3.18): Windows

I encourage ISPs to find better ways to manage the huge amounts of traffic BitTorrent is generating. Some ISPs may make it look like this is only a bandwidth problem, but in fact it may have more to do with money than most people assume. External traffic costs ISPs a lot of money. One possible solution is the Cache Discovery Protocol that was recently implemented in the mainline client.

The “Cache Discovery Protocol” allows ISP’s to detect the most popular torrents, cache the data, and seed it. ISP’s like this solution, because it’s cheaper to use bandwidth within their network than to use external traffic.

But for now I would say: Encrypt!