On Jan 15, 2008, at 3:03 PM, Joe Greco wrote:
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: On Jan 15, 2008, at 12:00 PM, Bill Woodcock wrote:
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. -- TTFN, patrick
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 -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e- mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.