Fix for stringent Bittorrent throttling by ISPs

[Greenport]

As many consumers of certain ISPs including Comcast and quite a few others know all too well, there is a lot of bittorrent throttling going on. Nowadays it seems they've managed to be able to detect P2P traffic even with encryption enabled/forced.

Their methods of throttling seem to include what is known as a 'sandvine', which involves monitoring connections for p2p-like traffic, and (usually mass-)sending forged RST packets to both of the computers connected. This causes the connection to be dropped on both ends, greatly reducing the speeds of the transfers. There have been situations I've seen where a torrent starts downloading, gets up to well over 500KBps then no more than a minute later withers away to almost nothing.

These RST packets can be filtered locally via various methods, however because the sandvine sends the RST packets to both of the IP addresses connected, doing so as of now would not be of great benefit. Also, because RST's are also used naturally on the internet, especially on bittorrent, filtering them non-selectively (even if it is only on one port) can be problematic.

--

Thus, I propose a new solution to this problem:

Bittorrent clients should start implementing a feature to filter forged RST packets on both ends, thus allowing the connection to continue. The way this would likely work is that if a user is affected by such throttling methods, he/she could check a checkbox which would tell supported clients about the throttling issue. Both sides would then filter RST packets, and instead send a specialized packet (either on the same connection or on a new, temporary connection on another port,) which would tell both sides to close the connection locally.

By filtering out the forged RST packets on both ends, the connections could stay alive and by using a specialized connection close packets it would allow network operations to continue as normal. The feature could be implemented in such a way that clients not supporting it would be able to just ignore it and normal connection closing methods could be used.

Eventually, when enough Bittorrent clients have this feature, it would render the throttling issue useless. At least for now.

Anyways it's obvious that SOMETHING needs to be done about this throttling issue. I can't download my fav. distro's of linux anymore

[Firon]

RSTs aren't handled on an application level. It has to be done on the kernel level, or in the router's firewall.

[Greenport]

There's gotta be a way to do it on the application level I'm sure

Couldn't the connections be routed through some sort of local proxy, so that it would become application level? Or something...

Couldn't this be done on the kernel level anyways? Firewalls work in that way don't they?

[edgehog]

As far as I am aware, throttling of encrypted P2P traffic is achieved by heuristic analysis of packets both individually and/or collectively over time related by an IP and/or associated port. Quite simply consecutive outgoing packets between two points in a torrent are the same length. Consecutive incoming packets are also the same length though not the same length as outgoing. If there is no other traffic, browsing etc, then it's quite obvious what you are doing as a pattern rapidly emerges. general browsing over a period of time does not generate the same sort of patterns. Also when an ISP is having a peak load issue they sometimes employ RED which simply throws away packets based on some statistical algorithms.

Perhaps a way forward might be the injection of some garbage of our own to make P2P traffic look more random and hence normal? That way it might not attract the attention of a DPI sniffer.

[Switeck]

(I'm on ComCast, and I can see the BitTorrent disruption done by ComCast.)

Any continuous uploading or downloading would also have a very similar pattern, though typically the download receiver would not be sending as much back as is typical for file-sharing.

Even streaming video/audio might have consistent packet sizes.

MTU set to 1500 bytes tends to result in full packets for sending files or large datasets, regardless of contents. These packets are not constantly sent at the same speed with most connections...because of lots of variables such as latency and other activities encroach on the maximum speed possible.

What's more brutally obvious for file-sharing is the incoming listening port typically sees the lion's share of the traffic, UNLESS you have semi-high half open connections and/or firewalled so you get no incoming traffic on uTorrent's listening port.

And running uTorrent while firewalled is not a good long-term solution, especially if lots of people do it.