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