Why is this international internet traffic routed so inefficiently? [closed]

Question

Being located in the Philippines/Asia, I did a traceroute to a datacenter in the Netherlands/Europe:

traceroute to www.transip.nl (37.97.254.1), 30 hops max, 60 byte packets
 1  _gateway (192.168.0.1)  0.603 ms  0.820 ms  1.044 ms
 2  192.168.1.1 (192.168.1.1)  1.626 ms  1.913 ms  2.450 ms
 3  100.80.0.1 (100.80.0.1)  15.024 ms  15.499 ms  15.574 ms
 4  122.2.175.210.static.pldt.net (122.2.175.210)  19.529 ms  13.686 ms  18.721 ms
 5  210.213.130.194.static.pldt.net (210.213.130.194)  26.495 ms  29.889 ms  25.421 ms
 6  210.213.130.166.static.pldt.net (210.213.130.166)  29.558 ms 210.213.130.170.static.pldt.net (210.213.130.170)  31.060 ms 210.213.130.166.static.pldt.net (210.213.130.166)  30.544 ms
 7  be4082.ccr21.sea02.atlas.cogentco.com (38.88.253.225)  175.644 ms  176.446 ms  175.543 ms
 8  be2085.ccr21.slc01.atlas.cogentco.com (154.54.2.198)  192.795 ms  202.931 ms 154.54.89.102 (154.54.89.102)  197.130 ms
 9  be3038.ccr22.den01.atlas.cogentco.com (154.54.42.98)  205.635 ms be3037.ccr21.den01.atlas.cogentco.com (154.54.41.146)  206.457 ms be3038.ccr22.den01.atlas.cogentco.com (154.54.42.98)  199.473 ms
10  be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90)  218.277 ms be3036.ccr22.mci01.atlas.cogentco.com (154.54.31.90)  217.505 ms  219.785 ms
11  be2832.ccr42.ord01.atlas.cogentco.com (154.54.44.170)  234.085 ms  232.986 ms be2831.ccr41.ord01.atlas.cogentco.com (154.54.42.166)  239.130 ms
12  be2717.ccr21.cle04.atlas.cogentco.com (154.54.6.222)  232.922 ms be2718.ccr22.cle04.atlas.cogentco.com (154.54.7.130)  234.582 ms  236.636 ms
13  be2993.ccr31.yyz02.atlas.cogentco.com (154.54.31.226)  350.882 ms be2994.ccr32.yyz02.atlas.cogentco.com (154.54.31.234)  309.069 ms be2993.ccr31.yyz02.atlas.cogentco.com (154.54.31.226)  241.048 ms
14  be3260.ccr22.ymq01.atlas.cogentco.com (154.54.42.90)  252.195 ms be3259.ccr21.ymq01.atlas.cogentco.com (154.54.41.206)  254.512 ms  250.827 ms
15  be3042.ccr21.lpl01.atlas.cogentco.com (154.54.44.161)  321.737 ms be3043.ccr22.lpl01.atlas.cogentco.com (154.54.44.165)  316.665 ms be3042.ccr21.lpl01.atlas.cogentco.com (154.54.44.161)  321.672 ms
16  be2182.ccr41.ams03.atlas.cogentco.com (154.54.77.245)  330.955 ms be2183.ccr42.ams03.atlas.cogentco.com (154.54.58.70)  325.524 ms  328.065 ms
17  be2519.rcr21.b015960-1.ams03.atlas.cogentco.com (130.117.3.98)  325.461 ms  328.000 ms be3458.ccr21.ams04.atlas.cogentco.com (154.54.39.186)  328.784 ms
18  transip-bv.demarc.cogentco.com (149.6.128.66)  319.343 ms transip-bv.demarc.cogentco.com (149.6.128.70)  321.417 ms transip-bv.demarc.cogentco.com (149.6.128.66)  387.741 ms
19  e1-a7.r1.ams0.transip.net (157.97.168.0)  323.007 ms e1-a8.r2.ams0.transip.net (157.97.168.5)  322.006 ms e1-a7.r1.ams0.transip.net (157.97.168.0)  327.590 ms
20  r2.s2.t2.ams0.transip.net (37.97.252.135)  331.404 ms r2.s1.t2.ams0.transip.net (37.97.252.133)  347.417 ms r1.s2.t2.ams0.transip.net (37.97.252.131)  347.202 ms
21  * * *
22  www.transip.nl (37.97.254.1)  346.537 ms !X  346.544 ms !X  346.686 ms !X

