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

[Gabor Kiss]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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,

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.

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'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.

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.

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.

Regards

Gabor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iEYEARECAAYFAk+mG+MACgkQd2oiOrtquzh/MACeM3B/3DhPrhHd8r4uuaEvngJs
ErgAn0qlala5wryAiJFHimP10WP34/hY
=3rl6
-----END PGP SIGNATURE-----