Re: [Sks-devel] Re: [Fwd: Re: Alternative to round-robin (was Re: pool.sks-keyservers.net having trouble?)]

[John Marshall]

On Thu, 26 Aug 2010, 23:48 +0200, Kristian Fiskerstrand wrote:
> That said, it is still a very simplistic approach by timing the
> connection speed (in seconds) and doing a weight = (int)(1/responsetime
> * 100). After this I have manually overwritten the weight of the local
> keyserver (keys.kfwebs.net) to 200.
> 
> I have added the weights into the table at
> http://sks-keyservers.net/status/

> At this point, what is the preferred approach?
> 1) keep the weights as they are
> 2) group them into intervals / steps in order to get some additional
> load balancing

Unless I'm missing something, it looks like we've transformed the global
pool.sks-keyservers.net pool into a regional European pool.  Do we want
the whole world using only the European servers?  From
http://sks-keyservers.net/overview-of-pools.php it is apparent that both
host and SRV DNS queries for pool.sks-keyservers.net will result in the
same set of servers (with the SRV queries including the additional
priority and weighting data).  How useful is this Europe-centric
response-time weighting for a global set of servers being used by global
clients?  The pool currently gives me (in Australia) a list of 10
European servers - all with ICMP round-trip times of between 320ms and
520ms.  Unless RTT is taken into account in the response weighting, I
can't see any value in using response time to weight selection of
servers for a global pool.

If we would prefer that clients use servers running more recent versions
of SKS, we could reflect that preference usefully in SRV records - but
perhaps using the priority field rather than the weight field.  But
then, we could just as easily exclude older SKS servers from the pool.

Just some food for thought.  Thanks to Kristian for all the work he does
maintaining this pool.

-- 
John Marshall

pgpGuGkWPJVTx.pgp
Description: PGP signature