On Wednesday 03 December 2003 07:15 pm, Martin Stone Davis wrote:Well, RNF (which I think is the same as a QR)
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?
yes. Also known as a QKR (Query Key Reject)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.No, because DNF's would be non-fatal. But don't forget about unobtanium. At this point D might also QKR (=DNF), since the remaining nodes in its RT might not be suitable for the key anymore.
DNF's should not be *necessarily* fatal. But as I said above, unobtanium increases the chance that a DNF (or QR) ends up being fatal.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.ya, somethin' like that
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.Huh? What makes you so certain that the key is two hops away? Furthermore, what makes you so certain that the nodes involved in the two hops would not be too busy to serve us at the moment?
Again, unobtanium tempers this explosion in requests, so the result isn't as bad as you illustrate.
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?
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
