Coordinated Forwarding and Caching in Information-Centric Networks

The concept of Information-Centric Networking (ICN) has emerged and become a significant part of the world-wide research efforts on Future Internet architectures. The principal paradigm of ICN is significantly different from the host-to-host communication model in the current Internet architecture. Instead, ICN focuses on information objects, their properties, and receiver interest in the network to achieve efficient and reliable distribution of such objects. In ICN, content caching is becoming an inherent capability of network elements such as routers. With routers being able to cache contents in ICN, it is likely that not only the content distribution costs incurred to the network but also the quality of service experienced by end users are significantly improved. Without specifying the details of content caching, the existing ICN architectures are designed to allow flexible design and implementation of new caching schemes. However, they also pose new challenges to caching schemes; in particular, it remains unclear how content caching should be provisioned (independently or collaboratively), and how it should be implemented efficiently. Many of current ICN designs adopt a hierarchical caching mechanism allowing only limited collaboration in content caching. More specifically, for a given content, caching in many ICN designs takes place only at en-route routers (i.e., routers on the paths between a requesting host and one or multiple content origins), and thus forms a hierarchical caching mechanism. An en-route router that has the requested content should directly respond with the content from its local content cache and suppress further forwarding the request to the next router in the routing hierarchy. For instance, Content-Centric Network (CCN) is an example of ICN; CCN adopts a name-based routing architecture, advocating a ``host-to-content'' communication model which differs from the ``host-to-host'' model in Internet. In CCN, where content comes from is no longer important to the requesting host. Additionally, not only en-route routers but also routers in the same administrative domain (particularly those nearby en-route routers) could have possibly cached a requested content. These observations suggest that collaborative caching beyond the current limited hierarchical mechanism is feasible and could be beneficial. Collaborative caching has drawn much attention and some have become commercially successful since more than a decade ago. This leads us to believe that collaborative caching in ICN is a key to success in that the network performance could be significantly improved by letting routers collaborate with each other. However, collaborative caching in ICN, if not well designed, could significantly increase the communication overhead. For instance, control messages exchanged among routers, as an example of such overhead, are necessary to enable collaborations. Such messages normally contain information about what contents are stored in a particular router; due to the enormously large number of distinct contents, such messages could consume a significant portion of the network bandwidth. Additionally, the extra latency of exchanging such messages may further slow down the collaborative decision making process and thus reduce the effectiveness. A naive approach to collaborative caching is to adopt a broadcast mechanism, i.e., each request is forwarded to all routers and only those with the requested content respond with the data. However, such an approach is too costly and inefficient. A key challenge to collaborative caching in ICN is how to make routers know what contents are available from other collaborative routers in an economic and efficient manner. Furthermore, since routers have knowledge about such availability information, routers should leverage it when making forwarding decisions; namely, forwarding and caching could be coordinated and collaborative to further optimize the network performance. We will go beyond the en-route caching model and propose a novel name-based distributed coordinated forwarding and caching design for ICN in this draft.

A content router with coordinated forwarding and caching is illustrated in the following figure. A new component called the Availability Info Base (AIB for short), is introduced to coordinate forwarding and caching in content routers. AIB keeps track of content availability information. More specifically, AIB can be thought of as a table, where each entry has two columns, Name and RouterID, suggesting that a given named content is available from a router. Note that we require that each router in the network should have a name and routers' names are propagated through the network via intradomain routing protocol such as OSPF. As a result, routers' names are treated in the same way as content names and put in FIB. For instance, the following figure shows an example of CCN content router architecture with coordinated forwarding and caching. The outbound face to reach Router R3 is face 3, and content /c/d is available from R3, as shown in the following figure.

