Re: Anycast root metrics and analysis

[hardie@equinix.com]

> Yes, of course, faster is always better - but there is nothing in
> the DNS that requires a response from the quickest server, any one
> will do.
> 

It's not a DNS requirement that the quickest server be used, it's
an optimization that helps the applications which depend on the DNS.

>   | Without any additional tweaking, an individual network will get the
>   | anycast server which is reachable via the shortest AS path-length.
> 
> That's fine.  Basically the point is to add additional servers and
> help spread the load.  As much as that also results in increased
> performance to the end sites, that's great.

I actually believe the point is to distribute the data to multiple
places in the network topology in order to improve performance for
those who have been under served.  The load can be handled where it
is, just not in a way that satisfies the performance preferences of
all the users.  If the current plan resulted in worse performance to
end sites, I believe it to have failed.  I also believe that there
might be other consequences, such as concentration of load on a small
number of the extant roots.

> 
>   | That may or may not map onto the server instance that would generate
>   | the best performance.
> 
> Each additional anycast group of root servers (ideally there would
> be several of them, at different addresses, living in different ASs)
> will give you an extra choice of root server to use.  Further, as the
> concept becomes proven, it may be that there will be many more root
> servers participating in each anycast group - it is entirely possible
> that each fairly major AS will have one local.   That ought mean that
> a server qith very good response time could be found from just about
> anywhere.

I agree that having one local to an AS would be useful, and that is why
I suggested splitting things so that any network could have a local copy
but only one network could offer transit to the AS/address.  

> 
>   | The access lists in the route filter would need to be updated whenever
>   | a different instance of the anycast server is notably better.
> 
> I don't think doing manually operated performance based routing is
> a scheme that will ever work...

On this point, we are in violent agreement.


> The current setup is intended as a proof of concept - that is, that it
> can be made to work at all.   I don't think it was ever intended to be
> optimal.

How, then, can we test that the system it is proving can be optimal?


					regards,
						Ted