Information-Centric Networking and IPFS

[raulk]

Hey IPFS friends! The more I read about ICN (Information-Centric Networking), the stronger I conclude that much of what IPFS, IPLD, and in a lesser degree, libp2p, are trying to achieve can be construed as elements of ICN.

In fact, one could arguably regard IPFS as a concrete application-level realisation of parts of an ICN stack.

What confuses me is that I have not once seen this term mentioned in our specs, whitepapers, or documentation.

Am I drawing imprecise conclusions and correlations?

Or perhaps there’s some kind of disconnect we could fix to realign IPFS with wider Internet Research directions?

---

copied over from an instant messaging thread for openness and wider participation

[raulk]

From @jimpick:

Check out the lightning talk by Christian Tschudin from the Decentralized Web conference last year https://www.decentralizedweb.net/videos/lightning-talks-new-discoveries-session-1/
After the conference, he made this interesting project https://github.com/cn-uofbasel/ssbdrv

From @daviddias:

There has definitely been some cross pollination in the past, strange I can't find records of it too

[daviddias]

PSA: For folks interested, we will have an open workshop on A Brief History of Information-Centric Networks this Wednesday at 5pm UTC, check details at protocol/research#14

[yiannisbot]

ICN is very closely related to both IPFS and libp2p IMO, given that a core function of libp2p is content discovery and content routing. It also links to IPLD, given naming is a core part of any content addressable system. Effectively ICN is proposing a new set of protocols for the network layer to be able to route based on content names. This comes mainly in two flavours:

1. Name-based routing, where network routers associate content name entries in their FIB table to next-hop nodes and do forwarding accordingly.
2. Name-resolution based routing, where an external/overlay entity (DHT or similar) needs to be consulted in order to associate a name with a location.

This is called the name-to-location binding and the later in the process of resolving content it happens, the more natively content can be found and distributed in the network (e.g., easier/native support for multicast). In a sense then, and assuming that IPFS deals with CIDs and libp2p with peerIDs (and their location in the topology), the interaction between the two defines the efficiency of the system in terms of performance.

There is a huge amount of very interesting work already done in the ICN area, which can prove very useful for IPFS and libp2p, including named functions that Christian talked about in the talk linked above, support for Named Functions as a Service (NFaaS), edge computing, IoT etc. More to follow tomorrow (protocol/research#14 - at 5pm UTC), but ping me in case you're interested in some particular aspect. Links to active work items in the ICNRG group can be found here: https://trac.ietf.org/trac/irtf/wiki/icnrg

[daviddias]

There is definitely room for exchange of ideas and complementing each other, however, ICN and IPFS have some key distinctions. Writing some of them here to clarify to the broader audience:

• ICN/NDN is often at the link layer, while IPFS is at the Application layer and leverages whatever is available at the Link and Transport layers
• Cryptographic Addressing is not a core primitive of the ICN/NDN stacks. ICN/NDN have no way to validate that the data delivered is the data requested (akin to HTTP)
• ICN/NDN relies on points of control that dictate how routing gets set up
• IPFS is highly resilient to node churn, while ICN/NDN networks aren't (due to being so close to the link layer)
• IPFS uses self-certified naming (from SFS) for secure mutable pointers. ICN/NDN relies on points of control to propagate these.
• Unfortunately, the ICN/NDN world hasn't been as focused in Public and Permissionless networks, hence a lot of design decisions requiring control trust, rather than verifiability and trustless interactions.

IPFS takes first and foremost a lot of inspiration from:

• Merkle-trees and Cryptographic Hashing
• Versioning Control Systems like git
• P2P Routing from Kademlia and other structured overlays

I would love to see more ideas from the ICN/NDN world applied to overlays on top of IPFS dedicated to applications, where certain apps and services would live on the Public IPFS Network, but coordinate among each other through ICN/NDN routing to speed up the content discovery and update propagation among themselves. Once you as a builder accept to have some point of control (e.g a Rendezvous node, a Gateway, etc) where the user of your application authenticate, then you can leverage that as the point of control that ICN/NDN networks expect to provide a coordination point for topology setup.

[yiannisbot]

@daviddias there is a terminology issue here. ICN should be read as anything content-addressable. ICN and NDN are not the same. NDN is one architecture proposed in the ICN space. There are/have been many others. Some of them are indeed network-layer approaches, but several others sit at the application-layer.

So, the comment above is mostly correct, but when referring to NDN, not ICN more generally.

Just so I get a more accurate understanding, can you elaborate on what you mean by "point of control"? Is point of control a certificate authority? (I guess, yes). Is point of control a network router owned and operated by an ISP? Is point of control the IPFS DHT server node that I own and operate?

I would love to see more ideas from the ICN/NDN world applied to overlays on top of IPFS dedicated to applications, where certain apps and services would live on the Public IPFS Network, but coordinate among each other through ICN/NDN routing to speed up the content discovery and update propagation among themselves.

Absolutely! It would be great to see what performance would look like and what challenges exist there.

[RotonEvan]

@yiannisbot I think by point-of-control he meant the DHT control node. Rendezvous Nodes can be found in the PURSUIT architecture.

I recently discovered ICN while learning about distributed caching. And then related with the notion of IPFS. IPFS uses content based naming to but DHT realigns it with the IP. What if we could use the singular content-based names for both IPFS and ICN. For a hierarchical routing structure like the PURSUIT, it uses many Rendezvous Networks as DHTs (both Global and Local; sounded to me like an IPFS-like thing). This might be a good start to implement both ICN and IPFS together.

* P2P Routing from Kademlia and other structured overlays

@daviddias as Kademlia is a DHT too, then won't it help ICN based on structured routing?

And, are there any implementations of ICN and IPFS as of now? I really want to learn more and if possible, contribute ideas and thoughts too!

@yiannisbot I just watched the recording of the ICN workshop talk you gave. It is very informative !