Michael Takeuchi and the invisible IXP bottleneck

Michael Takeuchi’s port was clear. The congestion was on the other side.

Why it matters

Indonesia’s crowded exchange market gives operators more paths. It also gives them more places where a fault can hide behind somebody else’s dashboard.

Sofia Ren9 November 2026Reading Time 2 minLast update: 9 November 2026

Michael Takeuchi; identity grounded in a named Peering Asia speaker photograph. The workspace is illustrative.

Summary

In his original May 2026 BKNIX Peering Forum presentation, Michael Takeuchi described congestion at another peering member’s limited port while his own port had spare capacity.
His slides put the missing looking glass, traffic statistics and shared operating rules beside the routing problem. A clean local graph could not identify the remote bottleneck.

The cruelest network graph is the green one beside a customer complaint. Takeuchi, RAPIDNET’s technology and operations chief and a deputy chief for Indonesia Internet Exchange and data centre work at APJII, gave BKNIX’s forum a specific case: his own port was not congested, yet traffic suffered because another peering member had limited ports and he could not see that member’s network management dashboard. He asked the obvious operational question: how can one operator monitor the other side?

That question carries more weight in Jakarta than it would in a single-exchange town. Takeuchi’s Peering Asia record lists RAPID Networks at IIX-Jakarta, EPIX Jakarta, OpenIXP/NiCE, JKT-IX, CXC and CDIX. In his BKNIX deck he illustrated one ISP connected to twelve Jakarta exchanges. He also showed one prefix arriving over eleven BGP sessions from five exchanges. Those are examples from his slides, not a national inventory. They show why another physical port creates another policy and another possible blind spot.

His complaint was pointed. Some networks offer a looking glass; others expose little telemetry. Exchanges also differ in route-server configuration, community support and filtering practice. A route can look tidy from one participant’s rack while a peer’s narrow port, policy or announcement sends traffic into a queue. Takeuchi’s deck describes a case where an exchange offered no BGP community control, leaving manual selective peering as the available manoeuvre when a path congested.

The network has plenty of ways to draw a route. It has fewer ways to show which organisation is making that route fail. A shared view of port pressure and a reachable escalation contact would turn Takeuchi’s mystery into a ticket with an owner. The public deck does not name the congested peer or provide its port counters; those records would establish the fault’s exact size and duration.