3.1. Scenario Description
We use
to represent an arbitrary topology, where
V is the set of ICN caching nodes and
E is the set of links between nodes. For node
i,
is its cache size, and
denotes the link between node
i and its neighbor node
j. The ICN caching scenario with an NRS is depicted in
Figure 1. Besides the aforementioned ICN caching nodes, the scenario has an NRS recording the mapping between the content name and the NAs, one or more source servers storing all contents persistently, and multiple users who continuously send requests for contents. The NRS is responsible for receiving registration messages for the content. In addition, the NRS will handle name resolution messages and respond to them with a list of the NAs of the content. This list is used by the user to further request the content. We use
C to denote the set of contents and for content
, and
represents the size of content
k.
According to the routing-by-resolution mechanism in ICN, the content will be registered to the NRS before being served. In the example of
Figure 1, when User1 wants to download the content, he or she needs to send a name resolution message for the corresponding content to the NRS, and the NRS returns an NA list of the content to User1. User1 gets the NA of the Source Server and sends a request to the Server. The Server returns the content to User1, meanwhile the on-path nodes R1 and R3 cache the content and register the content to the NRS. User2 retrieves the content following the same process. User2 first sends a name resolution message and the NRS returns a list containing the NAs of the Servers, R1 and R3. Then, User2 chooses to get the content from R1 and sends a request to R1. Finally, R1 serves the request and returns the content to User2.
For users to get contents using the NA list, there are two simple ways: applying Nearest Replica Routing (NRR [
20]) or applying random NA selection. In the first way, the user always sends a request to the nearest copy. However, in the second way, the user selects an NA at random from the NA list to send the request. We apply NRR in this paper, as the routing-by-resolution mechanism commonly sets NRR as the routing strategy.
3.2. Problem Formulation
Since the NRS enables all cached replicas in the network to provide services to any user, it is important for caching nodes to cache contents properly. The cache hit ratio represents the ability of the cache to serve requests, so it is usually used as an indicator to evaluate caching strategies. In general, a caching strategy with a higher cache hit ratio also results in lower server load and network latency. In this paper, we consider the cache hit ratio as the optimization goal. For a caching node , denotes the inflow request rate and denotes the outflow request rate. We use to denote the inflow request probability of content k in node i for , and we can easily find that . represents a boolean variable indicating whether node i caches content k. is 1 if content k is cached in node i and 0, otherwise. When contents cached in the node i serve the corresponding requests, these requests would no longer be forwarded. Thus, the relationship between and can be further expressed as . When equals 0 the cache hit ratio of node i (denoted as ) is obviously 0; when gets bigger, can be estimated as .
According to the above analysis, the cache hit ratio maximization problem can be expressed by the following equation:
Maximize:
subject to:
where
is the size of content
k and
is the size of cache equipped in node
i. In Equation (
2), the total space occupied by cached contents from node
i cannot exceed its original cache size. From Equation (
1), it is easy to find that more popular contents bring a higher cache hit ratio. To promote the cache hit ratio, an intuitive way is to cache popular contents and replace unpopular contents. Therefore, we need to choose popular contents when making content placement decisions.
As for the on-path caching strategy, a key question is how many copies need to be cached along the path. To improve the total cache hit ratio of the network, it is reasonable to place at most one copy at a time. When the popularity of the transferred content is low, it is not worth evicting popular content to cache it; on the contrary, for a particular delivery path, if the downstream node caches the content, requests for the content would not be forwarded upstream. Thus, placing more than one copy would waste the cache space of upstream nodes.
In addition, the cache hit ratio of the network is impacted by the request hit location. If the request of a popular content is hit on a Source Server, replacing unpopular content on a caching node with the popular content will directly increase the cache hit ratio. If the request is hit on a caching node, caching the popular content will not increase the total cache hit ratio, as requests for the content are just hit at different caching nodes. However, from the user’s perspective, getting content from closer caching nodes reduces more transmission latency. Therefore, the idea of caching popular contents at caching nodes closer to users has been used in many caching strategies, such as in Ref. [
13]. Based on this, we aim to design a caching strategy that makes the caching nodes cache more popular contents.
Another useful condition is that the NRS can provide information of contents, such as the number of copies in the network (the number of NAs mapped to the content). Our previous work [
14] has demonstrated that controlling the number of copies can significantly improve the network performance, since it can reduce cache redundancy and filter out unpopular contents, as well as reduce the probability of cache replacement occurring. Limiting the number of content copies can make more contents cached on the network. We consider further controlling the number of copies in ICN scenarios with the NRS to improve the performance of caching strategies.