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? 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) More suggestions? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090613/5d8dc271/attachment.pgp>