And a traceroute to the Dutch government website:

traceroute to www.rijksoverheid.nl (178.22.85.11), 30 hops max, 60 byte packets
 1  _gateway (192.168.0.1)  0.671 ms  0.829 ms  1.076 ms
 2  192.168.1.1 (192.168.1.1)  1.583 ms  1.837 ms  2.297 ms
 3  100.80.0.1 (100.80.0.1)  18.357 ms  14.273 ms  19.029 ms
 4  122.2.175.210.static.pldt.net (122.2.175.210)  17.365 ms  16.517 ms  19.562 ms
 5  210.213.134.138.static.pldt.net (210.213.134.138)  20.223 ms  20.523 ms  25.175 ms
 6  210.213.134.150.static.pldt.net (210.213.134.150)  53.741 ms  53.280 ms  48.837 ms
 7  10ge1-7.core1.hkg1.he.net (74.82.46.121)  46.192 ms  45.045 ms  49.970 ms
 8  100ge2-1.core1.sin1.he.net (184.105.222.102)  79.106 ms  79.390 ms  78.945 ms
 9  100ge11-1.core1.mrs1.he.net (184.105.65.14)  216.103 ms  214.327 ms  213.072 ms
10  100ge4-2.core1.par2.he.net (184.105.222.21)  216.944 ms  214.460 ms  217.548 ms
11  100ge10-1.core1.ams1.he.net (184.105.81.110)  231.812 ms  228.647 ms  227.183 ms
12  rc03-te2-1.core.as41887.net (80.249.210.128)  226.056 ms  219.802 ms  224.610 ms
13  rc10-xe-0-0-1.core.as41887.net (94.228.128.214)  287.617 ms  285.719 ms  280.354 ms
(...)

The first traceroute seems to go through Hong Kong -> somewhere through USA -> Amsterdam using CoGent according to this map from cogentco.com (not really sure which path it takes):

The second traceroute goes through Hong Kong -> Singapore -> Marseille -> Paris -> Amsterdam using Hurricane Electric, which is clearly a faster route with regard to ping.

I measured the difference in ping between those two Dutch destinations to be averaging 400ms vs 300ms respectively. That is a huge difference for responsiveness when using remote SSH. Note that multiple runs of the traceroutes were consistent for each destination.

What could be the reason for this strange and inefficient routing?

Answer 1

There are two factors playing a role here.

The first is a limitation in BGP. Border Gateway Protocol (BGP) seems the most common protocol to connect international networks. It chooses its path based on the destination address, going through the least amount of networks. However, as a limitation, it does not look at the path length within the network, only the number of networks itself. Neither does it look at the actual quality of the route.

As it turns out based on their reply to my inquiry. Cogent, as a major backbone ISP, has a poor internet connectivity between Europe and Asia. They said:

"Cogent has limited peering in the Asia market. At this time the best path is heard through our peers in Marseilles to where the path goes to Telia's network.

The first Cogent hop in your trace is in Seattle and will go east to Europe.

(...)

Unfortunately we only have limited peering in Asia at this time. In the future peering should increase in the Asia market." - Cogent Communications Inc.

Also read this article: myths about internet performance, which says:

BGP has two drawbacks. First, routes are selected based on cost. ISPs design routing tables based on business relationships negotiated with other ISPs and therefore route traffic based on cost, not speed.

Second, routes don't adapt to congestion or loss. There is no feedback mechanism which allows an ISP to change a route based on path or network performance, so routing traffic into congested networks is a common occurrence. BGP ensures routing resilience, but does not address speed or performance.

The second factor, is that the target destination address, belongs to a datacenter that has better contracts with Cogent than its competitor HE (Hurricane Electric). As is shown by the following image from that datacenter:

This is why any connection from Asia going to TransIP will tend to use Cogent, but when the destination is another datacenter it might use Hurricane Electric instead.

Disclaimer: This answer is based on my own research and helpful answers/comments on a closed question by user1686 and DavidPostill. As such, take it as a probable but not reliable explanation.