IMU: A Content Replacement Policy for CCN, Based on Immature Content Selection

Abstract

In-network caching is the essential part of Content-Centric Networking (CCN). The main aim of a CCN caching module is data distribution within the network. Each CCN node can cache content according to its placement policy. Therefore, it is fully equipped to meet the requirements of future networks demands. The placement strategy decides to cache the content at the optimized location and minimize content redundancy within the network. When cache capacity is full, the content eviction policy decides which content should stay in the cache and which content should be evicted. Hence, network performance and cache hit ratio almost equally depend on the content placement and replacement policies. Content eviction policies have diverse requirements due to limited cache capacity, higher request rates, and the rapid change of cache states. Many replacement policies follow the concept of low or high popularity and data freshness for content eviction. However, when content loses its popularity after becoming very popular in a certain period, it remains in the cache space. Moreover, content is evicted from the cache space before it becomes popular. To handle the above-mentioned issue, we introduced the concept of maturity/immaturity of the content. The proposed policy, named Immature Used (IMU), finds the content maturity index by using the content arrival time and its frequency within a specific time frame. Also, it determines the maturity level through a maturity classifier. In the case of a full cache, the least immature content is evicted from the cache space. We performed extensive simulations in the simulator (Icarus) to evaluate the performance (cache hit ratio, path stretch, latency, and link load) of the proposed policy with different well-known cache replacement policies in CCN. The obtained results, with varying popularity and cache sizes, indicate that our proposed policy can achieve up to 14.31% more cache hits, 5.91% reduced latency, 3.82% improved path stretch, and 9.53% decreased link load, compared to the recently proposed technique. Moreover, the proposed policy performed significantly better compared to other baseline approaches.

1. Introduction

Due to advancements in technology, things are becoming more integrated and intelligent, leading to a rapid increase in Internet usability. Internet usage patterns demonstrate that new era applications are becoming more sensitive in bandwidth and latency. IP video traffic is expected to dominate overall IP traffic by 82% by 2022 [1], up from 74% in 2017 [2]. Internet users are not interested in the location of the storage server. Their primary interest is having Internet connectivity that assures fast and reliable retrieval of desired information. Content-centric networking (CCN) has proven to be a promising solution to meet the needs of future networks [3]. CCN naturally supports in-network caching and it attempts to respond to the requested data when a user request contains the name or identity of the desired data. CCN assigns each piece of data a unique identity and addresses data objects at the network level, in contrast to the Internet’s host-centric architecture. CCN naturally supports in-network caching and many-to-many communication [4]. When the user request contains the name or identification of the desired data object, the network attempts to respond to the request with the data object. The name can also belong to a location or a host machine. This mechanism makes CCN more general than the host-to-host communication model [5].

In-network caching provides a solution for traditional Internet architecture that works in the application layer [3]. The content of the CCN cache changes rapidly due to enormous data demands. Furthermore, CCN is a solution that works on the network layer level [6]. It allows the CCN node to cache a temporary copy of the requested content. CCN can minimize network traffic and maximize content availability by providing the desired content closer to the consumer [7]; it is difficult to decide the cache location of the content to satisfy consumer requests and improve network performance [8]. In addition, it is also important to determine which content should be removed from the cache space to accommodate new content in the cache. Improper content selection causes the degradation of network performance [9]. In-network caching faces several challenges, including limited cache storage, caching replacement and placement, caching traffic, and complex network topology [10,11].

The performance of the CCN depends on the content placement and replacement policies. The content placement policy decides the appropriate cache location of each content [1]. Hence, the node selection for content caching should be optimized to satisfy consumer requests, with minimum overhead. Due to the limited cache capacity in the node, any cached content in the cache needs to be removed to accommodate new content [12]. Content replacement policy is responsible for choosing the right content against defined criteria [13]. The network performance and cache hit ratio decreases if popular content is removed from the cache or unpopular content remains in cache for a long time [14,15,16,17].

Although cached contents at all nodes, along with the routing path, increase the network performance and cache hit ratio, it is not a practical approach due to the finite cache space. That is, if the cache space is full and new content arrives, one of the cached content needs to be removed from the cache space. However, most existing replacement policies follow the concept of the Least Frequently Used (LFU) or Least Recently Used (LRU) policy to replace the content which is not effective for CNN [18]. The newly arrived content may become popular over time due to high demand. When popular content loses its popularity, it stays in the cache due to previous popularity. Therefore, the network performance may decrease due to the overstay of previous popular content that is currently unpopular or the eviction of currently popular content. To solve this issue and improve network performance, we introduced a new concept of content maturity and immaturity to deal with the aforementioned issues. The content that loses its popularity over a specific time frame and stays in the cache for a long time is called immature content. In contrast, the content will be considered mature if it has high popularity and is also recently requested in the network within a specific time frame. Every new content is neither popular nor mature. Content should stay in the cache for some time to know its maturity level. Hence, such content is not evicted from the cache, which is yet to become popular. In addition, this concept removes content from the cache that loses its popularity after being highly popular for some time.

A content replacement policy is proposed in this work called IMU (Immaturity used). This policy removes content from the cache that is immature within a limited time frame. Therefore, most of the contents in the cache are recently used and highly popular, leading to a better cache hit ratio and network performance. The key contributions are summarized below:

• A new concept of content maturity/immaturity has been introduced to design and develop an effective content eviction policy. The proposed content eviction policy evicts the content from cache through the immature content selection to improve the cache hit ratio, latency, path stretch, and link load.
• A mechanism to calculate the maturity level of the content has been designed and developed using the content frequency and arrival time of the content.
• Icarus [19] has been used to verify the performance of the proposed policy with existing state-of-the-art content replacement policies. Subsequently, we gained substantial improvement in cache hit ratio, latency, path stretch, and link load.

The rest of this paper is organized as follows: We discuss the related work in Section 2. The proposed policy is described in Section 3, which highlights its contribution. Section 4 describes the simulation environment and parameters as well as the result analysis and discussion. Finally, the conclusion and future work are in Section 5.

2. Related Work

Content eviction policy works when the cache space is filled with content. The eviction policy provides a mechanism to replace existing contents with requested contents in the cache. The eviction policy must keep popular contents in the cache with the least processing complexity. In general, an eviction policy should have two properties. First, the eviction policy should not remove popular content from the cache. Second, it also keeps the most frequently used contents in the cache by applying some sort of priority. Several eviction policies were proposed in the past [9,19,20,21,22,23,24,25]. Some of the most popular eviction policies include First in First out (FIFO), Random Replacement (RR), Least Recently Used (LRU), Least Frequently Used (LFU), Window-LFU (W-LFU), Least Frequent Recently Used (LFRU), Popularity Prediction Caching (PPC), Network-oriented Information-centric Centrality for Efficiency (NICE), NC-SDN, and Least Fresh First (LFF). A brief description of each cache eviction policy is summarized below.

