In this message, I won't talk about rate control (which is difficult) or on QR backoff (well, not directly).
I postulate that routing consists of a node's actions in two directions. The first direction (outgoing) is very obvious: a node selects the best route based on estimators in the routing table. Great- so long as our routing table data is accurate enough, we should be developing reasonable estimates of specialization for each of our routes. It is not clear that this is happening, therefore we must spend more time analyzing NGR. However, the second direction is that of incoming requests...
we are still not 100% certain of the meaning behind sending a Query
Reject. The immediate meaning is obvious ("we canna take no more, capt").
The less direct effect is not as plain to see - we are encouraging or
discouraging other nodes from routing to us. Please look closely atNode Status Info -> Inbound Requests http://localhost:8888/servlet/nodestatus/inboundRequests.txt
there is important information to be gathered by this data. Notice that is it per-requestor information (ie for a specific, inbound route). We can calculate the query success ratio for a given host. This ratio is something that WE solely established/determined, locally, by our use of the Query Reject (note: some may argue that the requestor also contributes to this value as a function of his/her RATE of requests )
Calculating (successes/accepted's) for a given requestor _may_ tell us
how well a requestor has specialized relative to the local node ("us").
It certainly tells us just how "lucky" that requestor has been with us.Here is a proposal, one that hinges on NGR having "some" or "any" effect on routing...
when considering whether to QR a given request, examine that requestor's success ratio. If that requestor has not yet made at least 1000 requests, just accept it, never reject it - allowing us (and them) to compile a representative sample of what that node has determined our specialization to be.
After 1000 ( <-the only alchemy in my proposal) requests , we begin to reject those requestors with the lowest success rates, or, conversely, we begin to encourage those requestors who obtain the best results through us.
There are far-reaching consequences to this approach, and I cannot see or describe them as yet. But is this concept worth considering ? I hope that we begin to create code that favors some requestors over others, whether our aim is to improve QR rates, load balancing, or specialization. This looks like the "missing half" of solving the tricky NGR implementation.
Of course, if NGR is simply not cooked up and coded right, this approach will probably be of significantly less value. How can we observe fred's specialization (and degree thereof) ? The histograms ? Would it be possible to compute a single value that would indicate the degree of "our" local specialization ? Something that *anyone* can easily interpret ... higher=gooder lower=badder :)
Maybe a short primer on how to evaluate specialization properly would be of immense help to everyone. Or should we look to the histograms for the complete answer ?
ken
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