+--------------------------------------------------------------------+ | Content Store Forwarding Info Base | | Name Data Name Destination List Face 0 | | +-->+-----+----+ +---> +-------+---------------+ +---+ | | | |... |... | | | ... | ... | | |----> | | |-----+----| | |-------+---------------| | | | | | |/a/b | | | | /e/f | 2 | | |〈---- | | |-----+----| | |-------+---------------| | | | | | |... |... | | | ... | ... | +---+ | | | +-----+----+ | |-------+---------------| | | | | | R3 | 3 | Face 1 | | | | |-------+---------------| +---+ | | | | | ... | ... | | |----> | | | +-------+---------------+ | | | | | Index | | |〈---- | | Ptr Type | | | | | | +---+-----+ | +---+ | | +--------| * | CS | | | | |---+-----| | | | +--------| * | PIT | | Face 2 | | | |---+-----| | +---+ | | | +-| * | AIB | | | |----> | | | |---+-----| | | | | | | | | * | FIB |----+ | |〈---- | | | +---+-----+ | | | | | +------------------+ +---+ | | | Pending Interest Table | Availability Info Base | | | Name Requesting Faces| Name Router ID Face 3 | | | +----+-------------+ +--->+-------+---------------+ +---+ | | +-->|... | ... | | ... | ... | | |----> | |----+-------------| |-------+---------------| | | | | |/e/f| 0,1 | | /c/d | R3 | | |〈---- | |----+-------------| |-------+---------------| | | | | |... | ... | | ... | ... | +---+ | | +----+-------------+ +-------+---------------+ | +--------------------------------------------------------------------+ Figure 1: Content router with coordinated forwarding and caching Each content router periodically announces the pairwise link cost and coordinated forwarding/caching related metrics via OSPF or ISIS intradomain routing protocols. Each router also measures the ranking of incoming Interests, namely, examine the received Interests from the users, and generates its local ranking sequence of the most popular contents. Each router implements the coordinated forwarding and caching mechanism, namely, a distributed mechanism to make joint decisions for forwarding and caching. Additionally, each router measures the miss rate of the interests in order to further improve the caching/forwarding efficiency. Upon receiving an Interest, a router first checks whether the content is available and fresh in its local CS. If yes, the router responds with the locally cached content. Otherwise, it looks up the Pending Interest Table (PIT), and either this Interest should not be forwarded if it is already pending in PIT, or it should be forwarded and PIT be updated accordingly. In the latter case, the router looks up AIB to check whether the content is available from other collaborative routers. If not, the Interest should be forwarded using the default policy in information-centric networks (e.g., look up the outbound face in FIB and forward to the designated face; if FIB lookup fails, use a broadcast-like approach to forward the Interest). Otherwise, the Interest should be forwarded to the designated collaborative router. In order to do so, the router needs to look up FIB to determine the outbound face to reach the designated router. Note that most likely retrieving contents from collaborative routers within an autonomous system saves a noticeable time than getting it from the origin, as the latter typically requires traversing multiple autonomous systems and multiple interdomain links.

To ease the description, we introduce the following notations. The network consists of N content routers. Each router i has a local Content Store (CS) that can cache up to Ci content objects (``contents'' for short). The maximum size of each content is u. It is a common practice that contents are chunked into pieces. Suppose that each piece fits one cache unit (i.e., the size of each piece is no greater than u). Then, the entire network can cache at most C*u of contents, where C = C1 + ... + CN. Users send requesting packets (e.g., Interest packets in CCN). We use a ranking sequence {r1, r2, ..., rC} to denote the most popular C contents, sorted in descending order of popularity. This ranking sequence can be measured in real time as routers receive Interests. All routers may not see the same distribution of content popularity, e.g., the ranking sequence {r1, r2, ..., rC} measured by different routers have a certain percentage of mismatches or shifts, refer to as the popularity inconsistency.