As the name suggests, FIFO replaces the content from the cache based on a first-come, first-serve basis. The content item that comes first in the cache is evicted first when there is a need for replacement [20]. It does not deal with the importance or priority of the content being replaced by the new content. RR policy randomly selects existing content from the cache to replace it with new content [21]. However, it has no particular criteria for content selection from the cache. LRU is a typical policy that has extensive usage in cache eviction [22]. LRU keeps track of the usage of each content in cache. When the replacement request is received, LRU checks the requested content in the cache. If this requested content is not already in the cache, it evicts the least recently used content to accommodate the requested content. Therefore, LRU is simple to implement and has less computational delay.. But on the other side, LRU does not consider the content frequency (dynamic changes of popularity over time), which plays a significant role in network performance and the cache hit ratio.

LFU keeps track of the frequency of each content in the cache [23]. LFU serves to store the most popular content in the cache statically. It keeps a counter of how many times the content is requested. Whenever a request is received for content, the counter value is incremented by one. When the cache space is full and there is a requirement to replace content, the content with the least counter value is selected to evict. LFU keeps popular content in the cache, but it requires a very high processing time that leads to performance degradation in CCN. Further, when content that has been popular for some time loses its popularity, it stays in the cache, causing severe performance losses. W-LFU is an eviction policy that uses a limited number of access requests over a time window [24]. This technique tries to solve the LFU problem by keeping the history of the requested contents. This record of history is referred to as a window. The size of this window is directly proportional to the total number of contents and the cache size in the network. This policy demonstrates considerable improvements, but it fails to evict suitable content in the case of bursty requests. Moreover, this policy only observes a small portion of the cache, making it impractical for full cache capacity.

LFRU is the combination of LRU and LFU [25]. According to the LFRU eviction policy, a cache divides into unprivileged and privileged partitions. The privileged partition is known as a protected partition. The popular content is pushed into the privileged partition. If the privileged partition is fully occupied and there is no more space available to store content, the LFRU ensures that the content is evicted from the unprivileged partition and that content is transferred from the privileged to the unprivileged partition. Filtering out the locally popular contents and placing the popular contents in the privileged partition are the key features of the LFRU eviction policy. This policy demonstrates considerable improvements, but it fails to evict suitable content in the case of bursty requests. Moreover, this technique also requires a large processing time to manage partitions.

PPC is a chunk-level in-network caching eviction policy [26]. It is capable of predicting the popularity of the video chunks. PPC stores content based on the popularity that it predicts. On the other side, the contents that have the least popular prediction are evicted out. This eviction scheme is also termed the Assist-predict model. It is based on the request information of the neighboring chunks. It also predicts future popularity by using past experience with the popularity of the content. If the popularity of the new content is less than the former popularity, the newly incoming chunk does not cache. Otherwise, it evicts the future content based on popular prediction. This model-based prediction technique works well but fails to predict properly against frequently changing requests. Moreover, this policy leads to high network load due to control signaling overhead and high computational workload. The NC-SDN eviction model was introduced as a cache eviction algorithm that relies on SDN (software-defined networking) [16]. NC-SDN model uses three arguments. First, it calculates data popularity; second, it comes to know the location of cache management switches; third, it facilitates cooperation among different nodes in the network. When the cache is fully occupied, it checks the popularity of each content and replaces the least popular content with new content. Although the replacement technique is straightforward, the control traffic and exchange of information between the switches are very high, leading to performance losses.

LFF is a content replacement policy that predicts the time of the next event [27]. Based on the prediction, it controls the residual life of retrieved content. When the cache capacity is full, this policy measures the time for which the content is considered invalid. In addition, this policy checks whether the source has been updated after retrieving the content to check the validity of each content. This policy ignores the high replacement rate in the central node and does excessive computing, making it impractical for large CCN. NICE has been introduced as a new metric for cache management in ICN [28]. This policy uses a method that computes the centrality. Centralization is used in the replacement phase to manage cache contents. This method is based on the number of caches instead of the number of contents. Content is replaced when the NICE value is high, as the contents move from one cache to the other due to the centrality of the content. However, it causes high network load and computational complexity.

Most of the replacement strategies [27,28,29,30,31,32,33,34] on CCN focus on content frequency, popularity, and time freshness. These policies ignore the concept of content immaturity in content eviction; it is neither popular nor mature when new content is cached in the cache. We need some time to evaluate whether this content has become popular or not. If that content is removed from the cache, the consumer has to retrieve it from the publisher, which affects network performance. Therefore, content may become popular for a certain period, and then its popularity starts decreasing [29]; if that content is not removed from the cache, network performance and the cache hit ratio also degrade. When the cache space is low and the popularity of the content changes frequently, it becomes challenging for the content eviction policy to decide which content should be evicted from the cache space. A content eviction policy should be able to provide equal opportunities for each content to become mature. Therefore, we introduced a concept of maturity and immaturity of the content, and our proposed cache replacement policy uses this concept to accommodate the request of new content. The proposed policy evicts immature content to solve content popularity issues.

3. Proposed Content Replacement Policy

Content replacement policy is an integral part of CCN cache management. The nodes in CCN need to free up space over time, due to limited cache space, so that new contents are cached. It is a crucial decision to evict content from the cache, which, in turn, increases or decreases network performance and the cache hit ratio. Numerous content replacement policies decide to evict content from the cache using various criteria, such as time in the cache, frequency, popularity, and node centralization. These policies do not use content immaturity for eviction. The proposed policy selects immature content from the cache that stays for a long time in the cache and has a lower frequency in a particular time window. Thus, the proposed policy avoids unnecessary content occupation in the cache space. Due to immature content eviction, network nodes contain more requested content within the cache space. Therefore, more customer interests are satisfied within the network.

The proposed technique determines the mature/immature contents. Algorithm 1 elaborates the procedure to label a content, ${\mathrm{s}}_i$ is mature or immature. The proposed policy keeps track of each content’s arrival time and frequency at each node. The current time and the frequency of the node ${\mathrm{s}}_i$ is denoted by ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$ and ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ respectively. The proposed technique calculates the content period, ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_i}$, with the help of content frequency, ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$, and content arrival time, ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$. Therefore, it determines the duration of the content ${\mathrm{s}}_i$ in the cache space. Then, the proposed policy calculates the maturity index ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$ by dividing the frequency of the content ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ and content period ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_i}$. The maturity classifier ${\text{Ϻ}}_{\text{Ƚ}}$ is calculated using the median of maturity indexes ${\text{Ϻ}}_{\text{Ƚ}}\leftarrow Median\left({\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_n}\right)$. Content ${\mathrm{s}}_i$ whose maturity index ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$ exceeds the value of ${\text{Ϻ}}_{\text{Ƚ}}$ is classified as mature content; otherwise, it is immature content. The median is used for finding the relevant mean value of the maturity index ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$, because it is not affected by lower or extreme high set values. Thus, this provides a fair value to the maturity classifier ${\text{Ϻ}}_{\text{Ƚ}}$.

Algorithm 1: Determine the mature and immature content.

