On Tuesday 07 April 2009 03:39:35 Matthew Toseland wrote: > On Tue, Apr 07, 2009 at 02:34:50AM +0100, Matthew Toseland wrote: > ... > > > > Lots more things that can be simulated (but I'm not saying you must implement > > all of these!): > ... > > - Various proposed new load management schemes such as token passing. The > > basic principle of token passing is that we tell our peers when we have the > > capacity for new requests, and then accept some of their requests; when we > > have accepted the requests, they are queued until we can either serve them > > from the datastore or from the results of another request, or we can forward > > them to one of our peers that says it can accept some requests. As I have > > mentioned there are many details that can be tweaked... > > - Whether queueing requests (probably only bulk requests) is useful in > > general. > ... > > > > I don't expect you to implement everything I've mentioned above! Getting a > > good simulation of the current model working is essential, particularly as it > > relates to load management. I'm not sure exactly how far load-balancing-sims > > went, mailing list traffic suggests phase 7 implements most of the current > > model, but I think preemptive rejection is missing, and IMHO that's a > > critical component of the current architecture. One thing to note is that > > vive has tried some interesting routing changes out without copying the code > > first, so you might need to turn them off. Simulating token passing would > > then be the next big thing, although as I mentioned there are a great many > > variations, most of which are in the mailing list archives; we would need to > > dig through the archives to find them. > > > ... > > David Cabanillas wrote: > > > The proposals for extend the simulations are as follows: > > > > > > - To extend the simulations phases in large scale. > > > - To compare simulations using and not using backoff. > > > > See here for mrogers' results from phase7 (these don't include preemptive > > rejection): > > http://archives.freenetproject.org/message/20061122.001144.52dbb09d.en.html > > > > > - To apply peer-peer token buckets to track fairness between accepting > > > requests from different peers, > > This is actually a fairly important detail. Without this, any queueing based > scheme, at least any queueing based scheme that matches requests to nodes > based on key closeness, can be DoS'ed by simply sending lots of requests for > keys close to the known specialisations of the target's peers (which can be > picked up by snooping on swapping, or from FOAF announcements). We need to > ensure that incoming requests are balanced between nodes, not just outgoing > requests (we already prevent more than 30% of our outgoing requests going to > any given peer). Such balance does not require token passing, although it > will be most interesting with some sort of queueing-based system. > > It is essential that we propagate load back to its originator, hence > flooding needs to be damped out at source; currently AIMDs ensure this > function, but on a token passing network, ensuring fairness should be > sufficient, although arguably going a bit further and rewarding > non-flooding nodes at the expense of flooding nodes may help more.
This message was in fact from me. -------------- 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/20090407/42a8c01a/attachment.pgp>
