The downside of non-probabilistic caching was not that the nodes always put the data into their cache. This just caused data to be dropped that was equally unimportant. Pcaching will drop the data, even if there are still gigs of free space left in the data store.
No it won't. Well, only if you have a huge datastore. Pcaching only kicks in after the store is 90% full.
I thought that the intension of pcaching was mainly to solve the "popular-to-death" problem that Dan Merillat described (but as the outcome of normal routing rather than of an attack). If it is rather a measure against flooding attacks, then it makes actually sense not to use pcaching until the data store is filled.
One can not decide beforehand, if caching data is good or bad. If the node that you route to is overloaded or it considers the data to be popular anyways, then dropping the data was a bad decision. On the other hand if our node caches the data, this might cause the data to be dropped on the node that is in the "shadow" of ours. This is bad, if the network prefers routing to that node.
The proposal postpones the decision. The node always caches the data and propagates new requests for the data as unimportant. The response tells it, if caching was a good decision. If not, the node behaves as if it had not cached the data.
Space on the node is finite. What is the point of caching it if you're only going to transfer it again? The only modification to pcaching that I've heard of that makes any sense would be to cache all stuff that was requested locally but ignore it if it is requested remotely.
You are usually not going to transfer it again, if the second request comes shortly after the first one, because the first request already increased the popularity of the data on the data source node and because of that it will decide to return a DNF.
I did not find a defence against flooding attacks that can actually replace pcaching. However one can reserve a certain fraction of the storage space for the data that pcaching would normally drop.
For the sake of the argument assume we have got a hundred items of data of equal size in our data store. Then this is where pcaching puts data into the store (correct me, if I am wrong):
1. data item <- pcaching decided positively . . 100. data item "below" data store <- dropped by pcaching
should be replaced by:
1. data item <- pcaching decided positively . . 90. data item (in quarantine) <- pcaching decided negatively . 100. data item
The data items that entered with a negative pcaching decision will be marked as being in quarantine. Every time a request for data in quarantine is made let the pcaching algorithm decide again.
On the other hand you can save storage. Because the proposal propagates all requests to the data source node, you can be quite sure that it will be popular on that node. Instead of pushing the item to the top, you just keep it in order to disburden the data source node in case it will be requested again. We may even want to pull down data items, that have been put at a higher position, because we received a DNF in a former request.
On the other hand we want to seriously save a small fraction of those data items (probalistic decision) just in case the data source node goes down or is taken down in an attack. And we really want to keep the data that we are data source of, because other nodes rely on us. However as a defence against flooding attacks this is not valid, if only external data declared us as the data source (e.g. in an insert).
1. data item <- data for that the node did spontaneously reset the data source to itself . 20. data item <- propagated data reply (privileged) . 30. data item <- other data . . 80. data item <- propagated data reply (unprivileged) . 100. data item
(One can argue about the numbers.)
-- Thomas Leske
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
