\section{Implications for server selection systems}
\label{section:implications}

The observations about the properties of mirror servers that we have
presented may be useful when designing server selection systems.
However, our measurements were made in the absence of a selection
mechanism.  The introduction of a systematic way to evaluate servers
may alter the performance of the servers significantly.  For example,
if all clients employ a load balancing algorithm, the correlation of
performance among the servers may increase.  Still, our observations
do supply a picture of the network that can be used as a starting
point in designing a system.

We have pointed out that the difference in performance from one mirror
server to another is quite significant.  This implies that choosing
the right server has the potential to significantly improve client
performance.  We have also seen that most server sets usually contain
more than one server, indicating that the best server for a given
client changes over time.  Server selection needs to take place
periodically to achieve good performance.  But because server sets are
also usually small, the server selection task is potentially a very
lightweight operation.

We have observed that server rank changes do not depend significantly
on time scale, implying that a ranking of servers from two hours ago
is as useful as a ranking from two days ago.  In other words, all
performance results older than an hour are approximately equally
useful.  Because of our experimental design, we cannot say anything
about performance results younger than an hour.

For the News and Mars data sets, we have found that most rank changes
are small, implying that 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 far apart in time.  For these data sets,
the benefits of server selection may be outweighed by the cost of
evaluating servers.  However, this does not hold for the Apache set,
where ranks are less stable.

We have found a weak link between a change in a server's performance
and a change in the server's rank.  If the performance that a server
can offer a client degrades massively, then it can be inferred that
the server's rank has dropped and a new server should be selected for
the client.  However, for smaller performance drops, we cannot assume
that a corresponding drop in rank has taken place.

% Disappointingly, our conclusions from Section~\ref{sec:drdt}
% indicate that a client cannot rely on changes in fetch times to a
% server to indicate changes in its rank with any great certainty.
% Had there been a stronger link between changes in transfer time and
% changes in rank, it might have been possible for a client to decide
% when a new search for a good server needed to be started purely
% based on its own local performance observations.  It seems that
% using fetch times is most useful when results from fetches to
% multiple servers are compared.

Finally, protocols probably do not have to make allowances for
picking a server based on the document that is being fetched.  While
we have noticed that there is a difference between the good servers
for the smallest Mars and Apache documents and other documents' good
servers, the difference in performance, both in relative and
absolute terms, is not very large.