ICN-Based Enhanced Content Delivery for CDN

Abstract

With the rapid growth of internet traffic, the traditional host-to-host TCP/IP architecture is subject to many service limitations faced with content-oriented applications. Various novel network architectures have been proposed to solve these limitations, among which Information-Centric Networking (ICN) is one of the most prominent. ICN features the decoupling of content (service) from the physical devices storing (providing) it through location-independent naming, and offers inherent enhancement to network performance, such as multicast and in-network caching. ICN in-network caching has been extensively studied, and we believe that it may also be the main incentive for ISPs to deploy ICN. A CDN (content delivery network) is a typical content-oriented network paradigm that aims to provide the fast delivery of content. In this paper, we leverage the advantages of the in-network caching of ICN to enhance the content delivery efficiency of CDN by integrating ICN as a service. First, we present our design of a content delivery network enhanced with ICN, called IECDN. Additionally, we formulate a mathematical model to optimize the performance of our proposed design and conduct a series of evaluations. The results indicate that our proposed design provides significant performance gains while reducing bandwidth consumption and shows better resilience to traffic surge.

1. Introduction

For the past few decades, the development of the internet has always adhered to the tenet of connecting a computer to another by establishing host-to-host communication. However, with the evolving user interests and requirements comes the boom of novel applications, such as Instagram and TikTok, which puts the nature of the internet under question. According to Cisco’s 2020 annual report [1], video and other applications are in enormous demand in today’s home, and there will be significant bandwidth demands with the video application requirements in the future. This simply means the internet is shifting towards a content-oriented delivery network of video files. Many content providers use content delivery networks (CDNs) as a patch to the current IP network infrastructure in order to enhance the availability of content. For example, Netflix has used services from both Akamai and Limelight to build an ISP-independent content delivery network [2]. A CDN caches content on edge servers in point-of-presence (POP) locations that are close to end users, thereby reducing access latency. When the user requests a file via a special domain name, the DNS routes the request to the optimal POP location, which is typically determined by geographic proximity. If no edge servers in the POP have cached the file, the file is retrieved from the origin server which is comparatively time consuming.

Meanwhile, in the context of future internet study, many studies focus on a new networking paradigm called Information-Centric Networking (ICN). Contrary to the current IP network, ICN emphasizes the content itself rather than its location. The shift from a host-centric to content-centric communication paradigm facilitates the communication between networking parties by the identifier of the content instead of the address of the host holding a copy of the content, which provides solutions to many issues faced by the IP infrastructure today. The design specifics of ICN paradigm have been proposed by many studies. Some of these research works advocate a clean-slate architecture, such as Content-Centric Networking (CCN) [3], Named Data Networking (NDN) [4] and Publish Subscribe Internet Technology (PURSUIT) [5]. However, many others acknowledge the unbearable cost of kicking IP networks out of the game and settle for the coexistence with existing IP networks to achieve incremental deployments, such as Data-Oriented Network Architecture (DONA) [6], the Network of Information (NetInf) [7], MobilityFirst [8] and SEANet [9]. Despite the differences in design, all of these candidate ICN architectures share the fundamental principle of ubiquitous in-network caching.

Since the very beginning of the proposition of ICN paradigm, numerous research fields have endeavored to leverage its striking feature of in-network caching to enhance their performance, such as Internet of Things (IoT) [10], vehicular networks [11], 5G networks [12] and IPFS [13]. The benefits that the ICN in-network caching brings are particularly similar to those of CDN [14]. Meanwhile, the effectiveness of in-network caching has already been proven by the commercial success of CDN. The ICN content-centric communication paradigm meets the CDN content-oriented service requirements. CDN has already been incorporating technologies to emancipate itself from the bounds of host-centric communication paradigm of IP networks, such as GeoDNS [15] and Anycast [16]. In that sense, we envision a future CDN architecture with the support of ICN infrastructure. We incorporate the ICN in-network caching as a service for CDN to further improve the content availability. The main contributions of this paper can be summarized as follows:

• We design an enhanced content delivery network architecture by integrating the ICN in-network caching as a service. Furthermore, we provide details on the mechanisms for enabling collaboration between different communication paradigms within these two networks.
• We quantify the optimization goals of content delivery network architecture by formulating a mathematical model derived from the Multi-Commodity Flow (MCF) problem, which jointly considers the QoS demand and bandwidth capacity constraint.
• Based on the optimization model, we use a real-world network topology to gauge the performance improvements of our proposed design by conducting a series of experiments. The results demonstrate our design’s benefits in terms of reduced delivery latency, decreased network bandwidth consumption and better resilience to traffic surge.

The rest of this paper is organized as follows. In Section 2, we first introduce the background of the ICN cache and content discovery mechanism, and then review the related research, which jointly studies ICN and CDN. In Section 3, we present our design of the ICN-enhanced CDN architecture, called IECDN. In Section 4, we describe the formulation of the optimization model in detail. Then we conduct a series of experiments and analyze the results in Section 5. Finally, the conclusion is drawn in Section 6.

2. Background and Related Work

2.1. ICN Cache in a Nutshell

There have been early attempts [17,18,19] to develop a ubiquitous caching system within the IP networks to avoid repeated transmission. Nevertheless, the emergence of ICN has raised both the intensity and breadth of research on in-network caching to a new level. There is a vast literature addressing the challenges of content caching in ICN, most of which focus on the cache placement strategy [20,21,22], cache replacement policy [23] and cache capacity allocation [24]. Three major features differentiate the ICN cache from the existing cache system. First, ICN caching is transparent to upper-level applications and exists as an underlying service, making it more efficient and available to different types of traffic. Second, in ICN, the cache can be equipped on any network node. This ubiquity allows for content to be cached closer to the end users, reducing latency and improving content delivery. Third, the objects cached in most traditional cache systems are generally based on files. However, to meet the line-speed constraints of ICN routers [25], ICN employs the smaller unit of chunk as its basic caching unit. As a side effect of this, many analysis reference models of traditional cache become outdated to ICN.

