I’ve been reading up on content-oriented networking off-and-on for a few years now. The concept is attractive at a high level: your URLs state what you want, not where you want it from. That is, you ask for “ccnx:cat-video.mp4” instead of “http://cat-videos-r.us/cat-video.mp4” and you don’t care which server provides the content. You’ll probably get it from a cache close to you if the content is popular enough.
It’s attractive because you no longer need to build load balancers and content distribution networks — the whole internet automatically becomes your CDN, and every router becomes a web cache.
But of course it’s not that simple. None of the articles (well, not the ones I’ve read anyway) ever address the real-world drawbacks. Like, content providers deeply want to know how many times a particular cat video has been watched. Analytics goes out the window if the caches are silently handling 99% of the requests.
And what about cache misses? The “long tail” means to me that a vast number of content requests are for obscure items which are not worth caching. How much of your proxy’s time is spent asking all of the other proxies “Hey, do you have a copy of charlie’s-brother’s-birthday.mp4?” when only one server in the world has that video, and that’s charlies-brother.com.
I’ve worked on (fairly simple) multicast-based systems, and the O(N^2) load of every asking everyone else gets really bad for even modest values of N. So, I’d like to understand how CCNx and other protocol proposals avoid going quadratic.
I have no doubt that smart people (Van Jacobson, etc) have thought of these obvious objections. But I haven’t seen the solutions yet…