Emile Aben

Connectivity to the K-Root Instance in Delhi

Emile Aben
Contributors: Rene Wilhelm
0 You have liked this article 0 times.

As a follow-up to the previous article and prompted by a question in the mailing list, we looked into connectivity of one particular instance of K-root: the one located in Delhi. India.

Prompted by an email from Anurag Bhatia , we looked into connectivity to the K-root instance located in Delhi, India.

RIPE Atlas probes query for the instance name of all root name servers periodically. From this data we distilled all queries that were answered by the instance in Delhi. We also record the round trip time (RTT) for these queries, which is plotted over time in Figure 1 for the 5 probes that we saw querying the Delhi K-Root instance.

RTT to New Delhi K-Root Instance from Atlas Probes Figure 1: Round trip time for queries answered by the New Delhi K-Root node

The image shows that probes 1020 (red) and 1032 (green) have periods where the RTT is around 300 ms. This is far above the average, which seems to lie at about 50 ms.

Looking at traceroute data collected in RIPE Atlas, probe 1020 seems to switch between just these 2 routes:

 traceroute to (, 30 hops max, 38 byte packets 
 1  1.835 ms  1.820 ms  1.603 ms 
 2  25.264 ms  25.523 ms  25.559 ms 
 3  25.591 ms  25.313 ms  25.464 ms 
 4  31.220 ms  30.228 ms  31.039 ms 
 5  31.023 ms  30.416 ms  31.918 ms


 traceroute to (, 30 hops max, 38 byte packets 
 1  18.587 ms  15.286 ms  18.437 ms 
 2  45.546 ms  45.281 ms  36.663 ms 
 3  45.648 ms  25.620 ms  46.263 ms 
 4  302.994 ms  302.111 ms  302.125 ms
 5  323.703 ms  322.929 ms  322.003 ms

The difference between the two lies in hop 4. In the fast ~30ms case, (BSNLNET National Internet Backbone) seems to hand it over to a host on the national Internet exchange LAN.  In the slow case, the same national backbone IP address is followed by (Software Technology Parks of India). The ~300ms round trip time seems to be introduced in this step. In cases like these it would be interesting to have the reverse path, which we can't get from traceroutes from the RIPE Atlas probes, to see if this increase in RTT is caused by the return packets.

If you know of significant network situations where you think RIPE Atlas data can help, you can register for RIPE Atlas after which you have access to data for all public probes. If there are network situations that you think are interesting to have analysed for the community, please leave a comment under the article or contact us at ripe-atlas at ripe dot net. We can then look into this and produce a short RIPE Labs article in response.

0 You have liked this article 0 times.

You may also like

View more

About the author

Emile Aben Based in Amsterdam, NL

I'm a system architect/research coordinator at the RIPE NCC, where I work in the science group. I'm a chemist by training, but have been working since 1998 on Internet related things, as a sysadmin, security consultant, web developer and researcher. I am interested in technology changes (like IPv6 deployment), Internet measurement, data analysis, data visualisation, sustainability and security. I'd like to bring research and operations closer together, ie. do research that is operationally relevant. When I'm not working I like to make music (electric guitar, bass and drums), do sports (swimming, (inline) skating, bouldering, soccer), and try to be a good parent.

Comments 1