Input: Suppose $\mathrm{S} \in \left\{{\mathrm{s}}_1,{\mathrm{s}}_2,{\mathrm{s}}_3,\dots ,{\mathrm{s}}_n\right\} \mathrm{is} \mathrm{set} \mathrm{of} \mathrm{contents}$.   Output: Categorization of contents.   ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$   is the arrival time of ith content.   ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$   is the frequency of ith content.   $W_{T }$   is the size of the time window.   ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_i}$   is the time period of ith content.   ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$  is the maturity index of ith content.   ${\text{Ϻ}}_{\text{Ƚ}}$    is the maturity classifier.   1. for $i=1 : n$       ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_i}\leftarrow W_{T }-{\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$     ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}\leftarrow {\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}/{\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_i}$   2. ${\text{Ϻ}}_{\text{Ƚ}}\leftarrow Median\left({\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_n}\right)$   3. for $i=1 : n$       if   ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$ >= ${\text{Ϻ}}_{\text{Ƚ}}$            ${\mathrm{s}}_i$ is mature      else         ${\mathrm{s}}_i$ is immature

Algorithm 2 describes the next part of our proposed policy. When a node $v$ receives an interest packet for content ${\mathrm{s}}_i$, and the time window has not expired, then the proposed policy finds the requested content ${\mathrm{s}}_i$ in the local cache. In the case of a cache hit, the proposed policy increments the frequency of content ${\mathrm{s}}_i$ by one and associates a new arrival time ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$. Moreover, node $v$ discards the interest packet from PIT and replies through the data packet to the requested consumer. Otherwise, a cache miss means that the requested content ${\mathrm{s}}_i$ is being cached for the first time in CS. Thus, its frequency ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ is one and it is associated with the current timestamp ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$. When the cache is full, it selects content ${\mathrm{s}}_k$ with a minimum value of the maturity index ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$ and evicts it from the cache space. Then, the proposed technique checks the time window $W_{T }$; if $W_{T }$ is expired, then the frequency of all content ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_n}$ is set to one, and the previously associated timestamp ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_n}$ remains the same.

Algorithm 2: IMU Replacement Policy.

Input: Request for a content ${\mathrm{s}}_i$ at node v Output: Content selection for replacement of newly arrived content   1. if $W_{T }$ is not expired     check local cache      if cache hit        ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ ← ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ $+$ 1        ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$ ← current time      else if cahe_size == full        ${\mathrm{s}}_k$ ← select the content with min ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$         evict ${\mathrm{s}}_k$         place ${\mathrm{s}}_i$ in cache        ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ ← $1$        ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$ ← current time       else        place ${\mathrm{s}}_i$ in cache         ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ ← $1$        ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$ ← current time   2. else      for each ${\mathrm{s}}_i$         ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ ← $1$      Update $W_{T }$      go to step 1

For simplicity, we assume that all the CCN based routers (node) have the same cache sizes, cached content, and discrete instants of time for interests to arrive. CS is the local cache size, and the window size is denoted by $W_{T }$. There are some events related to content ${\mathrm{s}}_i$, including received interest packet, received data packet, reply data packet, forward interest packet, cached content, eviction from the cache, and look-up content in local CS. The received interest packet (RIP), received data packet (RDP), reply data packet (REDP), forward interest packet (FIP), cached content (CC), eviction from the cache (EC), and look-up content (LU) are denoted by ${\text{Ř}}_{s_{ip}}$, ${\text{Ŕ}}_{s_{dp}}$, ${\text{Ȑ}}_{s_{edp}}$, ${\text{Ḟ}}_{s_{ip}}$, ${\text{Ḉ}}_s$, ${\text{Ѐ}}_s$ and ${\text{Ĺ}}_s$, respectively. These notations are helpful to understand the whole process of the proposed policy. For example, initially, we assumed the value of cache space (CS) = 6, $W_{T }$ = 4 s, t = [1, 2, 3, 4, …, 13], $\mathrm{S}$ ∈ {A, B, C, D, E, F, G, H, I}, as presented in Figure 1.

The consumer’s requested content (RC) is in the same sequence, window size, and cache space illustrated in Figure 1. The colors indicate three caching processes: cached, hit, and evicted content from the cache. With the help of these colors, we can easily understand the new entry in our tables and variations in the values.

We assume that the cache of a node is empty. The detailed caching process at t = 1 to t = 4 is expressed in

Table 1. Caching process at t = 1 to t = 4.

Time t	RC ${\mathbf{s}}_{\mathit{i}}$	RIP ${\mathbf{Ř}}_{{\mathbf{s}}_{\mathit{i}\mathit{p}}}$	LU ${\mathbf{Ĺ}}_{\mathbf{s}}$	FIP ${\mathbf{Ḟ}}_{{\mathbf{s}}_{\mathit{i}\mathit{p}}}$	REDP ${\mathbf{Ȑ}}_{{\mathbf{s}}_{\mathit{e}\mathit{d}\mathit{p}}}$	RDP ${\mathbf{Ŕ}}_{{\mathbf{s}}_{\mathit{d}\mathit{p}}}$	CC ${\mathbf{Ḉ}}_{\mathbf{s}}$	EC ${\mathbf{Ѐ}}_{\mathbf{s}}$
1	A	${\text{Ř}}_{A_{ip}}$ (1)	${\text{Ĺ}}_A$ (2)	${\text{Ḟ}}_{A_{ip}}$ (3)	${\text{Ȑ}}_{A_{edp}}$ (4)	${\text{Ŕ}}_{A_{dp}}$ (5)	${\text{Ḉ}}_A$ (6)
2	B	${\text{Ř}}_{B_{ip}}$ (1)	${\text{Ĺ}}_B$ (2)	${\text{Ḟ}}_{B_{ip}}$ (3)	${\text{Ȑ}}_{B_{edp}}$ (4)	${\text{Ŕ}}_{B_{dp}}$ (5)	${\text{Ḉ}}_B$ (6)
3	C	${\text{Ř}}_{C_{ip}}$ (1)	${\text{Ĺ}}_C$ (2)	${\text{Ḟ}}_{C_{ip}}$ (3)	${\text{Ȑ}}_{C_{edp}}$ (4)	${\text{Ŕ}}_{B_{dp}}$ (5)	${\text{Ḉ}}_C$ (6)
4	A	${\text{Ř}}_{A_{ip}}$ (1)	${\text{Ĺ}}_A$ (2)		${\text{Ȑ}}_{A_{edp}}$ (3)

, and

Table 2. IMU process at t = 1 to t = 4.

Time	${\mathbf{s}}_{\mathit{i}}$	${\mathbf{\text{Ʈ}}}_{\mathit{c}\mathbf{\text{ŕ}},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ƒ}}_{\mathbf{č},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ţ}}_{\mathbf{ƿ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ϻ}}_{\mathit{c}\mathbf{Ї},{\mathbf{s}}_{\mathit{i}}}$
t = 1	A	1	1	4	0.25
t = 2	A	1	1	4	0.25
	B	2	1	3	0.33
t = 3	A	1	1	4	0.25
	B	2	1	3	0.33
	C	3	1	2	0.50
t = 4	A	4	2	1	2.00
	B	2	1	3	0.33
	C	3	1	2	0.50

