[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

David Shaw wrote, On 04/06/2010 10:46 PM:
> On Apr 6, 2010, at 3:17 PM, Jeff Johnson wrote:
> 
>> On Apr 6, 2010, at 2:37 PM, David Shaw wrote:
>>> Just rig it up similarly to how DNS does it.  Rank things in
>>> order of performance, and then artificially penalize the fastest
>>> ones on each iteration until they aren't the fastest any more.
>>> Then repeat.  The goal isn't perfection - it's just to be better
>>> than round robin :)
>>> 
>> No disagreement that "round robin" isn't feeble, even if "fair".
>> 
>> It would certainly be nice if there was some means to get at DNS 
>> metrics from outside.
>> 
>> Off the top of my head (i.e 2minutes of thought), I can't think of 
>> an easy way to get at those DNS metric "innards" in spite of having
>> used DNS professionally for like 30 years.
> 
> I think you can get them by dumping the nameserver cache (dumpdb).
> They're in there as comments, so parsing them out might be a bit odd.
> 
> 
> Even so, I wasn't very clear - I didn't mean to literally use the DNS
> values, but rather hit each SKS server periodically and time the
> transaction (only similar to how DNS does it).  Kristian already
> checks each server periodically - I was thinking if he added
> performance measurements to his current tests, it could be used to
> rank things in the SRV list.  Of course, this is measuring things
> from his particular network perspective, so it might be wrong for
> everyone else...
> 
>> But I'm sure there's something that could be hacked up and whacked
>> together, there always is in uglix ;-)
> 
> But of course!
> 
> David
> 
> 

Hi again

Been slightly preoccupied at work lately, so been some time since we
last looked at this, but at least I've gotten around to implementing
some performance testing and weighting the SRV records now.

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/

;; ANSWER SECTION:
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 509 11371
keys.wuschelpuschel.org.
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 1026 11371
keyserver.ftbfs.org.
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 693 11371
keyserver.nijkamp.net.
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 597 11371
barbadine.canonical.com.
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 597 11371
esperanza.canonical.com.
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 593 11371
sks.karotte.org.
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 577 11371
sks-peer.spodhuis.org.
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 574 11371
keys.syn.co.uk.
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 543 11371
keyserver.kim-minh.com.
_pgpkey-http._tcp.pool.sks-keyservers.net. 28800 IN SRV 0 541 11371
pgp.uni-mainz.de.

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

other than that I'll look into penalizing upon request / use when I get
some more spare time.

Have a nice evening!

- --
- ----------------------------
Kristian Fiskerstrand
address@hidden
http://www.sumptuouscapital.com
- ----------------------------
Ne nuntium necare
Don't kill the messenger
- ----------------------------
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)

iQIcBAEBCAAGBQJMduEZAAoJEAt/i2Dj7frjOMAQAIAspgv5E/gmq2vrVB0qKUrM
PwPioCf0ngmge/kuvESiQVqElld8HtxLWdv/ouXSdPI/3ZoNyuI6r+UX8/DB0+8z
81vUeCeEtCEB1o77q7ZZMYPw0iDjKLN5W0WPJqY/s0DI/FsPKWE6Zwmznavp+vVM
gbdcoAfD7Vj1VCWo35QYpIwNsfyaTJHKI3/lAkPia2c9E0EnAT+2312frmYMciQ+
8T05qBnbYEzC7Vps0mL8+ly7ZDblXOy/o4YO4tu1vTUofQMzJ5SBx0LVsvqRSTmc
fkNlPEnFHrB3KiSOvuywe+NV1lwWc9xEvNi0O2JSNpwIwfcyVOODJCwwW13/m/7+
k/8UstFIRrsd8F2RQaBMVlfqCj6MoQlsIhzfSk8A0euFq66K3eHYDTAtjuDca3t3
+VDqUdhtLntutWZW2zIZIRadDZ2xVtxkoqdQRJkc4aD4tdiN3Bhs1I3msgvDzM0c
g9OYpvX3XXxy2W9OqMyjI+QxUqSr1rNc6Ak3/8ojesY7eynhDzo2+wH8gcY9KvB+
xg7hEi19nkvjlh2byF7nmSM/qus0RtUxI1gvNks/AdfWLq+FpZPq/sSdphT8/qEy
SAf0VIiFOpKP6ntWfJzQPSiuMTGvDfDNYGQgNS89X38p81R/OkjlUYjTjtCRpJz7
RxpYKCPMYOgOqyOnj4Nh
=cXsq
-----END PGP SIGNATURE-----