jat
join:2008-04-28
Burlington, ON
| Proof Bell throttles everything but known ports/protocols
The attached screenshots document my testing of Bell's throttling. They demonstrate that Bell is throttling everything but known ports and protocols. This proves Bell lied to the CRTC when they said they were only throttling "P2P file sharing applications."
Two sets of data were used to represent unknown protocols: 5MiB of zero bytes, and 5MiB of random data (attached to this post). Port 9999 was chosen as an unknown port, however the results were reproducible on other randomly selected ports as well.
During throttling hours, each data set was also tested on a well-known port (8080), and a well-known protocol (HTTP) tested on the unknown port. Some of these tests aren't shown, as they duplicate the results of other tests.
Because a fair bit of technical knowledge is required to understand these screenshots, I'll give a brief explanation of the test performed in each one:
151539-9999-zero.png:
Creation of zero data
Test completed at 15:15:39, port 9999, zero data, 5MiB in ~10s = ~512KiB/s
151625-9999-random.png:
Creation of random data
Test completed at 15:16:25, port 9999, random data, 5MiB in ~10s = ~512KiB/s
165041-9999-zero.png:
Test completed at 16:50:41, port 9999, zero data, 5MiB in ~89s = ~57KiB/s
165252-9999-random.png:
Test completed at 16:52:52, port 9999, random data, 5MiB in ~87s = ~58KiB/s
165635-9999-http.png:
Test completed at 16:56:35, port 9999, random data with fake HTTP headers, 5MiB in 9.9s = 516KiB/s
165750-8080-zero.png:
Test completed at 16:57:50, port 8080, zero data, 5MiB in ~10s = ~512KiB/s
165846-8080-random.png:
Test completed at 16:58:46, port 8080, random data, 5MiB in ~10s = ~512KiB/s
225616-9999-zero.png:
Test completed at 22:56:16, port 9999, zero data, 5MiB in ~172s = ~29KiB/s
225954-9999-random.png:
Test completed at 22:59:54, port 9999, random data, 5MiB in ~171s = ~29KiB/s |
|
j3richo
join:2007-12-08
Gatineau, QC
 ·Acanac
 ·Videotron
