Any new Internet architecture has to accept that it is impossible to replace the existing IP-based Internet in one step. The prevailing approach to deployment is creating individual network “islands” using the new approach, show its benefits, and gradually expand then to take over the Internet. In the meantime, these islands have to somehow interoperate with the existing network, either to communicate with each other, using the IP-based Internet as a bridge, or to interconnect IP-based areas, becoming themselves a bridge.
Most previous ICN efforts took the former approach, hoping to show that the benefits of ICN are so great, that everyone would have to embrace it. But the benefits can only become apparent if there are applications to showcase them. The POINT project has instead taken the latter approach, aiming to show that an ICN-based network can offer benefits for IP-based traffic, which is already there, even without changing anything in the IP world.
In a separate blog post, we discussed how we managed to carry Internet traffic over POINT islands, by supporting IP traffic as a baseline, and then adding application level services, e.g., for HTTP and CoAP, with additional benefits. Although there is no similar project in the CCN/NDN world, the need for compatibility is clear, with the most well-known effort in this area aiming to support the transport of TCP traffic over a CCN/NDN island.
Since we argued in a previous blog post that TCP does not offer a proper abstraction to translate into ICN traffic , it is worth examining why the CCN/NDN effort did focus on TCP. One of the main tenets of CCN/NDN is the balance between Interest and Data messages, which essentially translates to the requirement that no Data message should appear without a matching Interest message; the reverse does not hold, since Interests may never be responded to. Trying to directly support IP over CCN/NDN then, would require each IP datagram to be translated to two CCN/NDN packets: one Data to carry the payload, and one Interest to ask for it. This is where TCP, with its long-term connections, becomes attractive, as it allows reducing the relative cost of Interest messages, by using larger Data packets.
The actual execution of the TCP to CCN/NDN mapping however, shows that things are not so simple. The initial attempt presented, which simply translates TCP segments to CCN/NDN packets, needs at least two packets per segment, and in some cases three. To reduce this overhead and the resulting latency, their improved attempt pre-fetches Data and uses Interest messages as implicit TCP acknowledgments. In bidirectional connections however, since Interests are always needed in both directions, this scheme will, at best, inflate the number of packets sent by 50%, compared to the actual TCP segments. To reach parity with TCP, the performance evaluation relies on unidirectional transfers, to reduce the overhead, and combines multiple TCP segments into Jumbo Ethernet frames. If the IP-based network used itself Jumbo frames and the connection was bidirectional, the CCN/NDN network would unavoidably bloat and delay the connection. So, despite the complexity involved in handling the TCP state machines in the CCN/NDN handlers, there is no benefit to be reaped by this design – at best, performance parity may be achieved.
The reason POINT does not have to go down that way is that it does not rely on a balance between request/response messages: by sending a few messages to register an entire address range, each IP datagram can then be transported via a single ICN message. In this manner we achieve universal compatibility with the IP-based Internet, without the complexity of TCP support and its state machine. And even at this level we can offer traffic engineering, native multicast support and support for multiple failover scenarios. Although the real gains begin at higher layers, which have been the primary target of POINT (and CCN/NDN), universal compatibility with IP is also required, and the POINT approach clearly outshines the competition in this area.