Each content router keeps track of the most popular C contents. The coordination should be provisioned in such a way that the contents should be optimally distributed (cached) by the N routers, whose sizes are C1, C2, ...,CN, so that the average content access cost can be minimized in the network. We denote by cost_i the cost of accessing a given content at router i. Without loss of generality, assume that after sorting, cost_1 ≤ cost_2 ≤ ... ≤ cost_N. Also, suppose the ranking sequence is {r1, r2, ...rC} in descending order of popularity. The optimal way to distributing (caching) contents (i.e., minimizes the average cost of accessing the most popular C contents in the network) is to let the more popular content be cached at a place that has a lower cost, i.e., router 1 caches r1, ..., rC1 , router 2 caches rC1+1, ..., rC1+C2, and so on (see Theorem 1 in ). An example of delay-based cost metric can be defined for CCN as follows. Let I_i denote the average number of interests received by router i and d_ij denotes the link cost of nodes i and j (d_ij becomes the cost of accessing content from the local Content Store when i = j). Such costs can correspond to either intradomain routing weights or other performance-related metrics such as distance and latency. Then, for any cache unit in router i, the average cost of accessing this content requested by users is cost_i = (I_1 * d_1i + ... + I_N * d_Ni) / (I_1 + ... + I_N). There are many ways to obtain the cost information. For instance, with the help of intradomain routing protocol, topological information is generally available to each router; each router can calculate the average cost for all collaborative routers in the network and sort all routers using these values. For any cache unit in router, the average cost of accessing a content requested by users is the weighted sum of pair-wise access costs from all routers. Access costs can correspond to either intradomain routing weights or other performance-related metrics such as distance and latency. Then, the optimal solution that minimizes the average cost of accessing the most popular contents in the network is to let the more popular content be cached at a place that has a lower cost, and the less popular contents by the router with a larger cost. Therefore, for any top popular content, each router knows not only which contents it should keep in its local Content Store, but also which collaborative router it can request this content from, if not locally available. Such availability information for the top popular contents is stored in AIB.

