Decoupling NDN caches via CCndnS: Design, analysis, and application

Journal Pre-proof Decoupling NDN caches via CCndnS: Design, analysis, and application Mostafa Rezazad, Y.C. Tay

PII: DOI: Reference:

S0140-3664(18)30737-0 https://doi.org/10.1016/j.comcom.2019.12.053 COMCOM 6110

To appear in:

Computer Communications

Received date : 26 August 2018 Revised date : 30 October 2019 Accepted date : 27 December 2019 Please cite this article as: M. Rezazad and Y.C. Tay, Decoupling NDN caches via CCndnS: Design, analysis, and application, Computer Communications (2020), doi: https://doi.org/10.1016/j.comcom.2019.12.053. This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. © 2019 Published by Elsevier B.V.

Journal Pre-proof

Decoupling NDN caches via CCndnS: Design, Analysis, and Application Mostafa Rezazada,∗, Y.C. Tayb IPM (Institute for Research in Fundamental Sciences) b National University of Singapore

pro

of

a

Abstract

Jo

urn al P

re-

In-network caching is considered to be a vital part of the Internet for future applications (e.g., Internet of Things). One proposal that has attracted interest in recent years, Named Data Networking (NDN), aims to facilitate in-network caching by locating content by name. However, the efficiency of in-network caching has been questioned by experts. Data correlation among caches builds strong dependencies between caches at the edge and in the core. That dependency makes analyzing network performance difficult. This paper proposes CCndnS (Content Caching strategy for NDN with Skip), a caching policy to break the dependencies among caches, thus facilitating the design of an efficient data placement algorithm. Specifically, each cache — regardless of its location in the network — should receive an independent set of requests; otherwise, only misses from downstream caches make their way to the upstream caches, i.e. a filtering effect that induces a correlation among the caches. CCndnS breaks a file into smaller segments and spreads them in the path between requester and publisher in a way that the head a file (the first segment) should be cached at the edge router close to the requester and the tail far from the requester and toward the content provider. Requests for a segment skip searching caches in its path, to search only the cache with the segment of interest. That reduces the number of futile checks on caches, and thus the delay from memory accesses. This mechanism also decouples the caches, so there is a simple analytical model for cache performance in the network. We illustrate an application of the model to enforce a Service Level Agreement (SLA) between a content provider and the caching system proposed in this paper. The model can be used for cache provisioning for two purposes: 1) To specify the cache size needed to be reserved for specific contents to reach the desired performance. For instance, the client of an SLA agreement requires a 50% cache hit for its content at each router. The model can be used to specify the size of the space in the cache needed to be reserved to reach the requested cache hit rate. 2) To calculate the effect of such reservations on other contents meets the router. The design, analysis, and application are tested with extensive simulations. Keywords: Information-Centric Networking, Named Data Networking, Network of Caches, Cache Policy, Performance Modeling, Service Level Agreement Preprint submitted to Elsevier

October 28, 2019

Journal Pre-proof

1. Introduction

pro

of

There has been a dramatic change in the usage of the Internet. The Internet is now the platform for TV broadcast, telecommunication systems, music and movie sharing, online games, cloud services (i.e., applications and resources), IoT gadgets (i.e., devices used in smart buildings and cities which can connect to the Internet), self driving cars (in the near future) and many other useful applications. To overcome inefficiencies of the default TCP/IP protocol, middleboxes have been designed for various purposes (i.e., security, mobility, efficiency, etc). There are multiple efforts to redesign the Internet architecture, to fulfill current and anticipated demands. One such revolutionary idea is Named Data Networking (NDN)[1], which aims to make a paradigm shift in the Internet architecture, from the current location-based addressing scheme to one that is content-based. Giving the address to content instead of location creates new opportunities, like the following:

re-

Application-Friendliness: Data is what users are interested in, whereas the current communication model forces us to look first for the location of the data. To facilitate this task, application-specific middleware is used to map the location to data (like DNS). Since NDN names data, applications can ignore all the middleware complications by addressing the data directly, via the smallest addressable unit of content, called a Data chunk.

urn al P

Security: Many attacks like phishing emerged from the location-based security pitfall. Securing only the communication channels and the devices in between two IP hosts is not an adequate security policy for an end-to-end communication model. By providing security at the content level, NDN not only offers better security but also ends all the location-based security difficulties. Broadcast-Friendliness: Data chunks in the NDN network can be broadcast easily without any concern about looping. Moreover, requests can be aggregated at the routers to increase bandwidth efficiency. This property of NDN makes it a preferable platform for streaming applications (especially live streaming).

∗

Jo

Mobility-Friendliness: Finding the location of a mobile device or content in an IP network is quite challenging. This difficulty is less severe in NDN as the location of the content is not important with NDN. Besides, caching contents inside all communication devices (including switches and routers) simplifies the mobility support for NDN. In case of packet loss (which is common in wireless communication) or moving a requester from one base station to another, the requested content can be found from a closer device by the resent request. I am corresponding author Email addresses: [email protected] (Mostafa Rezazad), [email protected] (Y.C. Tay) URL: ipm.ir/~mostafa (Mostafa Rezazad) 1 No. 1, Shahid Farbin Alley Shahid Lavasani st Tehran, Iran

2

Journal Pre-proof

urn al P

re-

pro

of

However, this paradigm shift from location-centric to content-centric networking requires rigorous research on many aspects. Major obstacles include memory access latency [2] and the performance of in-network caching [3]. Given the diversity of the traffic passing through a router, an efficient caching system may require relatively large memory. However, fast memory technologies are still expensive. On the other hand, slow memories increase the packet processing latency at a router, which increases the risk of incompatibility between the router’s speed and line speed. Therefore, solutions like better lookup algorithms, efficient memory architecture and tailored caching policies may be a more realistic way of dealing with the memory problem than replacing them with very high-speed memories. To rectify the memory inefficiency in NDN, this paper presents CCndnS, a content caching strategy that is a modification of CCndn [4]. CCndnS divides a file into segments, where a segment is larger than a chunk and smaller than a file. (This subdivision is consistent with segmentation in HTTP streaming.) The chunks in a segment are cached together in the same router, but different segments may be cached at different routers. A file is thus spread across multiple routers. We will show that spreading files along a path among the routers reduces unnecessary searches on the memory (so memory latency is reduced) and improves cache placement, and thus improving the performance of in-network caching. The caching design would benefit from a mathematical model for analyzing its impact. Unfortunately, one cache in a network can act as a filter for the traffic to another cache, thus inducing a correlation between the performance of the two caches. CCndnS is designed to break this dependency, by assigning segments to routers. This leads to a tractable analytical performance model for the caches. We present such a model and use it to implement a Service Level Agreement (SLA) application that guarantees performance for content under the agreement. Besides SLA enforcement, the model can also be used for other applications, like studying how collaboration among cache providers can impact the overall performance of the system. In the following, Section 2 first provides an overview of the NDN architecture. Section 3 then describes how CCndnS can improve the overall user satisfaction by overlapping download time of various segments, how CCndn spreads a file, and how content requests can skip router checks under CCndnS. The idea is examined and compared with various well-known caching policies in section 4. The model for CCndnS is derived in Section 5 and its application to Service Level Agreement is presented in section 6. Section 7 reviews related work before 8 concludes with a summary. 2. NDN Summary

Jo

Addressing content by name instead of location is the main idea of all Content-Centric Networks (CCNs), including NDN. In NDN, a content file (email message, software binary, mobile TV, etc.) is divided into Data chunks that are individually addressable by name. For a high-level view, a client retrieves a chunk by sending a Interest packet that specifies the name of the Data chunk. The routing scheme forwards the Interest towards the source, where the chunk can be found. Along the way, the Interest may find its Data cached at a router; the chunk then follows the reverse path taken by the Interest to reach the client. A 3

Journal Pre-proof

pro

of

router along the reverse path may decide to cache a copy of the Data. This is why Data can be found in the routers, away from its source. The routers thus become a network of caches, providing in-network caching. An NDN router contains three main tables, Forwarding Information Base (FIB), Pending Interest Table (PIT) and Content Store (CS). The functionality of the FIB table is similar to the IP routing table. Information on what data can be accessed from which interfaces are specified by FIB. The PIT provides the reverse-path information for the data to send back to the requester(s). When a data packet arrives at a node it is sent out to all interfaces obtained from the PIT. It also aggregates all the received requests for the same content and forwards only one request to the upstream node. This strategy prevents inefficient usage of bandwidth. The CS keeps a copy of the data chunks for a short period (subject to replacement policy and incoming traffic) to satisfy future requests for the same data chunk. In addition to the tables, there are a few algorithms used in an NDN router:

re-

• A routing algorithm to fill in routing tables, like for traditional IP routing. OSPFN is the extension of the OSPF routing algorithm that advertises names [5]. This is the main reason for the claim that NDN can coexist with TCP/IP and makes gradual deployment of NDN possible. • Cache admission policy that decides whether to cache newly arrived content at a router or just pass it to the next router without keeping a copy of it in the cache.

urn al P

• A cache replacement policy that decides which content in the cache should be replaced, to make way for some new content that is to be cached. There are several issues with this idea2 :

Jo

1. A chunk may be cached at multiple routers, and routers may cache unpopular chunks that are rarely hit. Both are a waste of caching capacity. 2. The number of content files on the Internet is huge, and many are large (e.g. movies). To hold a significant fraction of these files, the caches will also have to be large, and therefore use cheaper and slower technology (e.g. DRAM instead of SRAM) [2]. The need to access this memory (to check if Data for an Interest is there, or to insert a chunk into the cache) slows down the router. This delay can increase tremendously if traffic is heavy and queues build up. 3. A router that caches some popular Data will filter out Interests for this Data, and forward Interests for unpopular Data to upstream routers. If content popularity has a long tail, then chances are slim that the filtered Interests will find their Data at some intermediate router before the source [3]. Routers in the core of the network thus cache unpopular content. The resulting imbalance in workload degrades performance. 2

