O Canada! > Canadian > Bell Canada > Non P2P SSL Protocols now being throttled

Non P2P SSL Protocols now being throttled

Re: Non P2P SSL Connections now being Throttled

reply to Soiduts

Re: Non P2P SSL Protocols now being throttled

--
Sens up 3-1 vs Leafs...GO SENS GO

Bell's really made a mess of this stuff... There was much less problems I remember hearing about when Rogers implemented their throttling...
--
GO LEAFS GO!
Don't question the authoritaaaa!

Different boxes in all probability. From time to time though it was clobbering stuff it shouldn't when P2P was running, and when it wasn't. When that happened a complaint would result in a box reset and the problem was solved quickly.

I'm in Waterloo and I don't have any problems with SSL FTP. The full ~500KB/s here. Albeit... it's FTPES SSL FTP (i.e. it starts out as a regular FTP connection then the client negotiates SSL mode)

reply to HiVolt
hivolt, just for your information, rogers does throttle vpn. (I read into it for a friend in the other forum and ssl was not mentioned in the same post).

I think bell is particularly getting a lot of flack this time around because I think it was the last primary supplier that implemented this (before people would just switch, so now its twice the load [previous switchers plus new switchers]) in combination of implementing caps at the same time.

There was an article not long ago in the Ottawa Business Journal (which was also referenced on Micheal Geist's website), that claimed that all SSL traffic is throttled on the Rogers network, and that they proved it as well.

I don't know if this is still the case, however it was at some point.
--
Sens up 3-1 vs Leafs...GO SENS GO

reply to Deadpool
I am currently using Gene6FTP V3.8.0, FlashFXP with OpenSSL 0.9.8d for my SSL ftp transmissions on ports 990. For email I am using Outlook 2007 with SP1.

ggpr, implicit/explicit ssl makes no difference for me unfortunately.

I do have IRC going, would that be considered a P2P app that would affect throttling? Most servers I am connected are also using SSL on port 6697 but I haven't noticed any problems with pingouts or connection stability.

I've received one complaint in another forum that IRC with SSL enabled was also problematic.

Again if you could PM me your B1 that would really help since you've provided me the other info I needed.

Thanks!
--
Sens up 3-1 vs Leafs...GO SENS GO

reply to Soiduts
Just another quick update as I did a couple of more tests;
SSL FTP connections on port 990 (Standard port for ssl ftp) I was getting: 12 to 30kbps.

Unencrypted FTP of the same file from the same ftp I was maxing out (520kbps).

Unfortunately I'de like to keep most my transmissions encrypted, so it will be nice to see this issue resolved. It's being investigated currently, but I'de still be interested to hear if others were also having similar issues.

reply to Soiduts
I just came across this thread and it's very interesting. I'm not a protocol expert, so forgive me if my question seems naive. If I understand this correctly the ISP is able to detect the fact that someone is doing an SSL FTP transfer even if it's implicit SSL and not on a standard port (i.e. 990)? I was under the impression that an implicit SSL ftp session started with encryption in place, so it's somewhat surprising to me that the ISP could detect this if you wern't using port 990, and throttle accordingly.

What is it that gives away the fact that SSL ftp is happening? Is there some sort of SSL handshake that for example has the same sequence of messages going back and forth and of a certain size, such that an outside observer without the key could deduce that some sort of SSL connection was being established? One of the posters above also hinted that this traffic throttling might be happening for other SSL applications, so based on that I'm postulating that there must be something unique in the initial message sequencing for all SSL application, regardless of type or port being used, that an outside observer could use to identify that SSL was being employed.

Or is the answer simpler than that and there is something in the IP header that says "SSL"?

Just curious.

mudtoe

Examining the content of packets isn't the only way to identify a protocol. You can also build a profile based on other metrics. Size of packets, frequency of packets, patterns of packet exchange, number of hosts connected, etc.

The fact that it's SSL is identified in the initial exchange. I'm not sure that there's a way to identify an individual packet and say "encrypted" vs say "binary data". You certainly can't make an absolute determination of SSL without digging into the packet beyond the IP headers.

reply to Soiduts
I was working long hours for a couple of days and haven't had the chance to do any downloading but after a couple of days was i surprised.

1) FTP non ssl changes speed like no tommorow, @ night i can get 60kb ~ 135kb/s going up and down, this morning i was getting 10 ~30kb/s..,

2) My max download speed from speedtest.net from Toronto is 3mb/s and runs into a brick wall that won't go past. My 2wire modem says i can get 5056. Funny thing is if i use Fenton, MI i can get 4mb/s.

OK, your modem says 5056 ... now take off 15% atm and PPPoE overhead that you get with DSL and your actual end user max is about 4300.

So, with the Fenton MI speedtest, you're not too far off. Your actual speed for your connection is pretty much the max speed you get off speedtests. Usually the Toronto one SHOULD be the fastest, but because Bell doesn't peer through TORIX, and the Toronto test site is on a different network, packets from Bell take a circuitous route to get there which seems to introduce delays.

So, your line speeds are what you'd expect, but there definitely appears to be some congestion.