On Tue, 15 Jan 2008, Patrick W.Gilmore wrote:
On Jan 15, 2008, at 12:00 PM, Bill Woodcock wrote:
[...]
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.)
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