# ICN-Based Enhanced Content Delivery for CDN
## 5 Simulation Study
### Overhead Analysis  
In general, for small content, the latency overhead in our proposed design is mainly caused by the process of protocol conversion and name resolution. For each HTTP content request, a single hash operation is required for discovering content in the ICN network. We adopt a piggyback method to deliver information required for protocol conversion; thus, an additional session of data transmission is avoided. It was suggested by [53] that the cost of updating the control layer is considerably lower than that of data downloading. Meanwhile, by adopting the deterministic-latency name resolution method [54], \(\alpha^{k}\) can be viewed as a constant, making resolution-based content discovery a promising solution. From a holistic point, the fraction of latency overhead decreases as the cardinality of the transmitted content in the network increases, which can be formulated in our model as \(\lim_{k\to\infty}\sum_{k\in K}\alpha^{k}/\sum_{k\in K}l^{k}=0\). On the other hand, as shown in Figure 7b, the content delivery latency nearly halves in the presence of ubiquitous cache, indicating that the latency overhead is worthwhile for the purpose of utilizing the ICN in-network caching.  
However, for large content, another overhead is introduced since manifests are required to store the mapping between content and chunks. Here, we discuss this overhead in detail.  
We conducted a simple simulation study focusing on content chunk and manifest generation under different chunking size. Web content sizes generally follow a Pareto  
Figure 9: The trend of total bandwidth consumption in Abilene (**a**) and Geant2, (**b**) topology as content demand frequency increases.  
distribution, a typical heavy-tailed distribution. Assuming a random variable \(X\) follows a Pareto distribution, the probability distribution of \(X\) is given by Equation (17) as follows:  
\[P(X>x)=(\frac{x}{x_{min}})^{-\alpha} \tag{17}\]  
Suppose there are 100,000 pieces of content whose sizes follow a Pareto distribution with model parameter \(x_{min}=133\) KB, referring to [55]. As in Algorithm 1, the manifest primarily stores 20 byte chunk IDs. Therefore, we can calculate the corresponding manifest sizes based on the content sizes and chunking size. We utilize the average size (bytes) of manifests as the evaluation parameter because it is a crucial determinant of both the transmission and storage overhead. We use different \(\alpha\) parameters of Pareto distribution to simulate varied content size distributions. When \(\alpha\) takes values of 1.1, 1.2, and 1.3, the corresponding average content sizes are 1141, 761 and 517 KB. Figure 10 depicts the variation of average manifest size with changing chunk size. The trend implies that when the chunk size grows exponentially, the average manifest size exhibits a corresponding exponential decrease when the chunk size is relatively small. However, as the chunk size increases significantly, particularly surpassing the average size of all contents (as indicated by the dashed line position), the decreasing trend reduces and tends to stabilize. This is because when the chunk size is large, content smaller than that chunking granularity cannot be further divided, so increasing the chunk size further does not significantly decrease the average manifest size. Combining this observation with [48], which reports an average web content size of 2.3 MB, selecting the chunk size of 2 MB in our framework is acceptable as a value for reducing manifest management overhead.