On Friday 27 March 2009 07:42:52 David Cabanillas wrote: > *Load management* is the process of balancing the supply of store on the > network and tunning my proposal the main idea could be to apply a QUID PRO > QUO mechanism to new nodes until they have a reputation in the system (i.e. > becomes "old nodes").
No, disk space is not the scarce resource - bandwidth is. Load management is the process of balancing the supply of BANDWIDTH on the network, and any form of load management will need to solve two main problems: 1) propagating load back to its originator i.e. reducing the number of requests starting at source, and 2) dealing with individual slow nodes. Load management inevitably results in some level of misrouting, which is generally a bad thing, but can be managed. Also most load management schemes are susceptible to denial of service attacks on some level, or may have security issues e.g. with the first goal (propagating load back to source) making it easier to guess which requests originate on the node via timing attacks. > > A classic problem in distributed system is the ?tragedy of the commons? for > example during a period of high de- mand. Here, a growing number of new > users simultaneously request storage resources. Freenet has built-in very good slashdot protection on the level of lots of users fetching the same content. However, adding lots of nodes is something we've historically been very bad at. > > One simple strategy based on reciprocity that has proven to be remarkably > robust and effective against a wide range of competing strategies is TIT FOR > TAT. And to apply this strategy to new nodes is a control that can restrict > overloading and DoS attacks. Any new scheme must be a benefit both during active attack and during normal operation. One of the biggest problems we face at the moment is that new users find that Freenet is slow; especially on opennet (which everyone uses, especially newbies), new nodes tend not to connect to the best possible peers for their part of the address space. Limiting the number of requests that a new node can make while it is "new" would make this problem worse, therefore is not very attractive at the moment... There have been various load management proposals made, some of which can incorporate tit-for-tat to some degree, however as a matter of policy we cannot deploy such drastic changes without simulating them first... > > The problem with Freenet performance right now is not altruism with regards > > to > > store space. 99% of users use opennet, and on opennet, fast nodes tend to > > get > > connected to fast nodes, hence there is a clear incentive for having a big > > store etc; if a node is not good at answering requests it will tend to get > > diverted to slower peers. One of the biggest right now is probably churn - > > lots of people try Freenet, figure out that it's slow and then go away, and > > this in itself slows down the network and breaks storage, but also the fact > > that many nodes run very much less than 24x7 and this is a problem for > > storage. > > > > Trading storage of individual blocks is not likely to help matters because > > we > > want blocks to move to wherever is closest to their locations, modulo > > demand. > > > > Having said that, there may be useful quid-pro-quo systems in other areas > > e.g. > > load management. Perhaps a new node should only have limited access until > > it > > proves itself? This might help to prevent flooding and DoS attacks, but it > > would make new nodes even slower than they already are ... > > > > > > > > > > > On Wednesday 25 March 2009 10:13:30 David Cabanillas wrote: > > > Name David Cabanillas > > > Email davidcabanillas75 at gmail.com > > > Project Title FreeSwap > > > Benefits to the Freenet Community The proposal wants to assure that the > > > nodes offer free space without either presence of altruistic participants > > > nor general norms. > > > Expected Results > > > o Improve the data storage process assuring that the nodes > > offer > > > free space to store information. > > > The idea is not rely on altruistic nodes. My approach is to > > use > > > a bartering mechanism at the moment to > > > include new data in the system. When a node wants to add a > > > content X in the system, it should accept store a > > > content from the system. Apart from the advantage that apply > > a > > > "quid pro quo" policy (i.e bartering) this approach avoid > > > a massive stored content from malicious nodes. > > > > > > Project Schedule - How long will the project take? When can you begin > > work? > > > Do you have any other commitment for the summer? > > > > > > I expect to work during 3-4 months. The idea is to start the project on > > May > > > and to finish on September. A short > > > description about the scheduling: > > > o In May review the architecture in special interest in how the > > > data is added to the system > > > o From Jun to August deploy the system > > > o In September to test and review the performance of the system > > > > > > Right now, I'm in a period of time where I have not many tasks to do. > > > This is good because I can read books and I may make many other things > > but > > > the bad point is that > > > the incoming funds have fallen :( > > > > > > Bio - Who are you? What makes you the best person to work on this > > project? > > > > > > I'm from Barcelona (Spain) during the last years have been doing my PhD. > > in > > > artificial > > > intelligence. I have experience in Java and some other languages. In the > > > future I want > > > to work as teacher in some University/school. When I have free-time I put > > on > > > my trainers > > > and I run during kilometers around my city. To me run is a way to escape. > > > > > > With respect the project I believe that this project is a good > > opportunity > > > to me in many aspects: > > > To work in a project very related with my academical and research work is > > > good for my curriculum and > > > it could be a personal experience. But the most important point is that I > > > want to show me that I'm > > > capable to work in an exciting project -------------- 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/20090327/58d71acd/attachment.pgp>
