Fluctuating speeds

[worric 12]

Hi,

First of all I'm very happy I invested in AirVPN. It seems overall like a very accomplished service with solid and noble ideals behind it.

My only complaint is the fluctuating speeds I get when connected to your service, especially to the 1gb servers. Draconis should be the closest to my location physically, but I get really poor speeds when connected to it (max of ~1MB/s, fluctuating a lot up to that speed, and averaging at 600KB/s). I have a 20mbit connection which I can easily max out and without fluctiations when not connected to airVPN.

All the while considering not many people are connected to Draconis compared to the other 1gb servers at any given time.

The 100mbit servers seem to provide a more stable, consistent speed, oddly enough, although the speeds are lower and can't always deliver the 20mbit I can pull.

I did try your speedtest and it showed 16mbit down, which I would be fully satisfied with getting if only the speed was stable and didn't fluctuate that much. But while the test was running, I kept an eye on the windows client which I suspect measures more accurately, and it showed the same high fluctuation in kbps downstream even though the speedometer in the test was happily stable maxing out at 16mbit.

And yes, I know that added overhead is incurred by using a VPN.

I guess there's not a whole lot to do about it other than to question whether the AirVPN solution is properly set up resource wise.

Also, are, say, two users on each of their 1gbit connection allowed to completely saturate the bandwidth of a single 1gbit server, effectively forcing all the other ~150 users connected down to (and probably below) the minimum guaranteed available bandwidth of 4mbit?

[Staff 9773]

Also, are, say, two users on each of their 1gbit connection allowed to completely saturate the bandwidth of a single 1gbit server, effectively forcing all the other ~150 users connected down to (and probably below) the minimum guaranteed available bandwidth of 4mbit?

Hello!

Thank you for your nice words. Although the causes for fluctuating speed are difficult to be detected, you might want to try every 1 Gbit/s server to see which one can give you the most stable performance.

On top of that, fluctuating speeds can be a hint for packet deprioritization from your ISP. Several ISPs deprioritize (or even shape) traffic on several or all UDP ports. Please test a connection on port 80 TCP to check whether it mitigates the issue or not.

Each connected user on any server has no caps on bandwidth. The system balances the bw between all the clients. Load balancing, in order to have a fair bandwidth distribution, is not 100% perfect of course, anyway it is quite effective. Furthermore, the load balancing system on 1 Gbit/s servers does not need to work at the moment, because our customers do not use more than 30-40% of the servers capacity.

Kind regards

[worric 12]

Hi!

Thank you for your answer!

It does seem like you were right. The speeds I get when connecting by TCP port 80 are as stable as they come! However, now I'm stuck at ~1MB/s only. Is that the sheer TCP overhead that eats up 10mbit?

Can you please clear up; what are the advantages/disadvantages of using the ports you offer, if any? (aside from the fact that my ISP seems to be deprioritizing UDP traffic).

[Staff 9773]

Hi!

Thank you for your answer!

It does seem like you were right. The speeds I get when connecting by TCP port 80 are as stable as they come! However, now I'm stuck at ~1MB/s only. Is that the sheer TCP overhead that eats up 10mbit?

Hello!

No, the overhead is not so heavy. The bandwidth difference can't be explained with this. Are you stuck at 8 Mbit/s on ANY 1 Gbit/s server? If so, such a coherence is suspect and again points to your ISP. Do you obtain just the very same bw on port 53 TCP and 443 TCP?

Can you please clear up; what are the advantages/disadvantages of using the ports you offer, if any? (aside from the fact that my ISP seems to be deprioritizing UDP traffic).

It's in the FAQ: https://airvpn.org/faq

Kind regards

[worric 12]

Again, thanks for your fast reply.

After switching to UDP port 80, I'm happy to say that the throughput fluctuation I've been experiencing is gone! I'm now pulling a more or less constant 1.5+ MB/s from the Delphini server. It does indeed seem like my ISP is deprioritizing UDP traffic for some ports, but not port 80 at least.

While testing, though, I found that the handshake failed on UDP port 53. At least to the Delphini server.

