Moving beyond end-to-end path information to optimize CDN performance

Abstract

Replicating content across a geographically distributed set of servers and redirecting clients to the closest server in terms of latency has emerged as a common paradigm for improving client performance.In this paper, we analyze latencies measured from servers in Google's content distribution network (CDN) to clients all across the Internet to study the effectiveness of latency-based server selection. Our main result is that redirecting every client to the server with least latency does not suffice to optimize client latencies. First, even though most clients are served by a geographically nearby CDN node, a sizeable fraction of clients experience latencies several tens of milliseconds higher than other clients in the same region. Second, we find that queueing delays often override the benefits of a client interacting with a nearby server.To help the administrators of Google's CDN cope with these problems, we have built a system called WhyHigh. First, WhyHigh measures client latencies across all nodes in the CDN and correlates measurements to identify the prefixes affected by inflated latencies. Second, since clients in several thousand prefixes have poor latencies, WhyHigh prioritizes problems based on the impact that solving them would have, e.g., by identifying either an AS path common to several inflated prefixes or a CDN node where path inflation is widespread. Finally, WhyHigh diagnoses the causes for inflated latencies using active measurements such as traceroutes and pings, in combination with datasets such as BGP paths and flow records. Typical causes discovered include lack of peering, routing misconfigurations, and side-effects of traffic engineering. We have used WhyHigh to diagnose several instances of inflated latencies, and our efforts over the course of a year have significantly helped improve the performance offered to clients by Google's CDN.

Content retrieval using cloud-based DNS

“…Using this service, we can easily geolocate Akamai content servers and nameservers with reasonable accuracy. For example, in Figure 1, we geolocate the end-server 149.165.180.19 to Bloomington, Indiana, which is found to be 85 miles away from our client IP with a Geo-RTT [10] of 1 ms, which matches the measured RTT of 1.5 ms.…”

“…However, they do not study a deeply distributed CDN like Akamai which handles dynamic content. Several studies have investigated data center performance [10], [20]. The WhyHigh tool [10] diagnoses high latency to Google's data centers and finds causes related to inter-domain routing, however effective solutions are not proposed.…”

Effectiveness of Service-oriented Router for ISP-CDN Collaboration

“…DNS-based end-user redirection is the most well-known redirection method used by CDNs [4], [6], [40], [42]. A detailed explanation about the DNS-based redirection is given in Refs.…”

Optimizing cost and performance for content multihoming

“…Figure 1 shows the edge server footprints of three real CDNs: Amazon CloudFront, MaxCDN and ChinaCache. When a content viewer from a location area a requests a content object through CDN k, a well designed CDN will choose an edge server (or several servers) that is close to a to serve the request, since a short latency from edge servers to end users is typically needed to achieve good content delivery performance [15]. Comparing the geographical footprints of the three CDNs shown in Figure 1, one can anticipate that CloudFront and MaxCDN are more likely to provide better performance in US and Europe, while ChinaCache may perform well in China.…”