# ICN-Based Enhanced Content Delivery for CDN
## 3 Proposed Design
### Details
#### 3.4.4 Large Content Chunking  
When a content is too large to fit into one chunk, it needs to be split into smaller pieces. Therefore, a proper chunking size should be determined. In [45], it is concluded that chunk size has a large impact on system performance. Figure 5: Protocol conversion from HTTP to ID-based ICN protocol. However, determining the optimal chunk size is indeed a challenging task since both large and small chunk sizes exhibit trade-offs across different performance metrics. We summarize the related work in [45; 46; 47] and provide analysis in Table 2. In CCN, 4 KB is adopted as the default chunk size [3]. However, this value is not applicable in the context of HTTP-based web content. Inspired by the latest report on [48] that the average size of web content is about 2.3 MB, the rounded-down value of 2 MB may be suggested as an appropriate chunking size, as it is storage-friendly, which helps mitigate cache fragmentation and is large enough to avoid chunking in many cases. The optimal chunk size is to be further adjusted based on extensive empirical research. After multiple chunks are generated, each one of them requires a unique chunk ID. We use a metadata file, called manifest, to store the mapping relation between one content to many chunks so that chunks can be retrieved from the ICN distributed cache system and assembled as the content. The operation of the manifest can be described as follows: first, when EG pulls content from the origin server, the manifest for this content is generated and stored on EG; second, we assign the hash digest of the content name to manifest. As for the ID of each chunk within the content, it is generated by hashing the content name tagged along with the numerical order of each chunk. The list of the chunk NAs are encoded into the manifest with a TLV format. The steps of content chunking, ICN chunk response and manifest generating are described in Algorithm 1. ```
0: HTTP content response (\(HCRP\))
0: ICN chunk responses (\(ICRPs\)), manifest chunk (\(MC\))
1: Initialization: \(ICRPs=\{\Diamond\}\), \(chunk\_size=2 MB\)
2:\(MC.ID\leftarrow hash(HCRP.url)\)
3:if\(HCRP.content\_length\leq chunk\_size\)then
4:\(ICRP.ID\gets SHA1(HCRP.url+string(0))\)
5:\(ICRP.payload\gets HCRP.payload\)
6:\(ICRPs.add(ICRP)\)
7:\(MC.payload\gets encode(ICRP.ID)\)
8:else
9:\(chunk\_num\leftarrow\lceil HCRP.content\_length/chunk\_size\rceil\)
10:for\(i=0;i\leq chunk\_num;i++\)do
11:\(ICRPi.ID\gets SHA1(HCRP.url+string(i))\)
12:\(ICRPi.payload\leftarrow[i\times chunk\_size,(i+1)\times chunk\_size)\) in \(HCRP.payload\)
13:\(ICRPs.add(ICRP)\)
14:endfor
15:\(MC.payload\gets encode([ICRP0.ID,ICRP1.ID,\ldots,ICRPn.ID])\)
16:endif
17:return\(ICRPs\),\(MC\)
``` \begin{table}
\begin{tabular}{c c c} \hline \hline
**Impact** & **Large Chunk Size** & **Small Chunk Size** \\ \hline \multirow{2}{*}{Cache Performance} & Higher cache hit ratio longer cache entry lifetime; & Lower cache hit ratio and shorter cache entry \\  & cache space not fully utilized & lifetime; better utilization of cache space \\ \hline \multirow{2}{*}{Transmission Performance} & Longer retrieval delay; less transmission & Shorter retrieval delay but bad throughput; more \\  & control overhead & control overhead introduced in packet header \\ \hline \multirow{2}{*}{Replica Router Load} & One-hot cache more likely occurs and entails an & Distortion of content popularity but hot cache is \\  & imbalance of the router load & distributed across more replica routers for \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Performance impact of chunk size. In such a case, the process of handling the HTTP request discussed in Section 3.3 should also be updated. The first step is to retrieve the manifest from EG, and after the retrieval, it is decoded to generate a list of chunk IDs belonging to the content. Afterwards, IG sends a resolution request of each chunk ID to NRS, and the follow-up process is the same.