On Saturday 13 June 2009 19:05:36 Evan Daniel wrote: > On Sat, Jun 13, 2009 at 1:08 PM, Matthew > Toseland<t...@amphibian.dyndns.org> wrote: > > Now that 0.7.5 has shipped, we can start making disruptive changes again in > > a few days. The number one item on freenet.uservoice.com has been for some > > time to allow more opennet peers for fast nodes. We have discussed this in > > the past, and the conclusions which I agree with and some others do: > > - This is feasible. > > - It will not seriously break routing. > > - Reducing the number of connections on slow nodes may actually be a gain > > in security, by increasing opportunities for coalescing. It will improve > > payload percentages, improve average transfer rates, let slow nodes accept > > more requests from each connection, and should improve overall performance. > > - The network should be less impacted by the speed of the slower nodes. > > - But we have tested using fewer connections on slow nodes in the past and > > had anecdotal evidence that it is slower. We need to evaluate it more > > rigorously somehow. > > - Increasing the number of peers allowed for fast opennet nodes, within > > reason, should not have a severe security impact. It should improve routing > > (by a smaller network diameter). It will of course allow fast nodes to > > contribute more to the network. We do need to be careful to avoid > > overreliance on ubernodes (hence an upper limit of maybe 50 peers). > > - Routing security: FOAF routing allows you to capture most of the traffic > > from a node already, the only thing stopping this is the 30%-to-one-peer > > limit. > > - Coalescing security: Increasing the number of peers without increasing > > the bandwidth usage does increase vulnerability to traffic analysis by > > doing less coalescing. On the other hand, this is not a problem if the > > bandwidth usage scales with the number of nodes. > > > > How can we move forward? We need some reliable test results on whether a > > 10KB/sec node is better off with 10 peers or with 20 peers. I think it's a > > fair assumption for faster nodes. Suggestions? > > I haven't tested at numbers that low. At 15KiB/s, the stats page > suggests your slightly better off with 12-15 peers than 20. I saw no > subjective difference in browsing speed either way.
Which stats are you comparing? > > I'm happy to do some testing here, if you tell me what data you want > me to collect. More testers would obviously be good. That would be a good start. It would be useful to compare: - 12KB/sec with 10, 12, 20 peers. - 8KB/sec with 8, 10, 20 peers. - 20KB/sec with 10, 15, 20 peers. > > > We also need to set some arbitrary parameters. There is an argument for > > linearity, to avoid penalising nodes with different bandwidth levels, but > > nodes with more peers and the same amount of bandwidth per peer are likely > > to be favoured by opennet anyway... Non-linearity, in the sense of having a > > lower threshold and an upper threshold and linearly add peers between them > > but not necessarily consistently with the lower threshold, would mean fewer > > nodes with lots of peers, and might achieve better results? E.g. > > > > 10 peers at 10KB/sec ... 20 peers at 20KB/sec (1 per KB/sec) > > 20 peers at 20KB/sec ... 50 peers at 80KB/sec (1 per 3KB/sec) > > I wouldn't go as low as 10 peers, simply because I haven't tested it. Well, maybe the lower bound should be different. Testing should help. It might very well be that there is a minimum number of opennet connections below which it just doesn't work well. > Other than that, those seem perfectly sensible to me. > > We should also watch for excessive cpu usage. If there's lots of bw > available, we'd want to have just enough connections to not quite > limit on available cpu power. Of course, I don't really know how many > connections / how much bw it is before that becomes a concern. Maybe... just routing requests isn't necessarily a big part of our overall CPU usage, the client layer stuff tends to be pretty heavy ... IMHO if people have CPU problems they can just reduce their bandwidth limits. To some degree ping time will keep it in check, but that's a crude measure in that it can't do much until the situation is pretty bad already... > > Evan Daniel
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
