On Wednesday 11 March 2009 16:42:15 Evan Daniel wrote: > 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.
It's certainly an argument for a slow node to have fewer connections: less bytes per second means less coalescing, fewer transfers happening simultaneously on average on a given connection. We will not actually achieve or implement CBR connections any time soon, because the performance impact would be massive: a certain amount of burstiness is sadly necessary especially on very slow connections (the majority!). However, with padding and coalescing, if we have enough traffic on every link, distinguishing flows may be reasonably difficult. On fast nodes, increasing the number of connections will reduce the number of opportunities for coalescing and hence reduce security somewhat. On the other hand, fast nodes may already have a reasonable level of traffic on each connection - limited by the node at the other end in general, and clearly it would be a performance gain, resulting in more users, which has to be a good thing! > > > > >> ?- we don't want to go back to the "route and missroute according to load" > > approach > > > > Agreed. I don't see how changing the number of connections would favour routing according to load. It would in fact make the capacity per connection more level, and thus mitigate against load-routing, no? > > > >> ?- 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. Only if they are the majority. If they are the exception, then they simply get backed off, and the majority - the non-backed-off nodes - determine the overall speed (the rate at which requests are started, determined by the AIMDs). > >> 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). So you suggest making non-hacked Freenet refuse to run if the outgoing bandwidth is below some level? This would tend to exclude users in some of the places where we most want users, apart from anything else... Clearly running Freenet on dial-up, or even on 256/64, is always going to suck, but if you just have 3 darknet connections, I don't see how it does any harm. > > > > 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$ -------------- 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/20090331/f3105b0c/attachment.pgp>
