On Tuesday 06 January 2009 16:03, Daniel Cheng wrote: > On Tue, Jan 6, 2009 at 11:07 PM, Florent Daigniere > <nextgens at freenetproject.org> wrote: > > Daniel Cheng wrote: > >> On Tue, Jan 6, 2009 at 10:42 PM, Florent Daigniere > >> <nextgens at freenetproject.org> wrote: > >>> Matthew Toseland wrote: > >>>> On Tuesday 06 January 2009 12:15, Florent Daigniere wrote: > >>>>> Matthew Toseland wrote: > >>>>>> On Wednesday 31 December 2008 14:23, Matthew Toseland wrote: > >>>>>>> #1: 41 votes : release the 20 nodes barrier > >>>>>>> > >>>>>>> "most of the users nowadays have a lot of upload-bandwith available. > >>>> Myself > >>>>>>> has about 3Mbits upload, but the limit to connect to not more than 20 > >>>> nodes > >>>>>>> results in about 50kb/s max. Please release the limit or use a dynamic > >>>>>> system > >>>>>>> that offers more connections if the node has a high bandwith upload limit > >>>>>>> (scaling). Thx" > >>>>>>> > >>>>>>> I'm not sure what to do about this. The original rationale for the 20 > >>>> peers > >>>>>>> limit was that we didn't want to disadvantage darknet nodes too much on a > >>>>>>> hybrid network, since they will not often have large numbers of peers. > >>>>>>> Combined with experience on 0.5 suggesting that more peers is not always > >>>>>>> better, a security concern over over-reliance on ubernodes, and the fact > >>>>>> that > >>>>>>> we should eventually be able to improve bandwidth usage through better > >>>> load > >>>>>>> management. However, there's a limit to what we are able to achieve > >>>> through > >>>>>>> better load management, and it's a difficult problem. > >>>>>>> > >>>>>>> Thoughts? > >>>>>> As people have pointed out, many people only have access to very slow > >>>>>> connections. Vive seems to think there is no theoretical problem with > >>>>>> this ... so the remaining questions: > >>>>>> - What should the minimum number of peers be? > >>>>>> - What should the maximum number of peers be? > >>>>>> - How much output bandwidth should we require for every additional peer? > >>>>>> > >>>>>> For the first, a safe answer would be 20, since that's what we use now; > >>>>>> clearly it won't seriously break things. IMHO less than 1kB/sec/peer is > >>>>>> unreasonable, but I might be persuaded to use more than that. And we > >>>> probably > >>>>>> should avoid adding more peers until we've reached the minimum bandwidth > >>>> for > >>>>>> the lower limit. Vive suggested a limit of 50, I originally suggested > >>>> 40 ... > >>>>>> probe requests continue to show approximately 1000 live nodes at any given > >>>>>> time, so we don't want the upper limit to be too high; 100 would certainly > >>>> be > >>>>>> too high. > >>>>>> > >>>>>> One possibility then: > >>>>>> > >>>>>> 0-20kB/sec : 20 peers > >>>>>> 21kB/sec : 21 peers > >>>>>> ... > >>>>>> 40kB/sec+ : 40 peers > >>>>>> > >>>>>> Arguably this is too fast; some connections have a lot more than 40kB/sec > >>>>>> spare upload bandwidth. Maybe it shouldn't even be linear? Or maybe we > >>>> should > >>>>>> have a lower minimum number of peers? > >>>>>> > >>>>>> 0-10kB/sec : 10 peers > >>>>>> 12kB/sec : 11 peers > >>>>>> 14kB/sec : 12 peers > >>>>>> ... > >>>>>> 70kB/sec : 40 peers > >>>>>> > >>>>> Yay, more alchemy! > >>>> More alchemical than an arbitrary 20 peers limit? I suppose there are more > >>>> parameters... > >>> See below; it's not about changing the alchemy; it's about changing it now. > >>> > >>>>> What's the reason why we are considering to raise the limit again? > >>>> To improve performance on opennet, in the average case, for slow nodes, and > >>>> for fast nodes? > >>>> > >>>>> It's > >>>>> not the top-priority on the uservoice thingy anymore. Anyway, I remain > >>>>> convinced that ~50 votes is irrelevant (especially when we consider that > >>>>> a single user can give 3 voices to the same task!) and that we shouldn't > >>>>> set priorities depending on what some "vocal" users are saying. > >>>>> > >>>>> They are concerned by their bandwidth not being sucked up? Fine! Turn > >>>>> them into seednodes, create a distribution toadlet, create a special > >>>>> mode where they would only serve UoMs (and would be registered by > >>>>> seednodes as such)... They are plenty of solutions to max out their > >>>>> upload bandwidth usage if that's what they want their node to do! > >>>> Don't you think that more opennet peers for fast nodes, and maybe fewer for > >>>> really slow nodes, would improve performance for everyone? > >>> Fewer peers for slow nodes would help in terms of latency; I'm not sure > >>> about more for fast nodes. > >>> > >>>> Given that our > >>>> current load management limits a node's performance by the number of its > >>>> peers multiplied by the average bandwidth per peer on the network? > >>>> > >>> IMHO it's a lot more trickier to do than to bump one constant! Anyway, > >> > >> ugh..... > >> Did anybody notice we have this dynamic already? > >> > >> r19603 Scale so 20 peers at 16K/sec. > >> r19602 Scaling of peers with bandwidth > >> > > > > That's because 20 peers couldn't be sustained with the default bandwidth > > limit at the time... > > > > Anyway, what we are talking about here is increasing the max bound... > > and that has side effects; At least on the FOAF code as it is > > implemented right now... Try it out locally: bump the constant and > > you'll lose all of your peers. > > This is because the FOAF acccept at most 20 locations. > We should increase this if we change the max limit.
Yes but there are wider effects. A higher peers limit makes it easier for an attacker to steal traffic. However, we do have some measures against this... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090106/805dafac/attachment.pgp>
