## 4 Performance Evaluation and Comparative Analysis
### PF-ClusterCache Comparative Analysis  
Within a network, we usually have a mix of popular and unpopular traffic. In the previous section, we ascertained the efficiency of the proposed popularity and freshness-aware caching scheme, PF-ClusterCache, using only popular flows. Indeed, any SCN in PF-ClusterCache discovers popular data content using its popularity table, and allows only the most popular content to be cached thanks to the underlying LPF replacement scheme. PF-ClusterCache does not cache unpopular content, and even low-popularity content may not have a chance to become cached unless the CS size allows it. When considering a mix of popular and unpopular flows, the question arises as to the size of the popularity table used at each SCN. Recall here that for each arriving Interest, an SCN verifies whether the requested content name has already an entry in the table. In the affirmative, its count is incremented; otherwise, it is inserted with a count set to one. This is done for every incoming interest, whether the requested content is popular or not. The remarkable fact is that this does not necessitate a larger size for the popularity table. The LFU strategy of the table replaces the old, least frequently used name, which is normally that for non-popular content. \begin{table}
\begin{tabular}{l l} \hline \hline
**Popularity Parameter** & **Max Table Size** \\ \hline
1.2 & 375 \\
1.4 & 229 \\
1.6 & 147 \\
1.8 & 100 \\
2.0 & 72 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Maximum popularity table size as a function of different popularity parameter values. Figure 9: Eviction rate for different popularity rates and cache sizes. The comparative analysis of PF-ClusterCache is performed with three different caching approaches: the well-known Leave Copy Everywhere (LCE) [27], customarily used as a yardstick for comparison in many studies on caching in NDN; the Caching Fresh and Popular Content (CFPC) [23], which is based on both popularity and freshness; and the PoolCache [29], which is a collaborative caching scheme based on pooling the cache storage of several nodes but with no explicit treatment of data popularity and no consideration of data freshness. These three caching policies use the Least Recently Used (LRU) replacement scheme. We divide the content catalogue into 10 groups of 50,000 pieces of content each. Requested content from each group is either selected randomly to generate unpopular traffic (unpopular flow) or using the Zipf probability distribution to generate popular traffic (popular group or flow). Interests are generated at each consumer and for each group of flows according to a Poisson distribution with parameter \(\lambda_{g}=2.5\) requests per second. Figure 10 depicts the server hit reduction ratio (SHR) for the popular traffic as a function of the number of popular flows among the 10 flows and for the different considered caching approaches. PF-ClusterCache clearly outperforms all the other approaches. LCE performs the worst as it maintains copies everywhere, which amounts to excessive evictions and replacements, resulting in cache misses and lower server hit reduction. In CFPC, content popularity control and verification is only performed when a cache is full. This allows it to intermittently cache unpopular content, resulting in a high cache miss and low server hit reduction ratio. PoolCache performs much less successfully than PF-ClusterCache although it uses a similar collaborative caching principle. This is essentially due to its inherent design as an approach that caches both popular and unpopular content. Its inefficiency against CFPC is essentially due to two facts: its underlying LRU replacement scheme that is forced to normally evict and replace unpopular content, and its caching principle, which enforces zero redundancy inside any pool of nodes. PF-ClusterCache clearly outperforms PoolCache thanks to its explicit treatment of content popularity, and its underlying LPF replacement scheme.