sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Optimum number of peers


From: Jeff Johnson
Subject: Re: [Sks-devel] Optimum number of peers
Date: Thu, 21 Apr 2011 00:52:02 -0400

On Apr 21, 2011, at 12:38 AM, Gabor Kiss wrote:

>> Are there any recommendations for the number of peers each keyserver
>> should have in the membership file?
> 
> Not yet. :-)
> 
> In theory an optimal value could be computed but there are
> too many parameters (e.g. network delay and bandwidth,
> probability of hardware errors, average length of outages,
> cpu power, number of new keys "produced" by each node etc.)
> Moreover some of them are subjective preferences
> (e.g. the estimated cost of your CPU time and networks BW,
> the required availability etc.)
> 
> So all of us have some idea about how many peers are the best.
> Some guys want to be connected to everybody else.
> I think 5-10 peer is more than enough.
> 
> (I guess a wild debate will start now... :-)
> 

Well one does need a stricter definition of "optimum"
that what was asked: "current" as in up to date.

Any model with "current" as "optimum" definition needs as many
peers as possible the more the merrier.

There are some simple heuristics that reaches "optimum" up-to-date as
staying green at
        http://sks-keyservers.net/status/
that will accomodate outages etc. Check occaisionally and if
you go red, add another peer.

There are other definitions for "optimum" such as minimal propagation
latency across all peers, or minimum distance to all other nodes.
Almost certainly someone has modeled gossip protocols, lemme dig a bit.

The minimum distance is likely computable simply from collecting
a snapshot of existing peers and then computing maximum path length
for each node to all other nodes, and comparing your node with others.

Minimum latency would require a simulation perhaps, using a model with
parameters derived from an existing log file to get the parametrs about right.

73 de Jeff

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]