The coordinated forwarding and caching design is illustrated using a simple example shown in the following figure. In the example, there are three coordinated routers R1, R2 and R3. These routers can cache 10 contents in total (the size of these three caches are 3, 4, and 3, respectively). The most popular 10 contents measured by these routers are consistent. Suppose cost_i is the average cost of accessing this content requested by users for any cache unit in router i, and cost_1 >= cost_2 >= cost3. The most popular 3 contents should be cached in router R3, the next 4 contents should be cached in R2, and the next 3 contents should be cached in R1. As shown in the figure, for any incoming Interest requesting for the most popular contents, AIB tells where it should be forwarded to (the content is either available from the router's local CS or other collaborative routers).

.-------------------------------------. | Availability Info Base | | .-------------------. | | Name |a|b|c|d|e|f|g|h|i|j| | | RouterID|3|3|3|2|2|2|2|1|1|1| | | .------|-|-|-|------. | | | | | | | | | | | | CS | | | | | | +---+ | | | | | ---->| g | | | | | | |---| | | | | ------>| h | | | | | |---| | | | -------->| e | | | | |---| | ------->| ---------->| d | | | | R2 +---+ | | .-------------------------------------. | ^ V | .-------------------------------------. | | Availability Info Base | | | +-------------------+ | | | Name |a|b|c|d|e|f|g|h|i|j| | | | RouterID|3|3|3|2|2|2|2|1|1|1| | | | +--------------|-|-|+ | | | | | | | | | CS | | | | | | +---+ | | | | | | | h |〈-- | | | | | |---| | | | | | | i |〈----| | | | | |---| | | | | | j |〈------| | | | |---+ | | | R1 | | .-------------------------------------. | ^ | | V | .-------------------------------------. |------>| Availability Info Base | | +-------------------+ | | Name |a|b|c|d|e|f|g|h|i|j| | | RouterID|3|3|3|2|2|2|2|1|1|1| | | +|-|-|--------------+ | | | | | | | | | | CS | | | | | +---+ | | | | ---->| c | | | | | |---| | | | ------>| b | | | | |---| | | -------->| a | | | +---+ | | R3 | .-------------------------------------. Figure 2: A design for coordinated forwarding and caching

In practice, popularity rankings seen by different routers are more likely inconsistent. In such cases, the efficiency of content forwarding and caching will be degraded. We describe a solution that leverages the dual-segment caching design to address the inconsistent popularity ranking problem.

Inconsistency in popularity ranking happens when the ranking sequences of routers are slightly different from each other. Therefore, the knowledge of routers about the distribution of contents in the caches may be inaccurate. In this situation, when any Interest requesting comes for a content, AIB may tell a wrong destination where it should be forwarded to, resulting in cache misses and efficiency degradation. We illustrate inconsistency in popularity ranking through an example shown in the following figure. In this example, router R2's ranking sequence is slightly different from R1's and R3's. In R2's ranking sequence, the positions of content h and f are swapped and content k replaces j. As a result, router R2 caches contents {d, e, h, g}; however, routers R1 and R3 expect that R2 caches {d, e, f, g} instead. Whenever R1 and R3 forward Interests for content f to R2, such Interests have to be further forwarded towards the origin by R2 (not shown in the figure). Similarly, R2 always forwards Interests for content f and k to R1, resulting in cache misses and further forwarding.

.-------------------------------------. | Availability Info Base | | .-------------------. | | Name |a|b|c|d|e|h|g|f|i|k| | | RouterID|3|3|3|2|2|2|2|1|1|1| | | .------|-|-|-|------. | | | | | | | | | | | | CS | | | | | | +---+ | | | | | ---->| g | | | | | | |---| | | | | ------>| h | | | | | |---| | | | -------->| e | | | | |---| | ------->| ---------->| d | | | | R2 +---+ | | .-------------------------------------. | ^ | | V | .-------------------------------------. | | Availability Info Base | | | +-------------------+ | | | Name |a|b|c|d|e|f|g|h|i|j| | | | RouterID|3|3|3|2|2|2|2|1|1|1| | | | +--------------|-|-|+ | | | | | | | | | | | | | | | +---+ | | | | | | | h |〈-- | | | | | |---| | | | | | | i |〈----| | | | | |---| | | | | | j |〈------| | | | |---+ | | | R1 | | .-------------------------------------. | ^ | | | | V | .-------------------------------------. |------>| Availability Info Base | | +-------------------+ | | Name |a|b|c|d|e|f|g|h|i|j| | | RouterID|3|3|3|2|2|2|2|1|1|1| | | +|-|-|--------------+ | | | | | | | | | | CS | | | | | +---+ | | | | ---->| c | | | | | |---| | | | ------>| b | | | | |---| | | -------->| a | | | +---+ | | R3 | .-------------------------------------. Figure 3: An example of inconsistent ranking sequences

To address the above problem resulted by inconsistent popularity, a dual-segment cache design can be adopted, namely, divide a router's Content Store into two segments: the Advertised Content Store (ACS for short), which is the regular collaborative cache that is operated the same way as described in the preceding subsection assuming consistent popularity; the Complementary Content Store (CCS for short), which is the cache space used for adapting to the inconsistency of popularity distribution. The rationale behind this dual-segment design is to leverage CCS to absorb contents that are supposed to be store at a router but are missing in its ACS due to inconsistent popularity. Upon receiving an Interest, if the requested content is available locally, the router directly responds with the data. Otherwise, if the Interest comes from another collaborative router, the router forwards the Interest towards the content origin and stores the returned data into its Complementary Content Store when the data comes back; if the Interest comes from a requesting host directly, the router applies its knowledge of popularity-ranking sequence and checks whether the ranking of the requesting content is less than the cache capacity; If yes, it forwards the Interest to the collaborative router designated by the sequence; otherwise, it forwards the Interest towards the origin.

The impact of the preceding dual-segment design on the performance of coordinated forwarding and caching in content-centric networks could be subtle. On the one hand, a sufficiently large CCS is more favorable to adapt to the popularity inconsistency; and on the other hand, when the total size of the Content Store is fixed, a smaller CCS is more favorable, as the ACS could be larger to store more frequently requested contents in the network. Clearly there exist trade-offs when determining their sizes. A straightforward solution is fixed division of ACS and CCS, e.g., 90% dedicated to ACS and the remaining to CCS. However, the problem of fixed division is one size does not fit all, namely, routers may experience different levels of popularity inconsistency, and a fixed size may either over-estimate or underestimate the inconsistency level, thus resulting an inefficient use of the cache space. A distributed, self-adaptive scheme can be designed to address the above division problem; specifically, the division of ACS and CCS is adjusted based on the dynamics experienced by the content routers. The scheme is designed based on cache miss rate as the cache miss rate plays an important role in the efficiency of dual-segment collaborative caching. On the one hand, when the miss rate is low, it implies a potentially oversized CCS and thus a waste of cache space. On the other hand, when the miss rate is high, then contents supposed to be stored in a designated collaborative router are actually not stored in it, resulting in additional costs to forward Interests to the designated router and then towards the origin. Below we describe an example algorithm for adaptively adjust the cache division. Define the Locking Miss Rate (LMR for short) to characterize the maximum miss rate (corresponding to a maximum level of popularity inconsistency) that a router would like to tolerate. Every router distributively adjusts its size of CCS to make its miss rate closely approach to LMR. More specifically, a router starts with a pre-configured initial cache division, e.g., 90% for the Advertised and 10% for CCS. It then begins measuring the cache miss rate for all Interests received from other collaborative routers. We denote the measured cache miss rate by MR. The example algorithm is as follows: If MR〈=LMR, it is likely that the router experiences less popularity inconsistency than expected, we may have an oversized CCS, so the size of CCS is halved so that we increase the size of ACS to cache more contents in the network. If MR>LMR, the popularity inconsistency is likely under-estimated; therefore we should reduce the size of ACS to have a larger CCS in order for accommodating the inconsistency. Usually, it will be better to reduce the size of ACS linearly comparing with reducing the size aggressively. For example, the size of ACS can be reduced to 1/(1+MR) of the orginal ACS size.

An example of this design for router R2 in the previous example is shown in the following figures. With the single-segment design, content f, which is supposed to be cached in R2, is always missing due to the inconsistency of R2's ranking statistics. However, with the dual-segment design, R2 only advertise 3 as its cache size. As a result, an extra cache unit can be used to store the missing content f. Therefore, future Interests requesting for f forwarded from routers R1 and R3 can be fulfilled by R2.

.-----------------------------------. | Availability Info Base | | .-------------------. | | Name |a|b|c|d|e|h|g|f|i|k| | | RouterID|3|3|3|2|2|2|2|1|1|1| | | .------|-|-|-|------. | | | | | | | | | | | | CS | | | | | | .---. | | | | | -->| g | | | | | | |---| | | | | ---->| h | | | | | |---| | | | ------>| e | | | | |---| | | -------->| d | | | R2 .---. | .-----------------------------------. (a)Single segment .------------------------------------. | Availability Info Base | | .-------------------. | | Name |a|b|c|d|e|h|g|f|i|k| | | RouterID|3|3|3|2|2|2|2|1|1|1| | | .------|-|-|--------. | | | | | CS | | | | | .-----------. | | | | | | ACS CCS | | | | | | | .-. .-. | | | | | --|->|h| |f| | | | | | | |-| .-. | | | | ----|->|e| | | | | | |-| | | | R2 ------|->|d| | | | .-----------. | .------------------------------------. (b)Dual segment Figure 4: An example of Content Store Division

In this draft, we describe a distributed, popularity-guided coordinated forwarding and caching design for information-centric networks, where we introduce an Availability Information Base to allow coordination between forwarding and caching in content routers. In order to deal with popularity inconsistency in realistic networks, we also describe a self-adaptive dual-segment cache division scheme. Simulation-based evaluations demonstrate that by coordinating forwarding and caching in ICN, content access cost and cache miss rate can be significantly improved.

Guoqiang Wang 2330 Central Expy Santa Clara US Email: gq.wang AT (huawei.com) Xinwen Zhang 2330 Central Expy Santa Clara US Email: xinwen.zhang AT (huawei.com) Shuo Guo University of Minnesota Minneapolis, Minnesota 55455 USA Email: sguo AT (umn.edu) Guangyu Shi Central Research Institute, Huawei Technologies Shenzhen China Email: shiguangyu AT (huawei.com)

Security issues are not discussed in this memo.

This document makes no specific request of IANA.