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].