Re: [freenet-dev] polling & sharing estimator data
On Wed, Nov 05, 2003 at 09:09:21PM -0600, Tom Kaitchuck wrote: > On Wednesday 05 November 2003 08:36 pm, Zlatin Balevsky wrote: > > This is an extention to the idea of keeping estimator data in the .refs > > which aims to bring more consistent "worldview" between the nodes. It > > works best if there is trust implemented between nodes, but will also > > bring some limited results without trust. > > > > At random interval the node asks a random subset of the nodes in the rt > > for the estimator data they have of another node/subset of nodes (the > > two subsets can overlap). After that the node "merges" their results > > with its own estimator in a manner that would be as cancer-proof as > > possible in a network without trust. (that means removing outliers, > > averaging, etc.) > > > > Drawbacks: > > * increased network traffic. The timing will have to be chosen not to > > create a cascade effect. > > * powerful attacker with many nodes totally screws up our estimates, or > > even worse - provides such data which would make the requesting node > > favor his cancer nodes. > > > > Benefits: > > * Nodes have a more consistent picture of each other's strengths and > > weaknesses. > > * Newer nodes find their place faster > > * The network does not become any more static > > * Since topological neighbors know similar things about each other, each > > request from within the "neighborhood" will go directly to the best node. > > > > "Neighborhood" is not rigidly defined; if a network map is drawn, there > > will be no rigid boundaries between shared estimator information; rather > > it will flow gradually, providing optimal routing paths. (ok this > > sounds psycho but its much easier to visualise than explain - will try > > and get a pic/graph soon) > > Rather than inventing a new protocol for this, I would propose that when a > node tells you about some other node. IE: it's noderef comes back as the > source for some data, it should tack on it's own estimate. That way, we don't > create much more overhead. Then if we don't know the node, we can use that as > an initializer, and if we already know about it, merge that in with what we > already know. If the data does not seem to fit, then don't trust the > reporter, and preferably get several nodes oppinion on a new node before > connecting to it. That is exactly what Ian proposed. :) Well, without the merging in bit. It will get implemented soon. Details: If we don't reset the datasource, and we have an estimator for that node, we substitute our own estimator. We should perhaps not do this if our estimator doesn't have much information to go on. Hopefully this can't be abused... the other side of the question is how to prevent it being abused - the former mechanism is a start, another means is to set all the ageing data really low so that although we have an initial estimator, when we try requests through it it is as sensitive to the results as if it were initialized from scratch i.e. a flat line or a mountain. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] polling & sharing estimator data
On Wednesday 05 November 2003 08:36 pm, Zlatin Balevsky wrote: > This is an extention to the idea of keeping estimator data in the .refs > which aims to bring more consistent "worldview" between the nodes. It > works best if there is trust implemented between nodes, but will also > bring some limited results without trust. > > At random interval the node asks a random subset of the nodes in the rt > for the estimator data they have of another node/subset of nodes (the > two subsets can overlap). After that the node "merges" their results > with its own estimator in a manner that would be as cancer-proof as > possible in a network without trust. (that means removing outliers, > averaging, etc.) > > Drawbacks: > * increased network traffic. The timing will have to be chosen not to > create a cascade effect. > * powerful attacker with many nodes totally screws up our estimates, or > even worse - provides such data which would make the requesting node > favor his cancer nodes. > > Benefits: > * Nodes have a more consistent picture of each other's strengths and > weaknesses. > * Newer nodes find their place faster > * The network does not become any more static > * Since topological neighbors know similar things about each other, each > request from within the "neighborhood" will go directly to the best node. > > "Neighborhood" is not rigidly defined; if a network map is drawn, there > will be no rigid boundaries between shared estimator information; rather > it will flow gradually, providing optimal routing paths. (ok this > sounds psycho but its much easier to visualise than explain - will try > and get a pic/graph soon) Rather than inventing a new protocol for this, I would propose that when a node tells you about some other node. IE: it's noderef comes back as the source for some data, it should tack on it's own estimate. That way, we don't create much more overhead. Then if we don't know the node, we can use that as an initializer, and if we already know about it, merge that in with what we already know. If the data does not seem to fit, then don't trust the reporter, and preferably get several nodes oppinion on a new node before connecting to it. ___ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] polling & sharing estimator data
This is an extention to the idea of keeping estimator data in the .refs which aims to bring more consistent "worldview" between the nodes. It works best if there is trust implemented between nodes, but will also bring some limited results without trust. At random interval the node asks a random subset of the nodes in the rt for the estimator data they have of another node/subset of nodes (the two subsets can overlap). After that the node "merges" their results with its own estimator in a manner that would be as cancer-proof as possible in a network without trust. (that means removing outliers, averaging, etc.) Drawbacks: * increased network traffic. The timing will have to be chosen not to create a cascade effect. * powerful attacker with many nodes totally screws up our estimates, or even worse - provides such data which would make the requesting node favor his cancer nodes. Benefits: * Nodes have a more consistent picture of each other's strengths and weaknesses. * Newer nodes find their place faster * The network does not become any more static * Since topological neighbors know similar things about each other, each request from within the "neighborhood" will go directly to the best node. "Neighborhood" is not rigidly defined; if a network map is drawn, there will be no rigid boundaries between shared estimator information; rather it will flow gradually, providing optimal routing paths. (ok this sounds psycho but its much easier to visualise than explain - will try and get a pic/graph soon) pgp0.pgp Description: PGP signature ___ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
