%\section{GOMER: Generic, semi-Optimal Mirror Evaluation Routine}

%--get gomer going with offsets
%--run it on set3-4 data

%--goals of protocol: illustrate some of the uses of the data
% presented here, not build a real protocol.
%--notoriously lacking: load balancing and general stuff to avoid
% multiple hosts trampling on each other

%--presentation of protocol
%--evaluation method - use fetch data as a trace, throw in random
% selection and static selection to see how well they do
%--results: who knows?

% new plan...

\section{Implications for Anycast Protocols}
\label{section:implications}

The observations about the properties of mirror servers that we have
discussed may be useful when designing anycast protocols.  However,
our measurements were made in the absence of an anycast protocol.  The
introduction of a systematic way to evaluate servers may alter the
performance of the servers significantly.  For example, the
introduction of load balancing among servers may increase the
correlation of performance among the servers.  Still, our observations
do supply a picture of the network that can be used as a starting
point in designing a protocol.

In general, our results support an architecture similar to SPAND,
proposed by Seshan et al \cite{seshan-usits97}, in which previous
performance results are cached on a campus-wide basis and are used to
predict future performance.  By aggregating performance results from
all hosts in an organization, long-term, stable rankings of hosts may
be found and recorded.  Also, shorter-term changes in rank may be
found as performance results from many clients are aggregated.

In Section~\ref{section:working-sets}, we argued that near-optimal
performance can be had by considering relatively few servers, in the
majority of cases less than half of the total number of mirrors.  This
implies that a client may be able to build a list of servers to
ignore.  The result is that server selection could be more efficient
since there would be fewer servers to evaluate at any given moment.
The client would build its list of servers to ignore by starting with
the assumption that all servers should be considered and gradually
pruning those that are consistently poor performers.

Because server ranks are stable over long periods of time, a client
may assume, with a reasonable amount of confidence, that a server
which delivered good performance during the last fetch will have
acceptable performance during the next fetch, even if the two fetches
are hours, or sometimes days, apart.  An anycast protocol which
reevaluates servers before each fetch must take this stability into
account.  Since a previously optimal server may still deliver good
performance, the protocol must ensure that the time to perform a
reevaluation is not greater than the performance gained from finding a
new good server.

Our results suggest that some types of anycast protocol will be much
less likely to work well that other types.  For example, a protocol
that makes predictions about server rank based on passive
observations of changes in transfer time would probably not work
well.  We have shown that changes in server transfer times, looked at
individually, are not good predictors of a server's rank.  However, by
aggregating individual results for servers across clients, there is a
better chance that they will be useful.

%--choice of document affects choice of server
Finally, protocols should make allowances for picking a server based
on the document that is being fetched.  While we have not completely
explored this area to determine which features of a document are most
important in predicting server performace, it is apparent that
aggregating performance results over an entire site's contents is
likely to be a poor design choice.  Similarly, a client should not
rely on a single server to provide good performance for any document
on a site.