Just to cover this particular base… when you VPN in to your employer’s network, are you also accessing a remote virtual desktop (e.g. Citrix), and using the browser on that remote session to do your speed test?
I also want to add a data point: where I was living in Italy for a couple of years recently I had a shitty shitty ADSL connection with PPPoE. It couldn’t even stream YouTube reliably at low-res settings. Then I bought into a commercial VPN service (TunnelBear) in an attempt to watch the BBC, and when connected via the VPN my YouTube was working again. Speedtest tests didn’t show a noticeable difference, but there was definite traffic shaping going on.
From reading all this speculation about howw Speedtest works, it strikes me that this is the key question. Otherwise surely it tests from the Speedtest server to the client, which is running in your local browser. It would surely be an end-to-end test. Unless your browser is on a VM at your company why would the speed be affected?
That’s what violates net neutrality. Now, IANAL, and there are exceptions (particularly around ISPs’ ability to give realtime guarantees to certain protocols), but an ISP cannot, in general, pick which packets to prioritize. For example, they cannot choose to let video through and block (or slow down) P2P sharing protocols. They have to be neutral towards what the packet is and where it’s going.
No, when I’m connecting via the VPN, I’m not connecting to a remote computer. Oh, and I do believe that they’re throttling to 5 mb, that’s the service commitment.
StG
Your ISP is an idiot.
The Cisco VPN is almost certainly using GRE to encapsulate the encrypted data. The ISP service level throttle only looks for IP packets. So the VPN does not get throttled.
Sadly, your run of the mill commercial VPN will not use the same encapsulation.
No, net neutrality has fuckall to do with what I am talking about. This is about edge speed, not routing priority.
si_Blakely explained it better than I did.
Slee
I’ll add:
Traffic Policy Enforcement for service carriers is actually pretty difficult, without actually having to deal with things like streaming services and gaming and voip …
Forgetting to include encapsulated IP packets into the rate-shaping profile qualifies as pretty small beans in my book. At least it works for StGermain, which is an advantage. The Cisco AnyConnect client (as I recall) tries multiple different connection methods, failing down to the next most compatible protocol as connection attempts fail.
StGermain may be able to find a VPN provider that uses a similar encapsulation, but it will be fairly hard - most commercial VPN providers have gone down the SSL VPN tunnel route for compatibility, and that traffic will almost certainly be shaped.
And as for net neutrality, ISPs can do what the hell they like in their own networks - they can rateshape any traffic they like: what they cannot do is rateshape similar products differently based on source. Net Neutrality means that video from Google Play cannot be throttled differently from video from Amazon Prime, or Netflix, or Pornhub.
However, Net Neutrality does not say that an ISP can’t get a peering agreement and/or a cache rack from Netflix that provides Netflix customers awesome streaming capacity within the ISP, as opposed to less favorable performance from other video providers. This is a customer advantage - it may penalise other providers, but they should be all on the same tier, and could arrange their own peering agreement.
Also, video from Google Play cannot be throttled differently from Skype (*), email, file transfers, or anything else. ISPs need to route packets neutrally relative to what type of packet it is.
On this we agree, and I suggested upthread that the differences in speed could very well be related to the use of different interconnects.
(*) There are exceptions for realtime guarantees, which could potentially advantage packets from things like Skype.
Can you clarify what you mean here, by the way? VPN traffic, as is all internet traffic, is transmitted via IP.
VPNs encapsulate an IP packet inside another packet (such as IPSEC or PPTP). That IP packet is hidden until it is received at the endpoint where the IP packet is separated from encapsulation (and decrypted), and passed on to its recipient. An ISP may not recognize an encapsulated packet for what it is.
Imagine your post office only lets you mail 5 letters a day. You want to mail 10 letters to different people at a business. So you put all the letters in a cardboard box and ship the box to that business through the post office. They don’t object because they don’t know what’s in the box. When the box arrives at the business, a recipient opens it up and hands the mail to the intended recipients.
It’s like packet smuggling. 
No, I get this. My point is that the actual, encrypted VPN packet is still transmitted over IP. Is it your contention that it uses a different Layer-3 protocol?
We are going to disagree here - I believe that (for example) email traffic packets (SMTP, POP, IMAP, and the secure variants of such) are fundamentally different from (for example) HTTP traffic, and can be routed, shaped and delivered in different ways. Your HTTP traffic almost certainly goes through a transparent proxy server at your ISP that you are not aware of. This is common practice, and is not what is meant by Net Neutrality, which is specifically to do with source/destination rate shaping based on financial agreements.
ISPs determine the traffic type using a classifier: tcp/udp port, source address, destination address, or deep packet inspection.
The packets are IP, but there are various IP protocols:
Most host/client traffic is TCP (0x06) or UDP (0x11), but there are plenty more IP protocols. SSL VPNs are just TCP packets, with the VPN functionality an Application Layer function. But other VPNs actually use different IP Protocol types (LLTP: 0x73, IPIP: 0x04, GRE: 0x2F, ESP 0x32) - these get routed across the internet (they are IP packets with a source address, destination address and TTL) but can be routed and examined differently by routers along the path.
My belief is that the ISP rateshaper for StGermain’s 5Mb/s connection only examines TCP and UDP traffic, and does not shape other IP protocols.
Thanks for the clarification. I wouldn’t be surprised if you are correct that this is what the ISP is doing, but I continue to contend that the ISP shouldn’t be doing this under the net neutrality rules, since it constitutes acting in a non-neutral way based on the type of packet being transmitted. You’ve got me curious enough about my understanding of the legal aspects here that I’ll probably dig in a little more on what is and isn’t allowed under net neutrality.
I will repeat that I think that this is an error of omission (to the OP’s benefit), not a deliberate policy choice.
Have fun down the rabbit hole …
I support Net Neutrality (defined as ensuring ISP customers are not penalised for using a particular provider of a service by cost or speed), and I live for the End-to-End principle (all routable nodes on the internet are equal). But ISPs need to be able to rate shape and internally route traffic in any way they like to maintain service and performance, as long as it is compatible with the previous principles and is applied fairly. If an ISP wants to throttle bittorrent traffic, I don’t actually care as long as they state this up-front when people sign up, or get informed correctly when policies change. Smart ISPs use timebased shaping too, so that some traffic can flow freely at offpeak periods but is throttled during on-peak times. Again, I don’t mind this as long as the customers know that this is going to occur.
Right, I agree. And I think the FCC is definitely less concerned with small ISPs taking their time getting up to net neutrality compliance than the Comcast’s of the world testing the edges by doing things like offering their own TV service package as a “non-Internet service.” It was more of a “hey, isn’t that a technical violation?” than a “the FCC is going to crackdown on them immediately!” type of comment.
It would be wrong to RemoteDesktop / Citrix / VMware into the office server, and run the speed test there and think it is testing the data through to your home… In that case its just the view of the browser that is coming to your home !
The speed test shows the worst of the bottlenecks… the minimum speed along the way…
His connection to work may be avoiding the ISP’s main connection to the internet, which was causing the minimum to be 5 mbs…
Perhaps the ISP peers in his city or state, and it peers to the same network that his work is on. OR perhaps his work has the same network provider… same effect, his traffic to his work isn’t leaving his city… its not subject to the bottle neck of the main internet connection.
So then, how does the work connect ? well they pay for a premium service (they may have their own private network to another city ) , and avoid the bottle neck … basically it may well be carried over the same fibre optic but they pay for priority…
Reported.