2.2. Name Resolution Mechanism

A primary concept of ICN is naming data independently from their physical location. Each Named Data Object (NDO) in ICN is identified with a unique name, which is not directly usable for forwarding or routing within the current IP network. Consequently, the issue of locating and discovering NDOs using their location-independent names has arisen. To address this challenge, a Name Resolution Service (NRS) is required, which provides the mapping between Identifiers (IDs) and Network Addresses (NAs). A NRS in ICN is defined as the service that provides the name resolution function for translating an object name into some other information, such as a locator, another name, metadata, next-hop info, etc., that is used for forwarding the object request [26]. There are generally three kinds of name resolution service approaches:

• Explicit name resolution approach: This approach is also referred to as a standalone name resolution approach. In this approach, the name resolution process and content request routing process are decoupled. The NRS first returns to the client the locators of the content and then it is used by the underlying network as the identifier to route the content request. This approach is employed by many ICN architectures, such as PURSUIT [5], DONA [6], NetInf [7] and MobilityFirst [8]. For instance, in the MobilityFirst ICN architecture, the infrastructure of NRS is called the Global Name Resolution Service (GNRS). It is designed as a massively scalable distributed system which provides the dynamic binding between a content’s Global Unique ID (GUID) and its NA.
• Name-based routing approach: Some ICN architectures employ a name-based routing approach which integrates the name resolution process with content request routing. In this approach, the name is used as the basis for routing and forwarding the content request. When a request is initiated, the name is used to search for the NDO in the NRS cache. The NDO is forwarded back to the requester along the same path used for request routing but in the opposite direction. A typical example is NDN [4].
• Hybrid approach: The hybrid approach entails both an explicit name resolution approach and name-based routing approach to complement each other. For example, if the name-based approach fails at a certain router, the explicit name resolution approach can be utilized as an alternative, and vice versa.

2.3. Related Work

CDN and ICN are two network paradigms proposed to enhance the content distribution efficiency in the presence of service limitations in current IP networks. Previous studies regarding the discussion of these two paradigms can be classified into two broad classes:

• Comparative studies: These studies have attempted to conduct comparative analyses of these two paradigms to evaluate their respective performance bounds. In their research, Ma Ge et al. [27] discussed the differences between CDN and NDN in terms of distribution efficiency, protocol overhead, security, robustness, and cost, and testbed research was conducted to compare the data transmission efficiency of the two paradigms, with the conclusion being that NDN outperforms CDN under the same network topology and cache storage budget. In [28], Ma Ge et al. constructed comparable testbeds on cloud computing platforms for CDN and CCN separately to systematically compare their performance metrics in content delivery capability. This research found that CCN is comparable to CDN, even though it introduces overhead in content chunk decoding and restructuring. M. Mangili et al. [29] studied the performance bounds of these paradigms using optimization models and proposed a comparative model to gauge the performance difference of a CDN with respect to CCN. The results showed that, under the same total caching storage, CDN can have slightly better performance than CCN. In [30], real-world experiments were conducted to compare the performance of NDN and two leading CDNs (Akamai and Fastly). The results showed that although NDN can provide satisfactory service, it lags behind CDN due to the hardware infrastructure and software/protocol immaturity. NDN outperforms in terms of server load balancing and failure resiliency enabled by ubiquitous caching. The comparative studies have shown that ICN does not necessarily outperform CDN in terms of content distribution efficiency; however, it is favorable in terms of lower management cost and better resiliency. Rather than being two separate models, these two can be explored to complement each other.
• Hybrid studies: Some prior research proposed to integrate CDN and ICN using hybrid approaches to achieve better performance. Ref. [31] proposed a named content delivery network called nCDN, which embeds NDN into the existing CDN framework by setting up NDN running over UDP/TCP to simplify the implementation and improve efficiency. In nCDN, ICN is only in charge of request routing and content delivery. Similarly, in [32], the authors borrow the ICN name-based routing idea and integrate it into the CDN architecture with a centralized routing engine to fully exploit the ISP underlay network infrastructure. In [33], Benkacem et al. integrate NDN with CDN as two network slices with the technology of Network Function Virtualization (NFV). In this architecture, NDN serves as a service slice designated for request routing and in-network caching over a specific region. The CDN slice is considered the content publisher of the NDN slice. Upon the first request for a particular content, the content is retrieved from the CDN service slice and simultaneously published to the NDN slice. Instead of building a CDN using NDN by the direct borrowing of the NDN network, the authors in [34] proposed another CDN-NDN architecture called iCDN, with two major mechanisms: first, to fully utilize in-networking caching, iCDN builds a cache hierarchy with the CDN full-mesh topology to exploit on-path and off-path caches and cuts the forwarding plane’s dependency on routing information; second, iCDN introduces a new forwarding strategy for enabling the forwarding plane to make efficient decisions. J. Chen et al. [35] designed a CDN architecture over MobilityFirst in the application layer so that minor modification is needed for existing protocol stack. Meanwhile, it uses a self-certifying naming schema to enable low-cost, efficient content validation and uses proactive caching to further improve the performance of CDN. The main features and discussions regarding the above hybrid approaches are compared and summarized in

  Table 1. Comparison of hybrid approaches in related work.

  Approach	ICN Paradigm	Integration Method	Discussions
  nCDN [31]	NDN	An overlay method by setting up NDN running over UDP/TCP	Provide better QoS, reliability and scalability especially in dynamic network
  R-iCDN [32]	Not mentioned but name-based routing	Integrate a centralized content routing engine in CDN, using ICN name-based routing	Improve CDN sub-optimal routing in ISP networks
  CDN with NDN slice [33]	NDN	Integrate NDN as a network slice	Shorten delivery time and reduce traffic load by leveraging ICN for regional content distribution
  iCDN [34]	NDN	Build CDN in NDN’s logic using stateful forwarding plane and in-network caches	Using NDN technology on the CDN full-mesh topology, shorter delay and less traffic load is achieved, FIB explosion is avoided
  CDN over MobilityFirst [35]	MobilityFirst	Build CDN on top of MobilityFirst	Combine the CDN application awareness and ICN efficient network forwarding
  IECDN proposed in this paper	IP-compatible and ID-based protocol	ICN infrastructure service layer with translation gateways	Show reduced latency, less overall bandwidth consumption and better resilience to traffic surge

  . To conclude, although the above hybrid studies differ in their approaches, they all clearly indicate that by integrating ICN into the CDN architecture, the content distribution efficiency of CDN can be significantly improved.

