Connectivity to the K-Root Instance in Delhi

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 193.0.14.129 (193.0.14.129), 30 hops max, 38 byte packets 
 1  192.168.1.1  1.835 ms  1.820 ms  1.603 ms 
 2  117.200.48.1  25.264 ms  25.523 ms  25.559 ms 
 3  218.248.173.42  25.591 ms  25.313 ms  25.464 ms 
 4  218.100.48.6  31.220 ms  30.228 ms  31.039 ms 
 5  193.0.14.129  31.023 ms  30.416 ms  31.918 ms

and

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

The difference between the two lies in hop 4. In the fast ~30ms case, 218.248.173.42 (BSNLNET National Internet Backbone) seems to hand it over to 218.100.48.6 a host on the national Internet exchange LAN. In the slow case, the same national backbone IP address is followed by 203.190.136.17 (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.