On Tue, Mar 10, 2009 at 7:16 PM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Monday 02 March 2009 20:55:59 Florent Daigni?re wrote: >> * Evan Daniel <evanbd at gmail.com> [2009-03-02 15:41:59]: >> >> > On Mon, Mar 2, 2009 at 3:11 PM, Florent Daigni?re >> > <nextgens at freenetproject.org> wrote: >> > > * Evan Daniel <evanbd at gmail.com> [2009-02-27 10:58:19]: >> > >> I think it would be inappropriate to reduce the connection limit >> > >> without further testing. >> > [...] >> > > Tweaking that code based on one's experience is just plain silly. >> > >> > Then it seems we're in agreement. >> > >> > Tweaking an emergent system based on hunches is silly. ?Gathering data >> > and tweaking based on that data isn't. ?Individual anecdotes like my >> > node's performance prove nothing, but can suggest routes for further >> > investigation. ?Right now, all I think we know is that the current >> > system works, and that there is reason to believe improvement is >> > possible (ie unused available bandwidth). ?Do you disagree with that >> > assessment? >> > >> > Is there a reason not to investigate this? ?I'm not wedded to any >> > particular solution or testing method, and I can think of plenty of >> > flaws in mine. ?If you have an improved proposal, by all means say so. >> > >> >> Yes, they are *good* reasons why we should keep the number of peers >> constant accross nodes. >> >> ?- makes traffic analysis harder (CBR is good; there is even an argument >> ? ?saying we should pad and send garbage if we have to) > > How is this related to the number of peers being constant across very fast and > very slow nodes? On a node with a very low transfer limit, we will have > different padding behaviour than on a node with a very high transfer limit: a > fast node has more opportunities for padding because we have a fixed period > of time for coalescing.
Agreed. This actually sounds like an argument in favor of variable connection count (at least relative to the current system). If each connection is CBR, then how many there are doesn't tell an observer anything. If all nodes have the same number of connections, then either there is bw going unused or some connections are higher bw than others -- which means there is significant routing based on capacity rather than location. If a fast node simply has more connections at the same (constant) bit rate instead of a mix of fast and slow links, this is mitigated. > >> ?- we don't want to go back to the "route and missroute according to load" > approach > > Agreed. > >> ?- dynamic systems are often easier to abuse than static ones >> >> It has been discussed numerous times already; As far as I am concerned, >> nothing has changed... We have to accept that we will always have to >> deal with slow nodes and those are going to determine the speed of the >> whole network. The only parameter we should change is the height of the >> ?"entry fence": how much is the minimal configuration needed to access >> freenet. >> >> Obviously that's some form of elitism... but that's much better than the >> alternative (creating a dynamic, fragile system which will work well only >> ?for *some* people). > > I don't see why it would be more fragile... however we would have to deploy it > and try to see if we can tell whether it's an improvement, which may be > tricky... >> >> NextGen$ > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
