## 4 Performance Evaluation and Comparative Analysis
### PF-ClusterCache Comparative Analysis
It is also worth noting in Figure 10 that the SHR for all the considered caching is insensitive to the considered number of popular flows as it is the SHR for popular traffic only. This SHR, however, is sensitive to the used values of the CS size and the Zipf parameter, as depicted in the next two figures. Figure 11 illustrates the SHR as a function of CS size for the different considered caching approaches, when using two popular flows among the 10 flows. Again, PF-ClusterCache outperforms all the other considered caching approaches. It is interesting to note that PF-ClusterCache necessitates a much smaller CS size. While PF-ClusterCache delivers its highest SHR even with a CS size of 5, the three other caching approaches require a CS size larger than 40 to attain their maximum SHR. Figure 12 depicts the SHR of popular traffic as a function of the Zipf parameter value, when using two popular flows among the 10 flows. PF-ClusterCache outperforms all the other approaches and delivers high SHR even for a low value of the Zipf parameter. Recall that the lower the Zipf parameter, the broader the range of popularity within each popular group of content. In turn, the lower the Zipf popularity, the higher the required CS size to attain high SHR ratios. PF-ClusterCache, as it requires a much smaller CS size, delivers much better SHR even at low values of the Zipf parameter for the popular flows. Figure 11: Server hit reduction ratio for popular traffic as a function of CS size. Figure 10: Server hit reduction ratio for popular traffic as a function of number of popular flows. Figure 13 and 14 illustrate the average retrieval time of popular content and the average number of hops required to retrieve popular content for the different considered schemes. We clearly observe the efficiency of PF-ClusterCache as it requires less than 50% retrieval delay and hop count compared to the next best approach, PoolCache. This is a direct result of the popularity-aware caching and replacement of PF-ClusterCache. Although CFPC is also a popularity-aware caching scheme, its performance is rather close to that of LCE. This is primarily due to its method of treating the content popularity, allowing it to cache unpopular content, its underlying replacement scheme, and most importantly allowing it to cache the same content at multiple nodes within the paths towards consumers. As explained earlier, PoolCache and CFPC attain lower server hit reduction and necessitate much a larger CS size. These facts tacitly amount to a much larger retrieval delay and hop count for popular content. Figure 12: Server hit reduction ratio for popular traffic as a function of popularity rate. Figure 13: Average delay for popular traffic. Last but not least, Figure 15 depicts the number of evicted pieces of content from the two considered popular flows per second using a Zipf parameter value of 1.6 and a CS size of 10. PF-ClusterCache provides the smallest eviction rate as it considers only popular content for caching and uses the LPF replacement scheme. PoolCache provides the second lowest eviction rate, though much larger than that of PF-ClusterCache, as it enforces a zero redundancy within each neighborhood, and thanks also to its LRU, which maintains a good SHR, as shown in Figure 10.