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.