Since the focus of this paper is on cache structure, only related issues are presented here, and we ignore issues related to naming structure, security difficulties [6], congestion control [7], and other challenges discussed in the literature.

4

Journal Pre-proof

C

A1 B1 C1 D1

A2 B2 C2 D2

A3 B3 C3 D3

A4 B4 C4 D4

S

of

Figure 1: CCndnS can reduce redundancy and increase the number of distinct chunks in the network between client C and source S. In this example, a file B is broken into 4 segments (B1 , B2 , B3 and B4 ) and distributed between C and S. The routers can thus together fairly cache 4 popular files (A, B, C and D) in the network.

pro

4. The filtering effect above causes a cache to affect its upstream caches. This coupling makes it difficult to construct a mathematical model for analyzing cache performance. CCndnS addresses the above issues in the following ways:

urn al P

re-

1. CCndnS’s caching strategy reduces the number of redundant copies of a chunk. This frees up space in the core for caching more chunks for popular files, thus squeezing unpopular files out of caches in the core (see Fig. 1). 2. CCndnS allows an Interest to skip a cache, i.e. pass through a router without checking if its Data is there. This reduces cache misses and shortens memory queues, thus reducing router latency. 3. CCndnS raises hit rates for caches in the core, so they are better utilized. This increases the chance that an Interest can find its Data before reaching the source, and balances the workload among caches in the core and at the edge. 4. Skipping decouples the dependency among caches. This makes it possible to analytically model aggregate cache behavior of the network, using one equation that works for all caches regardless of their locations. In contrast, the analysis of the filtering effect is known to be hard [8]. 3. CCndn and CCndnS

This section is organized into three subsections. First, we present the objective of CCndn in Sec. 3.1. Second, a description of CCndn is presented in Sec. 3.2. Finally, for a complete description of the caching policy, CCndnS (stands for Chunk Caching NDN with Skip) is described in Sec. 3.3. Results from experiments on CCndnS behavior are provided in Sec. 4.

Jo

3.1. CCndn: Objective In NDN, clients request content by sending an Interest that explicitly addresses a Data chunk of a content file. The content may be an email, a voice call, etc., but, for convenience, we refer to them as files. CCndn is a caching policy (admission policy) that specifies which router should cache a chunk and how chunks should be replaced. By default, NDN caches a chunk at every router that the chunk visits [9]. This redundancy wastes caching capacity, especially when CS size is already small when compared to the number of files. Moreover, hits at edge routers filter out their Interests, so copies in the core get few hits [3], again wasting capacity. 5

Journal Pre-proof

re-

pro

of

A possible improvement is to selectively cache popular content at the edge, and unpopular ones in the core. Doing so with file popularity is impractical, since that requires ranking a large number of files on the fly, as new files are added and popularity shifts. Moreover, popular files can be large, and so squeeze out other files at the edge. Instead, CCndn spreads a file over multiple routers along the discovered path from the client to the source, with the head nearer the client and the tail nearer the source. We have three reasons for doing so: (i) Previous traffic measurements have shown that users tend to abort downloads [10, 11], so chunks at the head of a file are more popular than those at the tail. CCndn is thus consistent with the well-known observation that popular content eventually saturates the edge in a network of caches [12, 3, 13]. (ii) Cache space that is close to clients is precious. By caching only the head at the edge, this valuable resource can be shared with more files. (iii) For content like video (which now dominates Internet traffic), user-perceived latency depends on how soon the application can have enough of the file to get started. Delays in retrieving the rest of the file can be hidden by the time it takes for the application to consume the head; there is a similar idea in file layout for solid-state disks [14]. To show the effectiveness of CCndn, especially for video streaming traffic (which is the most important target for network caching), a simple and intuitive way of caching is compared with CCndn:

urn al P

• Full-Caching: Caching a file entirely in one CS. Based on this caching scheme, each CS contains several files, depending on the size of the CS. However, file redundancy among CSs is zero (a file is cached only in one CS). • CCndn: Each CS contains a fraction of each file. Therefore, one CS contains fractions of many files and different parts of each file are cached in several CSs.

Jo

Fig. 2 compares CCndn with Full Caching. In Fig. 2(a) three different parts of a file are downloaded from three consecutive nodes connected, back-to-back. Since all Interests to download a file are initiated at once, the traveling time of Interest can be overlapped. To download three files using this scheme, the timing diagram for all three files are the same and segment x of each file can be accessed from the router at hop distance x. On the other hand, Fig. 2(b) depicts the time-line of downloading three different files entirely from three consecutive nodes. Although Interest packets to download the three files are initiated at once, download time for them is different. To further support the ideas in CCndn and illustrate its effectiveness, Section 4 will compare it with a few other caching policies. 3.2. CCndn: Description To spread a file, CCndn divides it into segments, where the chunks in a segment are cached at the same router. To segment a file, we could use a hop count h to divide a file into h − 1 segments, and cache segment i at router i along the path from the client to source. However, if two clients with different hop counts request the same file, they would thus use different segment sizes 6

2 1 0

0

20

40

60 time

80

100

120

3 2 1 0

0

20

40

60 time

pro

3

Hop Distance Delay Download File 1 Download File 2 Download File 3

of

Hop Distance Delay Download Seg 1 of all Files Download Seg 2 of all Files Download Seg 3 of all Files

Hop distance of cache

Hop distance of cache

Journal Pre-proof

80

100

120

(b) Full Caching

(a) CCndn

re-

Figure 2: Time-line of downloading files with (a) CCndn and (b) Full Caching. In (a) three requesters request three files and 1/3 of each file is retrieved from three different nodes. Therefore, the time required to download each file is identical. In (b) three clients are downloading three different files that are entirely cached in three consecutive nodes. The blue line shows the required time for an Interest packet to traverse the network and reach the node with the requested file.

urn al P

and cannot share segments. With the skipping scheme that we introduce later in Section 3.3, different segment sizes for the same file will harm the cache hit rate. Instead, CCndn fixes the number of segments S, so each file F has S segments, with size chunk Nseg = dNFchunk /Se, F

(1)

Jo

chunk is the number of chunks per segment of file F and NFchunk is the number of where Nseg F chunks per file. (Table 1 is a summary of our notation.) CCndn uses another parameter H that does not exceed the smallest hop count between client and source. Suppose an Interest I from client C takes a path through routers R1 , . . . , RH−1 , . . . to reach the source, where Ri is i hops from C. Let mF that can be calculated by mF = dS/(H − 1)e, be the number of segments to cache in a router Then R1 caches segments 1, 2, . . . , mF ; R2 caches segments mF + 1, . . . , 2mF , etc. H is a bound on the number of routers for spreading the S segments. If S ≤ H − 1, then only the first S routers cache 1 segment each. Although H can be as large as the hop count from client to source, a smaller H will keep file F’s tail away from the edge at the source, so that premium space can be used by clients there. The most generic way to choose H is to set this value to the hope distance from a client to a source that can be found in the header of the Interest packet. In a more advanced way, an administrator of the network can set boundaries for this value again based on the hop distance. In a stable network with stable routing tables, we expect that all Interest packets of a file traverse through the same path and they all experience the same hop distance. How does a router know which segments it should cache? There is no addressing scheme for locating a router in NDN. However, since the path taken by a chunk exactly reverses the path taken by its Interest, we can use hop count to identify a router, as follows: 7

Journal Pre-proof

Table 1: Summary of Notation

NFchunk

number of chunks in a file F

chunk Nseg F

number of chunks in a segment of file F number of segments in a file

H

CCndnS bound on hop count for spreading a file

mF

dS/(H − 1)e for file F

hit Ppath

hit probability at a router

pro

hit Prouter

of

S

probability that Data is found in a router in a path, not at the source

Ncopies

number of copies of a chunk among the routers

Nhops

number of hops made by Interest before finding Data

urn al P

re-

An Interest I from a client C searches the CS in every router along its path to the source (Note that this requirement of checking all the caches in the path will be removed in CCndnS, as we will explain in the next section). I keeps track of the hop count from C in its search. I may hit its Data along the way and thus not reach the source Z. If I reaches Z, Z knows the hop count h from C. It then chooses an appropriate H value and calculates mF . Z then puts h and i (the hop distance of the router to cache the content) in each chunk’s header. As the chunk passes through a router on the reverse path to C, h is decremented. This value becomes i at router Ri , so Ri knows it has to cache that chunk; other routers do not cache that chunk as it passes through. If Data is retrieved from an intermediate router, the h value will be set to M AX value in the field and i will be reset to 0. Then this content would not be cached again in any routers in the path to the requester(s). When a cache is full, CCndn uses LRU (least recently used) replacement. This policy is close to optimal in practice [15].

Jo

3.3. CCndnS: Decoupling Caches We now describe how CCndnS decouples the caches by splitting a file and distributing the pieces along a search path. CCndn uses a segment as the granularity (bigger than a chunk but smaller than a file) for caching content. It follows that if an Interest finds chunk k of a file in router Rx , then, the Interest for chunk k + 1 should skip other routers and go directly to Rx . This is the key idea in CCndnS. With CCndnS, an Interest can use hop count to skip this search for some routers, as follows: (S1) The first Interest of a file checks every CS along its path to the Data source. (S2) An Interest keeps track of hop count in its search. If it finds its Data at some intermediate router Rx , the Data copies the hop count from the Interest and carries it back 8

Journal Pre-proof

to the client. The Interest for the next chunk of the file uses this hop count to skip CS checks, until it reaches Rx .

pro

of

(S3) Suppose an Interest does not find its Data at intermediate routers and retrieves the chunk from the source Z. Z puts in the header of this chunk the file size NFchunk , chunk the segment size Nseg , and the value i for the router Ri that should cache this F Data. When the client receives this chunk, it learns hop count i and puts that in the Interest it sends out for the next chunk so, like in (S2), CS checking can be skipped for R1 , . . . , Ri−1 . If the Interest does not find its Data at Ri , it skips subsequent routers and retrieves from Z.

re-

(S4) There is an exception to (S3): When a client learns the segment size, it can determine if the next interest I is for the first chunk in a segment; if so, I returns to (S1) and checks every CS. This is because the next segment of a file may be cached at an earlier router, possibly because some other client has retrieved it. So all Interests requesting the first Data chunk of any segment, search every CS but the other Interests of a segment only check the designated router Ri for that segment.

4. Evaluation

urn al P

The following section compares CCndnS with two ideal cache policies. These cache policies might not be practical but they serve the purpose of showing the effectiveness of our scheme. Besides, the algorithm is compared against four well-known cache policies specifically developed for NDN.

To illustrate the effectiveness of CCndnS, this section first compares it to two optimized cache policies. These two policies require strong assumptions about the information that is available for caching the files, so they are not practical. However, they set the performance bounds that we should try to get close to it. Later, the performance of CCndnS is evaluated using four real cache policies which are: Leave Copy Down (LCD) [8], Move Copy Down (MCD) [16], Probabilistic Caching (probcache) [17], and Leave Copy Everywhere (LCE) [9]. In designing the two reference cache policies, we considered two main objectives:

Jo

Performance of the network of caches. We measure this with network hit rate, defined as the probability that the desired content can be found in one of the router caches, instead of retrieving from the source. Content redundancy is one obstacle that lowers the network hit rate. Redundant copies waste cache space, and their filtering effect lower hit rates on upstream caches. Download time. We measure this with the distance (number of hops) from a requester to its desired content. A good policy should bring content closer to the clients to reduce the access time to the content. Many cache policies reduce download time by caching popular content close to the clients. The two caching policies are: 9

Journal Pre-proof

Random Fixed Point (Random): When an Interest hits the content provider (i.e., Interest could not find the content in any caches on the path), the cache placement policy randomly selects one of the caches on the path and allows the data chunk to be cached only at the selected cache.

pro

of

Popularity-Based Caching (Popularity): This algorithm assumes files are ordered by known popularity (the most popular file has index 0, the second most popular file has index 1, and so on); it caches n files at each cache using the following equation:   fi mod (θ · |caches|) +1 SelectedCache = θ

re-

where θ is the number of consecutive popular files to cache in a node, fi is the index of the file popularity, and |caches| is the number of nodes or caches in the path between requester and the content provider. For instance, if the number of caches in the reversed path (path for Data chunks as reserved by PIT tables) is 6, there are 50 files in the network and θ = 3, the files cached at the first node are: {0,1,2, 18,19,20, 36,37,38}3 . A similar idea is proposed in [18]. These policies have some interesting characteristics:

urn al P

• The cardinality of redundancy for both policies is close to one. Meaning, there is almost only one copy of a data chunk in each cache along the path. • Randomly distributing content with Random Fixed Point policy results in uniform effectiveness of the caches at different distances from the clients (i.e., caches become location-agnostic). • Popularity-Based Caching places the most popular files closer to the clients, thus reducing the average access time to content. We show that CCndnS have uniform cache effectiveness (like Random), yet have small average access time to content (like Popularity). The measurements that we use to make the comparison are:

Jo

hit Network Hit Probability: Pnet The probability that an Interest finds its Data at some hit intermediate router, instead of the source; a strategy with a higher Pnet is more effective in using the caches to relieve the load on the source. Because of the skipping technique (Section 3.3), the number of Interests searching for a router cache with CCndnS is not the same as the number of Interests searching that cache with the other two policies. Therefore, the comparison of hit probabilities at a single router cache is not meaningful.

Average Distance to Content: The average number of hops taken by Interests to retrieve the desired file. It shows how effective the algorithm is in bringing the content close to the requesters. 3

θ = 1 in our experiments

10

Journal Pre-proof

250 Requesters

R1

R2

R3

R4

R5

250 Files

R6

R9

R10

R11

R12

R1

R2

R3

R7

R8

R9

R10

R11

R12

 Requesters

pro

R8

R4

R5

R6

250 Files

re-

R7

of

Figure 3: Chained network consisting of 6 routers connected in a chain. 250 files are hosted by 250 content providers connected to router 6 (R6) and 250 clients connected to R1 are requesting the files.

Figure 4: Five chained networks consisting of 3 routers each are connected to router R4 that is chained to another two routers.

urn al P

Average Distance to the First Packet: The average number of hops taken by an Interest to find the first Data chunk of the desired file. Since CCndnS spreads the content along a path, this measure highlights the effectiveness of CCndnS. Number of CS Search: This is the number of caches that an Interest searches along its path. 500 clients and files

...

500 clients and files

...

R11

R7

R8

R10

R9

R4

500 clients and files

R6

R2

Jo

...

R3

...

500 clients and files

R1

R5

Figure 5: Abilene topology and its client setup.

4.1. Simulation setup Many experiments in the literature on the network of caches use a tree topology [19, 13, 16, 20, 21]. Such networks do not test a caching strategy’s effectiveness for multipath 11

re-

pro

of

Journal Pre-proof

Figure 6: Geant topology with 40 nodes. Gray nodes indicates the routers that are connected to clients. Double circled nodes are routers connected to the servers, for static node assignment.

Jo

urn al P

and cross-traffic. Others use large random graphs [22, 23], but these make it difficult to control the experiments and analyze their results. Instead, we choose four topologies from a simplest one to a more realistic topology to evaluate the idea: (I) a chained network (Fig. 3), (II) a chain with multiple branches (Fig. 4), (III) Abilene network4 (Fig. 5), and (IV) Geant network (Fig.6). Since the results obtained form network (II) are very similar to the results from the network (I), we omit them here to avoid repetition. The chained network is selected for its simplicity, which allows us to focus on the characteristic of the caching policies. The performance of the policies on a more realistic scenario is tested on Abilene and Geant networks. A chained network is built by linking routers back-to-back, where the first and the last routers are connected to the end-hosts. End-hosts in a traditional network are clients and servers but here they are requesters and content providers (a requester can be a content provider as well). The chain network used in our evaluation (Fig. 3) consists of 6 routers with the first router connected to 250 requesters, and the last router connected to 250 content providers that each provides one file to share. The cache size of each router varies from 300 Data chunks to 3000 Data chunks. As each file consists of 500 Data chunks, the ratio of individual cache size to catalog size varies from 0.24% to 2.4%. Assuming content providers do not generate similar content, we observed that the behavior of the network with two-way traffic is similar to having just one-way traffic. Hence, we only present results for one-way traffic; i.e., requesters do not generate any content, and content providers do not initiate any requests for content. 4

http://nic.onenet.net/technical/category5/core topology.htm

12

Journal Pre-proof

Jo

urn al P

re-

pro

of

To set up the Abilene network, we attach clients only at routers R1, R2, R10 and R11, so these are edge routers; the other seven are core routers. Each edge router has 500 clients, and each client generates a file that has a geometrically-distributed size of 250 chunks, on average. The catalog of all files thus has about 4 × 500 × 250 = 500, 000 chunks. To provide results with a larger network, Geant topology which is a real testbed network in Europe5 is used. For this network, we set up two different scenarios: 1) location of content providers and clients are fixed 2) Content providers and clients are randomly distributed in the network. Each file has 600 data chunk length and there are 4000 files in the network. 3000 clients are requesting these files. The length of files and the number of files are set larger compared to the previous experiments to increase catalog size and reduce the ratio of cache size to catalog size. Unless otherwise stated, in each run of the experiment routers have the same CS size. This size for Abilene is from 300 to 10,000 chunks. Therefore, the cache size to catalog size ration varies from 0.06% to 2%. For Geant topology, CS size is set from 100 up to 3000 data chunks. That gives the cache size to catalog size ratio of 0.00416% to 0.125%. The cache size to catalog size ratio in this paper is more realistic compared to the 5% used by Fayazbakhsh et al. [12]. However, we follow these authors in using a request-level simulator that does not model details like router queues and TCP congestion control. A client sends Interest for a file at a constant rate. The time between the first Interests of two files is exponentially distributed; this means that, sometimes, a client may be downloading multiple files concurrently. However, we require the interest for chunk k + 1 be sent after the reception of chunk k. This prevents us from using advanced congestion control mechanisms (like Carofiglio et al. [7]) that would instead require to send a batch of interests to study congestion control. For the chained network, clients at R1 request files from clients at R6 . In the case of Abilene, the clients at R1 and R2 request files from clients at R10 and R11 , and vice versa, so there are 2 × 2 × 2 × 2 = 16 flows. Traffic generated in this way travel along the long side of the network, and there is cross traffic in all routers because of Interest flow to and fro. For Geant scenario 1 (content providers and clients are fixed), clients attached to 6 routers on the east side of the network are requesting files attached to 8 routers on the west side of the network. The selected routers remain the same throughout the entire experiment. On the other hand, the same number of routers for clients and content providers are selected randomly considering all routers in the network for scenario 2. Interests are routed via the shortest path to the source. If there are multiple paths from a router R to the source, R multicasts the first Interest of the file to all of them; R then chooses the one that brings back the Data chunk first, and uses that for the rest of the simulation [1]. As is common practice, we use a Zipf distribution with parameter α to model the popularity of files [24]. The default value for α is one. The figures that do not explicitly mentioned the value of α, the default value is set for them.

5

https://www.geant.org/Networks/Pan-Europeann etwork/P ages/GEAN Tt opologym ap.aspx

13

Journal Pre-proof

0.5

CCNDNS Random Popularity

0.4

0.2 0.1 0.0

500

1000

1500 2000 Cache size

2500

of

0.3

3000

pro

Network Hit Probability

0.6

Figure 7: Probability of finding a data chunk from one of the caches in the network.

re-

In the plots, each data point is the average of 5 runs but, to avoid clutter, we omit error bars.

Jo

urn al P

4.2. Evaluation: Chained Network All figures plot performance against different cache sizes, thus assessing the algorithms when the cache size varies. Fig. 7 compares the three policies for their network hit probability. It shows that CCndnS and Random cache placements are performing better compared to Popularity when the cache size of each router is small. This is because traffic is more uniformly distributed with these two policies, and all caches throughout the network are utilized. In contrast, with Popularity, only the edge caches that hold popular files are beneficial. The memory space of the edge router may not be large enough to hold a complete file (i.e., 300 chunks is smaller than the size of one file), as can happen for popular multimedia files. In that case, it is possible that thrashing happens because Data chunks of popular files compete over the cache space. In practice, to prevent thrashing for an algorithm like Popularity, the number and the size of the popular files determine the minimum cache size. Even so, there is a non-stop generation of content on the Internet, and the size and the number of popular files are very dynamic, so any cache size at the edge routers can become insufficient. Therefore, algorithms that perform well with small cache sizes are more desirable. Fig. 8 compares the three algorithms on how effectively they can bring content closer to the requesters. The average distance to content is shown in Fig. 8a and it shows that when the cache size is sufficiently large, Popularity can bring content closer to the requesters. This result shows that caching the most popular files closer to the requesters truly matters. However, Fig. 8b shows that CCndnS with any cache size brings the first Data chunk of each file even closer to the requesters. The access time to the first Data chunk of a file matters a lot as the access time to other Data chunks can be overlapped with the previous Data chunk (see Fig. 2). The ability to cache chunks from more files at the edge router is the main reason for CCndnS’s reduced access time for the first chunk. 14

500

1000

1500 2000 Cache size

2500

3000

7.0 6.5 6.0 5.5 5.0 4.5 4.0 3.5 3.0

CCNDNS Random Popularity

of

CCNDNS Random Popularity

500

1000

pro

7.0 6.5 6.0 5.5 5.0 4.5 4.0 3.5 3.0

Average Distance to First Packet

Average Distance to Content

Journal Pre-proof

(a) The average distance to all chunks that are retrieved (either from cache or the provider)

1500 2000 Cache size

2500

3000

(b) The average distance to the first chunk of files.

re-

Figure 8: Average distance to content for (a) all content and (b) the first chunk of each file.

7

CCNDNS Random Popularity

5 4

urn al P

Number of CS Search

6

3 2 1 0

500

1000

1500 2000 Cache size

2500

3000

Figure 9: The average number of CS search before finding data.

Jo

Another encouraging result supporting CCndnS is shown in Fig. 9, for the average number of lookups to find a chunk (within the network or from the source). If the data chunk is not cached in the network or not placed in a proper location, this lookup average increases rapidly. The objective of a caching system is to reduce file access time and increase system throughput, but an inferior caching scheme can degrade this performance by forcing all Interests to waste time searching many caches. If the caching system, for some reason such as dynamic file popularity, does not perform adequately, unsuccessful CS searches negatively impact the performance of the system [25]. Since CCndnS spreads content along a path, an Interest can expect to find its Data chunk at the specified hop distance from the requester, thus reducing CS search to just one search for most circumstances. 15

Journal Pre-proof

CCNDNS Random Popularity

0.5 0.4

0.2 0.1 0.0

0

2000

4000 6000 Cache size

8000

of

0.3

10000

pro

Network Hit Probability

0.6

urn al P

re-

Figure 10: A comparison of network hit probability. (A network hit is when an Interest finds Data in some CS, instead of retrieving it from the source.)

Figure 11: The average distance to content for the three algorithm and for Abilene topology.

To find more complicated, unexpected and possibly counter-intuitive behavior, we also ran experiments with the Abilene network (Fig. 5). The results are presented in the next section.

Jo

4.3. Evaluation: Abilene Now that the three polices have been compared using the simplest possible network, we examine their performance in a more realistic scenario. With the Abilene network, we can generate more diverse traffic, and paths with different lengths. In Fig. 5, there are 4 sources of content, connected to the routers R1 , R2 , R10 and R11 . Surprisingly, Fig. 10 shows that using this configuration, regardless of the router cache size, Popularity performs worse than the other two in finding the Data chunks from the network. This is against the previous finding with the chained network. The reason is, by caching the most popular files at the edge router, Popularity tries to increase the performance of the edge router which is the closest cache to the requesters. For the Abilene topology, 16

Journal Pre-proof

7

5 4 3 2 1 0

2000

4000 6000 Cache size

8000

5 4 3 2

10000

0

CCNDNS Random Popularity 2000 4000 6000 Cache size

pro

0

6

of

CCNDNS Random Popularity

Average Distance to First Packet

Average Distance to First Packet

6

(a) Content found from CSs.

8000

10000

(b) Content found from either CS or content providers.

re-

Figure 12: Average distance to the first chunk of requested files, found (a) from router CS, (b) from CS or content provider.

Jo

urn al P

however, if the most popular files were cached at the core routers (e.g., R5 and R6 ), more requesters from various parts of the network can benefit from the cache and the network hit probability would increase. It is important to emphasize that, file popularity is a network-wide parameter (not a local measure). However, since the requesters are randomly selected, a globally popular file may be less popular for one set of requesters than another. For instance, a popular file may have different popularity index at router R1 compared to router R2 . One conclusion is that a network-wide popular file should be cached at the core of the network to satisfy requests coming from different corners of the network, even if it is not popular at a particular location in the network. Fig. 11 shows the average distance to content for Abilene topology. Based on this figure, for very large cache sizes, CCndnS approaches to the Popularity scheme in terms of bringing data closer to the requesters. Fig. 12 represents the average distance to the first Data chunk of a file when it is found from a cache (Fig. 12a), or found from either a cache or the content generator itself (Fig. 12b). The results show that the distance to the first Data chunk with CCndnS is almost equal to one when only cache hits are measured. This is because CCndnS places the first segment of a file at the edge router, regardless of its popularity. Therefore, if the file can be found within the network, its first Data chunk is always found at the edge router. Since Popularity caches the most popular files at the edge router, compared to Random, it brings more popular Data closer to the requester when only router cache hits are considered. However, when both router cache and content generators are considered (Fig. 12b), Random is slightly better as its network hit probability is more than Popularity (Fig. 10). Fig. 13 shows that even with a more complex topology like Abilene, and clients from different locations can request the same data, data redundancy is still almost one for all 17

0

2000

4000 6000 Cache size

8000

5 4 3 2 1

10000

CCNDNS CCNDN Random Popularity

0

of

CCNDNS Random Popularity

2000

4000 6000 Cache size

pro

2.00 1.75 1.50 1.25 1.00 0.75 0.50 0.25 0.00

Number of CS Search

Data Redundancy

Journal Pre-proof

Figure 13: Data redundancy: the number of copies of each data chunk cached in the network.

8000

10000

Figure 14: The number of Routers need to be searched for content before finding it.

urn al P

re-

three policies. Moreover, Fig. 14 is consistent with the previous finding that the skipping scheme of CCndnS is effective. However, since the network hit probability for Popularity is worse than Random with the Abilene network, the average number of CS searches required to find data using Popularity is more than Random. A graph for CCndn (without Skip) is included in this figure to show the effectiveness of the skipping idea. The key conclusion is that, unlike the common practice of caching popular files in the edge routers, a heterogeneous traffic pattern can mean that caching in the network core is more effective.

Jo

4.4. Evaluation: Geant The topology used to compare CCndnS with other cache policies is Geant topology with 40 routers. We report the results with 4 types of simulation scenarios: 1) fixed location of files and clients with popularity parameter α = 1, 2) fixed location of files and clients with popularity parameter α = 0.8, 3) random location of files and clients with popularity parameter α = 1, 4) random location of files and clients with popularity parameter α = 0.8. The other parameters like the number of files and cache sizes remain the same in all scenarios. Our results are compared against four cache policies: LCD (Leave Copy Down) [8], MCD (Move Copy Down) [16], ProbCache (Probabilistic caching) [17] and LCE (Leave Copy Everywhere) [9]. To depict the graphs, Seaborn data visualization library6 is used to include the error space for multiple runs of each scenario. However, when content providers and requesting clients have fixed locations, there is not much randomness in the system and error space is not very visible. Figures Fig.15,Fig.16, Fig.17, and Fig.18 illustrate that CCndnS outperforms the other policies in Network hit rate when the cache size is smaller than one file (i.e., CS size is less than 600). In this case, thrashing occurs for other cache policies. Only CCndnS and ProbCache are exceptions whilst CCndnS beats ProbCache in utilizing cache better. In 6

https://seaborn.pydata.org/

18

Journal Pre-proof

our experiments, we have only one file in each class of popularity. Therefore, having enough space for the most popular file in caches is sufficient to get a high hit rate in the network. In practice, there might not be enough space in a single cache to store all popular files in their entirety.

0.20

0.150 0.125 0.100

pro

Network hit

0.25

0.175

Network hit

0.30

algorithm CCndnS LCD MCD ProbCache LCE

of

algorithm CCndnS LCD MCD ProbCache LCE

0.35

0.15 0.10

0.075 0.050

0.05

0.025

0.00

0.000

Figure 15: Network hit: Fixed Source Destination with α = 1

100 200 300 400 500 600 800 1000 2000 3000 cacheSize

re-

100 200 300 400 500 600 800 1000 2000 3000 cacheSize

Figure 16: Network hit: Fixed Source Destination with α = 0.8

Network hit

0.15 0.10 0.05 0.00

200

300

400

500 600 cacheSize

700

1000 2000

Jo

100

Figure 17: Network hit: Random SourceDestination with α = 1

algorithm CCndn LCD MCD ProbCache LCE

0.10 0.08 Network hit

algorithm CCndnS LCD MCD ProbCache LCE

0.20

urn al P

Figures Fig. 19, Fig. 20, Fig. 21, and Fig. 22, shows that the distance of the clients to the first packet of all files is much closer for CCndnS than the other policies regardless the cache size. That is because, CCndnS brings the head of more files closer to clients. Figures Fig. 23, Fig. 24, Fig. 25, and Fig. 26, reveals that only CCndnS and MCD reduce data redundancy to one copy of each file in the network.

0.06 0.04 0.02 0.00 100

200

300

400

500 600 cacheSize

700

1000 2000

Figure 18: Network hit: Random Source Destination with α = 0.8

19

Journal Pre-proof

3 2

200

Figure 21: with α = 1

300

400

500 600 cacheSize

700

Random Source-Destination

4 3 2 1

3.5 3.0 2.5

algorithm CCndnS LCD MCD ProbCache LCE

2.0 1.5 1.0

algorithm CCndnS LCD MCD ProbCache LCE

Jo

Average data redundancy

2.5

300

400

500 600 cacheSize

700

1000 2000

5 4 3

algorithm CCndnS LCD MCD ProbCache LCE

2 1

100 200 300 400 500 600 800 1000 2000 3000 cacheSize

Figure 20: Fixed Source Destination with α = 0.8

3.5 Average data redundancy

Figure 19: Fixed Source Destination with α=1

3.0

200

6

100 200 300 400 500 600 800 1000 2000 3000 cacheSize

3.5

100

Figure 22: Random Source Destination with α = 0.8

urn al P

5

4.0

2.0

1000 2000

6

4.5

pro

100

5.0

of

Average distance to first packet from CS

4

algorithm CCndn LCD MCD ProbCache LCE

5.5

Average distance to first packet from CS

5

1

Average distance to first packet from CS

6.0

algorithm CCndnS LCD MCD ProbCache LCE

re-

Average distance to first packet from CS

6

3.0 2.5

algorithm CCndnS LCD MCD ProbCache LCE

2.0 1.5 1.0

100 200 300 400 500 600 800 1000 2000 3000 cacheSize

100 200 300 400 500 600 800 1000 2000 3000 cacheSize

Figure 23: Fixed Source-Destination with α=1

Figure 24: Fixed Source Destination with α = 0.8

20

Journal Pre-proof

algorithm CCndnS LCD MCD ProbCache LCE

2.2 2.0

2.4

1.8 1.6 1.4 1.2

2.2 1.8 1.6 1.4 1.2

1.0

1.0 200

Figure 25: with α = 1

300

400

500 600 cacheSize

700

1000 2000

100

200

300

pro

100

algorithm CCndn LCD MCD ProbCache LCE

2.0

of

Average data redundancy

2.4

2.6

Average data redundancy

2.6

Random Source-Destination

400

500 600 cacheSize

700

1000 2000

Figure 26: Random Source Destination with α = 0.8

urn al P

re-

To show that the performance of CCndnS is independent of path length (it does not require fixed path length between requesters and publishers), Fig. 27 illustrates the distribution of path lengths of Interests to the content provider. Even if the Interest is satisfied by an intermediate cache, still the bar shows the length of the shortest path from the requester to the content provider. In overall, this section shows the effectiveness of CCndnS algorithm compared to other rival algorithms in increasing the performance of the network of caches in several ways: first, for small cache sizes (smaller than one popular file) using CCndnS the performance of the network of caches is the best (Fig 15). Second, for larger cache sizes, LCD and CCdndS are performing very close in terms of cache performance but CCndnS brings the head of a file closer to the requester (Fig. 19). Also, CCndnS significantly reduces the average data redundancy. That proves that CCndnS improved the performance of the overall network whilst LCD only improves the performance of the edge router.



7UDIILF3RUWLRQ

  

Jo

  







  +RSB'LVWDQFH







Figure 27: The average length of paths between requesters and publishers.

21

Journal Pre-proof

5. An Analytical Model for CCndnS

pro

of

In a conventional network of caches, the input to an upstream cache depends on the miss rates at downstream caches (closer to the client). This makes it very difficult to construct a mathematical model to analyze their performance. However, segmenting files and skipping caches in CCndnS considerably weakens this dependency. As illustrated in Section 4, there is, on average, almost only one CS search for every Interest along a path to the source. Therefore, miss or hit at one cache has no effect on the traffic to the upstream caches. This decoupling makes it possible to model cache behavior with some straightforward equations. The model is presented in [26] but we briefly review the model here. hit hit The probability of finding a Data chunk at a router (Prouter ) is derived first. Prouter , and the probability of whether an Interest checks CS or not, lead to the probability of finding hit ) and the hop distance of content from the requester a Data chunk from the path (Ppath (Nhops ).

re-

hit 5.1. Router Hit Probability Prouter In router r with CS size of Mr , the Interest arrival rate is λr , and average time a Data chunk stays in the router is Tr . By Little’s Law [27],

Mr = λr Tr .

(2)

urn al P

Under CCndnS, only a subset of the catalog is eligible for caching at router r; let Cr be the size of this subset. Let pf be the probability that an arriving Interest requests file f . Let Mrf be the size of router r’s CS that is occupied by chunks from file f . However, the part of file f that can be cached at router r is a fraction kf of Cr . Then the probability of a cache hit at router r is hit Prf =

Mrf Cr kf

(3)

The Interest arrival rate for file f is pf λr , so, in steady state, the equation becomes: ( (pf λr )Tr if pf λr Tr < Cr kf Mrf = C r kf if pf λr Tr ≥ Cr kf

Jo

where the second case applies if Mr is so large that router r can accommodate all chunks of file f that is to be cached there. By Eq. 2, we get ( Mr pf if Mr pf < Cr kf Mrf = (4) Cr kf if Mr pf ≥ Cr kf The probability of a hit at router r is, by Eq. 3, Prhit =

X

hit Prf pf =

k

22

X Mrf pf . Cr kf f

(5)

Journal Pre-proof

0.975

0.90 0.85 0.80

0.950 0.925 0.900 0.875

1000

Cache Size

1500

2000

500

1000

Cache Size

1500

R16

0.95

Model Simulation

0.90 0.85

2000

re-

500

Model Simulation

CS Miss probability

R10

Model Simulation

CS Miss probability

CS Miss probability

R14 0.95

pro

of

To show the accuracy of the model, the results obtained from Geant topology for three of the routers; an edge router, a router close to the edge and a core router; when sources and destinations are randomly selected are reported in Fig. 28. Note that, the model requires the popularity of files in the equation. We use the simulation information to find out which files are passing through the selected router. Then, the popularity of the file is calculated by Zipf distribution and used in the equation. When going deep into the core of the network, different segments may have slightly different popularity as they get globally. Thus, the accuracy of the model a bit reduces for core routers. Nevertheless, still, the model can be used as the trend is kept intact.

500

1000

Cache Size

1500

2000

Figure 28: Compared the result of the Model with the Simulation regards ”CS miss probability” for routers R14 (an edge router), R10 (a middle router), and R16 (a core router) in Fig. 6.

urn al P

hit 5.2. Path Hit Probability Ppath To calculate an aggregated metric for a path from a requester to a source of requested content, we first determine P rob(check), the probability that an Interest checks a CS. We assume every file in the network has, on average, NFchunk Data chunks. Router r checks its CS only for Interests whose Data the router is eligible to cache. Thus, to find P rob(check), we first need to estimate the number of chunks of a file that a CS caches. If S ≤ H − 17 , then router r caches at most 1 segment, which has NFchunk /S chunks; if S > H − 1, then the router caches, on average, NFchunk /(H − 1) chunks. Router r thus gets approximately I1 = NFchunk / min(S, H − 1) Interests for the chunks that it caches. In addition, CCndnS requires the Interest for the first chunk of a segment to probe every router; at worst, router r gets I2 = S Interests for this probing. We therefore estimate P rob(check) as (I1 + I2 )/NFchunk , i.e.

Jo

P rob(check) ≈

1 S + chunk . min(S, H − 1) NF

(6)

This approximation does not model how P rob(check) depends on r (e.g. Interest for the first chunk of a segment checks every CS in its path only until it gets a hit), as the effect is minor for large files (like video).

7

see Table 1 for notations.

23

Journal Pre-proof

Now suppose the route taken by Interests passes through routers 1, 2, . . . , i before reaching the source. The path hit probability is then hit = Ppath

i X

Prob(check)Prhit .

(7)

r=1

pro

of

hit hit For topologies like the chained network, Prouter = Pnet . For a more complicated graph like hit hit Geant topology, these two parameters Ppath and Pnet are different and to find out any of the measuring values, we need to collect some information from the simulator. This information is: the catalog size passing by the router and the popularity of the files meet the router.

5.3. Average Hop Count Nhops Similarly, the average hop count is

r=1

hit rProb(check)Prhit + (i + 1)(1 − Ppath )

(8)

re-

Nhops =

i X

urn al P

where the second term is for the Interest packets that hit the content publisher as they did not find the requesting data from the network. hit hit and Nhops ) ) and global (Pnet Our equations can thus accurately model both local (Prouter performance. The next section presents an application of this model to partition the caches and thus enforce Service Level Objectives for specific traffic classes. 6. Application: Service Level Agreement

Jo

A Service Level Agreement (SLA) is a part of a service contract between the producer of content and a distributor of content. The cache in NDN router offers an ISP the opportunity to play the role of a small content distributor. ISPs can dedicate some part of their routers’ memory to some specified content, based on an agreement with the content producer. Although it is not necessary to have an SLA contract for a complete file (ISP can reserve memory for only a fraction of a file), in our experiments, we assume the SLA contract is for entire files. An SLA file is divided into S segments and a portion of memory (how much depends on hop count H) is allocated at all routers along the paths between the target clients and the content provider. These portions are reserved for the SLA files only, and cannot be replaced by any other files. In this section, we examine the effect of this memory partitioning on the overall performance of the cache, and on the other cache contents that are not covered by the SLA contract. We use simulation setups that are similar to those in Sec. 4.1. Later, in Section 6.2, we use the model in Sec. 5 to estimate the impact of the agreement on the cache. The model is used for provisioning the minimum required memory when there is an SLA contract between the content distributor and the content provider, to achieve the desired level of performance. 24

Journal Pre-proof

of

Under SLA, the memory of a router is divided into two sections: shared area and dedicated area. The size of the dedicated area depends on the SLA contract; a larger dedicated area reduces the shared area for other files. In the following sections, the performance of the network of caches is evaluated for two cases: (a) when the SLA is for popular files and (b) when the SLA is for unpopular files. The results are compared to the case where there is no SLA contract. When the SLA is to reserve cache space for unpopular content, the equations can be used to estimate the extra memory space that should be provided for caches to perform at the same level of performance as when there is no SLA.

urn al P

re-

pro

6.1. Evaluation: Abilene Network The results from experiments with SLA for the Abilene network are presented in Fig. 29. The results for the chained network are omitted as these results are consistent with the Abilene network. The reason for this consistency is that, although there are multiple traffic flows and multiple paths in the Abilene network, the SLA is for specific files. The SLA files are generated in specific source nodes and consequently, the topology of the SLA paths would be a single- or multi-chained network, like Fig. 3 and Fig. 4. For instance, if the SLA file is in the source node that is connected to router R10 , then there are two almost disjoint chained networks of R2 , R4 , r5 , R9 , R10 and R1 , R3 , R6 , R8 , R9 , R10 from the requesters of that SLA file. Hence, for the next section, we only focus on the chained network.

Jo

6.2. Applying the model to SLA In this section, we first evaluate the accuracy of the model proposed in Section 5 for estimating cache performance when the memory is partitioned among SLA files and other files. The two important metrics for measuring the performance under SLA are average hop distance to content and router CS hit rate. Calculation of average hop distance to content (the average is taken over all Interests for all chunks of the file) depends on calculating router CS hit rate (see Eq. 7 and Eq. 8). Eq. 5 calculates router hit probability when the memory size of the routers is known. Here, we are interested in the memory size of the routers to reach a specific router hit probability. Therefore, Eq. 5 and Eq. 4 together can specify the memory size needed for a particular router hit probability. To validate Eq. 8 for measuring hop distance to content, Fig. 30 compares the model’s predictions to simulation results for two cases: when SLA files are very popular (Fig. 30a) and when they are not very popular (Fig. 30b). Fig. 31 assesses the model for CS miss probability of one single router when there is no SLA and when there is an SLA for two less popular files in the router. Since SLA files receive the maximum CS hit, we are mainly interested in studying the effect of the contract on the other files. Therefore, excluding the SLA files in our evaluations, the two graphs in Fig. 31 reports CS miss for all data chunks that cannot be found from the cache of a router. SLA files are not considered in the CS miss calculation. All experiments are conducted using small memory sizes as this is the most relevant area. 25

Journal Pre-proof

0.4 0.3 0.2 0.1 0.0

0

1000

2000 3000 Cache size

4000

5000

1000

2000 3000 Cache size

4000

5000

7

re-

4.50 4.25 4.00 3.75 3.50 3.25 3.00 2.75 2.50

0

(b) Average distance to any content in the network.

0

1000

urn al P

Average Distance to SLAs

(a) Network hit rate.

2_Most_Popular Less_Popular Without SLA

of

0.5

7.0 6.5 6.0 5.5 5.0 4.5 4.0 3.5 3.0

pro

Network Hit Probability

0.6

Average Distance to Content

2_Most_Popular Less_Popular Without SLA

Average Distance to the Most Popular File

0.7

2_Most_Popular Less_Popular 2000 3000 4000 5000 Cache size

(c) Average distance to all SLA files in the network.

6 5 4 3 2

0

1000

2_Most_Popular Less_Popular Without SLA 2000 3000 4000 5000 Cache size

(d) Average distance to the most popular file.

Figure 29: Results of SLA contract for the Abilene network.

Jo

As discussed in Sec. 6.1, a chained network is used to test the performance of the SLA contract. However, to highlight the accuracy of the model, in this part we increased the length of the chained network to 11 routers. Table 2 first shows the accuracy of the model by comparing its predictions with simulation results; second, it estimates the extra memory space needed, under SLA, to maintain the same performance as when there is no SLA. For instance, for a memory size of 200 Data chunks, the probability of CS hit is equal to 0.3 when there is no SLA for the router. The equation is used to estimate the memory size needed for the same hit probability of 0.3 when there is an SLA for two less popular files. The simulated experiments verify the correctness of this estimation.

26

12

200

300

400 500 Cache Size

600

11 10 9 8 7

700

Simulation Model

200

of

Simulation Model

300

pro

12.0 11.5 11.0 10.5 10.0 9.5 9.0 8.5 8.0

Average Hop Distance

Average Hop Distance

Journal Pre-proof

(a) SLA for the two most popular files.

400 500 Cache Size

600

700

(b) SLA for two unpopular files.

Figure 30: Model evaluation for SLA

0.6 0.4

urn al P

CS Miss Probability

0.8

re-

1.0

Simulation without SLA Model Without SLA Simulation with SLA Model with SLA 0.0 200 300 400 500 Cache size 0.2

600

700

Figure 31: Comparison between simulation measurements and the model, for miss probability at a single cache when there is no SLA and when there is SLA for two less popular files (index 40 and 49). The data here are for all files except SLA files, which are also called ”other files”.

7. Related Work

Jo

The version of Content-Centric Networking that we discuss here was first proposed in [9], as an example of information-centric networking (ICN). The next version of CCN was proposed in [28] as Named Data Networking (NDN) which is still an active project. NDN has been growing vastly in terms of applications such as, smart homes [29], adhoc networks [30], vehicle applications [31], wireless sensor notworks [32], IoT (Internet of Things) [33], etc. However, the main advantage of NDN lies in its compatibility with the current infrastructure. A tunneling method to run NDN on top of TCP/UDP protocols is proposed in [34]. One advantage of NDN over rival proposals is its ability to cache content. Ager et al. have confirmed the cacheable of Internet traffic in [35]. However, caching performance 27

Journal Pre-proof

Table 2: The equation can be used to find the extra memory size needed to keep the CS hit probability for the edge router. Results are for having SLA for unpopular files 40 and 49 only at the edge router.

of

With SLA CS hit probability Memory size Equation Simulation 0.30 0.28 380 0.39 0.38 480 0.45 0.44 580 0.49 0.48 680

pro

Without SLA CS hit probability Memory size Equation Simulation 0.30 0.27 200 0.39 0.38 300 0.45 0.43 400 0.49 0.48 500

Jo

urn al P

re-

depends on content popularity, caching policy, etc. [36]. Bad caching policy can even hurt performance. There is some skepticism over whether ICN in general, and NDN in particular, are fundamentally feasible. For Ghodsi et al., ICN’s in-network caching is futile because most hits will occur only at the edge, where the popular files are cached [3]. Perino and Varvello’s calculations also show that memory technology (e.g. size and speed) cannot match line speed at reasonable cost for NDN [2]. In a newly published article, it is shown that increasing the size of memory increases both the performance of the cache by storing more popular content and the cost of deployment. Based on this observation, a caching scheme is introduced to increase the performance of the small-sized caches [37] to reduce the cost of deployment. Nevertheless, their mathematical solution to find the optimum model cannot be used in practice. In this paper, we make no effort to examine whether NDN is feasible. Rather, the questions we pose are: How can we improve in-network caching for NDN? Is caching in the core routers futile? Is it possible to design a caching strategy that can be analyzed mathematically? In-network caching resembles cooperative web caching. Several papers have proposed protocols for such cooperation [38, 39, 40], but Wolman et al.’s analysis shows that they have marginal benefit for large populations [41]. However, that analysis used traffic data from some 19 years ago, when the Web was very different from today. In the case of ondemand TV, for example, Li and Simon have shown that their cooperative caching strategy can significantly reduce cross-domain traffic [42]. In general, although this problem has been studied extensively with optimization techniques for different applications such as Content Delivery Networks, IPTV, web-caching, etc, these are based on specific applications and topologies (e.g., hierarchical structures). The constraint for NDN is far tighter as caches are placed in the networking infrastructure (layer-3). Therefore, the cache placement problem in Information Networking is completely different from the previous application based caching [43]. An optimal cache placement is proposed in [43]. They proposed a two-step method to solve their equation that is based on the benefit of caching at each node. Caching nodes at further nodes reduces the benefit as well as caching less popular content. Since the optimal cache placement is not practical, they introduced a sub-optimal heuristic approach. Still, their heuristic approach requires a lot of graph computation. 28

Journal Pre-proof

Jo

urn al P

re-

pro

of

Many studies are using CCN to solve some of the problematic aspects (like connectivity) of mobile networks [44, 45, 31]. The aim of these studies to solve their problem using cache and their idea does not have to be efficient in general. Overall, most of the solutions that are not on-path caching are using some sort of coordination. Without cooperation, caches at the edge of the network will get most of the hits and act as a filter. This effect is most obvious for hierarchical systems; it is known for web caching [46], and later observed for CCN [13, 21]: caches at the edge are dominated by popular files, while those in the core are occupied by unpopular content that gets few hits. This is largely why Fayazbakhsh et al. believe that most of the benefit of in-network caching for ICN can be obtained with TCP/IP by putting all the caches at the edge [12]. On the other hand, Tyson et al.’s simulations with BitTorrent traces show that, if cache sizes are sufficiently large, then there is significant caching in Tier-2 Autonomous Systems using CCN instead of TCP/IP [47]. Aubry et al., [48] argue that caching at all nodes is not necessary and the same level of performance can be obtained by allowing only half of the routers to cache content that is passing through. However, few caches in the network can satisfy requests from different sets of users even if they request the same content. That is why cache hit increases when there are fewer caching nodes. With more caching nodes, the redundancy of content increases and the extra copies of contents are futile. Therefore, this again illustrates the negative impact of content redundancy. Although it is widely believed that popular content must be cached at the edge of the network and less popular content at the core routers, the introduction of an optimal cache allocation in [49] defies this belief. Wang et al. formulated the problem as a linear program to maximize the benefit of caching which is equivalent to hop distance minimization. Their finding matches our analysis that for a heterogeneous topology, a system tends to cache content at core routers, and for a homogeneous topology, content is pushed more toward the edge routers. One reason NDN’s default en-route caching strategy leaves the core caches cold lies in the lack of cache diversity, i.e. the core contains copies of the content at the edge. One way to reduce this redundancy is for the caches to run some coordination protocol [50, 51]. The coordination may require the measurement of content popularity [52, 53, 54]. Such schemes increase traffic overheads, add complexity to the routers, and may not adapt fast enough to changes in popularity. A global popularity measurement is proposed in [55]. Although they have a nice idea of caching the most popular content at the core router where can get more hits from more potential requesters, using Zipf distribution at all routers to assess content popularity seams, not a right approach. As mentioned earlier in this paper, cache hits at downstream routers change the popularity patterns at upstream routers. In another popularity-based approach to reduce redundancy that is inspired by web caching, an age-based cooperative caching scheme is proposed in [56]. In their design, popular content that is cached in routers closer to requesters receive larger age values. In this way, they push the popular content closer to the clients. Like the other caching proposals, measuring popularity is not a straightforward task. Moreover, as seen in Fig. 10, caching the popular content entirely at the edge routers is not always the best choice. 29

Journal Pre-proof

Jo

urn al P

re-

pro

of

In a recent paper [57], Kamiyama, et al. proposed to use popularity and router levels to cache the most popular content in many routers. Each router receives an ID and this ID is compared with a few bits in the hash of the content name to decide whether to cache the content in the router. For more popular content, the number of bits is fewer, so that the contents are cached in more routers. There are several issues with this scheme: First, there is a need for a central system to assign ID numbers to the routers as they should be unique. Second, multiple copies of content are not necessary even for popular content. Third, there is again a need for a central system to make decisions on the level of content popularity; otherwise, content providers may all label their contents as popular content, the algorithm then performs like Leave Copy Everywhere, and the redundancy issue remains. Similar studies used a hash function to determine the location of the content to be cached [58, 59]. Location addressing can be studied as a hybrid method but that introduces complexities to the routing algorithm and the forwarding architecture of the routers. Alternatively, this redundancy can be reduced by meta algorithms like LCD and MCD, as considered by Laoutaris et al. for hierarchical web caches [16]. In the studies above, the files are cached in their entirety. CCndnS, however, segments the files and spreads them over multiple routers, thus removing the filtering effect. (Our use of equal-sized segments is consistent with segmentation in HTTP streaming.) WAVE [60] is a chunk placement policy that is similar to MCD; it also has a chunk marking window that is similar to a segment. These algorithms have the common problem of caching only popular content at the edge, leaving the caches in the core ineffective. Another possibility is for a router to probabilistically decide whether to cache a chunk that is passing through, i.e. a randomized way of reducing redundancy [17]. We observed that random placement like the one we used here works better than most of the caching proposals. Arianfar et al. see probabilistic caching as a load-sharing strategy, having pointed out the difficulty for memory latency to match line speed [61]. Chai et al. also note that the need for an NDN router to work at line speed rules out any collaborative caching algorithms that require significant information exchange among the routers [22]. CCndnS does not require such control traffic among routers. The Interests and Data chunks at most carry hop count, file size and segment size in their headers. Nonetheless, it spreads content so the load for checking CS is spread out (Fig. 9). This reduces queueing delays at the CS and significantly postpones router saturation [4]. The redundancy reduction also ensures that caching capacity in the core is not wasted. CCndnS thus partly addresses the line speed and edge/core issues raised by Perino and Varvello, and Ghodsi et al. The filtering effect that makes en-route caching ineffective also makes the analytical modeling of a caching network “extremely difficult” [23, 8]. This is why many models consider only hierarchical topologies [13, 21]. In contrast, by caching at the granularity of a segment, CCndnS facilitates skipping, diminishes the filtering effect, and decouples the behavior among caches. We thus obtain a simple model (Section 5) that can be used to predict and analyze individual and aggregated router performance.

30

Journal Pre-proof

8. Conclusion

References

urn al P

re-

pro

of

This paper presents CCndnS as a strategy to improve the performance of NDN’s network of caches. Our mathematical and simulation analyses show that spreading content with enroute caching adds interesting value to the system: (1) It reduces content redundancy to almost one copy for each data chunk. That frees up space for more content to be cached in the network. (Our algorithm is for en-route caching, and makes sure that redundancy in a path between a set of requesters to the content publisher is one. Extra redundancy might occur if multiple paths form at the same time, between different sets of requesters to the content publisher.) (2) It evens out the traffic throughout the network by balancing the popularity of content cached in the network. (3) Since chunks are assigned to routers, an Interest can skip some CS checks. This technique leads to increased throughput and decreased latency by reducing packet processing time at each router. (4) Breaking content dependencies among caches makes it possible to develop a straightforward mathematical model for analyzing cache behavior and provisioning cache space for SLAs. Through extensive simulations, we compared CCndnS with two well-studied but impractical caching policies. CCndnS is not only a practical caching policy, it also shows promising performance with various topologies and traffic conditions. The experiments prove the efficiency of CCndnS compared to the other real cache policies especially when the cache size is very small compared to the average size of files. As an application of the policy and its mathematical model, we showed how it can be used for a Service Level Agreement, to help ISPs provision cache space to achieve SLA targets. Such an SLA application can help a new content provider and new applications to get the necessary performance to compete against other popular applications. The model can also be used to facilitate collaboration among ISPs, for mutual benefit. We will address this interesting issue in future work.

Jo

[1] L. Zhang, A. Afanasyev, J. Burke, et al., Named Data Networking, SIGCOMM Computer Communication Review 44 (3) (2014) 66–73. [2] D. Perino, M. Varvello, A reality check for content centric networking, in: Proc. ICN, 2011, pp. 44–49. [3] A. Ghodsi, S. Shenker, T. Koponen, et al., Information-centric networking: seeing the forest for the trees, in: HotNets-X, 2011, pp. 1:1–1:6. [4] M. Rezazad, Y. C. Tay, ndn||mem: An architecture to alleviate the memory bottleneck for named data networking, in: Proc. CoNEXT Student Workshop, 2013, pp. 1–3. [5] L. Wang, A. Hoque, C. Yi, A. Alyyan, B. Zhang, OSPFN: An OSPF based routing protocol for named data networking, Tech. rep., Technical Report NDN-0003 (2012). [6] T. Chatterjee, S. Ruj, S. D. Bit, Security issues in named data networks, Computer 51 (1) (2018) 66–75. [7] D. Tanaka, M. Kawarasaki, Congestion control in named data networking, in: 2016 IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), 2016, pp. 1–6. [8] N. Laoutaris, H. Che, I. Stavrakakis, The LCD interconnection of LRU caches and its analysis, Perform. Eval. 63 (7) (2006) 609–634.

31

Journal Pre-proof

Jo

urn al P

re-

pro

of

[9] V. Jacobson, D. K. Smetters, J. D. Thornton, et al., Networking named content, in: Proc. CoNEXT, 2009, pp. 1–12. [10] D. N. Tran, W. T. Ooi, Y. C. Tay, SAX: A tool for studying congestion-induced surfer behavior, in: Passive and Active Measurement Conference, 2006. [11] H. Yu, D. Zheng, B. Y. Zhao, W. Zheng, Understanding user behavior in large-scale video-on-demand systems., in: Proc. EuroSys, 2006, pp. 333–344. [12] S. K. Fayazbakhsh, Y. Lin, et al., Less pain, most of the gain: Incrementally deployable ICN, in: SIGCOMM, 2013, pp. 147–158. [13] Z. Jia, P. Zhang, J. Huang, et al., Modeling hierarchical caches in content-centric networks, in: Proc. ICCCN, 2013, pp. 1–7. [14] D. Huang, X. Zhang, W. Shi, et al., LiU: Hiding disk access latency for HPC applications with a new SSD-enabled data layout, in: Proc. MASCOTS, 2013, pp. 111–120. [15] A. Sharma, A. Venkataramani, R. K. Sitaraman, Distributing content simplifies ISP traffic engineering, in: Proc. SIGMETRICS, 2013, pp. 229–242. [16] N. Laoutaris, S. Syntila, I. Stavrakakis, Meta algorithms for hierarchical web caches, in: Proc. IPCC, 2004, pp. 445–452. [17] I. Psaras, W. K. Chai, G. Pavlou, Probabilistic in-network caching for information-centric networks, in: Proc. ICN, 2012, pp. 55–60. [18] M. Yu, R. Li, Y. Liu, Y. Li, A caching strategy based on content popularity and router level for NDN, in: 2017 7th IEEE Int. Conf. on Electronics Information and Emergency Communication (ICEIEC), 2017, pp. 195–198. [19] C. Fricker, P. Robert, J. Roberts, N. Sbihi, Impact of traffic mix on caching performance in a contentcentric network, in: Proc. INFOCOM Workshops, 2012, pp. 310–315. [20] L. Muscariello, G. Carofiglio, M. Gallo, Bandwidth and storage sharing performance in information centric networking, in: Proc. ICN, 2011, pp. 26–31. [21] I. Psaras, R. G. Clegg, R. Landa, et al., Modelling and evaluation of CCN-caching trees, in: Proc. IFIP Networking, 2011, pp. 78–91. [22] W. K. Chai, D. He, I. Psaras, G. Pavlou, Cache “less for more” in information-centric networks, in: Proc. IFIP Networking, 2012. [23] E. J. Rosensweig, J. Kurose, D. Towsley, Approximate models for general cache networks, in: Proc. INFOCOM, 2010, pp. 1100–1108. [24] L. Breslau, P. Cao, et al., Web caching and Zipf-like distributions: Evidence and implications, in: Proc. INFOCOM, 1999, pp. 126–134. [25] D. Kim, Y. Kim, Enhancing NDN feasibility via dedicated routing and caching, Computer Networks 126 (2017) 218 – 228. [26] M. Rezazad, Y. C. Tay, CCndnS: A strategy for spreading content and decoupling NDN caches, in: 2015 IFIP Networking Conference (IFIP Networking), 2015, pp. 1–9. [27] Y. C. Tay, Analytical Performance Modeling for Computer Systems, 3rd Edition, Vol. 7, Morgan and Claypool Publishers, 2018. [28] L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, k. claffy, P. Crowley, C. Papadopoulos, L. Wang, B. Zhang, Named Data Networking, SIGCOMM Comput. Commun. Rev. 44 (3) (2014) 66–73. [29] S. H. Ahmed, D. Kim, Named data networking-based smart home, ICT Express ELSEVIER 2 (3) (2016) 130–134. [30] R. A. Rehman, J. Kim, B.-S. Kim, NDN-CRAHNs: Named data networking for cognitive radio ad hoc networks, Mobile Information Systems 2015. [31] X. Liu, M. J. Nicolau, A. Costa, J. Macedo, A. Santos, A geographic opportunistic forwarding strategy for vehicular named data networking, in: Intelligent Distributed Computing IX, Springer, 2016, pp. 509–521. [32] M. Amadeo, C. Campo, A. Molinaro, N. Mitton, Named data networking: A natural design for data collection in wireless sensor networks, in: IEEE Wireless Days (WD), 2013. [33] M. A. Hail, M. Amadeo, A. Molinaro, S. Fischer, Caching in named data networking for the wireless

32

Journal Pre-proof

[39] [40] [41] [42] [43] [44] [45]

[46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57]

of

[38]

pro

[37]

re-

[36]

urn al P

[35]

Jo

[34]

internet of things, in: 2015 International Conference on Recent Advances in Internet of Things (RIoT), 2015, pp. 1–6. J. Shi, Tunnel ethernet traffic over NDN (2017). URL https://yoursunny.com/t/2017/tunnel-Ethernet-over-NDN/ B. Ager, F. Schneider, J. Kim, A. Feldmann, Revisiting cacheability in times of user generated content, in: INFOCOM IEEE Conference on Computer Communications Workshops , 2010, 2010, pp. 1–6. D. Rossi, G. Rossini, Caching performance of content centric networks under multi-path routing (and more), Tech. Rep. Telecom ParisTech (2011). F. Qazi, O. Khalid, R. N. B. Rais, I. A. Khan, et al., Optimal content caching in content-centric networks, Wireless Communications and Mobile Computing 2019. L. Fan, P. Cao, J. Almeida, A. Z. Broder, Summary cache: A scalable wide-area web cache sharing protocol, IEEE/ACM Trans. Netw. 8 (3) (2000) 281–293. S. Michel, K. Nguyen, A. Rosenstein, et al., Adaptive web caching: Towards a new global caching architecture, Comput. Netw. ISDN Syst. 30 (22-23) (1998) 2169–2177. M. Rabinovich, J. S. Chase, S. Gadde, Not all hits are created equal: Cooperative proxy caching over a wide-area network, Computer Networks 30 (22-23) (1998) 2253–2259. A. Wolman, M. Voelker, N. Sharma, et al., On the scale and performance of cooperative web proxy caching, in: Proc. SOSP, 1999, pp. 16–31. Z. Li, G. Simon, Time-shifted TV in content centric networks: The case for cooperative in-network caching, in: ICC, 2011, pp. 1–6. Y. Wang, Z. Li, G. Tyson, S. Uhlig, G. Xie, Design and evaluation of the optimal cache allocation for content-centric networking, IEEE Transactions on Computers 65 (1) (2015) 95–107. S. Naz, R. N. B. Rais, P. A. Shah, S. Yasmin, A. Qayyum, S. Rho, Y. Nam, A dynamic caching strategy for ccn-based manets, Computer Networks 142 (2018) 93–107. D. Grewe, M. Wagner, M. Arumaithurai, I. Psaras, D. Kutscher, Information-centric mobile edge computing for connected vehicle environments: Challenges and research directions, in: Proceedings of the Workshop on Mobile Edge Communications, ACM, 2017, pp. 7–12. H. Che, Y. Tung, Z. Wang, Hierarchical Web caching systems: modeling, design and experimental results, JSAC 20 (7) 1305–1314. G. Tyson, S. Kaune, S. Miles, et al., A trace-driven analysis of caching in content-centric networks, in: Proc. ICCCN, 2012, pp. 1–7. E. Aubry, T. Silverston, I. Chrisment, Green growth in ndn: Deployment of content stores, in: 2016 IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), 2016, pp. 1–6. Y. Wang, Z. Li, G. Tyson, S. Uhlig, G. Xie, Optimal cache allocation for content-centric networking, in: 2013 21st IEEE International Conference on Network Protocols (ICNP), 2013, pp. 1–10. W. Wong, L. Wang, J. Kangasharju, Neighborhood search and admission control in cooperative caching networks, in: Proc. GLOBECOM, 2012, pp. 2852–2858. L. Dong, D. Zhang, Y. Zhang, D. Raychaudhuri, Optimal caching with content broadcast in cache-andforward networks, in: Proc. ICC, 2011, pp. 1–5. J. Li, H. Wu, B. Liu, J. Lu, Y. Wang, X. Wang, Y. Zhang, L. Dong, Popularity-driven coordinated caching in named data networking, in: Proc. ANCS, 2012, pp. 15–26. H. Wu, J. Li, Y. Wang, B. Liu, EMC: The effective multi-path caching scheme for named data networking, in: Proc. ICCCN, 2013, pp. 1–7. doi:10.1109/ICCCN.2013.6614132. C. Bernardini, T. Silverston, O. Festor, Mpc: Popularity-based caching strategy for content centric networks, in: 2013 IEEE International Conference on Communications (ICC), 2013, pp. 3619–3623. H. Wu, J. Li, T. Pan, B. Liu, A novel caching scheme for the backbone of named data networking, in: 2013 IEEE International Conference on Communications (ICC), 2013, pp. 3634–3638. Z. Ming, M. Xu, D. Wang, Age-based cooperative caching in information-centric networks, in: 2012 Proceedings IEEE INFOCOM Workshops, 2012, pp. 268–273. N. Kamiyama, M. Murata, Spatially-dispersed caching in information-centric networking, in: 2018 IEEE International Conference on Communications (ICC), 2018, pp. 1–7.

33

Journal Pre-proof

of

[58] F. Song, Z.-Y. Ai, J.-J. Li, G. Pau, M. Collotta, I. You, H.-K. Zhang, Smart collaborative caching for information-centric iot in fog computing, Sensors 17 (11) (2017) 2512. [59] L. Saino, I. Psaras, G. Pavlou, Hash-routing schemes for information centric networking., in: ICN, ACM, 2013, pp. 27–32. [60] K. Cho, M. Lee, K. Park, T. T. Kwon, Y. Choi, S. Pack, WAVE: Popularity-based and collaborative in-network caching for content-oriented networks, in: INFOCOM Workshops, 2012, pp. 316–321. [61] S. Arianfar, P. Nikander, J. Ott, On content-centric router design and implications, in: Proc. ReArch, 2010, pp. 5:1–5:6.

Jo

urn al P

re-

pro

-

34

Journal Pre-proof

urn al P

re-

pro

of

CCndnS reduces content redundancy to almost one copy for each data chunk. CCndnS evens out the traffic by balancing the popularity of cached content. CCndnS introduces skipping technique to skip futile searches on CSs. CCndnS breaks content dependencies among caches. Develop a straightforward mathematical model for analyzing cache behavior

Jo

    

Journal Pre-proof

There is no conflict of interest between us and any other people or organization on publishing this work.

Jo

urn al P

re-

pro

of

Mostafa Rezazad