Looking for geo-directional DNS service

Mailman List Mirror (Read Only)
1

Except Hank is asking for true topological distance (latency /
throughput / packetloss).

Anycast gives you BGP distance, not topological distance.

Say I'm in Ashburn and peer directly with someone in Korea where he
has a node (1 AS hop), but I get to his node in Ashburn through my
transit provider (2 AS hops), guess which node anycast will pick?

Ashburn and other major network meet points are oddities in a very complex
network. It would be fair to note that anycast is likely to be reasonably
effective if deployed in a manner that was mindful of the overall Internet
architecture, and made allowances for such things.

Anycast by itself probably isn't entirely desirable in any case, and could
ideally be paired up with other technologies to "fix" problems like this.

I haven't seen many easy ways to roll-your-own geo-DNS service. The ones
I've done in the past simply built in knowledge of the networks in question,
and where such information wasn't available, took "best guess" and then may
have done a little research after the fact for future queries. This isn't
as comprehensive as doing actual latency / throughput / pl checking.

... JG

2

Except Hank is asking for true topological distance (latency /
throughput / packetloss).

Anycast gives you BGP distance, not topological distance.

Say I'm in Ashburn and peer directly with someone in Korea where he
has a node (1 AS hop), but I get to his node in Ashburn through my
transit provider (2 AS hops), guess which node anycast will pick?

Ashburn and other major network meet points are oddities in a very complex
network. It would be fair to note that anycast is likely to be reasonably
effective if deployed in a manner that was mindful of the overall Internet
architecture, and made allowances for such things.

You are not disagreeing with me. I was responding to Woody who said:

Yes, and that's how anycast works: it directs traffic to the
_topologically nearest_ server.

[...]

If you're doing things on the Internet, instead of the physical world,
topological distance is presumably of much greater interest than whatever
geographic proximity may coincidentally obtain.

Unless you define "topologically nearest" as "what BGP picks", that is incorrect. And even if you do define topology to be equivalent to BGP, that is not what is of the greatest interest. "Goodput" (latency, packet loss, throughput) is far more important. IMHO.

If you don't like my example, then ignore Ashburn and take a random, medium-sized network. Now assume an anycast node which is topologically (i.e. latency, bit-miles, throughput, whatever your definition) closer through transit, compared to a node topologically farther away through peering. Which is chosen? And this is not even close to an unusual situation.

This in no way means anycast sux. It just means anycast is not, by a long shot, guaranteed to give you the "closest" node by any reasonable definition. (Sorry, I don't think "node BGP picks" is "reasonable". You are welcome to disagree, but the point still stands that other definitions of "reasonable" are not satisfied.)

In general, anycast is better than not-anycast, and can be optimized to be better than non-anycast for nearly all user by someone with enough clue + money + time. This is not in question. It is essentially impossible to guarantee anycast is better than any other solution for all applications and all end users, especially over time as the Internet changes. This is not in question either.

3

[patrick@ianai.net ("Patrick W.Gilmore")]

And even if you do define topology to be equivalent to BGP, that is not
what is of the greatest interest. "Goodput" (latency, packet loss,
throughput) is far more important. IMHO.

in my less humble justified true belief, this is 100% truth.

This in no way means anycast sux. It just means anycast is not, by a
long shot, guaranteed to give you the "closest" node by any reasonable
definition. (Sorry, I don't think "node BGP picks" is "reasonable". ...

i also second this notion.

in our (ISC's) current use of anycase (for f-root and other dns servers),
anycast is a crutch for not having a global backbone, but wanting f-root to
have global representation and extreme replication. informal studies don't
show as much locality as we'd like -- but by peering aggressively everywhere
and by setting no-export on our route almost everywhere, we've been able to
localize and isolate ddos effects, which is all we were trying to accomplish.

but note, f-root is a normal dns server, it has an absolute mapping between
<qname,qtype,qclass,time> and <answer>. i don't believe in stupid dns tricks
(where that mapping is relativized for TE purposes), and one of the reasons
for my disbelief is that many ISP's in f-root's ~40 IXP locations do not
peer with us, and their traffic is therefore answered in remote (to them)
places where TE can't be predicted. in other words, people doing "stupid dns
tricks" are probably counting on anycast to do something f-root doesn't care
about (and which i think BGP won't do even on its best day.)

4

There are many different ways to set up Internet topology. Some of these achieve geographic proximity, and some don't. Network topology that doesn't match geographic proximity (common in Southern Africa, South America, and to a degree in the central US) leads to some unavoidable performance issues (speed of light, constraints on long distance capacity, etc.). A distribution system following topology in such an environment won't do nearly as well as one that follows topology in a better interconnected area, but following topology should still produce better performance than not doing so. If traffic from ISP A to ISP B in Region 1 goes through Region 2, ISP B will be served better by content in Region 2 than by content in ISP A. So, following topology is good.

There are many different ways to set up an anycast system, and how a system is set up has a lot of influence on what node BGP on the networks that connect to it are going to pick. If somebody setting up an anycast system plugs a bunch of nodes into random networks scattered around the world, they're not going to do very well on geographic or topological proximity. Chances are, they'll end up with situations like the K Root in India that was at one point getting most of its traffic from North America. But if an anycast system is set up with the right transit and peering policies, it can do a decent job of matching topology.

I went into this in a lot more detail in the paper at: http://www.pch.net/resources/papers.php?dir=/anycast-performance

Will a well-designed anycast system do as well as Akamai? Probably not. Akamai does actual testing of paths rather than using theory to decide what the paths will probably look like, which should give them a much better view of places where reality doesn't match theory. They've also got a lot more locations than anybody else doing this, which means they should typically be able to get much closer to where the content needs to go. But Akamai has lots of patents and lots of proprietary software making their decisions about where to source things from. They charge their customers quite a bit for this service, and the cost savings their technology and wide footprint should produce go to the receiving networks who don't have to carry the traffic very far, rather than to the content provider who would hot potato the traffic off at the closest possible point anyway. So, the decision for somebody deciding whether to use Akamai, use one of its less advanced competitors, or make their own, may come down to whether they can produce something good enough, rather than whether they can produce something as good or better.

-Steve