When incorporating ICN into CDN, addressing the challenges of communication paradigm translation between the two is an important research area. The translation operations are typically executed by gateways or proxies that support both paradigms. The first is to convert HTTP semantics into a ICN naming convention. In a hierarchical ICN naming convention like NDN/CCN, the most common approach [36,37,38] is to construct a hierarchical name structure by extracting information from the HTTP URL and HTTP header. In [36], the sub-level of the HTTP domain name is split and reversely appended in the NDN name, followed by the version, segment, and other information. This approach improves the NDN routing capability with route aggregation. The strategy in [38] puts a default prefix at the beginning of the CCN name, HTTP protocol, request method, and request domain, and the request parameters are hierarchically appended.In a flat naming convention like MobilityFirst, the key to translation is generating a globally unique ID that identifies the content/host [35,39]. In [35], the authors use a public key generated by the Elliptic Curve Cryptography (ECC) algorithm as the content ID. Secondly, regarding the different HTTP request methods, primarily GET and POST, the GET method can naturally correspond to the ICN pull-based interest packet, but the POST method is more complex. In [37,38], the proposed method is for the gateway/proxy to save data upon receiving a POST, then sends a special interest to the ICN terminal. This prompts the ICN terminal to send an echo interest to the gateway and pull the data, thus achieving a push-like effect.

In the integration methods discussed above, using overlay or network slice techniques can facilitate the fast deployment of ICN. However, they also introduce complexities in management and incur overhead associated with network abstraction. Inspired by the above research, we propose our ICN-enhanced CDN architecture, called IECDN. The ubiquitous caching capabilities of ICN can be a compelling incentive for ISP to embrace its deployment. In light of this, this paper envisions a scenario where ICN is employed as an infrastructure service, providing network services through dual-stack gateways. To ensure a cost-effective deployment of ICN, we propose the introduction of an IP-compatible ICN paradigm. This strategic combination of infrastructure deployment and an IP-compatible protocol stack aims to address the challenges posed by ICN deployment, presenting a balanced approach that capitalizes on the strengths of ICN while mitigating the associated complexities.

3. Proposed Design

In this section, we first clarify our motivation to utilize the ICN functionalities to enhance CDN and present the general description of the architecture design and its key components. Next, we explain the working mechanism of the architecture by presenting the workflow of a content request and delivery process. Finally, we introduce the details of our solution to several issues in converting from the HTTP paradigm to the ICN paradigm.

3.1. Motivation

Over the past few decades, CDN has evolved to demonstrate remarkable stability and high service performance. However, the inherent design of CDN often relies on a centralized set of content servers. On the contrary, ICN emphasizes more lightweight and ubiquitous caching. This motivation section explores the potential advantages of adopting ICN to complement the CDN architecture.

• Emphasis on lightweight and ubiquitous caching in ICN: ICN introduces a paradigm shift by emphasizing the lightweight nature of caching and embracing heterogeneous and ubiquitous caching capabilities. ICN nodes can seamlessly join and leave the network, offering great scalability and lower management costs. This departure from centralized caching servers brings better flexibility and failure resiliency.
• Leveraging ICN for cost-efficient content delivery: One of the primary costs of CDN is from bandwidth consumption and maintenance. The ubiquitous caching capability of ICN allows for the storage of content replicas within the network at any place. Utilizing idle resources of ICN nodes, such as bandwidth and storage, to provide content service can reduce CDN deployment costs and enhance system scalability.
• Benefits of the ICN cache relative to the CDN HTTP-based cache: In contrast to the CDN HTTP-based caching at the application level, the ICN cache operates at the network layer. The control overhead is minimized, involving only a few bits in the data packet for cache management. The ICN router can achieve line-speed caching operation. Furthermore, the ability of ICN to split content files into data chunks facilitates load balancing by distributing requests for locally popular content across multiple nodes.

3.2. Design Overview

An overview of our proposed design is illustrated in Figure 1. The major modification to CDN in our architecture is that we integrate an ICN service layer with routers supporting ICN paradigms, which mainly involves in-network caching and naming service. These routers constitute a large distributed caching entity of the ICN service layer. Moreover, Ingress Gateways (IGs) and Egress Gateways (EGs) are respectively deployed at the entry and exit points of the ICN service layer. These gateways function as both HTTP proxy and protocol conversion components. To be specific, IG can be viewed as an HTTP proxy, to which HTTP requests for content are redirected, and as a protocol conversion component which translates an HTTP request into an ICN chunk request so as to discover and retrieve content from the ICN service layer. EG receives HTTP content responses from the internet content provider (origin server) and publishes this content to the ICN service layer, which subsequently performs in-network caching in compliance with certain caching policies. A detailed process of the content request and delivery will be elaborated on in Section 3.3.

A standalone NRS system is deployed to resolve IDs to NAs. When a router caches a chunk, it simultaneously registers to NRS the value of its physical device NA with the key of chunk ID. Afterwards, this chunk can be discovered and retrieved with this ID: first, an ID resolution request is submitted to the NRS, and NRS returns a resolution response that comprises a list of chunk replica NAs, then, a replica selection mechanism is adopted to select a suitable chunk replica and triggers the download. In our context, the nearest replica selection mechanism [40] is adopted since it is commonly used in related work. Finally, the subsequent transmission is conducted through NA routing.

Content is cached at the granularity of a file in a CDN, whereas ICN performs caching at the granularity of a chunk. For the purpose of this discussion, we use the terms “content” and “file” interchangeably to refer to data within a CDN network, and the term “chunk” within an ICN network. Further information regarding this issue is discussed in Section 3.4.

3.3. Workflow

Hereafter, we elaborate on our proposed mechanisms for enabling seamless collaboration between CDN and ICN to achieve efficient content delivery as illustrated in Figure 2.

Upon a cache miss on the CDN edge server, the content request is redirected to IG. This can be achieved by configuring IG as a proxy (steps 1–2 in Figure 2). IG parses the HTTP content request and initiates a name resolution request to NRS, querying if the corresponding chunk ID is registered (steps 3–4 in Figure 2). If registered, NRS returns the list of NAs of chunk replicas, and then IG selects the optimal replica using the nearest replica mechanism (steps 5–6 in Figure 2). If not registered (as in the dotted box), NRS returns NULL and the content needs to be retrieved from the origin server: first, IG initiates a chunk request to EG; second, EG handles the chunk request and generates an HTTP request of the content; third, EG requests the content from the origin server and sends the content back to IG in the form of a chunk. While forwarding, the chunk is cached along path (steps 5${}^{\prime }$–6${}^{\prime }$ in Figure 2). The details of the conversion between the HTTP and ICN paradigm will be discussed in the following section. Once IG retrieves the content, it serves the CDN edge server (steps 7–8 in Figure 2).

3.4. Details

3.4.1. ID-Based ICN Protocol Stack

In our design, an ID-based ICN communication paradigm is utilized to decouple the name and location. In that sense, the content is named by a unique ID but retrieved with a late-binding network address as presented in the above section. In order to process IDs while avoiding an overhaul in the current IP network, it is favorable to deploy the ICN paradigm over the existing IP infrastructure. Figure 3 shows the whole picture of this ICN protocol stack. The identifier protocol (IDP) [41] is extended over the IP protocol, and it regulates ID-based NA operations, such as ID-to-NA register and resolution. Above IDP, an ID-to-ID ICN transmission protocol [42] is running, and it provides a pull-based, chunk-oriented transmission service with efficiency and reliability mechanisms, such as retransmission and congestion control.

3.4.2. Design of IG and EG

IG and EG are the most important components of the ICN service layer. As the interchange points between ICN and HTTP, the HTTP-ICN gateways must be compatible with both the HTTP and ICN paradigms. Figure 4 shows the design diagram of the HTTP-ICN gateway.

The HTTP server on IG parses and translates an HTTP request into an ICN chunk request with a protocol conversion mechanism. The chunk request is subsequently handled by the ICN client. Vice versa, upon receiving the chunk response on the ICN client, IG wraps the data in the HTTP payload and sends the HTTP response back to the CDN server. Similarly, EG receives an ICN chunk request, translates it into an HTTP content request and extracts data from the HTTP response payload to generate the ICN chunk response. The ICN client and server run on the ICN protocol stack described in the above section.

3.4.3. Protocol Conversion

The protocol conversion in our context is twofold:

• HTTP to ICN: An HTTP request generally consists of a request line and several request headers. The request line commonly consists of three items: a method that instructs the server what it should do with the resource; a URI that locates and identifies the resource; and an HTTP version number. In ICN, each chunk is identified with a unique ID. Since the URL of each content is unique, we use SHA1 to generate the 20-byte hash digest of the content URL as its chunk ID. This process is illustrated in Figure 5. Afterwards, this content will exist in the form of chunks in the ICN network with a unique ID used for registration/publishing and resolution/retrieval. Upon receiving a GET request for content on the HTTP server, the ID of its chunk counterpart is calculated to locate its physical address by querying NRS, then the follow-up download is triggered.
• ICN to HTTP: HTTP services on the application layer and is rich in semantics, whereas most of the ICN architectures reach up to only the network layer or transport layer. Apart from that, in our context, we use the hash digest of a content URL as its naming ID in ICN, which is a non-reversible operation. This means that a literal translation from the ICN protocol to HTTP is infeasible. To address this issue, we adopt a method commonly used in related work [43,44] that the ICN packets piggyback with extra control or feedback information. Specifically, since an HTTP request needs to be reconstructed by EG, IG sends to EG the ICN chunk request piggyback with HTTP request headers related to this content. Likewise, EG sends to IG the chunk response piggyback with the HTTP response headers for IG to reconstruct the HTTP response, and the response headers are cached on IG for future use. This can achieve zero loss of HTTP semantics at the cost of relatively low overhead.

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.

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. Performance impact of chunk size.

Impact	Large Chunk Size	Small Chunk Size
Cache Performance	Higher cache hit ratio longer cache entry lifetime; cache space not fully utilized	Lower cache hit ratio and shorter cache entry lifetime; better utilization of cache space
Transmission Performance	Longer retrieval delay; less transmission control overhead	Shorter retrieval delay but bad throughput; more control overhead introduced in packet header
Replica Router Load	One-hot cache more likely occurs and entails an imbalance of the router load	Distortion of content popularity but hot cache is distributed across more replica routers for load balancing

. 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.

Algorithm 1 Large content chunking.

Input:  HTTP content response ($HCRP$) Output:  ICN chunk responses ($ICRPs$), manifest chunk ($MC$)   1: Initialization: $ICRPs=\{\oslash \}$, $chunk\_size=2MB$   2: $MC.ID\leftarrow hash(HCRP.url)$   3: if  $HCRP.content\_length\le chunk\_size$ then   4:      $ICRP.ID\leftarrow SHA1(HCRP.url+string(0\left)\right)$   5:      $ICRP.payload\leftarrow HCRP.payload$   6:      $ICRPs.add\left(ICRP\right)$   7:      $MC.payload\leftarrow encode(ICRP.ID)$   8: else   9:      $chunk\_num\leftarrow ⌈HCRP.content\_length/chunk\_size⌉$ 10:      for $i=0;i\le chunk\_num;i++$ do 11:         $ICRPi.ID\leftarrow SHA1(HCRP.url+string(i\left)\right)$ 12:         $ICRPi.payload\leftarrow$$[i\times chunk\_size,(i+1)\times chunk\_size)$ in $HCRP.payload$ 13:         $ICRPs.add\left(ICRP\right)$ 14:      end for 15:      $MC.payload\leftarrow encode\left(\right[ICRP0.ID,ICRP1.ID,\dots ,ICRPn.ID\left]\right)$ 16: end if 17: return  $ICRPs,MC$

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. Multiple chunks can be retrieved concurrently from different cache replica routers so that the download latency can be reduced.

