Actual physical point to point distance means nothing in the internet world, it all depends on ISP inter-connections. One time I pinged a server in the rack next to me and it had a 300ms delay because the packets were routed across the pacific and back because that was how the ISPs were connected to each other. If the servers had been directly connected the delay would have been in the microseconds. The servers were inches away from each other but the actual distance that the packets traveled round-trip over all the hops was on the order of 25,000 miles! That is an extreme example, but it illustrates that you can't trust distance.
Rather than distance you need to look at latency, that is the round trip time it takes for an echo sent to the VPN destination to be replied to. As for what round trip time would make UDP a better choice than TCP I do not know, and it isn't that simple as there are other factors:
- packet loss and jitter: UDP is very sensitive to packet loss and jitter (out of order packet) and it has no built-in correcting mechanism like TCP does. Any latency or jitter will erode any benefit of using UDP over TCP
- OS IP stack efficiency: the VPN application will be using the operating system's TCP/IP stack, which will also process UDP packets. Much of the relative efficiency of TCP versus UDP will be down to how well the OS (and any packet filtering or firewalls in the way) processes TCP versus UDP
- Application coding: The VPN application's quality will make a big difference, as will the VPN software on the device you are connecting to. For instance, how does it recover from lost UDP packets? Can it request re-transmissions or does it rely on the upstream applications to request retransmissions?
There are too many factors to give you a definitive answer as it depends on too many factors. You'll simply have to try both methods and see.
