Optimum number of peers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Optimum number of peers

Andy Ruddock-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Are there any recommendations for the number of peers each keyserver
should have in the membership file?

I'm hesitant to add each and every peering offer, but also want to
ensure my keyserver stays current even if one, or a few, peers are down
for any reason.

- --
Andy Ruddock
- ------------
[hidden email] (GPG Key ID 0xEEC3AFB3)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJNrzhrAAoJEAC80KTuw6+zguYP/iM3AT5YwPJ/1m2qczE4WFVE
42JOx0xsVPxZJ3e/Qjnh0odvpLufKQJno+kDmAKn+Qm5KY6pfWdsSw8hAx2QadUO
ROSqToFWtGLoGwrvyYPTe33XW9vtITZNbJ2RmFPxBSVwg2dTnz/CgVfQSR6dF8w+
ly2GAq0zheBBc8KlEsmg77fAV0UEVmHvR94Ug5Lt9O/kD7MuY7CS4cA04ZoMm6ou
pPicL1t/NCHiZH90lYxDSELvWlaTcjAi9p39cEGeBR0+hTUoe2fHNFgxxyBdGeqM
/920XZKzCS7wfI+yzX0iMZJB0ThD66k7KLGy2m4sqklknGCXF0iaNgUzkQ0pTK8f
1cUbffpWAasE0X8SrInZwyw5G+vC+RPtrZo/Q4adzqNkSE1VslHqgbS3BFHPCqmk
I1t9OMIC+/tT4RWZHaGmlCMy+AZIwjeLAwdkK8iOycEKZC/H16Ew6yjxMw8o7tgZ
8Ht6kDPqLO43fa8EbsIb1aafAx5URG46hnHjkJRAU/nZASdmvijSP8tDcH9+GlC0
c2g9fNU5faFnyg1g7pFso6Ua6dRezeyqAzBt5Hteomwu55bstLWea6pXjTpKNANg
gwOKjWrGVdPF3YwUDG67kQcAlmBzibW8w47Ww12bsurH3niKvMr3gUndYY8LYPd2
C0F41NB7SCHT5sDmLPwG
=G8Z4
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

Kiss Gabor (Bitman)
> 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... :-)

Cheers

Gabor

--
No smoke, no drugs, no vindoze.

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

Jeff Johnson-12

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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

Jeff Johnson-12

On Apr 21, 2011, at 12:52 AM, Jeff Johnson wrote:

>
> Almost certainly someone has modeled gossip protocols, lemme dig a bit.

Caveat:
        This is just the 3-5 minute quick skim search. Take all my comments
        as guesses.

This link
        http://www.distributed-systems.net/maarten/data/papers/2009.icdcn.pdf
has a closed solution (section 5, and figure 7) for a "wireless" gossip model that seems
reasonably close to a SKS net.

Note that the results were looking at "optimal" exchange buffer size, not max. items on a node.
The model assumed full connectivity, presumably that means all other nodes are just 1 hop away.

This link seems pertinent to computing the "optimal" neighbor count:
        http://www.eecg.toronto.edu/~bli/papers/lzhong-globecom10.pdf

Figure 2 would seem to indicate that 5 neighbors is about where the
"fetching rate" maxes out at 100%.

Again this is just random searching and skimming and guessing (while waiting for
downloads to finish *yawn*). YMMV.

hth

73 de Jeff
_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

Kiss Gabor (Bitman)
In reply to this post by Jeff Johnson-12
> 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.

I don't worry about QoS and random errors at all.
However I would care with sabbotage.
An important characteristic of the topology is:
At least how many node should be blocked/destroyed/denied by
an attacker to split the network (graph) into two or more
unconnected parts?

Gabor

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

