I suggest we do not throttle incoming bandwith at all.

The main reason is that we do not throttle messages with trailing fields differently from the ones that don't. For the end-user that means that they cannot set separate limits for routing data as opposed to file transfer. Most end users ideally prefer to have as little possible bandwith spent for routing and as much as possible for downloads; any limit on incoming bandwith that we set is practically limit on download speed. Newbies especially will judge freenet by how fast they can get their filez downloaded.

Secondary reason is that based on observation, incoming bandwith tends to stabilize around the level outgoing bandwith is capped. Spikes are _very_ rare; of course when browsing/downloading the incoming bandwith goes up.

Adding to that, most p2p population knows that uplink is the most precious resource and are very diligent in setting limits; the reason being that majority of the residential broadband providers offer between 5 and 10 times as much downlink than uplink. Its rare to see a p2p app *not* capped for uplink by the user himself, and even more rare to see one capped for downlink. They just don't do that.

_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl

Reply via email to