On Monday 04 May 2009 17:29:51 Evan Daniel wrote: > On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland > <toad at amphibian.dyndns.org> wrote: > > 1. Release the 20 nodes barrier (206 votes) > > > > As I have mentioned IMHO this is a straightforward plea for more performance. > > I'll reiterate a point I've made before. > > While this represents a simple plea for performance, I don't think > it's an irrational one -- that is, I think the overall network > performance is hampered by having all nodes have the same number of > connections. > > Because all connections use similar amounts of bandwidth, the network > speed is limited by the slower nodes. This is true regardless of the > absolute number of connections; raising the maximum for fast nodes > should have a very similar effect to lowering it for slow nodes. What > matters is that slow nodes have fewer connections than fast nodes. > > For example, the max allowed connections (and default setting) could > be 1 connection per 2KiB/s output bandwidth, but never more than 20 or > less than 15.
What would the point be? Don't we need a significant range for it to make much difference? > Those numbers are based on some (very limited) testing > I've done -- if I reduce the allowed bw, that is the approximate > number of connections required to make full use of it. > > Reducing the number of connections for slow nodes has some additional > benefits. First, my limited testing shows a slight increase in > payload % at low bw limits as a result of reducing the connection > count (there is some per-connection network overhead). True. > Second, bloom > filter sharing represents a per-connection overhead (mostly in the > initial transfer -- updates are low bw, as discussed). If (when?) > implemented, it will represent a smaller total overhead with fewer > connections than with more. Presumably, the greatest impact is on > slower nodes. Really it's determined by churn, isn't it? Or by any heuristic artificial limits we impose... > > On the other hand, too few connections may make various attacks > easier. I have no idea how strong an effect this is. However, a node > that has too many connections (ie insufficient bw to use them all > fully) may show burstier behavior and thus be more susceptible to > traffic analysis. Yes, definitely true with our current padding algorithms. > In addition, fewer connections means a larger > network diameter on average, which may have an impact on routing. > Lower degree also means that the node has fewer neighbor bloom filters > to check, which means that a request is compared against fewer stores > during its traversal of the network. True. > > I'm intentionally suggesting a small change -- it's less likely to > cause major problems. By keeping the ratio between slow nodes (15 > connections) and fast nodes (20 connections) modest, the potential for > reliance on ubernodes is kept minimal. (Similarly, if you want to > raise the 20 connections limit instead of lower it, I think it should > only be increased slightly.) Why? I don't see the point unless the upper bound is significantly higher than the lower bound: any improvement won't be measurable. > > And finally: I have done some testing on this proposed change. At > first glance, it looks like it doesn't hurt and may help. However, I > have not done enough testing to be able to say anything with > confidence. I'm not suggesting to implement this change immediately; > rather, I'm saying that *any* change like this should see some > real-world testing before implementation, and that reducing the > defaults for slow nodes is as worthy of consideration and testing as > raising it for fast nodes. We did try this (with a minimum of 10 connections), and it seemed that slow nodes with only 10 connections were significantly slower. However, this was not based on widespread testing. My worry is that slow nodes with few connections will be *too* slow, and the network will marginalise them. But it's a tradeoff between slightly more efficiency, fewer routes to choose from, and fewer nodes sending requests... > > Also: do we have any idea what the distribution of available node > bandwidth looks like? It would be great, wouldn't it? Maybe a survey? What questions should we ask? > > Evan Daniel -------------- 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/20090504/75afa6bb/attachment.pgp>
