Some CDNs select servers based on the round-trip latency between the CDN server and the client's local DNS server [15]. It is therefore important to understand the correlation between the round-trip delay to a client and to its LDNS from a third location.
To compare with the results presented in [15], we study how the round-trip delays to the client and its LDNS determine the accuracy of the CDN server selection based on round-trip delays to the LDNS. Since our data set consists of more than 4.2 million pairs of client and LDNS, much larger than that presented in [15] (1,090 pairs), we expect some differences. Let and be the round-trip delays between the probe site and the client, and between the probe site and the client's LDNS, respectively. We ask the question whether implies . Depending on the locations of two probe sites and , the percentage of violations ranges from 17% to 38%. For instance, among the 9,360 client-LDNS pairs responding to traceroute from both probe site 1 and 2, about 38% violate this assumption. This implies that if one selects between two CDN servers located at probe sites 1 and 2 based on the round-trip delays to the LDNS, the decisions would be suboptimal 38% of the time for the set of clients considered based on the round-trip delay metric. On the other hand, among the 7,895 pairs responding to traceroute from both probe site 2 and 4, only 17% violate this assumption. This means that this metric is highly dependent on probe locations. However, it is a reasonable metric for use to avoid really distant servers.
Another interesting question to answer is whether, if two CDN servers are roughly an equal distance from the LDNS based on the round-trip delay, the same holds from the client's perspective. Thus, we ask whether implies , where is a small number (e.g., a 10 ms threshold was used by Shaikh et al. [15]). In the sample of our study, it holds in 44-75% of the cases depending on the probe sites. This number is bigger than the previously obtained result of 12% in [15].