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.
Certainly, but given some completely random transaction, there's still
going to be a tendency for anycast to be some sort of improvement over
pure random chance. 1000 boneheaded anycast implementations cannot be
wrong. That you don't get it right every time doesn't make it
wrong every time.
I'm certainly not arguing for anycast-only solutions, and said so. I'll
be happy to consider it as a first approximation to getting something to
a topologically "nearby" network, though as I also said, there needs to
be some care taken in the implementation.
Anycast can actually be very powerful within a single AS, where of course
you have some knowledge of the network and predictability. You lose some
(probably a lot) of that in the translation to the public Internet, but
I'm going to go out on a bit of a limb and guess that if I were to stick an
anycast node in Chicago, Sydney, and Amsterdam, I'm very likely to be able
to pick my networks such that I get a good amount of localization.
Of course, nobody's perfect, and it probably needs to be a data-driven
business if you really want well-optimized redirection. However, that's
a bit of magic. Even the fabled Akamai used to direct us to some ISP up
in Minnesota... (BFG)
So, anyways, would it be entertaining to discuss the relative merits of
various DNS implementations that attempt to provide geographic answers
to requests, versus doing it at a higher level? (I can hear everyone
groaning now, and some purist somewhere probably having fits)