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. 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. > > 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. 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. Evan Daniel _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
