Nov 032012

A question that often pops when the validity of ICN research is discussed, is how its goals differ from what is already available in CDN solutions. There are many answers to this question, but I would like to focus on one: in my opinion, ICN should not include data storage. Regardless of their implementation, CDNs attempt to push data to where it will be needed next, therefore they incorporate both distribution and storage capabilities: a content provider makes data available and the CDN intelligently replicates these data in its servers. Current ICN architectures on the other hand only offer distribution capabilities, leaving storage to separate entities. There is an argument for incorporating at least some storage at ICN nodes, for example, storing data made available by applications inside the ICN core, so that it remains available even if applications terminate. But delegating storage to another entity requires trust relationships to avoid Denial of Service attacks; do we want to embed these in the network? Even further, do we want to embed CDN-like replication strategies in the network in order to make CDNs obsolete? I would answer no to both: ICN should be a better substrate for CDNs than IP (and the DNS) but it should not attempt to become a CDN. Naming data and decoupling names from locations are powerful tools that can be used in many ways to facilitate diverse CDNs – and not only CDNs.