Hi Matthew! In sight of a number of things that are happening at international level I think there is one issue that needs a close watch: CO2 saving. By having an application to run over freenet we manage to do without big servers. This is a huge saving, as huge backbone servers make a LOT of CO2. If you can achieve a network that can make a lot of reduced uptime this means tons of CO2 savings that can be certified and cashed, down to individual level. Obviously enough, we will need some numbers (average emission of a home machine vs emission of a public dedicated WWW server) to reach that stage, hours of uptime and numbers of machines needed to reach the same effect, etc.
This has a deep impact on project financing. If you and I can prove we saved 1 tonn of CO2 emission by using freenet we get cash for that, and al the users get their share. Needless saying, money is often a much more powerful engine than ideology, so this may dramatically impact on the diffusion and employment of your technology. And if it saves CO2 emission, the more it's used, the more all users (and you) cash in. Do we have any data that can serve for a start-up computation of the savings implied? If we identify several critical factors I guess net stats and basic benchmarks can be used to make a public chart of the ongoing savings. This will need certification and once certified it will automatically turn into cash. As a first term of comparison, one can say that an average 24*7*52 www server (with some 430Wh consumption) makes ~3,8MWh, for an equivalent discharge of 2,3 metric tons of CO2. The nodes that run on freenet shall not be taken into account at all, as they have the same emission that people reading WWW data would have anyway (IF AND ONLY IF we require the same uptime for these nodes). Now let's have some basic math: the penalty a government pays for just ONE such server is stated in 100 ? + inflation rate/missed ton of CO2equivalents. So it's 230?+inflation per year, per server. If we aim to take away 1 hundred servers we already deal with a financial revenue of 23K? a year, plus inflation. Once clearly documented and certified, this becomes a key factor for maketing freenet to lots of countries who desperately need to buy CO2e certificates for the 40% of their top industries, as it doesn't absolutely matter where they get their certificates from. I'ma ware as anyone that loads of alternative models for CO2e savings have already been produced. Yet they all imply some kind of serious HW change at mass level: see http://www.netvoyager.co.uk/general/wtc.html Maybe a thin client is the best thing on earth, yet reality is that we all have normal PCs. If freenet can produce a way to use these PCs to produce CO2 savings without requiring the users to spend any money, then it can be easily marketed. Any data I can use to make some energy computations? I'm in the process of applying for funding and I really need to support my claims. Privacy is fantastic (and sure enough nobody needs to drop it because of this) but if freenet can prove worth an investment from more than one point of view it will be much simpler to keep things going. hmmmmmm you say freenet does not "burst". Can you elaborate in detail? This may well mean that we can make lighter computation of consuption/efficiency, since the consumption rate seems to be independent from what a user actually does. Berto 2009/4/2 Matthew Toseland <toad at amphibian.dyndns.org> > Freenet can never compete on speed with traditional peer to peer, for > several > reasons, of which at least 1 is intractable: > 1. Freenet assumes high uptime. This does not happen in practice, at least > not > for the mass market. To some degree we can resolve this with e.g. > persistent > requests in 0.10. > 2. Freenet returns data via intermediaries, both on darknet and opennet. > This > is what makes our caching model work, and it's a good thing for security, > however broadcasting a search (or using some more efficient form of lookup) > and then having those nodes with the data contact you directly will always > be > faster, often much much faster. Caching may well obviate this advantage in > practice, at least in the medium term. > 3. Freenet has a relatively low peer count. Hence the maximum transfer is > determined by the output bandwidths of the peers, which is low. Increasing > the number of peers will increase various costs, especially if they are > slow, > and make it harder to see whether the network can sclae, otoh it would > increase maximum download rates... > 4. Freenet avoids ubernodes. Very fast nodes are seen as a threat, rightly, > because over-reliance on them makes the network very vulnerable. > Practically > speaking they may be attacked, if this is common it again neutralises this > advantage of "traditional" p2p. > 5. FREENET DOESN'T BURST. > > The last is the fundamental, intractable issue IMHO. Freenet sends requests > at > a constant rate, and exchanges data between peers at a roughly constant > rate. > On something like Perfect Dark (which admittedly has much higher average > upstream bandwidth and bigger stores), you start a request, and you get a > huge great spike until the transfer is complete. It's similar on > bittorrent, > provided the file is popular. On Freenet, our load management is all > designed > to send requests constantly, and in practice, up to a certain level, it > will > use as much bandwidth as you allow it. We could introduce a monthly > transfer > limit as well as the upstream limit, but this would not help much, because > bursting is inherently dangerous for Freenet's architecture. If you are > Eve, > and you see a big burst of traffic spreading out from Alice, with tons of > traffic on the first hop, lots on the second, elevated levels on the third, > you can guess that Alice is making a big request. But it's a lot worse than > that: If you also own a node where the spike is perceptible, or can get one > there before the spike ends, you can immediately identify what Alice is > fetching! The more spiky the traffic, the more security is obliterated. And > encrypted tunnels do not solve the problem, because they still have to > carry > the same data spike. Ultimately only CBR links solve the problem > completely; > what we have right now is hope that most of the network is busy enough to > hide traffic flows, but this is the same assumption that many other systems > rely on. But big spikes - which are necessary if the user wants to queue a > large download and have it delivered at link speed - make it much worse. > > There are lots of ways we can improve Freenet's performance, and we will > implement some of the more interesting ones in 0.9: For example, sharing > Bloom filters of our datastore with our peers will gain us a lot, although > to > what degree it can work on opennet is an open question, and encrypted > tunnels > may eat up most of the hops we gain from bloom filters. And new load > management will help too when we eventually get there. However, at least > for > popular data, we can never achieve the high, transient download rates that > bursty filesharing networks can. How does that affect our target audience > and > our strategy for getting people to use Freenet in general? Does it affect > it? > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > -- ============================== Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole les droits du peuple, l'insurrection est, pour le peuple et pour chaque portion du peuple, le plus sacr? des droits et le plus indispensable des devoirs. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20090403/5b15b689/attachment.html>