also maps the IMU process with values. Moreover, we see the effect of values after the window $W_{T }$ is not expired. The router receives an interest packet for content A ${\text{Ř}}_{A_{ip}}$ but does not find that content in its CS after look-up ${\text{Ĺ}}_A$, then routers the same interest packet forwards ${\text{Ḟ}}_{A_{ip}}$ to the next router. The next router has A content and responds through the data packet ${\text{Ȑ}}_{A_{edp}}$, from which it receives the packet of interest. Furthermore, the router received A data packet ${\text{Ŕ}}_{A_{dp}}$ is then cached ${\text{Ḉ}}_A$ in CS, along with values ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_A}$ = 1, ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_A}$ = 1, ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_A}$ = 4, and ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_A}$ = 0.25. This process will be the same for content B and C. When a hit occurs at t = 4, then the values of ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_A}$ = 4, ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_A}$ = 2, ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_A}$ = 1, and ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_A}$ = 2. Furthermore, window $W_{T }$ has expired at the same t = 4, but the cache space is not yet full. Then, the router receives an interest packet for content A ${\text{Ř}}_{A_{ip}}$. The hit occurred at t = 4 and changed the values of values ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_A}$ = 4, ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_A}$ = 2, ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_A}$ = 1, and ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_A}$ = 2.00.

Table 3. Caching process at t = 5 to t = 8.

Time t	RC ${\mathbf{s}}_{\mathit{i}}$	RIP ${\mathbf{Ř}}_{{\mathit{s}}_{\mathit{i}\mathit{p}}}$	LU ${\mathbf{Ĺ}}_{\mathit{s}}$	FIP ${\mathbf{Ḟ}}_{{\mathit{s}}_{\mathit{i}\mathit{p}}}$	REDP ${\mathbf{Ȑ}}_{{\mathit{s}}_{\mathit{e}\mathit{d}\mathit{p}}}$	RDP ${\mathbf{Ŕ}}_{{\mathit{s}}_{\mathit{d}\mathit{p}}}$	CC ${\mathbf{Ḉ}}_{\mathit{s}}$	EC ${\mathbf{Ѐ}}_{\mathit{s}}$
5	D	${\text{Ř}}_{D_{ip}}$ (1)	${\text{Ĺ}}_D$ (2)	${\text{Ḟ}}_{D_{ip}}$ (3)	${\text{Ȑ}}_{D_{edp}}$ (4)	${\text{Ŕ}}_{D_{dp}}$ (5)	${\text{Ḉ}}_D$ (6)
6	B	${\text{Ř}}_{B_{ip}}$ (1)	${\text{Ĺ}}_B$ (2)		${\text{Ȑ}}_{B_{edp}}$ (3)
7	E	${\text{Ř}}_{E_{ip}}$ (1)	${\text{Ĺ}}_E$ (2)	${\text{Ḟ}}_{E_{ip}}$ (3)	${\text{Ȑ}}_{E_{edp}}$ (4)	${\text{Ŕ}}_{E_{dp}}$ (5)	${\text{Ḉ}}_E$ (6)
8	F	${\text{Ř}}_{F_{ip}}$ (1)	${\text{Ĺ}}_F$ (2)	${\text{Ḟ}}_{F_{ip}}$ (3)	${\text{Ȑ}}_{F_{edp}}$ (4)	${\text{Ŕ}}_{F_{dp}}$ (5)	${\text{Ḉ}}_F$ (6)

describes the detailed caching process at t = 5 to t = 8, and

Table 4. IMU process at t = 5 to t = 8.

Time	${\mathbf{s}}_{\mathit{i}}$	${\mathbf{Ʈ}}_{\mathit{c}\mathbf{ŕ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ƒ}}_{\mathbf{č},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ţ}}_{\text{ƿ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ϻ}}_{\mathit{c}\mathbf{Ї},{\mathbf{s}}_{\mathit{i}}}$	Time	${\mathbf{s}}_{\mathit{i}}$	${\mathbf{Ʈ}}_{\mathit{c}\mathbf{ŕ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ƒ}}_{\mathbf{č},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ţ}}_{\text{ƿ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ϻ}}_{\mathit{c}\mathbf{Ї},{\mathbf{s}}_{\mathit{i}}}$
t = 5	A	4	1	5	0.20	t = 7	B	6	2	3	0.67
	B	2	1	7	0.14		A	4	1	5	0.20
	C	3	1	6	0.17		C	3	1	6	0.17
	D	5	1	4	0.25		D	5	1	4	0.25
t = 6	B	6	2	3	0.67		E	7	1	2	0.50
	A	4	1	5	0.20	t = 8	B	6	2	3	0.67
	C	3	1	6	0.17		A	4	1	5	0.20
	D	5	1	4	0.25		C	3	1	6	0.17
							D	5	1	4	0.25
							E	7	1	2	0.50
							F	8	1	1	1.00

also maps the IMU process with values. Table 4 demonstrates that the new window $W_{T }$ starts at t = 5, and that all the values of ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ become 1 and retain all the values of ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$. Content D has cached ${\text{Ḉ}}_D$ at t = 5 and displays the values of ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_D}$ = 1, ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_D}$ = 5, ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_D}$ = 4, and ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_D}$ = 0.25 in Table 4. Furthermore, at this stage, cache space CS = 4. After the hit occurs at t = 6, the values of ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_D}$ = 6, ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_D}$ = 2, ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_D}$ = 3, and ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_D}$ = 0.67 have changed. New contents are cached at t = 7 and t = 8, ${\text{Ḉ}}_E$ and ${\text{Ḉ}}_F,$ respectively.

Content E and F have cached ${\text{Ḉ}}_E$ and ${\text{Ḉ}}_F,$ respectively, at t = 6 and t = 7, and the new values are presented in Table 4. We see that the caching process is displayed step by step in Table 3, and the numbers are associated with each process to illustrate the sequence of this process.

Table 5. Caching process at t = 9 to t = 12.

Time t	RC ${\mathbf{s}}_{\mathit{i}}$	RIP ${\mathbf{Ř}}_{{\mathit{s}}_{\mathit{i}\mathit{p}}}$	LU ${\mathbf{Ĺ}}_{\mathit{s}}$	FIP ${\mathbf{Ḟ}}_{{\mathit{s}}_{\mathit{i}\mathit{p}}}$	REDP ${\mathbf{Ȑ}}_{{\mathit{s}}_{\mathit{e}\mathit{d}\mathit{p}}}$	RDP ${\mathbf{Ŕ}}_{{\mathit{s}}_{\mathit{d}\mathit{p}}}$	CC ${\mathbf{Ḉ}}_{\mathit{s}}$	EC ${\mathbf{Ѐ}}_{\mathit{s}}$
9	G	${\text{Ř}}_{G_{ip}}$ (1)	${\text{Ĺ}}_G$ (2)	${\text{Ḟ}}_{G_{ip}}$ (3)	${\text{Ȑ}}_{G_{edp}}$ (4)	${\text{Ŕ}}_{G_{dp}}$ (5)	${\text{Ḉ}}_G$ (7)	${Ѐ}_C$ (6)
10	H	${\text{Ř}}_{H_{ip}}$ (1)	${\text{Ĺ}}_H$ (2)	${\text{Ḟ}}_{H_{ip}}$ (3)	${\text{Ȑ}}_{H_{edp}}$ (4)	${\text{Ŕ}}_{H_{dp}}$ (5)	${\text{Ḉ}}_H$ (7)	${Ѐ}_A$ (6)
11	E	${\text{Ř}}_{E_{ip}}$ (1)	${\text{Ĺ}}_E$ (2)		${\text{Ȑ}}_{E_{edp}}$ (3)
12	G	${\text{Ř}}_{G_{ip}}$ (1)	${\text{Ĺ}}_G$ (2)		${\text{Ȑ}}_{G_{edp}}$ (3)

