UDP to ALL Serves unstable!

[FPyro 2]

I've had this issue forever I believe and I think it should be known and addressed.

Whenever I use UDP on any port, the connection (upload in particular) gets interrupted for several seconds. This happens in a somewhat random but very regular fashion.

It interrupts browsing, gaming and even decreases file-sharing performance!

Although connecting via UDP does provide better speeds in general, I don't see any advantages to using that protocol at the moment.

TCP fixes these "interruptions", but speeds are considerably slower on all but the very closest server...

Would you kindly explain this phenomenon? Is there any hope of fixing it or does this problem just come with the UDP-connection?

My ISP has nothing to do with the issue...both the ISP and several other customers of my ISP assure me they don't impose any restrictions on any protocol or port.

Thank you.

[Staff 9972]

Hello!

Unfortunately there's not much that can be done on the servers side. UDP is a correctionless protocol (from which its higher efficiency in conditions of "good" line and low latency), and when a packet is lost, the OpenVPN server will try to resend it within a certain timeout. TCP implements a very robust error correction, which, in conditions of "noisy" lines/high latency, will result in higher reliability at the price of decreased performance.

However, it's odd that you experience bad line with ALL the datacenters where our servers are in. This is a matter that you could further investigate on your side. Are there "Window-replay backtrack occurred" occurrences in your client logs with any (or all) servers?

Kind regards

[FPyro 2]

Hi!

Thank you for your reply.

Actually I wasn't expecting a solution to this because of the nature of the UDP connection (i.e. no error correction).

What I should have said is that the problem refers to all servers I actually use, which is only 1GB/s servers in Ger, Uk, and NL!

The "Window-replay backtrack occurred" is indeed a common error for me when using UDP which seems to highly correlate with the connection loss, though I'm not absolutely certain if it gets displayed in every instance.

The confusing thing is that when I'm not connected to the VPN I never get any kind of interruption like this and my connection has no packet loss or I at least I don't notice it like this.

Also, why is only the upload affected? The upload literally drops drastically, while downloads continue for a few seconds. The connection to the server isn't at any point severed either.

Would asking my ISP to measure my line for any kind of packet loss be a good idea?

Thank you

[Staff 9972]

Hi!

Thank you for your reply.

Actually I wasn't expecting a solution to this because of the nature of the UDP connection (i.e. no error correction).

What I should have said is that the problem refers to all servers I actually use, which is only 1GB/s servers in Ger, Uk, and NL!

Hello!

Therefore you experience the same problem with 4 different datacenters (2 in Germany, 1 in Holland and 1 in UK) and 5 different networks (2 in Germany, 2 in Holland and 1 in UK) on 9 different servers. This strongly suggest that it's not a server/datacenter side problem.

The "Window-replay backtrack occurred" is indeed a common error for me when using UDP which seems to highly correlate with the connection loss, though I'm not absolutely certain if it gets displayed in every instance.

So there's indeed packet loss.

The confusing thing is that when I'm not connected to the VPN I never get any kind of interruption like this and my connection has no packet loss or I at least I don't notice it like this.

This may be normal, especially if you have for most of your activities TCP connections.

Also, why is only the upload affected? The upload literally drops drastically, while downloads continue for a few seconds. The connection to the server isn't at any point severed either.

There may be an explanation for that. OpenVPN implements a packet-resending even with UDP. In order to do that, the client must verify the packets, tell the server of problems (if any), wait for lost packets to be resent and finally re-order the received packets in the appropriate order (according to the maximum allowed replay frame). During the process the client could be unable to send out new packets because it is still waiting for lost packets to be resent. So you would notice same download bw but poor ul bandwidth.

Would asking my ISP to measure my line for any kind of packet loss be a good idea?

Thank you

A very useful tool is mtr ("My TraceRoute"), available for all Linux systems (probably it's available on BSD systems too). Try to generate consistent reports by mtr toward all the entry-IP addresses of our servers. Then you'll have some useful material that may help you pick the server which gives you the minimum packet loss. Compare also the results with hosts you frequently connect to with and without VPN.

Kind regards

[FPyro 2]

Thanks a lot!

I'm gonna try the mtr tool for windows right away.