-----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----- _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel