A Data Structure for Content Cache Management in Content-Centric Networking Haopei Wang, Zhen Chen, Feng Xie, Fuye Han Research Institute of Information Technology Tsinghua University, Beijing, China, 100084
[email protected]
Abstract—Content-Centric Networking (CCN) is a new network architecture that rethinks the model of network communication. In this architecture all the network sources will be looked as content and routed by name. In this paper, we describe a scheme about the memory management in CCN and explore the impact of this management. We hope to design a solution for the innetwork cache. To this purpose, we set up an application platform using the open source CCNx prototype and redesign the cache management by using a different data structure—splay tree and replacement policy compared to the existing design. This data structure is very suitable for caching for that recently accessed content is quick to access again. We also imitate some related work and design a similar experiment. The experimental results show the high efficiency of our management. Our solution improves the hit probability and make the popular content less time to access. Keywords-CCN, Cache management, Splay tree
I.
INTRODUCTION
The original motivation for Internet is to share expensive computing resources with host-to-host communication in mainframe era. Today’s Internet is based on the ossifying TCP/IP protocol stack and static host-to-host conversation model to disseminate contents with increasing large volume. This is most important issue among many others faced by the current architecture such as mobility, security, scalability, accountability and other targets. Some popular solutions are CDN [13-15], edge caching, P2P, multimedia streaming and etc. However these solution seems patches and don’t provide a natural architecture way to adapt this big challenge. Content-Centric Networking (CCN), also called Named Data Networking, is a new architecture recently proposed by PARC [2, 3]. The fundamental principles of CCN have been provided by some designs such as Content-Oriented Architecture or Information-Centric Networking. Some related designs are DONA [1], TRIAD [4], PSIRP [5, 6] and etc. CCN focuses on most of the issues that faced by the current Internet infrastructure and is considered to have many advantages. The consequent from host-centric to content-centric may support the original motivation for Internet to share resources. In CCN, content has a unique identifier. The content will be acquired by its name, not by where (host) it is. The content also will be transparently cached in content router. Because of these key features, CCN is supposed to have many useful advantages and
willing to replace the IP network. Most of the research issues about CCN are concentrated on naming, routing and security. The cache management in the CCN can be divided in two kinds: edge cache and in-network cache. In our view, the edge cache could be designed refer to the CDN. This paper focuses on in-network cache management in content router. Some related researches have already discussed about it. G. Carofiglio et al. [9] provides an analytical characterization of bandwidth and storage sharing in Information Centric Networking. D. Perino et al. [8] analyzes the feasibility of CCN under the condition of the existing hardware. Different packet-level replacement policies are discussed and analyzed in [7], including LRU (Least Recent Used) and LFU (Least Frequently Used). However, we note that either LRU or LFU is only replacement policy based on linear storage structure, as shown in the source code implementation in current CCNx [3] package version 0.4.2. This paper tries to fill the gap to implement the schedule arranging different contents in memory hierarchy and optimize the content access time in time complexity. In our research work, we study about the structure of today’s standard router memory hierarchy and the characteristic of the CCN content packet. We sort our content packets as Binary Search Tree. We comprehensively investigate the idea of Balanced Tree [10] and Self-Adjusting Tree [11, 12] and design a cache management for CCN and implement and experiment in our platform. We will detail our design and experiment. The results will show the high efficiency. The rest of this paper is organized as follows. Section Ⅱdescribes the CCNx software prototype and its basic principles and our experimental platform based on the CCNx. Section Ⅲ describes our content cache management policy. Section Ⅳ describes the evaluation in our platform. And the last Section Ⅴ will give a conclusion. II.
BACKGROUND
A. CCNx CCNx [3] is an open source project in intensive development stage to explore the next step in networking, based on one fundamental architectural change: replacing
named hosts with named content as the primary abstraction. So CCN is a network architecture and CCNx is a software prototype which implements the CCN architecture. CCN has no notion of host at its lowest level — a packet "address" names content instead of location. The CCNx protocol efficiently delivers named content rather than connecting different hosts. Every packet of data may be cached at any CCNx content router —combined with fundamental support for multicast or broadcast delivery this brings a very efficient and controllable use of the network when many people are interested in the same content at the same time. In CCNx node model, every node should contain Content Store (CS), Forwarding Information Base (FIB), Pending Interest Table (PIT) and I/O called Face. A Face is more like an abstract interface. FIB and PIT is used for routing. The Content Store is a buffer memory organized for retrieval. Somaya Arianfer et al. [10], propose an organization for Content Store. In their structure, they call the lowest level content identifiers as packet identifiers (PIds), whether the PIds is a hierarchical name in CCN or a flat name in DONA. The Content Store contains a packet store (the physical location of packet) and an index table for quick accessing the store. Packets are stored in a different locations in the packet store with free space is organized as list. The index table indexes the packets in the packet store. Then they describe the details of the operation. The index table will indeed accelerate the searching of each packet. We rethink of the designing of CCN cache structure and take the followings into consideration: The more popular content should be searched faster and the cached content should be sorted in the popular metric to fit the memory hierarchy. So we can see, the structure proposed in [10], any operation about the popularity of the content is quite slow, e.g., which content to retain or to replace. On the whole, this design does not take full advantage of CCN cache. Its comprehensive efficiency is not satisfactory.
following (Table 1) provides an general condition of current memory technologies that may be employed for the CCN router. It is easy to see that the structure of the memory looks like a pyramid. Fast cache usually has a small memory size but a high price. Therefore, the content that we cache should be consistent with this structure. The cache design should be a tree structure (Figure 3). So in our design, we try to use tree structure instead of the linear structure. And the level of each node generally indicates its cache priority. At the same time, the operating time of each node will also be controlled within a reasonable range. Technology TCAM SRAM RLDRAM DRAM High-speed SSD SSD
Access time [ns] 4 0.45 15 55
~20Mb ~210Mb ~2Gb ~10GB
Cost [$/MB] 200 27 0.27 0.016
Power[W/ MB] 15 0.12 0.027 0.023
1,000
~10TB
0.03
0.00005
10,000
~1TB
0.003
0.00001
TABLE I.
Structure of cache and queue in [10]
B. Hardware and deployment Some recent researches show that memory access is the main bottleneck of today’s hardware router design [17]. The
SUMMARY OF MEMORY TECHNOLOGY [8]
Figure 2.
Pyramidal structure of the cache
Then we think about the deployment of the CCN network. According to [8], it can be concluded that a CCN deployment is feasible at a CDN and ISP scale. From the perspective of cache management, we also think that the large-scale cache should be deployed in edge networks. And the cached content should be adapted to the attribute of the edge networks. As the names in CCN are hierarchical and human-readable, we may also study how to learn the type of each. Cache should also be designed for some particular types of flow, e.g. streaming, web pages. III.
Figure 1.
Max. size
CACHE MANAGEMENT POLICIES
Our design also follows today’s standard router memory hierarchy. The packet store is kept in the DRAM and the index table is kept in the SRAM. The design of packet store follows the description in [9]. But the design of index table is quite different. We will detail our design in the following.
A. Goals The time of insertion, deletion and lookup should be as fast as possible.
The content with high popularity should have high priority of caching and should be quick accessed.
Some unpopular content should be deleted when the cache is close to be full. In other words, there should be a reasonable replacement policy.
Unlike the LRU or LFU, we should take both the frequency of accesses and the recent access into consideration when we evaluate the popularity of the content.
B. Data structure In the index table, we organize the PIds as a splay tree [12]. A splay tree is a self-adjusting binary search tree with the additional function that recently accessed nodes are quick to access again. In an amortized sense, it is not much worse than dynamic balanced trees and static optimal trees. The basic operation is call splaying. Splaying the tree for a node rearranges the tree so that the node is arranged to the root of the tree. Thus, future access to this node will be faster. To do this function, firstly it needs to perform a standard binary tree search for the node in question, and then use tree rotations in a specific fashion to bring the node to the top. We will detail the algorithms of the basic operations.
Cache DRAM
Packet Store
SRAM
Index table
PId1 PId3 Figure 3.
Insertion: We can just insert the node as with a normal binary search tree. BST BstInsert(bst, node) { if (!bst) {Insert(bst, node); return(VALUE_INSERTED_OK); } switch (ValueCompare(Value(node), Value(bst))) { case LT:return(BstInsert(LChild(bst), pNode)); case GT:return(BstInsert(RChild(bst), pNode)); default :return(VALUE_EXISTS); } } Deletion: To delete the node x, we use the same method as with a binary search tree. If x has two children, we swap its value with that of either the rightmost node of its left sub tree (its inorder predecessor) or the leftmost node of its right sub tree (its in-order successor). Then we remove that node instead. In this way, deletion is reduced to the problem of removing a node with 0 or 1 children. That will be very easy. Lookup: We can just search the node as with a normal binary search tree as following algorithm. Then we do a splay operation.
PId4
PId2
Zig Step: Prerequisite is when p is the root. Zig-zig Step: Prerequisite is when p is not the root and both x and p are either right children or left children. Zig-zag Step: Prerequisite is when p is not the root and x is a left child and p is a right child or vice versa.
PId6
PId5 PId7
BST BstSearch(bst, value) { if (!bst) return(NULL); switch (ValueCompare(value, Value(bst))) { case LT:return(BstSearch (LChild(bst), value)); case GT:return(BstSearch (RChild(bst), value)); default :return(bst); } }
Data Structure
C. Algorithms Splaying When the node x is accessed, a splay operation will move x closer to the root. There is a sequence of splay steps. After every operation, the recently accessed nodes are moved near the root and the tree remains to be a binary search tree, which means its In-Order Traversal will not change. In the meantime we keep the tree to remain roughly balanced by limiting its depth, so that we achieve the desired amortized time bounds. We assume that x is the child of p (whether left child or right child). There are three different types of splay steps as following:
Replacement: Because the nodes with higher popularities will be moved gradually closer to the root, we just need to replace some leaf nodes. To keep the tree roughly balanced, we may limit the depth of the tree. In the meantime, if the cache is full, we just need to cut the lowest leaf nodes. D. Analysis Splay tree has a good performance which depends on the fact that it is self-optimizing, in that frequently accessed nodes will move nearer to the root where they can be accessed more quickly. The time complexity of the operations is shown in Table Ⅱ. The worst-case height is O( n) , with the average being O (log n) [13].
Space Search Insert Delete TABLE II.
IV.
1 1 ) . The access sequence contains about k 1 k K
C (
Time complexity in big O notation Average
Worst case
O(n) O(logn) O(logn) O(logn)
O(n) O(n) O(n) O(n)
TIME COMPLEXITY ANALYSIS [13]
EXPERIMENTAL EVALUATION
Our experiment is performed on the Omedia platform using CCNx package version 0.4.2. Our machines use the 2.0 GHz Intel Core Duo CPU and 2GB of RAM. The operation system is Linux Ubuntu 9.10. Each machine is connected through a 10 Gbps line card. Figure 4 shows the network topology. The distribution of the routers is a binary tree. The client which provides data source is connected to the root node. The left four clients which will download data are connected to the leaf nodes. We expect to evaluate the results at every node.
100,000 content items which are the web pages or the songs. When the cache is almost full, we cut some of the lowest leaf nodes in the search tree. And we limit the depth of the tree to keep roughly balanced. B. Experiment results Firstly we discuss about the relationship between download time and popularity. We set x 20, 000 . Figure 5 reports the average content download time for all the 20 classes of content. As we can see, the download time is related to popular class. The content with high probability to access has a very short download time. And the 2 most popular classes of content use very little time. By comparing with the two kinds of content items –web pages and song, we can observe that the performance of the web pages is better than that of the songs, both in average time and the rate of rise. There are two reasons that we analyze. One is that 80% of the access sequence are web pages, in some ways, which means web pages are more popular than the songs. Another reason is that web pages have smaller size, which means the cache will contain more web pages than songs. Then we will discuss the hit probability at different levels in topology. As shown in Figure 6, most of the contents of web pages have a high hit probability in leaf nodes. And the high classes of content of songs also have high hit probability. Comparing the Figure 6 to Figure 7 and Figure 8, we can observe a “filter effct” [19], the same as [7].
Figure 4.
Topology
A. Reference scenario To order to compare the results with [7], we design a similar experiment. We store 1200 different web pages which have an average size of 120 KB and 400 different songs which have an average size of 2 MB. As we know, the content will be separated into several packets in the CCN. The size of the packets is 4 KB which is the default data packet size in CCNx. The statistic of our experiment is based on the content-level, which means we cache the whole content, not part of the content. In every router, we limit the max number x of packets in the cache ( x may change in every different test). Then we describe the access sequence. 80% of the access sequence are web pages and 20% are songs. The two kinds of content items are grouped in K 20 classes of decreasing popularity and the class popularity distribution is Zipf with parameter 1 0.7 for web pages and 2 2.4 for songs. More precisely, the probability to access a content of class k ,
k 1, 2,..., K , is p(k )
C , where C is obviously k
Comparing with the result in [7], we improve the range of content items which have high hit probability. Unlike the LRU or LFU, we take both the frequency of visits and the recent visit into consideration when we evaluate the popularity of the content. And the results show that the hit probability become more regular and foreseeable.
Figure 5.
Average download time
retrieve some of the popular content. Unlike the LRU or LFU, we take both the frequency of visits and the recent visit into consideration when we evaluate the popularity of the content. The experiment also shows that the repeatability of network traffic is quite considerable. Our work is just an attempt to find an appropriate solution for the cache management and has many limitations and shortcomings. As a future work, we plan to further investigate the properties of this structure and test the efficiency under large-scale deployment. In the future work, we will conduct our experiment based on 64-core Tilera Tile Processor [18]. ACKNOWLEDGMENT Figure 6.
Average hit probability in leaf nodes
This work has been partially funded by Ministry of Science and Technology of China under National 973 Basic Research Program Grant No. 2011CD302600, Grant No. 2011CB302805, Grant No. 2011CB302601, and Brant No. 2012CB315800. This work is also supported by China NSFC A3 Program (No. 61161140320). REFERENCES [1] [2]
Figure 7.
Average hit probability in intermediate nodes
[3] [4] [5]
[6] [7]
[8] [9]
Figure 8.
Average hit probability in root nodes
[10] [11]
V.
CONCLUSION AND FUTURE WORK
CCN makes it possible to start applying it now to solve communication problems in new ways. There are interesting problems in many areas still to be solved about CCN. In CCN, chunk-level caching has a fundamental role in determining the efficiency of networking. In that case cache management is a very important research focus. Paper [7] gives an attempt to the management, but there is still space to increase. In this paper, we evaluate the impact of a different design. As we can see in the experiment, our design does have benefits in many ways. By redesigning the index table, we improve the hit probability of the content and accelerate to
[12] [13] [14] [15] [16] [17] [18] [19]
T. Koponen et al., A Data-Oriented (and Beyound) Network Architecture, SIGCOMM’07, 2007, pp. 191-92. V. Jacobson et al., Networking Named Content, CoNEXT’09, New York, NY, 2009, pp. 1-12. Project CCNx. http://www.ccnx.org/ M. Gritter and D. R. Cheriton. TRIAD: A New Next-Generation Internet Architecture. http://www-dsg.stanford.edu/triad/, July, 2000. Lagutin, D., Visala, K, and Tarkoma, S. Publish/Subscribe for Internet: PSIRP Perspective. Towards the Future Internet-Emerging Trends from European Research, 2010. (Valencia FIA book 2010).R. Nicole, “Title of paper with only first word capitalized,” J. Name Stand. Abbrev., in press. Project PSIRP. http://www.psirp.org/ G. Carofiglio et al., Experimental Evaluation of Memory Management in Content-Centric Networking. IEEE International Conference on Communications (ICC), Kyoto, Japan, 2011, pp. 1-6. D. Perino, M. Varvello, A Reality Check for Content Centric Networking, SIGCOMM ICN’11, Toronto, Ontario, Canada, 2011. G. Carofiglio et al., Bandwidth and Storage sharing Performance in Information Centric Networking, SIGCOMM ICN’11, Toronto, Ontario, Canada,2011. Somaya Arianfar et al., On Content-Centric Router Design and Implications,ACM ReArch 2010. Adelson-Velskii, G.; E. M. Landis (1962). "An algorithm for the organization of information". Proceedings of the USSR Academy of Sciences 146: 263–266, 1962. D. D. Sleator & R. E. Tarjan, Self-Adjusting Binary Trees. JACM, 32:652-686, 1985. http://en.wikipedia.org/wiki/Splay_tree M. J. Freedman, E. Freudenthal, and D. Mazières. Democratizing content publication with Coral. In NSDI, 2004. Akamai, www.akamia.com China cache, www.chiancache.com S. Dharmapurikar, P. Krishnamurthy, and D. E. Taylor. Longest prefix matching using bloom filters. Sigcomm 2003. Tilera 64core Network Processor, www.tilera.com C. Williamson, “On filter effects in web caching hierarchies”, ACM Trans. Internet Technol., vol. 2, no. 1, pp. 47-77, 2002.
