Pakistan-Europe connectivity via China

Last week I saw an interesting re-tweet by my friend Doug Madory sharing a post by a Pakistani journalist on how Pakistan and China have reached an agreement to provide connectivity from Pakistan to Europe via China.

Before going into the tech part, an important thing to note here is that this scenario is unlikely to materialize because fibre connecting Pakistan to China would be via Karakoram pass as fibre is often deployed alongside existing/planned road infrastructure and this would cross POK (Pak Occupied Kashmir) which is part of Kashmir illegally held by Pakistan. Strongly doubt any infra development will be fruitful in the area in the long term.

Anyway, this brings me to a curious question by a friend - will such (hypothetical) connectivity reduce latency? To understand this let’s first look at how Pakistani networks presently connect to networks in Europe.

Pakistan’s global connectivity

Pakistan has a submarine cable landing station in Karachi that has the following cables:

  • Transworld (TW-1) - This is a 1300km long cable connecting Al Seeb (Oman), Fujairah (UAE) with Karachi, Pakistan - While this cable does not directly connect to Europe, there is a fair amount of diverse paths from Fujairah onwards over different cable systems. This map on shows it’s path. It’s a “Y” like design with one branch connecting Oman, other connecting UAE.

    (image source: Wikipedia)

  • Asia Africa Europe-1 (AAE-1) - This is a 25000km long cable connecting France to Hong Kong with few legs in between connecting Pakistan, India, and Myanmar to Hong Kong. The official map on the AAE1 website sums it up nicely.

  • SMW-4 - This is an old 18,800km long cable connecting Singapore with France. In total, it has 17 landing points with one of its legs connecting Karachi giving it access to UAE, Europe, Singapore etc.

    (image source: Wikipedia)

China’s Europe connectivity

China has a bunch of submarine cables and more importantly a land route from China - to Mongolia - Russia - Europe. This gives a completely separate land route to pushing traffic to Europe. I don’t need to go into detail about China - EU routing as you will realise as we test latency from Pakistan to the EU & possible new routes.

Latency from Karachi (Pakistan) - Marseille (France)

Currently, Karachi serves as a single-point failure, but there are multiple cables providing paths to Europe. Now while I cannot find the best possible latency over these cables unless we have access to these cable systems directly internet routing tells us what is there right now.