4. Problem Formulation

4.1. Model Description

The core philosophy of CDN is to move content from the places of origin servers to the places of edge servers, which are much closer to users so that a better QoS (lower access latency and higher transfer rate) is ensured. To this end, the optimization model is QoS-oriented. Meanwhile, a significant traffic engineering goal is to be responsive to sudden traffic surges and have better control over the link load since network links packed with traffic may experience significant degradation in performance. This means our model is subject to bandwidth constraints on each link, which translates our model into a Multi-Commodity Flow (MCF) problem.

We formulate a QoS-oriented model subject to bandwidth constraints to mathematically represent our proposed design. The model is considered a directed graph $G=(V,E)$ with $\left|V\right|$ vertices and $\left|E\right|$ edges. The set $V=\left\{v_1,v_2,\dots ,v_n\right\}$ and set $E=\left\{e_1,e_2,\dots ,e_n\right\}$ represent nodes and links in the network, respectively. A node can act as one of the following roles: user, router, CDN edge server, origin server, IG and EG. We assume that there is only one origin server providing all the contents to the whole network, which we denote as $V_s$. IG and EG are chosen from the set of routers $R=\left\{r_1,r_2,\dots ,r_n\right\}$ with a specific mechanism which will be introduced in Section 5. Let $U=\left\{u_1,u_2,\dots ,u_n\right\}$ be the set of users and $N=\left\{n_1,n_2,\dots ,n_m\right\}$ be the set of CDN edge servers. Thus, we have that $V=U\cup N\cup R\cup V_s$. Each router and CDN edge server can potentially cache content and is restricted with finite cache capacity $C\left(v\right)$. For each link $(i,j)$ in the network, it is characterized by its bandwidth capacity $b_{(i,j)}$ and delay $d_{(i,j)}$.

A large proportion of content cached on CDN edge servers is web files whose sizes range from several bytes to megabytes. In most cases, a content is equivalent to a chunk. And we discuss content/chunks from an object level referring to [49]. To this end, we define the set of content as $F=\left\{f_1,f_2,\dots ,f_n\right\}$ and $Size\left(f_p\right)=Size\left(f_q\right),\forall f_p,f_q\in F$. Derived from MCF model, we define $K=\left\{k_1,k_2,\dots ,k_n\right\}$, $k=(s^k,t^k,{\omega }^k)$ as the set of demands in our model and refer to k as a content delivery demand, which needs to route a content from source $s^k$ to destination $t^k$ with a demand for transmission rate at ${\omega }^k$. In our context, $s^k$ is the node where the content is stored, and $t^k$ is the user requesting the content. The content f demanded by each k complies with a certain probability distribution, which we denote as $f=\xi \left(k\right)$. In the context of CDN, Zipf distribution is one of the possibilities. For each demand k, we define variable $z_{(i,j)}$ such that if $z_{(i,j)}=1$, the route goes through link $(i,j)$ and $z_{(i,j)}=0$ otherwise. The traffic generated by demand k on link $(i,j)$ is denoted as ${\gamma }_{(i,j)}^k$. Moreover, the conversion from an HTTP paradigm to an ICN paradigm in our proposed design can introduce overhead, which we denote as ${\alpha }^k$.

In our proposed design, both routers and CDN edge servers have to make the decision of caching a content according to its caching policy. Let $X(f,r)⟶\left\{0,1\right\}$ be the Boolean function of caching the content f at router r, and $Y(f,n)⟶\left\{0,1\right\}$ be the Boolean function of caching it at edge server n. After a content is cached at a router or edge server, it becomes an available source for content delivery demand k. We denote the content availability at a certain node with binary value $x\in \left\{0,1\right\}$ and $y\in \left\{0,1\right\}$ such that:

