Matthew, I completely agree with you. People should not be using freenet to get the latest and fastest file-sharing technology. Probably not either to get stronger privacy if they still require very efficient file-sharing. I cannot see that the current design (as far as I understand it) is aimed for that.
Requests to make freenet optimized for large-scale file-sharing sounds like a promising idea to many, but would IMHO require a re-design with lower security and privacy. These are tradeoffs that you need to make. It may be good to make more explicit that part of Freenet is about trading off efficiency and high-bw/low latency for stronger privacy and the possibility to avoid various kinds of censorship. These are the benefits. /V. On Thu, Apr 02, 2009 at 08:18:32PM +0100, Matthew Toseland wrote: > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20090403/4208bd21/attachment.pgp>
