Anycast Latency: How Many Sites are Enough?. Heidemann, J., de O. Schmidt, R., & Kuipers, J. H. Presentation at DNS-OARC Meeting, October, 2016. Based on the the technical report [Schmidt16a]Paper abstract bibtex This talk will evaluate anycast latency. 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.
@Misc{Heidemann16b,
author = "John Heidemann and
Ricardo de O. Schmidt and Jan Harm Kuipers",
title = "Anycast Latency: How Many Sites are Enough?",
howpublished = "Presentation at DNS-OARC Meeting",
note = "Based on the the technical report [Schmidt16a]",
month = oct,
year = 2016,
address = "Dallas, Texas, USA",
sortdate = "2016-10-16",
project = "ant, lacrend, retrofuture, researchroot, pinest, nipet",
jsubject = "network_security",
jlocation = "johnh: pafile",
keywords = "based on [Schmidt16a], anycast, dns, design, latency",
url = "https://ant.isi.edu/%7ejohnh/PAPERS/Heidemann16b.html",
pdfurl = "https://ant.isi.edu/%7ejohnh/PAPERS/Heidemann16b.pdf",
myorganization = "USC/Information Sciences Institute",
copyrightholder = "authors",
abstract = "
This talk will evaluate anycast latency. 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":"4gXgRjqTcdcxcnGSo","bibbaseid":"heidemann-deoschmidt-kuipers-anycastlatencyhowmanysitesareenough-2016","author_short":["Heidemann, J.","de O. Schmidt, R.","Kuipers, J. H."],"bibdata":{"bibtype":"misc","type":"misc","author":[{"firstnames":["John"],"propositions":[],"lastnames":["Heidemann"],"suffixes":[]},{"firstnames":["Ricardo"],"propositions":["de"],"lastnames":["O.","Schmidt"],"suffixes":[]},{"firstnames":["Jan","Harm"],"propositions":[],"lastnames":["Kuipers"],"suffixes":[]}],"title":"Anycast Latency: How Many Sites are Enough?","howpublished":"Presentation at DNS-OARC Meeting","note":"Based on the the technical report [Schmidt16a]","month":"October","year":"2016","address":"Dallas, Texas, USA","sortdate":"2016-10-16","project":"ant, lacrend, retrofuture, researchroot, pinest, nipet","jsubject":"network_security","jlocation":"johnh: pafile","keywords":"based on [Schmidt16a], anycast, dns, design, latency","url":"https://ant.isi.edu/%7ejohnh/PAPERS/Heidemann16b.html","pdfurl":"https://ant.isi.edu/%7ejohnh/PAPERS/Heidemann16b.pdf","myorganization":"USC/Information Sciences Institute","copyrightholder":"authors","abstract":"This talk will evaluate anycast latency. 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":"@Misc{Heidemann16b,\n\tauthor = \t\"John Heidemann and\n Ricardo de O. Schmidt and Jan Harm Kuipers\",\n\ttitle = \t\"Anycast Latency: How Many Sites are Enough?\",\n\thowpublished = \"Presentation at DNS-OARC Meeting\",\n\tnote = \"Based on the the technical report [Schmidt16a]\",\n\tmonth = \toct,\n\tyear = \t2016,\n\taddress = \"Dallas, Texas, USA\",\n\tsortdate = \t\"2016-10-16\",\n\tproject = \"ant, lacrend, retrofuture, researchroot, pinest, nipet\",\n\tjsubject = \"network_security\",\n\tjlocation = \t\"johnh: pafile\",\n\tkeywords = \t\"based on [Schmidt16a], anycast, dns, design, latency\",\n\turl =\t\t\"https://ant.isi.edu/%7ejohnh/PAPERS/Heidemann16b.html\",\n\tpdfurl =\t\"https://ant.isi.edu/%7ejohnh/PAPERS/Heidemann16b.pdf\",\n\tmyorganization =\t\"USC/Information Sciences Institute\",\n\tcopyrightholder = \"authors\",\n\tabstract = \"\nThis talk will evaluate anycast latency. An anycast service uses\nmultiple \\emph{sites} to provide high availability, capacity and\nredundancy, with BGP routing associating users to nearby anycast\nsites. Routing defines the \\emph{catchment} of the users that each\nsite serves. Although prior work has studied how users associate with\nanycast services informally, in this paper we examine the key question\n\\emph{how many anycast sites are needed} to provide good latency, and\nthe worst case latencies that specific deployments see. To answer\nthis question, we must first define the \\emph{optimal performance}\nthat is possible, then explore how routing, specific anycast policies,\nand site location affect performance. We develop a new method capable\nof determining optimal performance and use it to study four real-world\nanycast services operated by different organizations: C-, F-, K-, and\nL-Root, each part of the Root DNS service. We measure their\nperformance from more than \\numbervps worldwide vantage points (VPs)\nin RIPE Atlas. (Given the VPs uneven geographic distribution, we\nevaluate and control for potential bias.) Key results of our study\nare to show that a few sites can provide performance nearly as good as\nmany, and that geographic location and good connectivity have a far\nstronger effect on latency than having many nodes. We show how often\nusers see the closest anycast site, and how strongly routing policy\naffects site selection.\n\",\n}\n\n","author_short":["Heidemann, J.","de O. Schmidt, R.","Kuipers, J. H."],"bibbaseid":"heidemann-deoschmidt-kuipers-anycastlatencyhowmanysitesareenough-2016","role":"author","urls":{"Paper":"https://ant.isi.edu/%7ejohnh/PAPERS/Heidemann16b.html"},"keyword":["based on [Schmidt16a]","anycast","dns","design","latency"],"metadata":{"authorlinks":{}}},"bibtype":"misc","biburl":"https://bibbase.org/f/dHevizJoWEhWowz8q/johnh-2023-2.bib","dataSources":["YLyu3mj3xsBeoqiHK","fLZcDgNSoSuatv6aX","fxEParwu2ZfurScPY","7nuQvtHTqKrLmgu99"],"keywords":["based on [schmidt16a]","anycast","dns","design","latency"],"search_terms":["anycast","latency","many","sites","enough","heidemann","de o. schmidt","kuipers"],"title":"Anycast Latency: How Many Sites are Enough?","year":2016}