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? _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