reflects caching events from t = 9 to t = 12. At t = 9, the router receives an interest packet of G ${\text{Ř}}_{G_{ip}}$. After the look-up ${\text{Ĺ}}_G$ content is not found in CS, the interest packet is forwarded ${\text{Ḟ}}_{G_{ip}}$ to the next router. This time, CS is full when it receives the ${\text{Ŕ}}_{G_{dp}}$ data packet. Now, we find the lowest ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_C}$ = 0.10 value and remove that content ${Ѐ}_C$ from CS. Therefore, it caches the new content ${\text{Ḉ}}_G$ with the associated values of ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_G}$ = 9, ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_G}$ = 1, ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_G}$ = 4, and ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_G}$ = 0.25 in the CS. We can observe in

Table 6. IMU process at t = 9 to t = 12.

Time	${\mathbf{s}}_{\mathit{i}}$	${\mathbf{Ʈ}}_{\mathit{c}\mathbf{ŕ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ƒ}}_{\mathbf{č},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ţ}}_{\text{ƿ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ϻ}}_{\mathit{c}\mathbf{Ї},{\mathbf{s}}_{\mathit{i}}}$	Time	${\mathbf{s}}_{\mathit{i}}$	${\mathbf{Ʈ}}_{\mathit{c}\mathbf{ŕ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ƒ}}_{\mathbf{č},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ţ}}_{\text{ƿ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ϻ}}_{\mathit{c}\mathbf{Ї},{\mathbf{s}}_{\mathit{i}}}$
t = 9	B	6	1	7	0.14	t = 11	E	11	2	2	1.00
	A	4	1	9	0.11		B	6	1	7	0.14
	C	3	1	10	0.10		D	5	1	8	0.13
	D	5	1	8	0.13		F	8	1	5	0.20
	E	7	1	6	0.17		G	9	1	4	0.25
	F	8	1	5	0.20		H	10	1	3	0.33
	G	9	1	4	0.25	t = 12	G	12	2	1	2.00
t = 10	B	6	1	7	0.14		E	11	2	2	1.00
	A	4	1	9	0.11		B	6	1	7	0.14
	D	5	1	8	0.13		D	5	1	8	0.13
	E	7	1	6	0.17		F	8	1	5	0.20
	F	8	1	5	0.20		H	10	1	3	0.33
	G	9	1	4	0.25
	H	10	1	3	0.33

how the IMU works when the memory is full and new content arrives simultaneously.

We repeat the same process at t = 10 for content H. The hit occurs at t = 11, and t = 12 updates the values of ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_E}$, ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_E}$, ${\text{Ţ}}_{\text{ƿ},{\mathrm{s}}_E},$ and ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_E}$, as illustrated in Table 6. The hit occurred at t = 11 and t = 12 for requested contents E and G, respectively. Table 5 illustrates that the minimum caching process and forwarding operations have been minimized when the hit occurs.

Table 7. Caching process at t = 13.

Time t	RC ${\mathbf{s}}_{\mathit{i}}$	RIP ${\mathbf{Ř}}_{{\mathit{s}}_{\mathit{i}\mathit{p}}}$	LU ${\mathbf{Ĺ}}_{\mathit{s}}$	FIP ${\mathbf{Ḟ}}_{{\mathit{s}}_{\mathit{i}\mathit{p}}}$	REDP ${\mathbf{Ȑ}}_{{\mathit{s}}_{\mathit{e}\mathit{d}\mathit{p}}}$	RDP ${\mathbf{Ŕ}}_{{\mathit{s}}_{\mathit{d}\mathit{p}}}$	CC ${\mathbf{Ḉ}}_{\mathit{s}}$	EC ${\mathbf{Ѐ}}_{\mathit{s}}$
13	I	${\text{Ř}}_{I_{ip}}$ (1)	${\text{Ĺ}}_I$ (2)	${\text{Ḟ}}_{I_{ip}}$ (3)	${\text{Ȑ}}_{I_{edp}}$ (4)	${\text{Ŕ}}_{I_{dp}}$ (5)	${\text{Ḉ}}_I$ (7)	${Ѐ}_D$ (6)

describes the detailed process of caching at t = 13. The cache space CS is full, and the time window $W_{T }$ has expired;

Table 8. IMU process at t = 13.

Time	${\mathbf{s}}_{\mathit{i}}$	${\mathbf{Ʈ}}_{\mathit{c}\mathbf{ŕ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ƒ}}_{\mathbf{č},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ţ}}_{\text{ƿ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ϻ}}_{\mathit{c}\mathbf{Ї},{\mathbf{s}}_{\mathit{i}}}$	Time	${\mathbf{s}}_{\mathit{i}}$	${\mathbf{Ʈ}}_{\mathit{c}\mathbf{ŕ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ƒ}}_{\mathbf{č},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ţ}}_{\text{ƿ},{\mathbf{s}}_{\mathit{i}}}$	${\mathbf{Ϻ}}_{\mathit{c}\mathbf{Ї},{\mathbf{s}}_{\mathit{i}}}$
t = 13	G	12	1	5	0.20		F	8	1	9	0.11
	E	11	1	6	0.17		H	10	1	7	0.14
	B	6	1	11	0.10		I	13	1	4	0.25
	D	5	1	12	0.08

demonstrates that when the new time window starts, all the values of ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ become one (1) and retain the values of ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$. The exact process that was performed at t = 9 and t = 10 is repeated at t = 13. The IMU used the ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$ and ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ for calculating the maturity index ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$ of the content ${\mathrm{s}}_i$. This value indicates the maturity of the content with the specific time window $W_{T }$.

The tables demonstrate that the lower value of a content maturity index ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$ represents a longer stay in the cache space, with a lower frequency (popularity) over a particular time frame $W_{T }$. Therefore, this content is evicted from the cache when the cache space is full. It takes some time to define the maturity/immaturity of new cached content. Therefore, the content should not be evicted without checking the level of a content maturity index; the tables indicate that the maturity index value of new cached content is greater than others. Content that has become popular over time, but loses its popularity, has a higher frequency than other content. Therefore, this kind of content stays in CS for a long time and wastes cache space. However, the window $W_{T }$ is used to equalize the frequency of all contents after a specific time, and immature content is selected from the maturity index ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$ to evict content from the CS. The proposed policy has significantly improved the cache hit ratio, bandwidth usage, latency, and path stretch.

4. Performance Evaluation

