Currently the situation, even with the recently integrated probabilistic
rejection, is as follows: We start off with no load
We accept some queries
Eventually we use up our outbound bandwidth, and due to either
messageSendTimeRequest or the output bandwidth limit, we reject queries
until our currently transferring requests have been fulfilled.
With our current running average code, at this point the node's
pSearchFailed estimate will go through the floor, and it won't recover
because it won't be routed to.
Possible solutions proposed:
1. Try the nodes again after some fixed, perhaps increasing, backoff,
once we are into QR mode. One way to do this is to abuse the
pSearchFailed estimator as edt has suggested; another way would be to
randomly fork requests occasionally such that each node in the RT is
visited at least every N seconds as long as the node has some load.
The search failed estimator will recover quite fast if it gets retried
and is not queryrejecting.
2. Use a really long term average.
3. Have the node somehow guess when it will next be available for
queries, and tell the requesting node, which then uses that as a backoff
time. Somebody suggested this too essentially. You could perhaps
guesstimate it from the transfer rate... but sadly the transfer rate
will vary over time..
Any other suggestions? Any detail as to why/how a particular option would work?
Option 3 is close to my Doctor-Patient analogy where appointments are scheduled (see "Solving the QR problem with scheduled appointments"). There are two points to that strategy: The first is to benefit the requestees, by reducing the number of queries made down to an amount closer to that which the network can actually handle. The second is to benefit the requesters, by improving their ability to predict when another node will accept a query from them. I would approve of any of the other options if they could be made to achieve these two goals. As far as I can see, options 1 and 2 benefit the requesters (probably 1 is better than 2 in this regard) but neither option help the requestees. My plan of enforced scheduled appointments benefits both.
Before I get into detail on how the requestee (Doctor) node should conduct scheduling, let me revise the "Appointment" scheme. A simpler alternative to making appointments is to just worry about when the node is likely to be available, and not worry about when it will get busy again (i.e. closer to option 3 than my original proposal). In this case, the Doctor node responds to queries it rejects by saying, "Not now, and please don't disturb me again for at least x seconds". If a requesting node violates this command, then it gets penalized by the requestee, who will then tend to QR all requests from the offending node for a limited period of time.
Now, about how the Doctor should set x. Really, any plausible method would be fine. Toad, you suggested guesstimating it from the transfer rate, but then criticized it due to the transfer rate varying over time. But I say, guess away! It's okay to not have a perfect prediction of how long we will be busy, just as long as we stop requesters from sending us a bunch of queries during the times when we are almost certain not to be able to accept them.
Here's a method based on past experience only: Suppose the node notices that with x=0 (the current scheme), for 50% of the time, its QR:s last for 5 seconds straight, and for the other 50%, they last 15 seconds. Then for half the requesting nodes, it would want to set x=5, and the rest, set x=15. So, my proposal for our node to set x according to past experience. If the node starts noticing periods of inactivity where it could accept queries, it can start reducing x. There's more details to be filled in here, but I'll stop and await your input.
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
