DeeLoaf

I realize that this topic has been discussed to the point of sickness. However I am actually looking for a way to test the theory. I have been on MNSI(local DSL Provider) and have worked with Bell and neither have been as slow as cogeco for uploads. Now I realize that there are some differences in service and technology but it was pretty blatant that there was a difference in speeds. There must be a conclusive way to tell if traffic shaping is being done on the cogeco network.

Do you think there is any chance that cogeco will admit to traffic shaping and if they do not is there anything the CRTC can do. Like does cogeco not have to disclose that information to there users?

When putting in my 3rd network tech support ticket I asked them to have the tech call me. He did and we had an interesting conversation.

The crux of it is that cogeco will do what cogeco needs to do in order to deliver reliable service to its customers, in terms of what most customers expect. Certain network usages of a minority of users can not be allowed to disrupt the online experience of other users. He said he could not go into detail about it. He did mention shaping, but when I asked more on that he backtracked and said it wasnt for him to discuss. He would not, however, deny that traffic shaping is happening within cogecos network. That, so far, is the best confirmation that I've been able to get. He said that whatever is going on is going to go on for a long time.

You want an easy test? You'll need a remote computer with a good internet connection that you can control and send things to. For this I rented a VPS from one of the many inexpensive VPS providers, sub $20 per month for one with the co I pay. PM me for more details if you like. The test I run is simple and pretty fool-proof as far as I'm concerned. Upload a 18MB .avi file via FTP to that computer. Then upload it with BT to that computer. Locally, BT upload tests are conducted using Azureus to seed the .avi file and Azureus's built-in tracker to keep it nice and controlled and private. Remotely, to receive the file for the BT test, I use rtorrent which is based on lib_torrent and ncurses. You can interactively control it via SSH. During testing, the only peer to connect to the Azureus tracker and join the 'swarm' is the remote VPS. At the moment the remote peer connects, the local seed should max its upload.

The consistent result of this testing has shown that on Cogeco, FTP works (70kb/s), and BT is broken (10kb/s), while on DSL, FTP and BT both work fine (both do 70kb/s). One note is that rtorrent does not support BT protocol encryption, but we shouldnt have to encrypt things for them to work anyways.

Everything about my cogeco connection works fine except for BT (and possibly other p2p stuff that is upload-heavy, but thats not my focus), and yet, like magic, if I plug my router into the DSL line and then stop/start torrents BT starts uploading properly right away.

You are not the only one experiencing this issue with Cogeco. I know of at least two other registered users on this BBR who are experiencing the same ACUTE inability to upload using certain protocols (like BT, encrypted or not) on top of TCP. So there are at _least_ 4 of us here. And meanwhile, many others (such as urbanriot), the vast majority it would seem, have no apparent problem to upload on BT.

There is only one line of devices that I am aware of that are marketed as being able to specifically target and disrupt BT traffic encrypted or not, and that is the NetEnforcer from Allot Communications. If Cogeco is NOT using this, then they've managed to roll their own solution to accomplish the same thing. On you. And on me.

Cogeco needs to come clean on this.

# posted by DeeLoaf @ 9:10 AM