We performed a simulation in the GEANT network topology using the Icarus [13] simulator, to evaluate the performance of our policy. The GEANT topology consists of 40 nodes and 60 edges. The cache capacity of each node in the network is the same and ranges between 4% to 20% of the total content population. We used warm-up requests to settle caches before running the actual experiment, to minimize experimental errors. The cache warm-up requests are 40,000 and measured requests are also 40,000. We also used measured requests for performance evaluation. Zipf’s law is used to distribute the popularity of the content and popularity distribution of the exponent alpha ($\mathsf{\alpha }$) $\in$ [0.6, 0.8, 1.0] used in our simulation. For fair comparison with state-of-the-art replacement policies, the popularity of requested contents follows a Zipf distribution with a parameter ranging from 0.6 to 1.0, as presented in [10]. The lower and higher values indicate a low and high correlation between content requests [30]. The parameters of our simulation setup are mentioned in

Table 9. Simulation Parameters.

Parameters	Value
Warm-up Requests	40,000
Measured Requests	40,000
Model of Popularity	0.6, 0.8, 1.0
Total Contents	100,000
Cache Capacity	4–20%
Consumer Request Rate	1.0 request/s
Placement Policy	LCE, CL4M, ProbCache, LCD, opt-Cache
Topology	GEANT

.

The obtained results have been compared with state-of-the-art content replacement policies, including LRU, LFU, FIFO, and LFRU. To check the effectiveness of our approach, we compared popular cache placement policies, including Leave Copy Everywhere (LCE) [27], Cache Less for More (CL4M) [31], ProbCache [32], Leave Copy Down (LCD) [33], and opt-Cache [10], with our proposed replacement policy (IMU). These placement policies indicate the more redundant data to less redundant data in the network, respectively [10]. These placement policies indicate the more redundant data to less redundant data in the network. These results prove the effectiveness of our proposed technique with different cache sizes and populations, using various performance metrics such as cache hit ratio, latency, link load, and path stretch. These performance metrics are compared one by one, as explained below.

4.1. Cache Hit Ratio

The cache hit ratio is an essential metric for evaluating the performance of CCN cache. It identifies the response to network cache storage, in which content is cached locally within a specific time frame. Two terms are important in the cache hit ratio. The first is the cache hit (requested content is found from the cache), and the second is the cache miss (unlike cache hit). When content is available in the cache, the content request does not forward to the publisher. Therefore, a higher hit ratio indicates good cache performance and represents low bandwidth utilization, reduction in latency, and low server load. The cache hit ratio is defined as follows:

$$Hit Ratio=\frac{Cach{e}_{hits}}{Cach{e}_{hits}+Serve{r}_{hits}}$$

(1)

Our proposed strategy, IMU, compared to existing well-known replacement strategies in terms of the cache hit ratio. We have extracted the results from low to high popularity and different cache sizes. We first comment that content eviction policies behave the same under different caching strategies. Regardless of the content eviction policy, we observe in Figure 2 that the opt_cache performs best and the LCE performs the worst in terms of the cache hit ratio. Moreover, different eviction policies affect the performance of the cache hit ratio.

