Esta seção foi baseada no artigo Information –Centric Networking: Seeing the Forest for the Trees de Ali Ghodsi, Scott Shenker, Teemu Koponen, Ankit Singla, Barath Raghavan, e James Wilcox.

     O artigo “Information –Centric Networking: Seeing the Forest for the Trees”  faz algumas considerações sobre a forma como a comunidade científica vem tratando esse tópico. Ele critica o fato de que a maioria parece tomar por garantido que as premissas sobre as quais esse conceito foi definido são verdadeiras e não precisam ser checadas , estão muito focados na implementação e pouco na arquitetura e conceitos.

     De acordo com os autores, no momento estudar formas de implementar ICN não são importantes pois com as técnicas atuais o HTTP já suporta os princípios básicos de ICN, faltando apenas discutir com fornecedores de roteadores quanto a capacidade destes de armazenar dados e decidir como implementar a segurança.

Para os autores existem aspectos mais importantes do ICN a serem pensados, como:

Privacidade

     Como os dados se encontram distribuídos em vários nós do sistema, seu conteúdo pode ser acessado por outras pessoas que não o fornecedor e o consumidor. Isso implicaria numa perda de privacidade. É necessário estudar métodos para evitar essa perda.

Scaling, Object Sizes  and the Narrow Waist

     Para que as decisões de roteamento sejam feitas de forma rápida é necessário que as tabelas de roteamento sejam pequenas em relação à quantidade total de objetos.  Para tal, poder-se-ia utilizar uma estrutura hierárquica de nomes, que permitiria ter um único nome na tabela de roteamento, mas isso dificultaria o multihomming pois os dados sempre viriam pelo caminho que leva diretamente o fornecedor original e o cachê universal não seria bem aproveitado.  Essa diminuição também  poderia ser causada pelo fato dos padrões de pedidos feitos resultarem numa pequena porção da tabela de roteamento, tornando desnecessário o armazenamento de toda a tabela de roteamento no “fast path” .

     Logo, ou faz-se um roteamento lento ou não será possível aproveitar o cachê universal. Isso seria um problema no inicio da transferência, mas a partir do momento que a localização do conteúdo é conhecida isso não será mais um problema, o roteamento será realizado de forma rápida.  Como o roteamento dos nomes é mais lento que o roteamento dos pacotes, é necessário, para que o sistema seja eficiente, que os conteúdos a serem solicitados sejam grandes. Assim o impacto do tempo longo de roteamento do nome não será grande.

     Devido a essa lentidão no processamento dos nomes dificilmente uma arquitetura que não utilize os nomes ao invés do IP como base poderá ser implementada de forma eficiente.

     Pesquisas nessas áreas seriam de grande importância para o design de redes ICN que visem se substituir a internet atual, porém a reflexão mais importante a ser feita é quanto a solidez da base sobre a qual a arquitetura ICN foi concebida. É necessário avaliar as vantagens reais em desempenho do cachê cooperativo das redes com arquitetura ICN. 

     O princípio de cachê cooperativo já foi estudado anteriormente e chegou-se a conclusão que a partir de certo limite de usuários ele não seria vantajoso.  ICN é um novo paradigma, mas o seu conceito de cachê universal é muito semelhante, se não igual, ao cachê cooperativo. Essas conclusões foram tiradas há mais de 10 anos, porém, de acordo com os dados de utilização do cachê nos servidores de imagem do Facebook, essas conclusões ainda são válidas. É possível que com apenas um cachê Proxy por grupo de usuários seja possível obter o mesmo desempenho que se teria com um cachê distribuído entre todos os nós da rede, mas com um custo muito menor.