Anycast Latency: How Many Sites Are Enough?. Schmidt, R. d. O., Heidemann, J., & Kuipers, J. H. Technical Report ISI-TR-2016-708, USC/Information Sciences Institute, May, 2016. ![Anycast Latency: How Many Sites Are Enough? [link]](https://bibbase.org/img/filetypes/link.svg "link")
Paper abstract bibtex 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 \emphsites to provide high availability, capacity and redundancy, with BGP routing associating users to nearby anycast sites. Routing defines the \emphcatchment 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 \emphhow 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 \emphoptimal 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 νmbervps 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.
@TechReport{Schmidt16a,
author = "Schmidt, Ricardo de O. and John Heidemann and Jan Harm Kuipers",
title = "Anycast Latency: How Many Sites Are Enough?",
institution = "USC/Information Sciences Institute",
year = 2016,
sortdate = "2016-05-18",
number = "ISI-TR-2016-708",
project = "ant, lacrend, lander, retrofuture, researchroot, pinest, nipet",
month = may,
jlocation = "johnh: pafile",
keywords = "anycast, dns, design",
url = "https://ant.isi.edu/%7ejohnh/PAPERS/Schmidt16a.html",
pdfurl = "https://ant.isi.edu/%7ejohnh/PAPERS/Schmidt16a.pdf",
myorganization = "USC/Information Sciences Institute",
copyrightholder = "authors",
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 \emph{sites} to provide high
availability, capacity and redundancy, with BGP routing associating
users to nearby anycast sites. Routing defines the \emph{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 \emph{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
\emph{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 \numbervps
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.",
}
Downloads: 0
{"_id":"3zEXtqfS3iCsfXvxu","bibbaseid":"schmidt-heidemann-kuipers-anycastlatencyhowmanysitesareenough-2016","author_short":["Schmidt, R. d. O.","Heidemann, J.","Kuipers, J. H."],"bibdata":{"bibtype":"techreport","type":"techreport","author":[{"propositions":[],"lastnames":["Schmidt"],"firstnames":["Ricardo","de","O."],"suffixes":[]},{"firstnames":["John"],"propositions":[],"lastnames":["Heidemann"],"suffixes":[]},{"firstnames":["Jan","Harm"],"propositions":[],"lastnames":["Kuipers"],"suffixes":[]}],"title":"Anycast Latency: How Many Sites Are Enough?","institution":"USC/Information Sciences Institute","year":"2016","sortdate":"2016-05-18","number":"ISI-TR-2016-708","project":"ant, lacrend, lander, retrofuture, researchroot, pinest, nipet","month":"May","jlocation":"johnh: pafile","keywords":"anycast, dns, design","url":"https://ant.isi.edu/%7ejohnh/PAPERS/Schmidt16a.html","pdfurl":"https://ant.isi.edu/%7ejohnh/PAPERS/Schmidt16a.pdf","myorganization":"USC/Information Sciences Institute","copyrightholder":"authors","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 \\emphsites to provide high availability, capacity and redundancy, with BGP routing associating users to nearby anycast sites. Routing defines the \\emphcatchment 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 \\emphhow 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 \\emphoptimal 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 νmbervps 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.","bibtex":"@TechReport{Schmidt16a,\n\tauthor = \t\"Schmidt, Ricardo de O. and John Heidemann and Jan Harm Kuipers\",\n\ttitle = \t\"Anycast Latency: How Many Sites Are Enough?\",\n\tinstitution = \t\"USC/Information Sciences Institute\",\n\tyear = \t\t2016,\n\tsortdate = \"2016-05-18\",\n\tnumber = \t\"ISI-TR-2016-708\",\n\tproject = \"ant, lacrend, lander, retrofuture, researchroot, pinest, nipet\",\n\tmonth = \tmay,\n\tjlocation = \t\"johnh: pafile\",\n\tkeywords = \t\"anycast, dns, design\",\n\turl =\t\t\"https://ant.isi.edu/%7ejohnh/PAPERS/Schmidt16a.html\",\n\tpdfurl =\t\"https://ant.isi.edu/%7ejohnh/PAPERS/Schmidt16a.pdf\",\n\tmyorganization =\t\"USC/Information Sciences Institute\",\n\tcopyrightholder = \"authors\",\n\tabstract = \"Anycast is widely used today to provide important services including\nnaming and content, with DNS and Content Delivery Networks (CDNs). An\nanycast service uses multiple \\emph{sites} to provide high\navailability, capacity and redundancy, with BGP routing associating\nusers to nearby anycast sites. Routing defines the \\emph{catchment} of\nthe users that each site serves. Although prior work has studied how\nusers associate with anycast services informally, in this paper we\nexamine the key question \\emph{how many anycast sites are needed} to\nprovide good latency, and the worst case latencies that specific\ndeployments see. To answer this question, we must first define the\n\\emph{optimal performance} that is possible, then explore how routing,\nspecific anycast policies, and site location affect performance. We\ndevelop a new method capable of determining optimal performance and\nuse it to study four real-world anycast services operated by different\norganizations: C-, F-, K-, and L-Root, each part of the Root DNS\nservice. We measure their performance from more than \\numbervps\nworldwide vantage points (VPs) in RIPE Atlas. (Given the VPs uneven\ngeographic distribution, we evaluate and control for potential bias.)\nKey results of our study are to show that a few sites can provide\nperformance nearly as good as many, and that geographic location and\ngood connectivity have a far stronger effect on latency than having\nmany nodes. We show how often users see the closest anycast site, and\nhow strongly routing policy affects site selection.\",\n}\n\n\n","author_short":["Schmidt, R. d. O.","Heidemann, J.","Kuipers, J. H."],"bibbaseid":"schmidt-heidemann-kuipers-anycastlatencyhowmanysitesareenough-2016","role":"author","urls":{"Paper":"https://ant.isi.edu/%7ejohnh/PAPERS/Schmidt16a.html"},"keyword":["anycast","dns","design"],"metadata":{"authorlinks":{}}},"bibtype":"techreport","biburl":"https://bibbase.org/f/dHevizJoWEhWowz8q/johnh-2023-2.bib","dataSources":["YLyu3mj3xsBeoqiHK","fLZcDgNSoSuatv6aX","fxEParwu2ZfurScPY","7nuQvtHTqKrLmgu99"],"keywords":["anycast","dns","design"],"search_terms":["anycast","latency","many","sites","enough","schmidt","heidemann","kuipers"],"title":"Anycast Latency: How Many Sites Are Enough?","year":2016}