Robert J. Hansen-3
In reply to this post by Kiss Gabor (Bitman)
> In theory an optimal value could be computed but there are
> too many parameters (e.g. network delay and bandwidth...

Additionally, these parameters are in effect constants.  The SKS algorithm will have roughly logarithmic speed in propagating keys through the network: everything else (including how many peers you're connected with) affects it only by a constant factor.

O(lg N) speed is *fast*.  Like, really, really fast.  So my suggestion: make sure you have at least two peers and you should be golden.  Trying to make it even faster is kind of like trying to put racing stripes and aftermarket body kits on a Saturn V rocket: you can do it if you really want to, but there's not much point.  :)


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

Ari Trachtenberg
Gossip protocols exhibit a thresholding phenomenon.  If everyone talks to greater than a certain
fraction of their peers, data will propagate to everyone in the network.  If everyone talks to less than
this fraction, then very few network members will get all the data.  Unfortunately, this fraction depends
on many parameters of the network ...we are working on some research that may give some more
concrete answers ... but it will take a bit.

best,
        -Ari

On Apr 21, 2011, at 9:20 AM, Robert J. Hansen wrote:

>> In theory an optimal value could be computed but there are
>> too many parameters (e.g. network delay and bandwidth...
>
> Additionally, these parameters are in effect constants.  The SKS algorithm will have roughly logarithmic speed in propagating keys through the network: everything else (including how many peers you're connected with) affects it only by a constant factor.
>
> O(lg N) speed is *fast*.  Like, really, really fast.  So my suggestion: make sure you have at least two peers and you should be golden.  Trying to make it even faster is kind of like trying to put racing stripes and aftermarket body kits on a Saturn V rocket: you can do it if you really want to, but there's not much point.  :)
>
>
> _______________________________________________
> Sks-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/sks-devel

---
Ari Trachtenberg, Boston University
http://people.bu.edu/trachten mailto:[hidden email]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Random quote of the day:
"Only a nation that can defend its freedom truly deserves it." - Ehud Olmert.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

robert.O
In reply to this post by Andy Ruddock-2
For me, it is not the number of peering, but the quantity of the time
zones.
It is necessary that the keys are available immediately for everyone.

Afflicted for my English

robert

--------------------------------------------------------------------

On Wed, 20 Apr 2011 20:47:55 +0100, Andy Ruddock
<[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Are there any recommendations for the number of peers each keyserver
> should have in the membership file?
>
> I'm hesitant to add each and every peering offer, but also want to
> ensure my keyserver stays current even if one, or a few, peers are down
> for any reason.
>
> - --
> Andy Ruddock
> - ------------
> [hidden email] (GPG Key ID 0xEEC3AFB3)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBCgAGBQJNrzhrAAoJEAC80KTuw6+zguYP/iM3AT5YwPJ/1m2qczE4WFVE
> 42JOx0xsVPxZJ3e/Qjnh0odvpLufKQJno+kDmAKn+Qm5KY6pfWdsSw8hAx2QadUO
> ROSqToFWtGLoGwrvyYPTe33XW9vtITZNbJ2RmFPxBSVwg2dTnz/CgVfQSR6dF8w+
> ly2GAq0zheBBc8KlEsmg77fAV0UEVmHvR94Ug5Lt9O/kD7MuY7CS4cA04ZoMm6ou
> pPicL1t/NCHiZH90lYxDSELvWlaTcjAi9p39cEGeBR0+hTUoe2fHNFgxxyBdGeqM
> /920XZKzCS7wfI+yzX0iMZJB0ThD66k7KLGy2m4sqklknGCXF0iaNgUzkQ0pTK8f
> 1cUbffpWAasE0X8SrInZwyw5G+vC+RPtrZo/Q4adzqNkSE1VslHqgbS3BFHPCqmk
> I1t9OMIC+/tT4RWZHaGmlCMy+AZIwjeLAwdkK8iOycEKZC/H16Ew6yjxMw8o7tgZ
> 8Ht6kDPqLO43fa8EbsIb1aafAx5URG46hnHjkJRAU/nZASdmvijSP8tDcH9+GlC0
> c2g9fNU5faFnyg1g7pFso6Ua6dRezeyqAzBt5Hteomwu55bstLWea6pXjTpKNANg
> gwOKjWrGVdPF3YwUDG67kQcAlmBzibW8w47Ww12bsurH3niKvMr3gUndYY8LYPd2
> C0F41NB7SCHT5sDmLPwG
> =G8Z4
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Sks-devel mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/sks-devel


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

Andy Ruddock-2
In reply to this post by Ari Trachtenberg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ari Trachtenberg wrote:
> Gossip protocols exhibit a thresholding phenomenon.  If everyone talks to greater than a certain
> fraction of their peers, data will propagate to everyone in the network.  If everyone talks to less than
> this fraction, then very few network members will get all the data.  Unfortunately, this fraction depends
> on many parameters of the network ...we are working on some research that may give some more
> concrete answers ... but it will take a bit.
>

For me this is the important issue, it would seem that the algorithm
used handles having many peers extremely well - in that it would appear
not to lead to excessive network usage.

I've tended to keep the number of peers I have to a small number and
have traditionally only peered with those who are geographically close
(generally speaking).

I think it may be advantageous to have a small number of geographically
distant peers to prevent this "thresholding phenomenon".

For this reason I think I shall seek to peer with one or two peers in
the North American continent, and one or two in Australia/New Zealand or
Southern/Eastern Asia.

If this is deemed to be suitable my membership details are :

keyserver.rainydayz.org 11370 # Andy Ruddock
<[hidden email]> 0xEEC3AFB3


>
> On Apr 21, 2011, at 9:20 AM, Robert J. Hansen wrote:
>
>>> In theory an optimal value could be computed but there are
>>> too many parameters (e.g. network delay and bandwidth...
>>
>> Additionally, these parameters are in effect constants.  The SKS algorithm will have roughly logarithmic speed in propagating keys through the network: everything else (including how many peers you're connected with) affects it only by a constant factor.
>>
>> O(lg N) speed is *fast*.  Like, really, really fast.  So my suggestion: make sure you have at least two peers and you should be golden.  Trying to make it even faster is kind of like trying to put racing stripes and aftermarket body kits on a Saturn V rocket: you can do it if you really want to, but there's not much point.  :)
>>

- --
Andy Ruddock
- ------------
[hidden email] (GPG Key ID 0xEEC3AFB3)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJNsxcTAAoJEAC80KTuw6+zCxoP/15JVxAZe6n0b7B4n3eD8yOn
n+2tdNydg7cyeJhmDxEiuCscBN42uFgDrbzpdHi/tlxPr2Cbjn6za2Js37Y5EAWm
HjfcaVWLXKIbCRWf8MGRD30gri3DLNF7+3plahD/GlTMLC/jl6Ayh3hbwBEsTXLL
arfyJVy3lbM9cOrQK0u+YT2fEVXH8xESnC2JbMNVrZUTjzvgzbXDm54GHbnts3E5
YPsABASbfB8imZ1lpBsCLfAboOItE1s31vTnUGkWidAEwr4zcwhCk9BwYXzcLDKe
LRVR8UYAyDvFkp0uwhFY2ElYMlWaWBFcK4tjT3CKj7uo3LCmF8neNVfKMm5qJ8z1
h+p/pxf5Rq+434VEHEvhTBFDrpcwRwd4LEuxUQ5vgUHf0nsAf0OkdtPxVOCJGKgy
v5ylLEJKRyNjhMPIzb48derVOqCdZOqcL/hQkst6je64oaFoxvv6CIG1CQ6+Pakf
4V1vhlwxPFZ4nAz6hlADJAbUtGplVdMrN0SigBNTGYjyOqiuxQnHALOhZRWTlXpq
UsIC6nBtuRNCFDxErCYqgvTQwI6noqmM/cDBbXuvdIdWu3R5mGSdA+KKxw3vEhos
CTRlXFcaoAXeHOu45BTEfhNVt1yDW3mMzCS1qEfdwYyyFG0uGbK7hYvEwHe5aOSw
kFvPC3xCMZkvB0ydqora
=o0A/
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

Jeff Johnson-12

On Apr 23, 2011, at 2:14 PM, Andy Ruddock wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Ari Trachtenberg wrote:
>> Gossip protocols exhibit a thresholding phenomenon.  If everyone talks to greater than a certain
>> fraction of their peers, data will propagate to everyone in the network.  If everyone talks to less than
>> this fraction, then very few network members will get all the data.  Unfortunately, this fraction depends
>> on many parameters of the network ...we are working on some research that may give some more
>> concrete answers ... but it will take a bit.
>>
>
> For me this is the important issue, it would seem that the algorithm
> used handles having many peers extremely well - in that it would appear
> not to lead to excessive network usage.
>
> I've tended to keep the number of peers I have to a small number and
> have traditionally only peered with those who are geographically close
> (generally speaking).
>
> I think it may be advantageous to have a small number of geographically
> distant peers to prevent this "thresholding phenomenon".
>
I suspect that avoiding the "thresholding phenomenon" isn't the right
basis for your reasoning. Nothing wrong with your reasoning
at all, all depends on what one chooses to optimize: in your
case you seem to want "robust global propagation" not "minimal necessary load"
as an optimization goal.

But that is merely a guess.

> For this reason I think I shall seek to peer with one or two peers in
> the North American continent, and one or two in Australia/New Zealand or
> Southern/Eastern Asia.
>
> If this is deemed to be suitable my membership details are :
>
> keyserver.rainydayz.org 11370 # Andy Ruddock
> <[hidden email]> 0xEEC3AFB3
>

For North American coverage, try peering here:
        keys.n3npq.net 11370
in a Tier IV data center with high availability and good bandwidth.

You are also welcome to peer with
        keys.rpm5.org 11370
which is an aging dual G5 on a (my) residence cable box.

Send along your membership information if interested.

73 de Jeff
_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

Andy Ruddock-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jeff Johnson wrote:

>
> On Apr 23, 2011, at 2:14 PM, Andy Ruddock wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Ari Trachtenberg wrote:
>>> Gossip protocols exhibit a thresholding phenomenon.  If everyone talks to greater than a certain
>>> fraction of their peers, data will propagate to everyone in the network.  If everyone talks to less than
>>> this fraction, then very few network members will get all the data.  Unfortunately, this fraction depends
>>> on many parameters of the network ...we are working on some research that may give some more
>>> concrete answers ... but it will take a bit.
>>>
>>
>> For me this is the important issue, it would seem that the algorithm
>> used handles having many peers extremely well - in that it would appear
>> not to lead to excessive network usage.
>>
>> I've tended to keep the number of peers I have to a small number and
>> have traditionally only peered with those who are geographically close
>> (generally speaking).
>>
>> I think it may be advantageous to have a small number of geographically
>> distant peers to prevent this "thresholding phenomenon".
>>
>
> I suspect that avoiding the "thresholding phenomenon" isn't the right
> basis for your reasoning. Nothing wrong with your reasoning
> at all, all depends on what one chooses to optimize: in your
> case you seem to want "robust global propagation" not "minimal necessary load"
> as an optimization goal.
>
> But that is merely a guess.

Good guess, spot on. But although I'm not seeking to minimize the load
on my servers they do perform other roles. I have to weigh up the
resources which I'm able to allocate to each service which I wish to
make available, and the fewer I have to allocate in order to achieve my
goals the better.

When I first started to operate an OpenPGP keyserver the advice was to
peer with geographically local peers - which would lead to peering wth
only a small number of hosts and would possibly lead to the "threshold
phenomenon" at continental borders (people peering within their own
continent but possibly excluding closer hosts in a neighbouring
continent). This was my thinking - with, as you say, robust global
propagation as a goal.

>> For this reason I think I shall seek to peer with one or two peers in
>> the North American continent, and one or two in Australia/New Zealand or
>> Southern/Eastern Asia.
>>
>> If this is deemed to be suitable my membership details are :
>>
>> keyserver.rainydayz.org 11370 # Andy Ruddock
>> <[hidden email]> 0xEEC3AFB3
>>
>
> For North American coverage, try peering here:
> keys.n3npq.net 11370
> in a Tier IV data center with high availability and good bandwidth.
>
> You are also welcome to peer with
> keys.rpm5.org 11370
> which is an aging dual G5 on a (my) residence cable box.
>
> Send along your membership information if interested.
>
> 73 de Jeff

- --
Andy Ruddock
- ------------
[hidden email] (GPG Key ID 0xEEC3AFB3)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJNszPvAAoJEAC80KTuw6+zdFcP/31/wfwgnDIpJ9ldjDXQz2Vs
WEl0fYng7DhzWxKatokkqzaSkHdxX/H0DqEY1AWQCt7aJ63A2cuXIvz+6pNvj2Hw
0wX5qPE6TCej10zVobsUNzTe5DbAtZ7tJQSB/wgjwPSn1Ap8XGHZyKSWV0cYt4W9
jYlZqrXbptFx9Bojg1GIn5sbPS+O9TdzqMjriOVJVpWSG//AlITapcfvoJ2KLCSZ
OVLz1zFYFwEFm2QWFGVCYdhRivyDUP6R22101j9H9R8aFRYMQwKyOZRyeU/Uz/Vg
21OGkKH65RMvUcWIy0ssjaM6tunfWA+WSrfA/y7H0xpjaBkFPO/AhhARSTT+Wbe/
/OwTIBJT5YhZ3DdPFXrGxtFQhRnqDrXRStXzXFSbUTNWB2P1FJf3Hv1385ZxBr1s
KjrPN5DsL4yt8ZwrbcWfJJ5c+IeLF/eodZqr/X7EGmAom70aPYB6aE36vMMauXz+
n2ll1wSYLt9nZ2lPJlQWXFtOGc8Dx3iK5Sv70feovSimp2cI6YUz3AxD89/bcBxJ
LhHdIwNR7DsjlitZVGlYbDhbLrQXG4YjhtOEgY7IqfL0ahHYxAfFov9ozqyv1s4m
nNC4ZOSwwzdVtG0fzs4C4Ljk8Y156iTS9401/BzjUkdPC+gxgzmsX/931FC3TcII
bsyeEfKfYVftcQTYCrc+
=Q1SX
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimum number of peers

David Benfell
On Sat, 23 Apr 2011 and before, Andy Ruddock and others wrote:

> > I suspect that avoiding the "thresholding phenomenon" isn't the right
> > basis for your reasoning. Nothing wrong with your reasoning
> > at all, all depends on what one chooses to optimize: in your
> > case you seem to want "robust global propagation" not "minimal necessary load"
> > as an optimization goal.

It seems to me that the point of a keyserver service is "robust
global propagation."  And to this end, I have to say, having a large
number of peers helps considerably when, much to my shame, I have
had to restore from dumps twice over the last couple of weeks.

In essence, my observation of my recon log leads me to believe that
spreading the load makes a rapid recovery possible and reduces the
load on everyone (except whomever I hit first--over 8,000 keys this
time, ouch).

>
> Good guess, spot on. But although I'm not seeking to minimize the load
> on my servers they do perform other roles. I have to weigh up the
> resources which I'm able to allocate to each service which I wish to
> make available, and the fewer I have to allocate in order to achieve my
> goals the better.
>
> >> For this reason I think I shall seek to peer with one or two peers in
> >> the North American continent, and one or two in Australia/New Zealand or
> >> Southern/Eastern Asia.
> >>
> >> If this is deemed to be suitable my membership details are :
> >>
> >> keyserver.rainydayz.org 11370 # Andy Ruddock
> >> <[hidden email]> 0xEEC3AFB3
Seeing as I don't have your public key, I'm thinking it would be
nice to add you.  My server is physically located on a Linode in
Atlanta.  But I'll let you make that call.
> >
> > For North American coverage, try peering here:
> > keys.n3npq.net 11370
> > in a Tier IV data center with high availability and good bandwidth.
> >
> > You are also welcome to peer with
> > keys.rpm5.org 11370
> > which is an aging dual G5 on a (my) residence cable box.
> >
Likewise, I'm assuming these offers weren't addressed to me, having
been down at the time that this was sent and not having previously
participated in this conversation.  But my philosophy remains, the
more the merrier.

cybernude.org 11370 #David Benfell <[hidden email]> 0xFBEC617D
--
David Benfell <[hidden email]>
http://www.parts-unknown.org/

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (853 bytes) Download Attachment