| reply to jat
Re: Proof Bell throttles everything but known ports/protocols
good job, however we already knew that Bell does this when Deadpool admitted they use a "better safe than sorry" policy, meaning they throttle what they can't identify. It just shows how little regard they have for providing their customers with actual value, they'd rather degrade his connection even when it doesn't fall under P2P then risk having the data molestation fail. |
|
derekm
join:2008-02-26
·TekSavvy Solutions..
·Rogers Hi-Speed
| said by j3richo  :"better safe than sorry" policy From where I'm looking, it looks like a "better sorry than safe" policy. |
|
jat
join:2008-04-28
Burlington, ON
| reply to Anon
KiB = 1024*1024 = 1048576 bytes
MiB = 1024*1024*1024 = 1073741824 bytes
I didn't use KB or MB because some people use them to refer to 1000*1000 and 1000*1000*1000 bytes. KiB/MiB are quite explicit about using 1024 instead of 1000.
And for those complaining that my post was too technical, here's the dumbed down version:
Before 4:30, random data on port 9999 downloads at max speed. After 4:30, it only downloads at about 60KiB/s, while the same data on port 8080 and an HTTP download on port 9999 still download at max speed. Late in the evening, random data on port 9999 drops down to about 30KiB/s. |
|
jat
join:2008-04-28
Burlington, ON
| reply to j3richo
I must've missed that post. I was pretty pissed when I realized that while testing.
In any case, I just wanted the raw data and testing procedures public. If CAIP wants to, they can reproduce it and use it as evidence that Bell lied to the CRTC. |
|
Name96
join:2008-03-28 | reply to jat
Great job doing this.
Can you test with some UDP streams as well?
--
Coridon Henshaw -=- »www.talisiorder.ca |
|
Name96
join:2008-03-28
| reply to j3richo
said by j3richo :good job, however we already knew that Bell does this when Deadpool admitted they use a "better safe than sorry" policy, meaning they throttle what they can't identify. Got a link to that?
It's certainly been implied that they're molesting anything they can't identify but I haven't seen an explicit admission anywhere.
This has really bad ramifications for the deployment of new protocols on the Canadian Internet. Bell has frozen out the possibility for using anything custom, unusual, or heavily encrypted anywhere in Bell-controlled territory unless Bell decides to allow it. This means that if someone develops a new killer app that uses a new protocol, that 'killer app' won't work in Bell territory until Bell specifically decides to unblock it.
To put this in perspective, just think how slowly the WWW would have been adopted if it was necessary for every ISP to explicitly permit HTTP before their customers could access website. Chances are the Web would still be a niche tool with no widespread market penetration, and with that, the Internet would remain the niche domain of academics and professionals.
This is why we need net neutrality. No one should have to ask permission to innovate. |
|
np
@bell.ca | reply to jat
Thank you for your work. It's good to have hard evidence regardless of what an employee alluded to what was happening. Moreover this is a good baseline to check changes in the way throttling is performed in the future. |
|
np
@bell.ca | reply to jat
Additionally it makes it clear how throttling can be evaded (although this was easily suspected beforehand) |
|
recneps
join:2006-06-24
Whitby, ON
| reply to jat
To clarify his explanation:
KiB (kibibyte) and MiB (mebibyte)
are used to distinguish between "true" binary values (1024) and the "metric" (is it really metric?) values (1000's)
KiB = KB in terms of computer language (1024 bytes)
MiB = MB in terms of computer language (1024 kilobytes (of 1024 bytes each))
This is opposed to the now common (by hard drive manufacturers) use of (technically true) kilobyte ("1000 bytes") and megabyte ("1000000 bytes)
Much like the metric system (powers of 10)
In this system KB is not the same as KB above (1000 bytes vs 1024), so KiB is used to ensure there is no confusion.
(same with MiB, GiB, and so on) |
|
SteveJ
@bell.ca | reply to jat
Can you re-run your tests in UDP mode? netcat has a '-u' switch which should do it. |
|
Rand2k1
join:2003-12-09
Canada
| reply to recneps
said by recneps :To clarify his explanation: KiB (kibibyte) and MiB (mebibyte) are used to distinguish between "true" binary values (1024) and the "metric" (is it really metric?) values (1000's) KiB = KB in terms of computer language (1024 bytes) MiB = MB in terms of computer language (1024 kilobytes (of 1024 bytes each)) This is opposed to the now common (by hard drive manufacturers) use of (technically true) kilobyte ("1000 bytes") and megabyte ("1000000 bytes) Much like the metric system (powers of 10) In this system KB is not the same as KB above (1000 bytes vs 1024), so KiB is used to ensure there is no confusion. (same with MiB, GiB, and so on) Not metric, base 10, which is the standard numbering system we use.
Base 2, Base 8 and base 16 are also used for various purposes.
Computers are binary (base 2) and 1024 was called a kilobyte because it was the closest whole number in binary to 1000 (1024 in binary is 10000000000) this was done so they didn't have to make up a new term as they figured anyone who would care would take the time to understand the differences between base 10 and base 2.
They were wrong. |
|
jat
join:2008-04-28
Burlington, ON
| reply to SteveJ
said by SteveJ :
netcat has a '-u' switch which should do it. If only it were that easy. Unfortunately, UDP is a bit more complicated, and I can't find a good way to test it with existing tools.
Timing how long netcat runs doesn't work. UDP provides no way of indicating that one side is done sending, so the receiving netcat never knows to quit. It also doesn't resend dropped packets, so the sending netcat quits as soon as it's done sending everything as fast as it can, despite the fact that the receiver never got half of the data.
Per-connection speed monitoring only works for connection-oriented protocols (i.e., TCP), so the usual tools for that don't work. I think I have something I can use (it monitors host/port pairs instead of connections), but I'll have to play with it another day. Although it's worth mentioning that my connection seems to get maxed out receiving the random data over UDP on an unknown port, so it doesn't look like it's being throttled.
I'll see about playing with it tomorrow. Maybe I'll write something to test it in a reliable way. I don't think it should be too hard. |
|
dbsanfte
join:2005-03-15
Montreal, QC | reply to jat
Gonna chime in to say the KiB/MiB nonsense is pedantic at best. |
|
ultracat
join:2008-01-30
Toronto, ON | reply to jat
You should print this all out, write up your methodology, and mail it off to the CRTC explaining exactly how it proves Bell lied in its submission to them. One more nail for the coffin. |
|
Bellthrottles
@teksavvy.com
| reply to jat
This proves that Bell is effectively reducing the speed of everyone's connection to a mere 350kbps when they feel like it. Right now it's 4pm to 1am (or 2am)? Eventually it could be anything at all.
Normally, a company that would act like that would die in a true concurrential environment, so Bell decided that for Slowpatico to survive it had to push the throttling over to the independant ISPs. After all, who would accept to have a slow and crippled connected about half the daily hours.
As it stands now, Canadians have one of the worst internet service offer in the industrialized world.
If the appeal to the CRTC doesn't work, Slowpatico and other independant DSL customers should launch a class action lawsuit about how Bell is using its monopoly to force unconcurrential business practices upon the customers.
The throttling of nothing but what Bell thinks you should use your internet connection for is just the start of the downfall for all DSL customers. What's next after that? They will decide that you can't max out your connection for over 2 minutes before deeming you an abuser? Am I the only one that thinks it is absurd that the DSL terms of use are now worse than they were eight years ago?
Finally, I must say I am surprised that a company like Bell, with already a really bad reputation, would do a kind of move that brings the hatred of their customer base that's left. If the situation isn't resolved, I will move all my remaining services from Bell and I will inform all my family so they do as well to the cable company (not that I like them that much either, but at least they're not crapping on their customer base yet). |
|
tyip
join:2003-11-26
North York, ON
| reply to jat
I like to management my bandwidth better to minimize the effects of throttling have on my internet usage.
So if I am using P2P (or an application protocol unknown to Bell) during throttling hours and it maxes out the 30 KB/s limit, would my other applications (e.g. http, ftp, mms, rtsp, Shoutcast, etc) be affected if I use them simultaneously?
In other words, does the throttling slow down your entire internet connection when P2P is detected? (I heard that's what Rogers was doing some years ago, but I am not sure.)
Is Skype throttled?
Are they throttling upload, download, or both?
If they are throttling both, is the 30 or 60 KB/s limit shared for both upload and download, or do they have seperated limits?
Does Bell throttle wholesalers like TekSavvy the exact same way as they throttle Sympatico?
How does Bell different from Rogers in their throttling method? |
|
teksuebell
@cgocable.net
| reply to jat
JAT
JAT
Great work!. Please send your info not just to CRTC but PLEASE SEND IT TO:
www.michaelgeist.ca
mgeist@uottawa.ca
Michael Geist
University of Ottawa
Faculty of Law
Common Law Section
57 Louis Pasteur
Box 450, Stn. A
Ottawa, ON K1N 6N5
Canada
Please .... |
|
timc
join:2008-04-21
·TekSavvy Solutions..
·odynet
| reply to dbsanfte
said by dbsanfte :Gonna chime in to say the KiB/MiB nonsense is pedantic at best. Yes, let's work on differentiating kB from kb first. |
|
