Considering the difficulty of introducing new technologies into the Internet, as evidenced by the span of years that the migration from IPv4 to IPv6 is taking, any transition to ICN must consider how existing Internet applications and services will execute over a mixed ICN and IP substrate. Since POINT attempts to introduce ICN into individual operator networks, transparently to the rest of the network, an issue we faced on day one is how to transport existing Internet traffic over an ICN network. In technical terms, the question is “what is the right x in x-over-ICN”? Ethernet frames, IP packets, TCP segments, HTTP messages, something else?

Ethernet frames could be an option for small ICN networks, but the interest in SDN networks clearly shows that Ethernet is not a viable option for larger networks, only a necessity, which requires considerable complexity (e.g., VLANs) to support non-trivial networks. And it is not even a universal frame format, despite its prevalence.

IP is the level at which the Internet interoperates and is the only common protocol across the Internet. This means that we must provide an IP-over-ICN service in order to catch everything on the Internet, and of course, we do. Even though the publish-subscribe operation of our underlying ICN network may seem to imply that we would need at least two messages to transport a single IP datagram, we actually only use only a few ICN messages per IP address range, to register an endpoint’s intention to receive IP datagrams for the corresponding range; afterwards, there is a one-to-one correspondence between IP datagrams and IP messages.

Although the IP-over-ICN service can take advantage of some POINT functionality, such as load balancing and resilience to path failures, the driving force behind ICN is to move from naming endpoints (e.g., DNS names, IP addresses) to naming content. Therefore, POINT is most effective when dealing with named content, as is the case with HTTP requests and responses, which involve resources named via URLs. Our HTTP-over-ICN service relies on this explicit naming to offer additional functionality. For example, near-simultaneous requests for the same content, common in many video applications (e.g., HLS or MPEG-DASH), are identified and served via multicast inside the POINT network, leading to large bandwidth savings.

Similar benefits arise with our CoAP-over-ICN service where, again, resources (e.g., sensors and actuators) are explicitly named via URIs. For example, multiple endpoints observing the same resource (that is, expecting notifications when the resource changes) can be served via multicast. The essential reason that these services work so well is that the named content semantics of HTTP and CoAP can be beneficially translated into ICN semantics, allowing the POINT network to optimize their transport.

Since so many applications and services run on top of TCP, offering a TCP-over-ICN service would allow supporting a large fraction of Internet traffic, without dealing with numerous higher layer protocols like HTTP. However, TCP is agnostic about content, treating all data as a sequence of bytes, regardless of its structure and semantics, unlike ICN. For example, when multiple users request the same content from an HTTP server, while the commonality is obvious at the HTTP level, it is hidden at the TCP level, where the same data are sent with different sequence numbers and segment sizes. There is no obvious mapping between TCP segments, which are arbitrary parts of the TCP sequence space, and ICN messages, which are named entities. As a result, there are no clear benefits to offering a TCP-over-ICN service. And since an IP-over-ICN service needs to be offered anyway, the additional complexity of a TCP service cannot be justified.

Moving beyond what POINT already offers, it has become clear that in order to do better than IP-over-ICN, an x-over-ICN service needs to understand the content being transferred to properly map it to ICN. Even simple protocols like FTP have such semantics, dealing with entire files as pieces of content; POINT has taken advantage of these semantics, developing schemes to transport entire files via multiple paths to multiple sources. Similarly, BitTorrent traffic, with its focus on clearly identified pieces of named content and its disregard to the actual source of each piece, would be another good candidate for an x-over-ICN service. The pattern here is clear: content named at the application level, is the best focus for x-over-ICN.