> > On 05/23/2012 10:47 PM, Zlatin Balevsky wrote: > > On a global scale, the if the rate of new probe requests is higher > > than the rate at which existing ones expire the number of active > > probes at any moment will not reach balance. Higher HTL makes a > > ddos against the probe mechanism easier; in this scenario the > > internal limit of 5 simultaneous probes ends up assisting the > > attacker. > > Good point. I'm not sure what to do to improve that behavior though. I > can add some rate limiting if that looks like it'll be necessary.
The way we dealt with this problem in Gnutella was to cap the max htl at each hop. Even if an attacker sent a message with very high htl each node on the path would reduce it to a small value before forwarding. Not sure if this will work with Freenet. > > > Would it be possible to simulate a single-digit HTL network? My > > intuition suggests the graph of effectiveness of probes vs. HTL has > > a logarithmic shape. > > Indeed it is possible to simulate, and that was the subject of my > second update on this project. [1] My main findings are here, [2] > where one can see that it's true that an HTL of 5 or 10 or so could > provide pretty good distribution already. can you tell what is the absolutely lowest htl value that will give "good enough" performance? > > evanbd, my mentor for this project, suggested the maximum HTL of 50. > Here's some of his reasoning from the #freenet logs: > > 2012-05-09: > "So it looks to me from the graphs like HTL 20 is plenty for the new > probes. Which I take to mean we should set the default HTL as at least > 30, possibly 40. Because your nice simulated graphs don't have > problematic behaviors like clustering or partitioning or whatever :) > Basically, I think we should have a fairly high *maximum* HTL (at > least 50), and have the actual HTL be a user-specified parameter." > > 2012-05-19: > "And the plan is to send the requests at < max HTL, assuming that we > don't need the full 50. It looked from graphs like 20 was sufficient, > so I want to send at 30." We should discuss this in more detail and have more people involved before releasing these changes. I can see evanbd's point but the side effects of very high htl must be taken into account as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120524/ee685047/attachment.html>