Figure 2 illustrates that the IMU’s performance is better than the existing replacement strategies; this is because the IMU not only considers the time ${\text{Ʈ}}_{c\text{ŕ},{\mathrm{s}}_i}$ but also the frequency ${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$ of the requested content within the specific period $W_{T }$. When the $W_{T }$ is expired, then all the ${\text{Ƒ}}_{\text{č},s_i}$ initialize to their starting frequency (${\text{Ƒ}}_{\text{č},{\mathrm{s}}_i}$= 1). Moreover, it helps to evict content from the cache space whose popularity increases for a while and decreases shortly. When the cache is full, it is evicted from the cache after selecting the least value of the maturity index ${\text{Ϻ}}_{c\text{Ї},{\mathrm{s}}_i}$. The advantage of immature content eviction from the cache is that most of the content is mature, which leads to a higher cache hit ratio.

We observed that FIFO underperformed because contents are removed from the cache in the same order in which they were cached, regardless of how many times they were previously accessed. Besides, increasing cache space and similar content requests improve FIFO’s performance because the content stays in the cache for a longer period, which increases the chances of increasing the cache hit ratio. LFU performs better than LRU when the cache size is large and the content is repeatedly requested because LFU considers the frequency of the requested content, while LRU does not. Moreover, LFU caches popular content and evicts unpopular content from the cache. Besides, contents are often evicted from the cache when the cache size is small. However, LFU displays low performance in small cache sizes. LFRU has better performance due to the coupling of LRU and LFU; however, when the content request rate is minimum from the maximum normalized request rate, the content is evicted from the unprivileged partition. Therefore, the new content is cached in the unprivileged partition. Besides, if the content request rate is higher than the maximum normalized request rate, it chooses the least recent content from the privileged partition and pushes that content into the unprivileged partition. Hence, new content is cached in the privileged partition and hit counter associated with each partition. However, content that loses popularity stays in the unprivileged partition for a long time due to its high frequency. IMU outperformed FIFO, LRU, LFU, and LFRU in terms of the cache hit ratio by 48.33%, 30.07%, 26.34%, and 14.31%, respectively.

The percentage (%) of IMU performance in different popularities, and low to high cache sizes with different content placement strategies, is presented in

Table 10. IMU cache hit ratio percentage improvement.

α	Cache Size	Placement	FIFO (%)	LRU (%)	LFU (%)	LFRU (%)
0.6	4% to 20%	LCE	320.35	133.19	121.34	64.43
0.6		CL4M	64.17	52.41	41.74	20.14
0.6		ProbCache	38.71	35.01	32.35	16.53
0.6		LCD	56.49	31.90	26.71	14.37
0.6		opt-Cache	48.84	40.46	33.82	18.57
0.8	4% to 20%	LCE	47.34	36.94	27.08	17.86
0.8		CL4M	27.84	25.22	18.72	12.93
0.8		ProbCache	17.64	14.11	11.70	6.38
0.8		LCD	20.15	14.08	13.66	6.53
0.8		opt-Cache	22.30	17.98	17.12	9.48
1.0	4% to 20%	LCE	25.60	22.04	21.29	14.05
1.0		CL4M	11.47	9.76	9.24	5.35
1.0		ProbCache	7.56	6.21	6.38	1.98
1.0		LCD	7.49	4.96	6.82	2.59
1.0		opt-Cache	9.02	6.74	7.21	3.46

. We observed that IMU is outperformed with low popularity because, if such content is popular for some time but its popularity decreases with time and its frequency is high, then IMU evicts this content from the cache space. When the cache space is low and the popularity of the content changes frequently, it becomes very difficult for the content eviction policy to decide which content should be removed from the cache space. Hence, the IMU policy evicts immature content from the cache space and gives each content an equal opportunity to define its maturity/immaturity level. Such content is not removed from the cache space that is gaining popularity.

4.2. Path Stretch (Hop Count)

Path stretch indicates the distance traveled to the content provider by the consumer’s interest. The value of the path stretch is low when the consumer’s interest packet is found from the routing path. Therefore, the better content replacement policy identifies content that users are interested in and that is mature. Such content should not be evicted from the cache. If such content is evicted from the cache, the publisher’s load and bandwidth utilization will be high. Therefore, a better content replacement strategy should be to minimize the hops between the consumer and the publisher. Path stretch is defined as follows:

$$Path Stretch=\frac{{{\displaystyle \sum }}_{i=1}^{n}Hop-Traveled}{{{\displaystyle \sum }}_{i=1}^{n}THop-Hop}$$

(2)

where ${{\displaystyle \sum }}_{i=1}^{n}Hop-Traveled$ is the number of hops between the consumer and publisher nodes covered by consumer interest. The value ${{\displaystyle \sum }}_{i=1}^{n}THop-Hop$ denotes the total number of hops between the consumer and the provider. $n$ represent the total number of generated interests for specific content.

Figure 3 illustrates that the IMU’s performance in terms of path stretch is better than other existing replacement policies. The placement strategy chooses the location of the cache, which may reduce the number of hops. IMU removes content that has been in the cache for a long time but has not matured. Therefore, when immature content is removed from the cache and new content is cached so that the consumer’s requested content is available nearby, the request is not forward to the publisher. However, cached content on nearby routers is mostly popular or close to being popular.

FIFO, LRU, and LFU represent the high path stretch due to content selection for eviction based on a single factor. FIFO content is evicted in the order in which it was cached. However, no matter how many times the content has been accessed, the timeline of popular and unpopular contents in FIFO will be the same, which increases the path stretch value. Figure 4 indicates that LRU is better than LFU when the cache size is smaller; however, as the cache size increases, the performance of LFU improves because LFU considers the popularity of content. Therefore, as cache size increases, popular content stays longer in the cache. LRU ignores the popularity of the content and the least recently used content evicts from the cached. However, content that is not popular, but, over time, their request keeps coming, are present in the cache space, making the path stretch higher. LFRU divides the cache space into two parts: LRU used privilege partition and LFU used unprivileged partition. With the higher request rate, the least recently used content has been evicted from the privilege partition and that content pushes it to the unprivileged partition. When unpopular content is pushed into the unprivileged partition, the content stays in the cache space for a long time. Further, these techniques are not focused on the maturity of the content. IMU outperformed FIFO, LRU, LFU, and LFRU in terms of path stretch by 11.33%, 6.16%, 5.77%, and 3.82%, respectively.

Table 11. IMU path stretch percentage improvement.

α	Cache Size	Placement	FIFO (%)	LRU (%)	LFU (%)	LFRU (%)
0.6	4% to 20%	LCE	8.76	3.97	2.68	1.26
0.6		CL4M	6.17	2.80	2.20	1.42
0.6		ProbCache	6.38	4.07	3.98	2.95
0.6		LCD	3.84	1.65	1.30	0.94
0.6		opt-Cache	14.02	5.10	4.35	2.51
0.8	4% to 20%	LCE	10.32	4.88	4.30	2.44
0.8		CL4M	8.56	5.40	5.34	3.14
0.8		ProbCache	9.43	4.20	3.62	3.05
0.8		LCD	7.42	4.96	4.20	3.16
0.8		opt-Cache	10.14	6.10	5.56	3.18
1.0	4% to 20%	LCE	21.51	14.47	14.54	10.00
1.0		CL4M	20.35	9.04	9.27	6.25
1.0		ProbCache	17.03	8.16	8.30	5.25
1.0		LCD	10.73	8.49	8.69	7.13
1.0		opt-Cache	15.30	9.06	8.17	4.68

illustrates the improvement of IMU in terms of path stretch using different content placement strategies with content eviction policies. We have observed IMU perform better in low to high cache space. In addition, IMU is better in high popularity. When the cache space is full, IMU selects immature content and evicts it from the cache. Therefore, popular content and content that may be popular remain in the cache. However, the consumer’s request for specific content is fulfilled from the nearest node.

4.3. Latency

Latency indicates the delay in the delivery of requests and content from consumers. It is a vital metric for evaluating the performance of the CCN cache, and it is defined as follows:

$$Latency=Request Travel Delay+Content Travel Delay$$

(3)

The IMU provides low latency because it evicts the most suitable content from the cache, based on immaturity. If the cache is full, the IMU jointly considers the frequency and time and selects the content for potential eviction from the cache. Hence, more popular and mature content will be in the cache, and content that may be popular. However, most consumer requests are satisfied along the routing path, which reduces latency. Figure 5 illustrates that IMU’s performance is better than other content replacement policies, regarding latency with different cache sizes and popularity.

Figure 5 illustrates that FIFO represents a high latency because the duration of popular and unpopular content is the same. However, latency increases when popular content is evicted from the cache. LRU ignores the popularity of the content. Therefore, requests for less popular content come before eviction, and the content will remain in the cache, which causes high latency. LFU considers the frequency of the content, and contents that increase in frequency over a short period of time but are no longer popular; such contents use cache space due to their high frequency.

Therefore, fresh contents are reduced in the cache, which increases the latency. LFRU performs better than the previous two discussed replacement techniques because LRU and LFU are used together. When the request rate is high, then the required processing should be high, because the least recently used content is evicted from the privileged partition and pushed to the unprivileged partition and associated with the access history of content. In addition, low-frequency content is evicted from unprivileged partition. However, content with a high access history that is no longer popular will spend more time in the cache space, reducing the freshness of the content. IMU outperformed FIFO, LRU, LFU, and LFRU in terms of latency by 12.32%, 9.97%, 9.08%, and 5.91%, respectively.

When the alpha equals 0.8 with cache size is 0.04, IMU is 64.44 ms, which is 9.45% lower than LFRU (71.16 ms), 13.90% lower than LFU (74.84 ms), 13.34% lower than LRU (74.35 ms), and 15.60% lower than FIFO (76.34 ms). When the alpha equals 0.8, the cache size is 0.12, IMU is 61.03 ms, which is 5.40% lower than LFRU (64.51 ms), 9.65% lower than LFU (67.55 ms), 12.05% lower than LRU (69.39 ms), and 14.50% lower than FIFO (71.38 ms). When the alpha equals 0.8 with cache size is 0.2, IMU is 60.05 ms, which is 3.71% lower than LFRU (62.37 ms), 5.58% lower than LFU (63.60 ms), 8.93% lower than LRU (65.94 ms), and 11.59% lower than FIFO (67.92 ms). Therefore, as the cache size increases, the latency is reduced because more content in the network can be cached.

The latency improvement performance from IMU is illustrated in

Table 12. IMU latency percentage improvement.

α	Cache Size	Placement	FIFO (%)	LRU (%)	LFU (%)	LFRU (%)
0.6	4% to 20%	LCE	10.37	8.71	7.48	3.45
0.6		CL4M	7.58	6.79	6.17	5.49
0.6		ProbCache	8.13	7.12	6.43	2.10
0.6		LCD	10.00	5.76	4.90	6.55
0.6		opt-Cache	7.12	5.37	4.51	2.26
0.8	4% to 20%	LCE	14.01	11.55	10.08	6.08
0.8		CL4M	14.32	9.65	8.71	6.30
0.8		ProbCache	7.39	6.12	5.44	1.95
0.8		LCD	10.12	7.01	6.36	4.07
0.8		opt-Cache	9.26	7.18	5.97	3.38
1.0	4% to 20%	LCE	21.37	19.60	18.87	9.98
1.0		CL4M	18.36	15.96	15.24	13.53
1.0		ProbCache	14.55	12.39	12.24	7.51
1.0		LCD	14.61	11.90	11.08	6.89
1.0		opt-Cache	17.67	14.39	12.74	9.05

, using different content placement strategies with low to high popularities and cache sizes. We have observed that, as the popularity of content increases, so performs IMU. The IMU evicts content from the cache that has been in the cache for a long time and has few requests. Furthermore, content that has been in high demand for some time but declined over time has also been evicted from the cache. Therefore, the cache contains mostly mature content. However, when a consumer requests specific content, the consumer’s request does not reach the publisher because the consumer is satisfied along the routing path.

4.4. Link Load

Link load indicates the total number of bytes (consumer’s request size and content size) traversed for retrieving the interesting content at the specific time limit. It measures bandwidth usage in the network and is defined as follows:

$$Link Load=\frac{\left(reques{t}_{size}\times reques{t}_{link\_count}\right)+\left(conten{t}_{size}\times conten{t}_{link\_count}\right)}{Duration}$$

(4)

$$Duration=Content Retrieval Time-Content Request Time$$

(5)

where, $reques{t}_{size}$ denotes the request’s size in bytes, $reques{t}_{link\_count}$ designates the number of the links traversed that reach the source, $conten{t}_{size}$ is the content size to retrieve, $conten{t}_{link\_count}$ is the number of links where the content reaches the request’s originator.

Figure 5 illustrates that IMU performs better than other existing strategies in terms of link load. IMU does not replace such content from the cache, which has a frequency over a certain period of time. Therefore, consumer request is mostly satisfied with the routing path or close to the consumer. Therefore, most of the content in the cache is of interest to the user. In addition, content that increases in frequency for some time but does not become popular later also removes such content from the cache. However, IMU maintains the freshness of the content as well as the mature content in the cache.

FIFO does not compete with the popularity of content because this technique only considers the order in which the content is cached and evicts the content from the cache in that order. Therefore, popular content is evicted from the cache. However, most consumer requests are satisfied with the publisher. Figure 5 demonstrates that LRU is better than LFU when the cache size is smaller. LFU performance improves as the cache size increases, as LFU takes into account the popularity of the content. Therefore, popular content stays in the cache for a long time, and the consumer’s request is found in the cache space and not forwarded to the publisher. In addition, content that increases in frequency stays in the cache space, even if it is not popular. However, this is a misuse of cache space and leads to a higher link load. LRU ignores the popularity of the content as well as the maturity of the content. Therefore, popular content requested in the past is likely to be used in the future, but recently requested content may be replaced with less popularity; thus, it does not adapt to changing workloads. When the request rate is high in LFRU, the least recently used content is evicted from the privileged partition and pushed towards the unprivileged partition, with complete access history. However, this content is no longer popular but has a high access history; this content spends more time in cache space, which causes high link load. IMU outperformed FIFO, LRU, LFU, and LFRU in terms of link load by 18.04%, 13.61%, 12.49%, and 9.53%, respectively.

When the alpha equals 0.8, with a cache size of 0.04, IMU is 55.48 bytes/ms, which is 16.41% lower than LFRU (66.37 ms), 19.60% lower than LFU (69.01 bytes/ms), 17.85% lower than LRU (67.53 bytes/ms), and 20.57% lower than FIFO (69.85 bytes/ms). When the alpha equals 0.8, with a cache size is 0.12, IMU is 48.99 bytes/ms, which is 15.25% lower than LFRU (57.81 bytes/ms), 18.57% lower than LFU (60.16 bytes/ms), 19.21% lower than LRU (60.64 bytes/ms), and 22.19% lower than FIFO (62.96 bytes/ms). When the alpha equals 0.8, with cache size is 0.2, IMU is 44.93 bytes/ms, which is 10.40% lower than LFRU (50.15 bytes/ms), 10.68% lower than LFU (50.30 bytes/ms), 11.51% lower than LRU (50.78 bytes/ms), and 15.37% lower than FIFO (53.09 bytes/ms). As the cache size increases, we observed that the link load decreases, as the proposed scheme removes immature content from the cache. Therefore, IMU maintains the data freshness with popularity within the network. However, none of the previous eviction policies have adopted the concept of immaturity for content selection.

Table 13. IMU link load percentage improvement.

α	Cache Size	Placement	FIFO (%)	LRU (%)	LFU (%)	LFRU (%)
0.6	4% to 20%	LCE	15.58	12.34	11.49	9.30
0.6		CL4M	14.83	10.52	10.34	8.46
0.6		ProbCache	13.45	10.40	10.30	7.61
0.6		LCD	17.08	13.71	12.93	9.68
0.6		opt-Cache	15.07	10.43	10.27	6.10
0.8	4% to 20%	LCE	20.32	17.19	17.19	14.40
0.8		CL4M	21.54	18.04	17.45	15.28
0.8		ProbCache	19.18	16.17	14.95	12.04
0.8		LCD	23.44	18.48	16.51	14.64
0.8		opt-Cache	22.03	11.74	9.19	6.97
1.0	4% to 20%	LCE	20.89	17.40	15.27	13.09
1.0		CL4M	16.10	11.15	9.99	5.95
1.0		ProbCache	16.23	12.78	11.73	7.43
1.0		LCD	17.56	11.62	9.37	6.40
1.0		opt-Cache	17.30	12.14	10.35	5.55

describes the IMU’s improvement in percentage (%) of the link load, which used different content placement strategies along with content eviction policies. We observed that IMU outperformed the other content eviction policies against low to high popularity and cache space. It performed better in a fully redundant and low redundancy environments. IMU contains the most popular and mature content in the cache and makes better use of cache space. Moreover, the consumer is mostly satisfied along the routing path when requesting content. Therefore, the link load value is low because the request is not sent to the publisher.

5. Conclusions and Future Work

In-network caching is one of the essential features in the CCN architecture network, allowing content items to be cached in the router nodes for some time, to meet subsequent consumer requests. Due to the limited cache capacity in the node, any cached content in the cache needs to be evicted to accommodate new content. Content replacement policy is responsible for choosing the right content against defined criteria. Existing cache replacement policies use the concept of popularity or time for content eviction. However, when content loses its popularity after becoming very popular in a certain period, it remains in the cache space. Moreover, content is evicted from the cache space before it becomes popular. Therefore, the proposed policy handles cached items that lose their popularity over a specific time frame and remain in the cache for a long time. We introduced the new concept of content maturity and immaturity for content eviction in CCN. The proposed content replacement policy (IMU) uses the concept of maturity/immaturity of the content. This policy finds the content maturity index by using the content arrival time and its frequency. Also, it determines the maturity level through a maturity classifier. We have performed extensive simulations to evaluate the proposed content replacement policy, using the Icarus simulator under different cache sizes and content popularity. The simulation results indicate that the proposed policy outperformed recent and baseline content replacement policies (FIFO, LRU, LFU, and LFRU). The results demonstrate that the proposed policy is better in terms of the cache hit ratio, latency, path stretch, and link load. In the future, this work can be extended to use the content replacement policy (IMU) with different constraints in different use cases. Another potential future work is in-depth investigation of content diversity for the nodes with very high content popularity.