On November 08, 2003 04:54 am, Martin Stone Davis wrote: If we try this here is a way it could work. We used the anullation (how every it is spelt) in the QR message to transmit sendqueuesize/outputbandwidthlimit or sendqueuesize/outputbandwidthused if there is no limit.
In standard node estimator we add a new running average. It predicts the probabiliy of a node to fail a request after the anullation time has passed. We replace pSf with this once the anullation time a node passes us expires. Tracking the this new probability (pAfterFailed) should tell us if the scheme is working. Ed > Toad wrote: > > 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 _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