On these submarine cable systems networks typically order wavelengths/circuits in 10G/100G or even 400G with max traffic flows and commercial interest. So e.g Karachi and Mumbai each have a branch going for the cable there are (as far as I know) no direct circuits in between because there’s no commercial interest in operators buying capacity or connecting. Thus while the latency between Karachi to Mumbai can be extremely low (likely sub 50ms range) it’s hard to know for sure. However, there is considerable connectivity visible between Pakistani networks and networks in Europe. This can give some latency estimates. Another extremely important thing to understand here is that when we look from public networks/anchor points like looking glass, [RIPE Atlas(] etc we are looking at layer 3 latency and that greatly depends on the interconnection. It’s well known fact that at times interconnection happens a bit away from submarine landing stations. So if I send packets from say Karachi (Pakistan) to Marsellie (France) they might very well be exchanged somewhere in Paris or Amsterdam or Frankfurt instead of Marsellie. Layer 3 does not exactly overlap layer 1 but whatever lowest number we see on layer 3 can give some estimate of possible layer 1 connectivity.

This gives me a trace from two active RIPE Atlas probes in Pakistan to this NLNOG ring node participating machine in Marseille:

anurag@server7 ~> ripe-atlas measure traceroute --from-country PK --target

Looking good!  Your measurement was created and details about it can be found here:

Connecting to stream...


Traceroute to (, 48 byte packets

1 AS7018 3.539ms 0.616ms 0.749ms
2 AS7018 2.197ms 1.994ms 4.291ms
3 7.007ms 4.351ms 4.363ms
4 AS17557 4.465ms 6.172ms 5.27ms
5 9.334ms 5.67ms 8.322ms
6 6.321ms 5.778ms 11.854ms
7 23.957ms 21.373ms 23.913ms
8 31.276ms 25.226ms 21.095ms
9 AS1299 124.331ms 124.216ms 123.665ms
10 AS1299 126.804ms 130.061ms 127.417ms
11 AS30781 125.494ms 127.641ms 124.746ms
12 AS30781 129.082ms 131.659ms 127.247ms

2024-02-05 00:44 UTC

Traceroute to (, 48 byte packets

1 0.793ms 0.588ms 0.393ms
2 AS17557 1.904ms 0.902ms 0.795ms
3 AS17557 1.739ms 1.656ms 1.596ms
4 3.048ms 2.112ms 2.207ms
5 2.468ms 2.85ms 2.393ms
6 28.583ms 28.672ms 28.664ms
7 24.954ms 25.002ms 24.968ms
8 AS1299 134.328ms 134.508ms 134.984ms
9 AS1299 140.079ms 140.065ms 139.874ms
10 AS30781 136.739ms 136.791ms 136.799ms
11 AS30781 135.884ms 136.033ms 135.888ms

The first trace may seem a little confusing because of the presence of / AT&T AS7018 in the rDNS PTR. This is because of incorrect use of IP addresses in between. Someone felt was a private range while in fact, it’s part of AT&T Since this came just in between and is not a routing hijack, this anomaly can be ignored in the context of this post.

hop 8 in the first trace and hop 7 in 2nd trace show the last hop before the major jump to 120ms levels. Thus for sure one can get as low as 124ms between France and Pakistan. Since I see traffic landing on Arelion/Telia/AS1299, let’s look at the return trace to WAN IPv4 of one of the probes from my server in Germany:

traceroute to (, 30 hops max, 60 byte packets
 1 (  5.196 ms  5.109 ms  5.117 ms
 2 (  0.811 ms  0.782 ms  0.806 ms
 3 (  4.028 ms  3.932 ms  3.905 ms
 4 (  18.519 ms  18.491 ms  18.537 ms
 5 (  121.140 ms  121.110 ms  120.511 ms
 6  * * *
 7 (  135.580 ms  140.251 ms  132.034 ms
 8  * * *
 9  * * *
10  * * *

Hop 5 shows the Arelion/Telia IP (somewhere in Pakistan) on the PTCL router. It’s likely the /30 of the BGP session between Arelion and PTCL. This is at the PTCL side, the other would be likely on the Arelion side.

anurag@server7 ~> traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 (  3.017 ms  2.924 ms  2.909 ms
 2 (  0.882 ms  0.842 ms  0.903 ms
 3 (  3.959 ms  3.932 ms  3.905 ms
 4 (  12.021 ms  11.992 ms *
 5  * (  12.659 ms *
anurag@server7 ~> 

Latency from my server in Germany confirms the same. Again, to be more precise one can use the Arelion looking glass and ping the PTCL side from the router in the same location where PTCL has a L3 interconnection. To find where PTCL is connected, let’s pick any random EU PoP and look at the BGP table output for

Router: ffm-b11 / Frankfurt (Equinix FR5, Kleyerstrasse)
Command: show bgp ipv4 unicast

BGP routing table entry for
Last Modified: Jan 18 12:05:13.821 for 2w3d
Paths: (8 available, best #1)

  Path #1: Received by speaker 0
  17557 (metric 2172) from (
      Origin IGP, localpref 200, valid, internal, best, group-best, import-candidate
(RPKI state Valid)
(Prepend 3x to ANY peer in Asia)
(Prepend 3x to Orange/5511 in Asia)
(Prepend 3x to Centurylink/Level3/3356 in Asia)
(Prepend 3x to AT&T/2687 in Asia)
(Prepend 3x to GTT/3257 in Asia)
(Prepend 3x to Telecom Italia/6762 in Asia)
(Prepend 3x to Vodafone/1273 in Asia)
(Prepend 3x to China Unicom/4837 in Asia)
(Prepend 3x to China Telecom/4134 in Asia)
(Prepend 3x to PCCW/3491 in Asia)
1299:1000 1299:7573 1299:7613 1299:30000 1299:30410

      Originator: (mei-b5), Cluster list:

  Path #2: Received by speaker 0

While most of this is usual day-to-day traffic engineering (and is fascinating to watch), let’s focus on the last line:

1299:1000 1299:7573 1299:7613 1299:30000 1299:30410

These BGP communities are documented on Arelion here and the last one 1299:30410 tells a specific city which is Marseille, France.

So this confirms that PTCL connects/takes transit from Arelion in Marseille itself. This can give a pretty good estimate of the lowest possible latency on this path.

Let’s trace and ping Arelion IP on PTCL in Pakistan from Arelion PoP in Marseille:

Command: traceroute ipv4 timeout 1 source Loopback0

Tracing the route to

 1 ( 103 msec  103 msec  103 msec 

With this one can conclude the existing latency of 103ms. It could be slightly better since I did not ping a server / open ICMP endpoint but rather a big fat router which likely could rate limit/slowdown ICMP.

Comparing latency

So back to the original question - Will Pakistan have latency better than 103ms if it goes via the POK -> China -> Mongolia -> Russia -> Europe route?

I don’t know what the latency between Pakistan -> POK, and POK -> China will look like. I cannot test latency reliably from China -> Europe simply because of the known great firewall of China & overall case of known poor layer 3 interconnections. But I can check from Mongolia -> Europe.

anurag@server7 ~> ripe-atlas measure traceroute --from-country MN --target

Looking good!  Your measurement was created and details about it can be found here:

Connecting to stream...


The lowest visible latency here seems to be 121 ms. This latency is slightly higher than the latency between Pakistan and Marseille!

Thus while the EU as a whole can be large, I am quite certain Pakistan would not have latency better than what they have right now with Europe over the submarine cable links. Therefore, despite the allure of a new connectivity route, it’s unlikely that Pakistan would achieve significantly lower latency to Europe via China.

Disclaimer: This post is on my personal blog and thus written in my personal capacity only. It has no relation to my employer.