Tagged as: Net Neutrality

My ISP in Los Angeles is Time Warner Cable, and I'm pretty sure they're cheating on my speed tests. I pay about $39 a month for either 15 Mbps down or 20 (I don't remember which), and when I run speed tests on sites such as speedtest.net, I always get a download speed between 15 and 20, usually around 17 on average.

But, the entire rest of the Internet totally sucks. I'm using Google's DNS (because Time Warner Cable's have been absolutely useless, like making me wait several minutes just to resolve a domain name), so that's not part of the problem either. It seems also that on the general Internet, the entire network drops in pulses every 30 seconds for 5 seconds at a time. So if I'm on Reddit, and click to expand a dozen imgur links with my RES extension... all of the links take a while to load, and then all of a sudden they all load at the exact same time.

I was reasonably sure that Time Warner Cable was using traffic shaping to "put on a good show" for Speedtest.net, and throttling my network speeds for all the other sites. So that if I called and complained about my slow Internet, they'd say "go to Speedtest.net and see for yourself that you're getting your 15-20 megs down that you're paying for" when instead, they're cheating on speed tests and slowing me down on every other site in the world.

I just had to find a way to prove it. The idea I came up with was to proxy my speed test through a fast web server. My web server, though, wouldn't cut it. My server got 900 megs down, but only like 12 megs up... which I thought was absurd, because a web server's entire purpose in life is to upload web content to the end users. A server's upload speed is the bottleneck that controls your maximum download speed when downloading data off of it.

I migrated to a new web server that gets much better results on speed tests, and its upload speed is higher than my quoted download from my ISP. So, I used it to try and test whether my ISP is cheating on me.

The tools I used: speedtest-cli, a command line Speedtest.net client (so I don't have to worry about trying to proxy Adobe Flash traffic, which is notoriously difficult to do), and proxychains, a Unix tool that lets you force any other program through a proxy regardless if the program wants it or not. This way I could proxy speedtest-cli to run through my web server instead of directly hitting up Speedtest.net.

My web server is hosted in Kansas City, MO, which is a bit of a drive away from Los Angeles, so to remove any geographical bias from the equation, when I ran my speed tests from my web server, I selected Speedtest servers here in Los Angeles. This showed me that my web server was able to download and upload reasonably fast from Kansas City to LA, and that the opposite should be true as well.

Hypothesis:

Time Warner Cable is aware of the entire list of Speedtest.net servers, and when it sees traffic downloading or uploading to one of these servers, they shape the traffic to give you your quoted speeds. All other servers besides these on the list, they slow your traffic speeds immensely.

Expected results:

Assuming my ISP was honest, I would expect my speed test running through proxychains to be similar (perhaps a couple megs less) than a direct speed test, given the overhead of an SSH socks tunnel and network travel between my apartment and my server in Kansas City.

Experiment:

Run a Speed Test by proxying through a third party server that Time Warner Cable is not aware of, in such a way that the ISP does not know I am running a speed test, and therefore they do not know to shape my traffic in a way that gives me my quoted transfer speeds.

I'll let the results speak for themselves (note: I'm hosting these images here locally because I'm not sure speedtest.net hosts the results on their server forever. Clicking the images though will take you to the link that speedtest.net gave me). I did two rounds of tests for redundancy.

• PC Speedtest: A speed test from my local PC to a local Speedtest server in Los Angeles.
• Server to LA: A speed test from my server in Kansas City to a Speedtest server in Los Angeles.
• Proxychains: A speed test from my local PC, proxied through my server in Kansas City, to a speed test server near Kansas City (local to the server).

PC Speedtest	Server to LA	Proxychains

I also ran a non-scientific test of simply downloading a very large file from my web server (I picked the Android 4.0 VirtualBox ISO from one of my blog posts which weighs in at 243 MB). The download speeds shown in wget initially spiked to about 500 some entire kilobytes per second (about 4,000 kilobits or 3.9 megabits) before quickly dropping to between 100 and 200 KB/s (or 800-1600 kilobits/s) for the remainder of the file transfer. Overall it took 22 minutes, 46 seconds to download. Given my quoted download speed of ~17 Mbps, and my server's upload speed of 35 Mbps upload to Los Angeles, this is inexcusable.

For those who like the dirty details, I copy/pasted my terminal outputs from speedtest-cli and you can see them here: speedtest-cli.txt. So you understand what you're looking at:

• The hostname aerelon is my local PC.
• The hostname debian is my web server.
• The command proxychains ./speedtest-cli --share is me running the proxy through my web server.

My proxychains configuration, less comments:

[kirsle@aerelon ~]$ cat .proxychains/proxychains.conf | grep -v '^#'
strict_chain
quiet_mode
proxy_dns 
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
socks5	127.0.0.1	8080

Where 127.0.0.1:8080 is a SOCKS5 proxy over SSH to the web server.