On Tue, Jun 25, 2002 at 01:18:37AM -0400, Gianni Johansson wrote: > On Monday 24 June 2002 23:19, Matthew wrote: > > > > On Tue, Jun 25, 2002 at 04:16:49AM +0100, Matthew Toseland wrote: > > > Patch committed, changes overload handling to: I hoped it might get your attention :) > > > always accept if in failure table (as now) > > > 60%-70% load: > > > accept HTL=1, HTL=0 (this is after we have decremented it) > > > accept if in most successful 1/256th of the keyspace (by % requests > > > fulfilled successfully) > See below > > > > > accept if in datastore > > > 70-80% load: > > > accept HTL=0 > > > accept if in datastore > > > 80%+ load: > > > reject all except in fail table > I'm glad to see someone actively working on fixing the overload problem. > > Unfortunately, I don't think this approach to selecting which requests to > acccept is a good idea. > > Here are my concerns: > > 1) Your approach will penalize the nodes that route well (i.e. route to a > node that has a high chance of having the data, without consuming much htl) > at the expense of those that route poorly (i.e. nodes that route to many > nodes unsuccessfully before landing at your node with a low htl). I don't > see how this can be good for the global (network wide) routing effectiveness > / specialization. > > It would be a disaster if everyone setup their nodes to route every request > to every other node they could get a noderef for with an htl of 0 or 1. Okay... this is a critique of the thing Ian forwarded, which I didn't see at the time. You want to never prioritise low HTLs? > > 2) Also, I don't think that its a good idea to try to pick a winning discrete > segment of the keyspace and ignore all others. Real nodes don't have > successful request key distributions with single peaks. > > What I proposed was that each request would be accepted or qr'd based on its > approximate Ps(k) value. > > What I imagined is that the implementation would keep a Psmin minimum > acceptable Ps(k) value which it increases under overload and decreases when > not overloaded. All requests with Ps(k) > Psmin would be accepted. OK. How do we determine Psmin? This was a hack, you understand, I'd like to implement the Psmin thing. > > > > 3) I think you need to distinguish between successful DataRequests and > InsertRequests. When the network is performance is bad there will be a > disproportiate number of successful InsertRequests as compared to the number > of successful DataRequests. InsertRequests just mean that data was inserted > -- not that it was inserted where anyone else will ever find it. > > I think that it would better to do the inbound request triaging based on > DataRequests only. Hmmmm. > > > Regards, > > --gj > > > p.s. Don't take that proposal as gospel. I haven't heard any comment on it > from Oskar yet. It has not yet sustained the withering critique typical of > the devl mailing list ;-).
msg03334/pgp00000.pgp
Description: PGP signature
