Anycast Latency: How Many Sites Are Enough?

Abstract

Anycast is widely used today to provide important services including naming and content, with DNS and Content Delivery Networks (CDNs). An anycast service uses multiple sites to provide high availability, capacity and redundancy, with BGP routing associating users to nearby anycast sites. Routing defines the catchment of the users that each site serves. Although prior work has studied how users associate with anycast services informally, in this paper we examine the key question how many anycast sites are needed to provide good latency, and the worst case latencies that specific deployments see. To answer this question, we must first define the optimal performance that is possible, then explore how routing, specific anycast policies, and site location affect performance. We develop a new method capable of determining optimal performance and use it to study four real-world anycast services operated by different organizations: C-, F-, K-, and L-Root, each part of the Root DNS service. We measure their performance from more than 7,900 worldwide vantage points (VPs) in RIPE Atlas. (Given the VPs uneven geographic distribution, we evaluate and control for potential bias.) Key results of our study are to show that a few sites can provide performance nearly as good as many, and that geographic location and good connectivity have a far stronger effect on latency than having many nodes. We show how often users see the closest anycast site, and how strongly routing policy affects site selection.

Taming Anycast in the Wild Internet

“…Moreover, we examine how manipulating inbound routes alters the end-user performance of anycast. We demonstrate that these announcement changes may induce significant changes to both the site selected, as explored in previous work [15,27], as well as changes in the route taken. 49.5% of vantage point groups shift site catchment (i.e.…”

“…Other providers may re-announce only in specific regions or in other conditions. As described in previous work [15,16,27], these external decisions are difficult to predict, and they change not only where traffic arrives (i.e., the site the traffic arrives at, and the catchment to which each user belongs), but also how traffic arrives at that site (i.e., the AS path taken).…”

“…As our first measurement target, we consider the DNS root servers. The DNS roots have been a common measurement target when studying anycast [15,27]. They are appealing targets due to the relative availability of information on their deployments [3], as well as the fact that they are managed by multiple organizations with differing deployment strategies.…”

“…Previous studies have explored techniques for managing anycast networks, including proposals to use only a single provider [10], focusing on effective deployment at site level [15], working around poor anycast performance using DNS routing [12], and deploying new BGP communities [27]. While many of these approaches are effective in context, they may not be applicable in scenarios where many providers are necessary for scale and reliability, certain site choices are not available, significant rearchitecting is not possible, or upstream providers are unlikely to provide support for new communities.…”

Oblivious DNS: Practical Privacy for DNS Queries

“…As described in Section 4.3, ODNS resolvers are replicated and use anycast IP addresses in order to provide scalability and achieve desirable latencies. To get a sense for the size of an anycast deployment that would provide adequate performance, Schmidt et al [14] investigated the performance of realworld anycast systems and determined that a system deployed in only 12 locations around the world can result in relatively low latency for a global client base. Though the target RTTs for DNS would likely call for a larger anycast deployment, we anticipate that a widelydeployed ODNS anycast network could achieve acceptable lookup latencies for any user.…”