Overview

Information-Centric Networking (ICN) has emerged as an alternative to the current host-to-host communication paradigm and proposes direct communication between user applications and the content itself, putting the actual information or content in the forefront and disregarding location. In ICN, the network transfers individual, identifiable content chunks, instead of data containers, i.e. packets, with opaque data. Contents are identified by name and relevant packets contain a part of a content chunk; the latter can be retrieved from the hosting server or from an in-network router cache, given that in-network caching is a key aspect of the ICN paradigm. Popular content tends to stay longer in network caches and "anycast routing" based on content names retrieves the closest copy to the user. This increases dramatically traffic localisation, avoids flash crowd events and gives to network providers control over the information transferred, allowing them to engineer their networks based on the actual demand for named content.

Content Resolution Approach

Despite the considerable amount of effort that has been invested to date by the research community in location-independent routing based on content names, a widely acceptable and scalable solution is yet to be found. Any naming scheme would have to be able to accommodate 10**12 or more objects and content resolution and routing based solely on content names raises serious scalability concerns. In addition, the current IP-based Internet represents a massive infrastructure that cannot be easily replaced by a new, clean slate design. Having this in mind, we believe it is possible to achieve the ICN benefits of traffic localisation and sustainable network evolution without radical ICN approaches but by introducing, in an evolutionary manner, a "content layer" in the Internet architecture which will operate above the current network layer and below the transport layer, i.e. layer 3.5.

This layer will intercept communication, will produce unique location-independent names for requested content and will store the latter within the network according to sophisticated caching policies. Content will be accessed in an anycast fashion using ICN style of operation but overlaid over IP, exploiting the existence of scalable IP-based routing, maintaining full backwards compatibility and protecting current investment. In addition, congestion control will be dealt with in a hop-by-hop rather than an end-to-end basis within the content layer, maintaining at the same time compatibility with current end-to-end operation while maximizing the use of available network resources, increasing user quality of experience and paving the way for future Internet applications with stringent real-time requirements.

Hop-by-hop Congestion Control

In this project, we question the widely adopted view of in-network caches acting as temporary storage for the most popular content in Information-Centric Networks (ICN). Instead, we propose that in-network storage is used as a place of temporary custody for incoming data in a store and forward manner. Given this functionality of in-network storage, senders push data into the network, in an open-loop manner to take advantage of underutilised links. When data hits the bottleneck link it gets re-routed through alternative un-congested paths. If alternative paths do not exist, incoming data is temporarily stored in in-network caches, while the system enters a closed-loop, back-pressure mode of operation to avoid congestion.

Single-/Multi-Path Resource Utilisation

Our proposal follows in spirit the resource pooling principle, which, however, is restricted to end-to-end resources and paths. We extend this principle to also take advantage of in-network resources, in terms of multiplicity of available sub-paths (as compared to multihomed users only) and in-network cache space. We call the proposed principle In-Network Resource Pooling Principle (INRPP). Using the INRPP, congestion, or increased contention over a link, is dealt with locally in a hop-by-hop manner, instead of end-to-end. INRPP utilises resources throughout the network more efficiently and opens up new directions for research in the multipath routing and congestion control areas.

Left: e2e Flow Control: Bandwidth is split according to the slowest link on the path. Right: INRPP: Bandwidth is split equally up to the bottleneck link (global fairness). Detour applies to guarantee local stability.