Connectivity to the K-Root Instance in Delhi

Emile Aben — Feb 20, 2012 05:35 PM
Contributors: Rene Wilhelm
Filed under: , ,
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 ProbesFigure 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.

1 Comment

Steve says:
Feb 22, 2012 07:22 AM
H-Root looks interesting for (at least) probes 4, 8, 20, 38, 39, 53, 57 & 78.
Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Related Items
Increased Reach of RIPE Atlas Anchors

Increasing the reach of RIPE Atlas anchors is one of the highest priority goals of RIPE Atlas Team. ...

Proposing Making RIPE Atlas Data More Public

RIPE Atlas is now three years old, and is moving from a prototype to production service. Based on ...

RIPE Atlas: Improved Probe Pages

We've made it much easier to get an overview of the history and measurements for all the public ...

Visualising Bandwidth Capacity and Network Activity in RIPEstat Using M-Lab Data

As a result of the cooperation between the RIPE NCC and Measurement Lab (M-Lab), you can now ...

RIPE Atlas Fun: Map a RIPE Atlas Anchor

View maps based on RIPE Atlas traceroute measurements. Compare the maps to the ISP's description of ...

more ...