Continental Bottlenecks and VPN Slowdowns

I've been on the Philippines recently for a round of meetings and it was interesting to observe the availability of bandwidth for non-secure and VPN encrypted traffic to oversea destinations.

During the later parts of the evening, at night and during the morning, I could easily transfer 2-3 MBit/s a second over my VPN connection. If I dropped the VPN connection and went to the same overseas websites directly and downloaded email (still encrypted over secure POP3 and secure SMTP), speeds were in the same region. During the day however, speeds over the VPN connection dropped to 200 to 300 kbit/s while unencrypted access to web resources in Europe and the US remained above the 1 MBit/s level. The difference remained even when I changed the VPN transport type from UDP packets to TCP packets terminating at the https port 443.

The same effect could be seen no matter whether I used the hotel Wi-Fi or the 3G network via a local SIM card. That likely means that it's the overseas link that becomes congested during the day. Just strange that encrypted connections were more affected by it than plain http traffic. Also, it didn't matter whether the VPN tunnel ended in the United States or in Europe, throughput levels were equally low during business hours.

I wonder if all that means there is a special preference for certain types of traffic for oversea links!? It was also interesting to observe that my company VPN, which works with a different technology than my private VPN based on OpenVPN was throttled down even further during the day time to 100 kbit/s and sometimes even less. Other participants at the meeting noticed the same behavior which is a bit of an annoyance if everyone depends on new versions of documents stored on a server abroad.

To overcome this limitation I mirrored some documents for the meeting on a local server on the IP subnet the Wi-Fi access point supplied. Unfortunately, not all participants could access local resources as many company firewalls and VPNs prevent devices to access local resources.

2 thoughts on “Continental Bottlenecks and VPN Slowdowns”

  1. Although http://www.cablemap.info/ shows seven submarine cables landing on the Philippines only two are intercontinental ones:
    The old and slow SEA-ME-WE 3 cable running to Europe with 24 landing points inbetween which each claim some of the relatively moderate 1 TBit/s-bandwidth and the AAG with 2.88TBit/s heading to the US.
    All other cables have a rather regional scope. Further there seems to be little overall capacity from Asia westbound to Europe.
    That said I believe most of Filipino internet traffic is routed through Japan or Guam to the US and further given the lack of capacity from Asia to Europe on the westbound route even traffic to Europe is likely to also travel through the US.
    When I traceroute http://www.smart.com.ph and http://www.globe.com.ph (Filipino MNOs) at least my German ISP routes through the States. Tracing http://www.digitel.ph didn’t give a clear result as IP-packets are forwarded transparently (on IP level) on a long distance but given the fact latency after the last hop in Europe (in Munich) increases by 330ms when pinging the next hop in Hong Kong indicates a routing via the USA, too.
    Actually the submarine cable topology of the world has been very USA-centric and only recently projects for new transoceanic routes emerge (e.g. from Africa to Latin America like WASACE South or SAex) and with several cable systems surrounding Africa plans are to establish new westbound routes from Asia to Europe on these cables.
    So your traffic back to Germany has probably taken a quite long route with many potential bottlenecks. Anyway your observations regarding the discrepancy in data rates between different services is strange. Perhaps your VPN packets require more CPU power during interception and deep packet inspection by Echelon when passing the USA 😉

  2. Could this simply be a result of (transparent) web caches or CDNs like Akamai? With VPN connections, you won’t get the contents served by local servers …

Comments are closed.