From the beginning of the PURSUIT project, we started looking at the problem of caching in Information Centric Networks from two angles. The first is following a management apporach to caching – what we call information replication, similar to what is done in CDNs today – using dedicated storage devices attached to ICN nodes. The second approach is that of in-network (packet-level) caching, where every network node opportunistically caches every packet it forwards and is able reply to request for info items/chunks it holds. The latter approach has also been studied by most of the proposed ICN apporaches.
In the information replication problem, the placement/replacement of info items decision is made by a managemenet component taking into account subscriptions (popularity of objects etc) which proactively configures the storage/caching devices in terms of what items to store/replace. We investigated and continue to look at centralised (offline) and distributed (online) algorithms that decide the network location of the caches and the replica assignment of the information objects to the decided caching points. This decision is also related to the topology manager function of the PURSUIT model that can also perform some traffic engineering tasks deciding the ‘best’ available replica for every subscriber.
Moreover, in the in-network caching appraoch, we have thought of a taxonomy of the relevant policies that can be applied there such as replacement policies (e.g. LRU/LFU), request dissemination strategies (e.g. en route, flooding), replication strategies, analytical models of the caching mechanisms, and their interaction with possible transport protocol functionality.
While packet-level caching is considered one of the salient characteristics of information-centric network architectures, one can argue that with that mechanism in place storage placement and information replica assignment is not necessary any more. We still believe that information replication still has an important role to play. Unlike in-network caching, which attempts to store the most commonly accessed objects/packets as close to the clients as possible, replication distributes contents across multiple mirror servers. Replication is used to increase availability and fault tolerance, while it has as side effect load- balancing and enhanced client-server or publisher-subscriber proximity. In conclusion, our belief is that replication and in-network caching complement each other.
We are currently finalising the implementation of in-network and managed caching in the PURSUIT prototype (Blackadder) and plan to evaluate the above in as possible realistic scenarios.