On Wednesday 03 December 2003 07:15 pm, Martin Stone Davis wrote: > Tom Kaitchuck wrote: > > On Wednesday 03 December 2003 03:25 pm, Martin Stone Davis wrote: > >>>>1. How should we calculate pLegitDNF? > >>>>A. There is no pLegitDNF or even a pDNF. This is because all failures > >>>> to find data are considered a timeout. This means this means the > >>>> NGrouting formula only has one varable, you just go with whatever node > >>>> is fastest for that key value. So if there are a bunch of DNFs then > >>>> you still have a ranking of the nodes. > >> > >>Unfortunately, those questions I had are all a bit out of date. Read > >>the discussion about iTTL (indefinite time-to-live). Toad's > >>latest-and-greatest idea is to discard the hops/timeout entirely. There > >>are still DNF's in his system: they occur when the routed node rejects > >>based on key (unobtanium). > >> > >> From IRC: > >> > >><m0davis> under iTTL, are there any DNFs? > >><toad> yes, but they aren't fatal > >><m0davis> When would a node return a DNF? > >><toad> m0davis: whenever it rejects based on the key > >>DNF is QKR > >>failure table, unobtanium, lots of things would cause it > >><m0davis> so the concept of a pLegitDNF still can exist > >><toad> yes, but we don't have to make tRetry crazy > >>any more > >><m0davis> In that case, I think the formula I derived would not change. > >>Do you agree? Or could you review it and get back to me on the ML? > >><toad> probably your formula would be correct > >> > >>Tom, see if you can follow the discussion about iTTL (it started off as > >>"Where now?". Hopefully you use gmane.org and a thread-based news > >>reader). You might decide you like iTTL best. > >> > >>>>Under such a system an anti-specialization attack would be harder, > >>>>because there is no pDNF to attack, only time, which has an upperbound > >>>>on how bad it can make the other node look and will have already have > >>>>decremented substantially by the time the request gets there, or if the > >>>>attacker succeeds in making a node look bad to another node, it will go > >>>>to a third node instead which would then possibly route to the first > >>>>node, but the attack would be less effective because of the additional > >>>>hop. > >>>> > >>>>None the less, such an attack is still possible. To prevent this, using > >>>> a trust biased system is important. > >> > >>Once you understand iTTL, I'd like to see if you think it is vulnerable > >>to attack. > >> > >>>Oh, one imporntant thing is that the transfer time should NOT be > >>> included when considering which node to route to. However it SHOULD be > >>> considered when awarding trust. This prevents favoring fast nodes too > >>> much, because some requests are bound to fail. While still rewarding > >>> good preformance. > >>> > >>>>2. How do other estimators such as pDNFGivenSearchSuccess depend on the > >>>>time allotment? > >>>> > >>>>Same situation. That estimator would no longer exist. > >>>> > >>>>3. How should we handle failure tables? > >>>> > >>>>A failure table or a "Success table" could work exactly the same as > >>>> they otherwise would. We just kill any request with the same or lower > >>>> TTL. > >> > >>Under iTTL, I believe the failure tables would work exactly as they do > >>now, except there'd be no need to store the HTL or TTL, since they don't > >>exist. Again, see the discussion on iTTL. > > > > Ok, I am very confused by iTTL. So no HTL / TTL is passed to the > > processing node at all? It just sends a key? > > > > What prevents a node from saying ok, I'll get that, then it goes to the > > next and the next, and the next ... But the data is not in the network. > > When does it die? > > Eventually, it will run out of nodes which specialize at the key, and > will get DNF:ed (DNF=QKR=Query Key Reject via unobtanium).
So Node A to B. B to C. C to D. D to E. E to F. F to G. G tries all nodes it it's table and is querry rejected because they are all busy. It then returns a QR? So, F to H, and same thing. so, F to I, and same thing. so, F to J, and same thing. so, F QR? so, E to K is QRed. so E to L is QRed. so E to M is QRed. so E DNF. D to O. O says "This is way off the requests I normaly take. You must be desperate." O DNF. D DNF. C DNF. B DNF. A gets DNF. But I thought Toad said this makes DNF's non-fatal. So that means then get retried TOO?!? So, then you try to go as close to the data as you can get. Then you get QR'ed or DNFed. Then you backup and go again. Ether it you have to do that the whole way back, you try all possible branches off the path to the data. The only reason you don't try every node in the whole network, is because you have already explored all the nodes close to where the data should be, node of them have it, and you go further out until you get a QKR. Then ether way it gets back to A with a DNF. But it happened because the nodes that are far back on the chain returned a DNF or a QKR. But why wouldn't B just return a QKR staring out. It's likely just as far from the node your looking for. Odds are you should never get any further form the data than that. Also by passing the non-existant request until some node decides it is too busy to take it, you effectively ensure that all the nodes are 100% load 100% of the time, because as soon as they are unloaded an exponential number of node to node relies of requests are generated. Why did we want this again? _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
