Re: [Sks-devel] sks-keyservers.net: Calculation of SRV weights

[Kristian Fiskerstrand]

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

On 06.05.2012 08:36, Gabor Kiss wrote:
>> The SRV records are currently used for the sub-pools eu.pool and 
>> na.pool. Before implementing a new approach with a higher degree
>> of complexity, that require more effort to implement, I'd
>> appreciate feedback on the current implementation. Are the
>> sub-pools being actively used? are they performing as it should?
>> Or could it be modified in a simpler way and achieve the same
>> real-world benefits?
> 
> Dear Kristian,

Hi Gabor,

Thanks for your feedback.

> 
> Although I don't use the subpools I'd like to comment the document 
> you wrote. :-)
> 
> 1. As section 2.2 discusses the the current weigth calculation is
> misleading a bit. You measure response time from your location, so
> average subpool clients will use the nearest 10 servers to you. It
> would better to do this measurement from several points of the 
> network.
> 

Indeed, but note that 2.2 is named Disadvantages and already state
"Only a single measurement is performed at the time of server
discovery, and the performance measurements as a client is only
performed from a single point\footnote{The location of the server} for
each of the pools\footnote{Two mirrors exists, one in Norway that is
used for the EU pool and one in USA that is used for the North America
pool}."


> 2. You wrote | In addition the size | of the SKS status page is
> typically less than 3 KiB, | which doesn't provide enough
> information for a proper | measurement of the bandwidth capacity of
> the server.

I agree that I can clear this one up a bit. It is intended as an
argument for adding information on bandwidth in a new implementation,
but probably should be elaborated on.


> 
> I'm afraid there is a little confusion here. What do you want to
> measure at all? a) the network delay (i.e. round trip time, "ping
> time"), b) the bandwidth bottleneck c) processor/disk speed of the
> remote key server
> 
> I think it is no worth to do a very complicated, multifactor 
> measurement.  We need no hair cutting accuracy but an "average 
> responsiveness" value.

Responsiveness in terms of ping time isn't necessarily responsive in
terms of receiving a key, or in the case of a non-reverse proxy
server, that sks is ready to accept new requests.

> 
> So I suggest to recruit a small group of volunteers worldwide who
> are willing to run a measurement station. They would install a
> simple CGI script that receives two parameters: a key server name
> and a key ID and replies the time of downloading the given key from
> the given server. After all this time is more important than how
> long time takes to download index.html.

This is a good idea, I'll consider something like this.

> 
> Your central data acquiring software can compute SRV values from 
> these times. Additionally local keyserver operators may bias it by 
> adding advertising a number via TXT records of their key server. 
> Some similar possibility is required beacause they know better the
> actual local network and HW resource policy/status. E.g. 
> keys.niif.hu. 3600 TXT        "SKS Pool weight factor=30%" where the
> allowed range is 0-150 percent.
> 

Ideally this could be used, but it could also open up a can of worms
if a server admin is operating in bad faith and want to steer traffic
in his direction for whatever reason. I'll make a note of the suggestion.

- -- 
- ----------------------------
Kristian Fiskerstrand
http://www.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws
- ----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this
The book: Sending Emails - The Safe Way: An
introduction to OpenPGP security is now
available in both Amazon Kindle and Paperback
format at
http://www.amazon.com/dp/B006RSG1S4/
- ----------------------------
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPplSnAAoJEBbgz41rC5UI40MQAKBj4hHC3UULXXHd+F78McOZ
PxkZOs4dBkXIRYdxb0DB0inSG6dbkmawTiOfARjvSflQvTZdSEO7WqCxEe9z2H4r
sm4BlQI+zmI0hBjuGKiXFLt1Vr0t7WUl9D9vOMRKCfEiN5ueqeYHTgnDmt7gdcNT
CVITQQeLwH+w7uu2lmlhS7hHC3vjjJRs2+G5SfQUMoJI2s4NkR6yYuaOQXB9Jldp
JWU7d7O0Fptqw/LZAbOE2r2Zb3rFYZ1aYdfEr8R9kyr9dR0sgS12ffa/WjmdZuqE
+2Tacai5N3gEd5uVB7pk+NqsBQxIgWAc1Ll8YlrXa1oIhwpuiox9SumHqytEcF8S
4DBOH2i2JSQKuNWEMpdLZIGOhuCHLXtY6ndQHXQQ8Nqt7sc2BGgbb/SbXkALpGSl
c7G3nCGU6h7WOMRy6n6vgFKmhH+drM4Jef3V/Z280S0uZmuZ0tDNuGdiufpNKY2V
tXweOrsOj4H0xUbjuuBmGrQvQrc6i585tR7+Cbaq2nIqq8YlZb7BmDwNHtHG+9Eu
tcM+jlf0PI2TZcrXm1QlItlvaMG3QXcLfxd85xkp2XYruupCyWUQiR5JfW9CxNnY
Q2t1WwuZcAh7EewuL+nXMIuI5yYZrshdb9lLJH4KCh2Xq0wNzNv4GXC+ehoBHo2W
fpwzSpk+c6piBkZn/g+p
=U135
-----END PGP SIGNATURE-----