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

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

John Marshall wrote, On 09/03/2010 11:24 AM:
> 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.
> 

I agree with your reasoning, so I moved the added features into a new
european centric pool eu.pool.sks-keyservers.net. (
and_pgpkey-http._tcp.eu.pool.sks-keyservers.net ) and reverted
pool.sks-keyservers.net to the prior mechanism (random).

- --
- ----------------------------
Kristian Fiskerstrand
address@hidden
http://www.sumptuouscapital.com
- ----------------------------
Audaces fortuna iuvat
Fortune favors the brave
- ----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this, visit:
http://www.secure-my-email.com
- ----------------------------
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iQIcBAEBCAAGBQJMgQLeAAoJEAt/i2Dj7frjdw8P/0n4r9wamsPzSsEjZ0SqOo7n
kCnUDnikUgWh6ZTlZ+UNUFUZgVggUma2sghaaMNgicDBiiDDfgHKSBql8AA8yeQl
BQ2HUzahB5k7qih+/JXqWIlWwMU7dRN2qkncauWwFs6aBDHvIQ1tXlj6u+8q1amd
V0HX5Wyp35Jjqg/BPqObk7eZmyhVWZRZrYclPS6pUO8v87S8C6l8+X65fmpWX8NG
mXpFhSt8n/wJpWnNURewEsf7f+zXT3a85gsMXIbzNAp2+EaRZcpGkY+TG2CvRmW5
M47jbxeEsmSD2oLb7ylZ1lyqCtoNQyuooVpSzvNW5Zy4Cpo8w6T9lIXGw5rlQJEx
Ls1g8Kz7ngXpXJ2UG+oQu+Xizyx366jGMb+FRux90E7zORuBKiJacYyXZ8BD4tbE
lsI2bU2p9Nqc+NEWOsNKPq7NbZw+T9OeQrVizAbsA+6Wn4XKhUbVU/Fx4cEnqBkT
p8x/w4jpRhcEGL7FXs4cIQDMA8R6M0kJ+7a8iAF3Lu+GqKrvGJC9SQ1RGlsoH2sT
1UIfJg3o9QXy8iwgEJiWRcorD24aolyowSa4mn+GbrBmmXbf5cjj7YcgJCMCRu7w
/N3nQRkFg0ZMEogLa91c70I1/6e9Z/U/ggNUwylQul4Q4Cbo4Yr+DLGNu+ONdauv
GCOmmVezvMaaqB7pQMMA
=Iz2z
-----END PGP SIGNATURE-----