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