Re: Anycast root metrics and analysis

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Tue, 31 Oct 2000 13:32:58 -0800 (PST)
    From:        hardie@equinix.com
    Message-ID:  <200010312132.NAA27371@nemo.corp.equinix.com>

  | on the number of requests coming in.  The use of RTT and periodic
  | checks on server response time recognizes the importance of quick
  | responses for the DNS system;

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.

  | 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.

  | That may or may not map onto the server instance that would generate
  | the best performance.

True - but nor does any algorithm, the one bind uses now bases expected
response time upon past performance - which also may, or may not, map
onto the server 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.

  | 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...

  | In the case
  | that an anycast system is so well distributed that every AS runs its
  | own copy of an anycast AS and root server, the parallel would indeed
  | be strong.  In the current case, though, the very small number of
  | participants in the system seems to demonstrate that the BGP policy of
  | the adjacent and transit ASes is going to dominate the selection of
  | anycast root server instances.  That produces a conflict of metrics
  | and suboptimal results.

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.

  | What do others think of this analysis?

I suspect that you're worrying too much over nothing.

The spikes in reachability to the servers that your data collection
shows could do with more analysis though - do you have any idea what
is causing them?   Is something dropping off the net?

kre