Just a quick question, wouldn't it seem.. umm.. suspicious to an ISP if a lot of data is being transferred though port 53? And possibly even attract further attention, leading to further investigation of the circumstances and negating the privacy that's being added while using a VPN in the first place?

Or would you say that it's rather unlikely that an ISP will notice at all?

[Staff 9773]

While testing, though, I found that the handshake failed on UDP port 53. At least to the Delphini server.

Hello!

We'll look into this as soon as possible. Thank you for the information.

EDIT: no problems detected on Delphini port 53 UDP. Connections are just fine.

Just a quick question, wouldn't it seem.. umm.. suspicious to an ISP if a lot of data is being transferred though port 53? And possibly even attract further attention, leading to further investigation of the circumstances and negating the privacy that's being added while using a VPN in the first place?

Or would you say that it's rather unlikely that an ISP will notice at all?

If usage of a VPN is legal in your country, you should not be bothered by what an ISP can think of tunneled traffic. VPNs are normally used by tens of thousands companies in order to provide their employees and customers a more secure and comfortable environment.

In general, while a VPN harms some commercial plans based on traffic discrimination/Net Neutrality violation (usually enacted by ISPs to force customers to pay more for "different QoS" etc.), it also can be seen as a relief for the ISP because it strengthens the ISP role of mere conduit.

Kind regards

[worric 12]

Hm, it seems I'm still having trouble with the handshake:

29-06-2012 - 13:50 Login...

29-06-2012 - 13:50 Login success.

29-06-2012 - 13:50 Contacting service...

29-06-2012 - 13:50 Connecting...

29-06-2012 - 13:50 OpenVPN 2.2.2 Win32-MSVC++ [sSL] [LZO2] [PKCS11] built on Dec 15 2011

29-06-2012 - 13:50 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

29-06-2012 - 13:50 LZO compression initialized

29-06-2012 - 13:50 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]

29-06-2012 - 13:50 Socket Buffers: R=[8192->8192] S=[8192->8192]

29-06-2012 - 13:50 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]

29-06-2012 - 13:50 Local Options hash (VER=V4): '22188c5b'

29-06-2012 - 13:50 Expected Remote Options hash (VER=V4): 'a8f55717'

29-06-2012 - 13:50 UDPv4 link local: [undef]

29-06-2012 - 13:50 UDPv4 link remote: 146.185.25.170:53

29-06-2012 - 13:51 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

29-06-2012 - 13:51 TLS Error: TLS handshake failed

29-06-2012 - 13:51 TCP/UDP: Closing socket

29-06-2012 - 13:51 SIGUSR1[soft,tls-error] received, process restarting

29-06-2012 - 13:51 Restart pause, 2 second(s)

29-06-2012 - 13:51 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

29-06-2012 - 13:51 LZO compression initialized

29-06-2012 - 13:51 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]

29-06-2012 - 13:51 Socket Buffers: R=[8192->8192] S=[8192->8192]

29-06-2012 - 13:51 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]

29-06-2012 - 13:51 Local Options hash (VER=V4): '22188c5b'

29-06-2012 - 13:51 Expected Remote Options hash (VER=V4): 'a8f55717'

29-06-2012 - 13:51 UDPv4 link local: [undef]

29-06-2012 - 13:51 UDPv4 link remote: 146.185.25.170:53

29-06-2012 - 13:51 Disconnecting...

29-06-2012 - 13:51 Disconnected.

All other ports to Delphini are alright.

[Staff 9773]

Hm, it seems I'm still having trouble with the handshake:

29-06-2012 - 13:50 UDPv4 link local: [undef]

29-06-2012 - 13:50 UDPv4 link remote: 146.185.25.170:53

29-06-2012 - 13:51 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

29-06-2012 - 13:51 TLS Error: TLS handshake failed

Hello!

It looks like your outbound port 53 UDP is blocked. We confirm you that Delphini OpenVPN is accepting packets on port 53 UDP. Please make sure that you have no firewall blocking the port. Are you able to connect via port 53 UDP to some other of our servers?

Kind regards