Why Does Internet Traffic from Kazakhstan to Indonesia Go Through London and San Jose?
Why Does Internet Traffic from Kazakhstan to Indonesia Go Through London and San Jose?
Based on real RIPE Atlas measurements from GeoCables monitoring infrastructure, March 2026
It takes 334 milliseconds for a data packet to travel from Almaty, Kazakhstan to Jakarta, Indonesia. That sounds reasonable for a long distance — until you look at the actual path it takes.
The packet doesn't travel east through Central Asia and Southeast Asia. It goes west.
The Geography Problem
Kazakhstan is landlocked. With no coastline, it has no direct access to submarine cables — the fiber-optic systems that carry over 95% of international internet traffic. The nearest ocean is the Caspian Sea, which is a closed basin with no connection to global cable infrastructure.
This forces all of Kazakhstan's international traffic onto terrestrial fiber heading to neighboring countries before it can reach the sea. The question is: which direction?
Geographically, the answer should be east — through China into the South China Sea, then south to Indonesia. That route covers roughly 7,000–8,000 km. At the speed of light in fiber (~200,000 km/s), it should take around 40–50ms one way, or 80–100ms round trip.
The actual measured RTT is 334ms. Something is very wrong.
The Real Path: A Traceroute Story
A traceroute from our RIPE Atlas probe in Almaty reveals what actually happens:
| Hop | Location | ASN | RTT |
|---|---|---|---|
| 1-5 | Almaty → Astana, KZ | Signal Telecom / Transtelecom (AS41798) | ~5ms |
| 6 | London, UK | RETN Limited (AS9002) | 44ms |
| 7-8 | Frankfurt, DE | NTT America (AS2914) | 85ms |
| 9 | Paris, FR | NTT America (AS2914) | 172ms |
| 10 | Ashburn, US | NTT America (AS2914) | 228ms |
| 11 | San Jose, US | NTT America (AS2914) | 228ms |
| 12 | Osaka, JP | NTT America (AS2914) | 330ms |
| 13+ | Tokyo → Indonesia | AS23774 | 334ms |
Total actual distance traveled: approximately 30,000+ km. Logical direct distance: ~7,500 km. Overhead factor: 4×
Which Cables Are Involved
The westward path uses well-documented cable infrastructure:
Kazakhstan → Europe leg: Transtelecom (AS41798) connects Kazakhstan to Russia via terrestrial fiber, then hands off to RETN (AS9002), a pan-European carrier with a major presence in CIS countries. This gets the traffic to Frankfurt and London in ~44ms.
Atlantic crossing: NTT America (AS2914) picks up the traffic in Frankfurt and routes it westward across the Atlantic — likely via FLAG Atlantic-1 (FA-1, 14,000 km, New York–UK/France) or a similar transatlantic system.
Pacific crossing: From San Jose, NTT's backbone crosses the Pacific to Osaka. NTT operates one of the largest submarine cable networks in the Pacific, including the Pacific Crossing systems connecting the US West Coast to Japan.
Final leg to Indonesia: From Osaka/Tokyo, traffic enters Indonesia via cables such as SEA-ME-WE 5 (which lands at Dumai and Medan in Sumatra) or the AAE-1 system (landing at multiple Indonesian points via Singapore). Both connect Japan to Indonesian landing points.
Why Does This Happen?
The routing is driven by BGP (Border Gateway Protocol) economics, not geography.
1. No direct peering east: Kazakh carriers have limited peering agreements with Chinese operators (China Telecom, China Unicom). Cross-border connectivity between KZ and CN is constrained by policy and commercial terms.
2. NTT's global backbone: NTT America (AS2914) operates one of the most extensive global IP backbones. Once traffic enters NTT's network in Frankfurt, it follows NTT's internal routing — which sends Asian destinations via their Pacific infrastructure, not back eastward through Asia.
3. Traffic engineering: For NTT, routing KZ→ID traffic through their existing US-Japan infrastructure is operationally simpler than maintaining optimized Central Asia → Southeast Asia paths.
The result is a technically functional but geographically absurd route.
What an Optimal Route Would Look Like
A geographically optimal path would be:
Almaty → Tashkent (UZ) → Urumqi (CN) → Shanghai (CN) → Singapore → Jakarta
This route would use: - Terrestrial fiber through Central Asia and Western China - PEACE Cable or AAE-1 from China/Southeast Asia south to Indonesia - Estimated RTT: 120–150ms (based on cable distances)
That's a 2.2× improvement over the current 334ms. For latency-sensitive applications — gaming, VoIP, video conferencing — the difference between 150ms and 334ms is the difference between usable and unusable.
Current Monitoring Status
GeoCables monitors this route continuously via RIPE Atlas probes in Almaty. Over the past 30 days:
- Average RTT: 334ms (Almaty → Jakarta) - Best measured RTT: 317ms - Consistency: Extremely stable — the routing anomaly is structural, not transient - Measurement frequency: Every 6 hours across multiple Indonesian endpoints (Jakarta, Kendari, Batam, Kauditan, Manokwari)
The stability actually makes this worse news: this isn't a temporary degradation. It's the normal state of Kazakhstan–Indonesia connectivity.
The Bigger Picture
Kazakhstan is not alone. Many landlocked countries in Central Asia — Uzbekistan, Kyrgyzstan, Tajikistan, Turkmenistan — face similar routing inefficiencies. Their traffic often travels tens of thousands of kilometers in the wrong direction before reaching destinations in neighboring regions.
As China's Belt and Road Initiative builds out terrestrial fiber infrastructure across Central Asia, and as new cable systems like PEACE (which connects Pakistan and East Africa via the Middle East) mature, these routing inefficiencies may gradually improve.
For now, if you're pinging from Almaty to Jakarta, your data is taking the scenic route — via London, New York, and Tokyo.
Route data collected by GeoCables RIPE Atlas probes. Measurements updated every 6 hours. Check the current status →