$$x_r^k=\left\{\begin{array}{cc}1,\hfill & \mathrm{content}\mathrm{demanded}\mathrm{by}k\mathrm{is}\mathrm{available}\mathrm{at}\mathrm{router}r\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(1)

$$y_n^k=\left\{\begin{array}{cc}1,\hfill & \mathrm{content}\mathrm{demanded}\mathrm{by}k\mathrm{is}\mathrm{available}\mathrm{at}\mathrm{server}n\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(2)

When a content is available at the edge server, it will be routed directly to user. However, on encountering a cache miss on the edge server, the routing occurs in two stages. The first is to route the content from a source that is either a router or the origin server in our proposed design, to the CDN edge server. The second is to route content from the edge server to user. Meanwhile, the content is cached along the path. We also assume that IG is placed near edge servers; thus, the delay from IG to an edge server is ignored. The routing process from the origin server to EG is simply regarded as a one-hop transmission with unlimited bandwidth and a large delay.

We evaluate the efficiency of completing a content delivery demand based on QoS, which we measure by its most important factor: the total latency from the source to the destination. In the meantime, each demand must fulfill constraints on link and node capacity. To proceed with further discussion,

Table 3. Summary of the notation used in this paper.

Notation	Comment
V	Set of vertices (network nodes)
E	Set of edges (network links)
U	Set of user nodes
N	Set of edge server nodes
R	Set of router nodes
$V_s$	The single origin server node
F	Set of contents
K	Set of demands
$C\left(v\right)$	Finite cache capacity of node v
$Size\left(f\right)$	Size of content f
$f=\xi \left(k\right)$	Mapping of demand k to content f
$b_{(i,j)}$	Link capacity of $(i,j)$
$d_{(i,j)}$	Link delay of $(i,j)$
${\gamma }_{(i,j)}^k$	Traffic flow related to demand k at link $(i,j)$
${\alpha }^k$	Latency overhead related to demand k
$z_{(i,j)}^k$	0–1 variable, indicating whether $(i,j)$ is used for routing demand k
$X(f,r)$	Boolean function of whether to cache content f at router r
$Y(f,n)$	Boolean function of whether to cache content f at edge server n
$x_r^k$	0–1 constraint, indicating availability of demand k at router r
$y_n^k$	0–1 constraint, indicating availability of demand k at edge server n

summarizes the notations used in this paper.

Given the above definitions and assumptions, we formulate our QoS-based optimal design model as follows:

$$min\sum _{k\in K}\left(\sum _{n\in N}\sum _{r\in R}(1-y_n^k)[x_r^k{l}_1^k+(1-x_r^k)l_1^{{}^{\prime }k}]\right)+l_2^k$$

(3)

$$\begin{array}{cc}\hfill l_1^k& =\sum _{(i,j)\in E}{z}_{(i,j)}^k{d}_{(i,j)}+{\alpha }^k,\forall k\in K,s^k\in R,t^k\in N,\left|s^k\right|⩾1\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill l_1^{{}^{\prime }k}& =\sum _{(i,j)\in E}{z}_{\left(i,j\right)}^k{d}_{(i,j)}+{\alpha }^k,\forall k\in K,s^k\in V_s,t^k\in N\hfill \end{array}$$

(5)

$$\begin{array}{cc}\hfill l_2^k& =\sum _{(i,j)\in E}{z}_{(i,j)}^k{d}_{(i,j)},\forall k\in K,s^k\in N,t^k\in U\hfill \end{array}$$

(6)

subject to constraints (7)–(15):

$$\begin{array}{cc}\hfill & \sum _{j:\left(i,j\right)\in E}{z}_{\left(i,j\right)}^k-\sum _{j:\left(j,i\right)\in E}{z}_{\left(j,i\right)}^k={\lambda }_i^k,\forall k\in K,\left(i,j\right)\in E,\hfill \end{array}$$

(7)

$$\begin{array}{cc}\hfill & {\lambda }_i^k=\left\{\begin{array}{cc}1,\hfill & i=s\hfill \\ -1,\hfill & i=t^k\hfill \\ 0,\hfill & i\ne s^{k}andi\ne t^k\hfill \end{array}\right.\hfill \end{array}$$

$$\begin{array}{cc}\hfill & {\gamma }_{(i,j)}^k{z}_{(i,j)}^k=\left\{0,{\omega }^k\right\},\forall k\in K,\forall (i,j)\in E\hfill \end{array}$$

(8)

$$\begin{array}{cc}\hfill & \sum _{k\in K}{z}_{(i,j)}^k{\gamma }_{(i,j)}^k⩽b_{(i,j)},\forall (i,j)\in E\hfill \end{array}$$

(9)

$$\begin{array}{cc}\hfill & \sum _{k\in K}[Y(n,\xi \left(k\right))+y_n^k]⩽C\left(n\right),\forall n\in N\hfill \end{array}$$

(10)

$$\begin{array}{cc}\hfill & Y(n,\xi \left(k\right))+y_n^k⩽1,\forall n\in N,k\in K\hfill \end{array}$$

(11)

$$\begin{array}{cc}\hfill & \sum _{k\in K}[X(r,\xi \left(k\right))+x_r^k]⩽C\left(r\right),\forall r\in R\hfill \end{array}$$

(12)

$$\begin{array}{cc}\hfill & X(r,f\xi \left(k\right))+x_r^k⩽1,\forall r\in R,k\in K\hfill \end{array}$$

(13)

$$\begin{array}{cc}\hfill & y_n^k=\left\{0,1\right\},\forall k\in K,n\in N\hfill \end{array}$$

(14)

$$\begin{array}{cc}\hfill & x_r^k=\left\{0,1\right\},\forall k\in K,n\in N\hfill \end{array}$$

(15)

The objective function (3) minimizes the total content delivery latency over all content. For each demand k, $l_1^k$ in Equation (4) denotes the latency to deliver content from an ICN in-network caching router to the edge server. Note that $\left|s\right|\ge 1$, which means there is generally more than one available replica for content. Equation (5) means that if there is no available content in the ICN in-network cache, the source will be assigned to origin server, and the latency is denoted as $l_1^{{}^{\prime }k}$ in such a case. $l_2^k$ in Equation (6) denotes the latency to deliver content from the edge server to the user. In (7), we use the standard flow conservation constraint of the MCF problem, i.e., for nodes that are neither the source nor destination, the inflow is equal to the outflow. This means our model does not support multicast routing, even though multicast is another attractive enhancement technique of ICN; we intend to explore this further in our future work. Constraint (8) ensures that each link chosen by demand k fulfills its demanded transmission rate of ${\omega }^k$. Constraint (9) ensures that the traffic on link $(i,j)$ does not surpass its capacity. Content cached on each router and the CDN edge server should not surpass its capacity, and only one replica of the content is cached per server/router as enforced by constraint (10)–(13). Finally, we add to the model the binary constraint (14) on $y_n^k$ and (15) on $x_r^k$.

4.2. IECDN Model and Conventional CDN Model

The optimal design model we described above is based upon our proposed content delivery architecture. However, both our proposed design and a conventional CDN can be adapted to it. In our proposed design, ${\alpha }^k$ in the objective function (3) is a value larger than zero, whereas in a conventional CDN model, ${\alpha }^k$ is always equal to zero. Since routers in a conventional CDN do not perform caching, constraint (12)–(15) can be removed, and constraint (15) is re-adapted to (16). Therefore, a conventional CDN model has that objective function (3), wherein ${\alpha }^k\equiv 0$, subject to constraints (7)–(11), (14) and (16):

$$x_r^k=0,\forall k\in K,n\in N$$

(16)

From a practical point of view, when a certain cache policy for ICN (e.g., LCE, LCD and CL4M) is given, the Boolean function $X(f,r)$ is given as an input of the problem. Meanwhile $Y(f,n)$ is deterministic when the HTTP response header indicates a preference for caching content (e.g., Cache-Control: max-age = 300 instructs server to cache the content for 300 s). For simplicity, we assume that content will always be cached on the CDN edge server, i.e., $Y(f,n)=1$. Additionally, when a certain cache eviction policy is given for both ICN and CDN (e.g., LRU, LFU), constraints (10)–(13) are always satisfied. As for constraints (14) and (15), the CDN edge server is aware of the existence of cached content, so $y_n^k$ is also given as an input. Likewise, a content discovery mechanism of ICN provides the value of $x_r^k$. As we introduced in Section 3, a name resolution service is integrated in our proposed design, which facilitates content discovery. The value of variable $z_{(i,j)}^k$ is dependent upon both content delivery architecture design and routing. When a candidate design is given from $\{IECDN,ConventionalCDN\}$, the problem is reduced to a routing problem, which prompts us to solve the problem using Linear Programming.

5. Simulation Study

5.1. Methodology

We implemented the simulation program in Python and the optimization problem was solved using CPLEX (v 22.1.0).

5.1.1. Topology

In order to establish a network topology for our proposed design that contains the key components, we developed a mechanism to generate the topology:

• Routers: We use a real network topology for core routers as follows:
  • Abilene topology (12 nodes, 14 bidirectional links);
  • Geant2 topology (32 nodes, 54 bidirectional links).
• IG and EG: Both IG and EG are selected from routers. Based on our previous assumption, IG is placed close to CDN edge servers. In light of the topology-informed placement strategy for CDN servers proposed in [50], we select IG as the router with the highest out-degrees so that it reaches out to more users with smaller latency. In contrast, EG is selected as the router with the maximum sum of distances to all other routers, reflecting that EG is placed towards the origin server, which is distant from users.
• Edge servers and origin server: Edge servers are arranged in a ring topology, with each one of them linked to the IG. We set the number of edge servers in proportion to the number of users, with one edge server per ten users. Lastly, the origin server is directly connected to the EG as previously assumed. A topology of our proposed design generated with the Abilene topology is shown in Figure 6.

5.1.2. Parameter Configuration

As stated in Section 4, our problem can be solved using an ILP (Integer Linear Programming) model. Hereafter, we list the parameters we used in our numerical analysis, which can be categorized as follows:

• Content and request parameters: Since working with objects of a large cardinality is practically unfeasible in an ILP model, we generated a workload extracted from a catalog of $1\times {10}^4$ content objects following the Zipf distribution, and to study the impact of different content popularity on our model, we varied the parameter $\alpha$ of the Zipf distribution to within the range of [0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 1.2], referring to [51]. The requests of this workload were designed up to $2\times {10}^4$, with each request mapped to a content delivery demand in our model. We generated different demand profiles at the numbers in the range of [10, 12, 14, 16, 18, 20] to model different user demand frequency. Within an analysis, the destination of each request/demand was randomly assigned to an unrepeated user; the CDN edge servers servicing these requests were scheduled in a Round Robin manner. To stay faithful to the real CDN routing scenario, routing for each requested content was carried out in two stages if necessary as mentioned in Section 4.1. Furthermore, we analyzed two possible user demand rates of 0.5 and 1.0 Gbps. Finally, we computed the mean total bandwidth consumption and delay as the outcome.
• Network parameters: We classified links into two main categories, the core links and the edge links.
  • Core links refer to links connecting routers. Bandwidth limits on core links in both topologies are set to 10 Gbps. Delays on core links in the Abilene topology are set to the measurement results of [52].
  • Edge links connect routers to user. For both topologies, bandwidth limits on edge links are set to the highest user demand rate of 1.0 Gbps, and delays are set to random values between 1 and 5 ms, following a uniform distribution.
  In particular, according to our previous assumption, for the link between the origin server and EG, the bandwidth is set to infinite, and the delay is set to a large number, for which we deem 100 ms to be reasonable, considering the dataset we employed from [52]. Meanwhile, we relaxed the bandwidth constraints on links connected to IG since it is the meeting point of all the influx when delivering content from the source to the PoP. Their limits are elevated to the value of $max$ (content demand frequency) × $max$ (contend demand rate) to allow the concurrency of all the flows.
• Cache parameters: In the context of our study, caching is involved in both CDN and ICN. As we assumed in Section 4.2, content is always preferably cached on CDN servers in our model. Regarding ICN, we implemented the LCE policy, which we deemed as the counterpart. We set the cache capacity for CDN nodes to be within the range of [10, 50, 100, 200, 300, 500] (objects). From a practical point of view, the cache capacity for CDN servers is assuredly larger than that of ICN routers. Therefore, we set the cache capacity of all ICN routers equally as one-tenth of the CDN server capacity, conforming to the homogeneous cache allocation strategy. When reaching the maximum cache capacity, the eviction policy of LRU is adopted for both ICN and CDN. The fundamental parameters we tested in our numerical analysis are shown in

  Table 4. Parameters for numerical analysis.

  Parameter	Value	Default
  Topology	Abilene, Geant2	Abilene
  Catalog size	$1\times {10}^4$	-
  Request number	$2\times {10}^4$	-
  $\alpha$ of Zipf	[0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 1.2]	0.8
  Content demand frequency	[10, 12, 14, 16, 18, 20]	10
  Content demand rate [Gbps]	0.5, 1.0	1.0
  CDN node cache size [Objects]	[10, 50, 100, 200, 500]	100
  ICN node cache size [Objects]	[1, 5, 10, 20, 50]	10

  .

5.2. Result Analysis

5.2.1. Enhancement to Performance

In this experiment, we attempt to evaluate the performance of our proposed design compared with conventional CDN. We use the Abilene topology for analysis and vary the cache size in the network, noting that by changing the maximum cache size of CDN servers, the maximum cache size of the ICN routers is correspondingly changed. Other parameters are set to their default values. The results are illustrated in Figure 7a,b with the direct comparison of total bandwidth consumption and average content delivery delay under different cache sizes between IECDN and conventional CDN.

Overall, it is obvious that compared with conventional CDN, IECDN achieves considerable performance gains while reducing bandwidth consumption. Therefore, it is verified that it is favorable to integrate ICN into the CDN architecture. Specifically, with a default cache size of 100 objects on CDN servers and correspondingly 10 objects on ICN routers, the average delay is reduced by approximately $46\%$, and bandwidth consumption is decreased by around $19\%$. Meanwhile, it is noteworthy that in the context of CDN, the reduction of bandwidth consumption and average delay exhibits a significant decline when the cache size per server increases from 10 to 200 objects, whereas there are only marginal benefits observed in the wide range of 200 to 500 cache size per server. This phenomenon can be attributed to the inherent characteristics of the Zipf distribution, wherein numerous objects are rarely accessed. The analysis of the impact of Zipf distribution on our proposed design is presented in the following section. A similar but more moderate trend can be also observed in the case of IECDN: when enlarging the cache size, despite a noticeable decline at the beginning, a saturation of both bandwidth consumption and average delay ensues with minor benefits continuing to be achieved. This enlightened us that less storage cost is required for CDN providers to achieve an adequate performance goal in the presence of in-network caching.

5.2.2. Impact of Content Popularity

As discussed in the above section, the Zipf distribution exerts inherent influence on our model. In this experiment, we attempt to explore this further by studying the most import factor of Zipf distribution: for the $\alpha$ parameter, the higher the value of $\alpha$, the more focused the users’ preferences. We still use the Abilene topology for analysis and change the $\alpha$ parameters of the Zipf distribution. Other parameters are set as the default. Additionally, we present the results with both the comparison between the two architectures and their performance gap as the $\alpha$ parameter varies. As demonstrated in Figure 8a,b, as $\alpha$ increases, both the total bandwidth consumption and average delay decrease as expected because with a higher $\alpha$ value, there are more requests for popular content, which makes caching play a more important role in improving performance. However, as $\alpha$ increases, the performance gaps between IECDN and conventional CDN also tend to narrow (as indicated by the green columns). Specifically, with the $\alpha$ value of 0.6, the total bandwidth consumption is reduced by 19.24 Gbps, and the average delay is reduced by 77.16 ms, whereas these two gaps narrow down to 6.66 Gbps and 27.43 ms, respectively, with the $\alpha$ value of 1.2. This is also because a higher $\alpha$ value leads to a more focused preference for popular content. Most content with high popularity is requested and cached on CDN servers, which in turn makes more content readily available on CDN servers. Therefore, the ICN in-network caching tends to be of service for fewer content requests, resulting in smaller performance improvement.

5.2.3. Resilience to Traffic Surge

At last, we attempt to dig deeper into our design’s resilience to traffic surge compared with conventional CDN. By increasing the content demand frequency, more content is demanded to be routed in the network simultaneously, thus increasing the traffic. We also set the demand rate at two different values, 0.5 and 1.0 Gbps. Both Abilene and Geant2 topologies are used for analysis. Figure 9 depicts the trend of total bandwidth consumption in the Abilene and Geant2 network topologies as the content demand frequency increases.

It is observed that at the demand rate of 0.5 Gbps, the total bandwidth consumption is trended as near linear in all scenarios. This meets the expectation because even with the largest demand frequency of 20, the network links are not subject to congestion. Apart from that, there is a subtle feature that the line of conventional CDN rises more steeply than that of our proposed design. Specifically, we calculate the slope of each fitted line (as indicated by the dotted lines) to provide a clearer indication of its rate of growth, and it shows that the growth rate of the total bandwidth consumption in conventional CDN outweighs that of our proposed design. At the demand rate of 1.0 Gbps, congestion is more possibly to occur in the network links as demand frequency increases. More and more content has to make a longer detour to avoid congestion instead of a Dijkstra shortest path as imposed by link constraints. Under these circumstances, a linear trend of bandwidth consumption is unsustainable in conventional CDN. However, in our proposed design, the bandwidth consumption still maintains closely linear, which benefits from the presence of in-network caching that alleviates network congestion. This demonstrates a better resilience to traffic surge by integrating ICN and is of great importance to traffic engineering.

5.3. 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 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)={\left(\frac{x}{x_{min}}\right)}^{-\alpha }$$

(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.

6. Discussion and Conclusions

ICN in-networking caching has been widely adopted to address issues in other fields because of its advantages in terms of less content retrieval latency, low network traffic and so on. This study focuses on the design and evaluation of utilizing the ubiquitous caching of ICN as a service to enhance the performance of CDN. To this end, first, we introduce the overview of our proposed design of a CDN enhanced with ICN, called IECDN, and elaborate on the mechanisms for enabling the collaboration between CDN and ICN to achieve efficient content delivery. Second, we formulate an optimization model derived from the MCF problem, which quantifies the optimization goal for content delivery. Through a series of numerical analyses, the results demonstrate that our design not only improves content delivery efficiency but also reduces the network load and is more resilient to network traffic surge. Based on these findings, we venture the conclusion that the ICN-based enhanced CDN distribution can economically satisfy the exponential growth of internet content without placing an unacceptable burden on link loads.

However, the ubiquitous caching and dynamic replica selection of ICN also pose a great challenge to the security design within ICN. In our framework, an associated manifest is generated when the content is published in ICN. Therefore, the manifest can be leveraged as a handle to ensure content-level security. In our forthcoming work, we intend to further explore the solutions to security issues by considering the distinctive features of our framework and using the existing mature security mechanism support. Moreover, we will explore more advantages of ICN in the domains where it can possibly provide better solutions.