The paper illustrates the design of MobEYE, a cooperative cache system for file transfer over MANETs. Its implementation is based on the sniffing facilities ...
Saving Energy and Reducing Latency in MANET File Access Gabriella Dodero, Vittoria Gianuzzi DISI, Universit`a di Genova, Via Dodecaneso, 35 16146 Genova, Italy {dodero, gianuzzi}@disi.unige.it Abstract The paper illustrates the design of MobEYE, a cooperative cache system for file transfer over MANETs. Its implementation is based on the sniffing facilities provided by the BSD Packet Filter, to process in-transit messages at the application level. MobEYE has been simulated, deriving support for the claim of saving energy and reducing latency; further possible optimizations, based on the use of promiscuous transmission mode, are discussed as well.
this costly access, we implemented a system providing a cooperative cache over a MANET, which aims at reducing, at the same time, both energy consumption and file transfer latency among mobile peers. The system we developed is called MobEYE (Mobile intErcepting proxY cachE), it is working in a WEB environment, and it supports read only access to remote files by means of any kind of browser. It implements a light web server on every node where it is installed, and it allows to share the local file cache with the other nodes.
1. Introduction So far, MANETs have been mainly considered for military (interactions among soldiers grouped around commanding officers, moving in a battlefield) or civil protection (disaster recovery) environments, but it is possible to envision many more agreeable environments that could be the killer application for the MANET. It can be assumed that in a few years many people will be equipped with cellular phones with WiFi functionalities and cameras to take pictures and movies, mainly young people, sensitive to the new devices and applications. We can easily envision groups of people meeting and exchanging information during cultural, religious and sporting happenings. Of course, in a network with so many peers not all nodes will be able to provide the same functionality for all the time. Some of them will be supported by more powerful devices, or equipped with long lasting batteries, and others will not, or will not exhibit a cooperative behaviour. Over the time, powerful nodes will disconnect because they are moving away or because they run out of power; and other nodes will come in. Maintaining resource sharing facilities will be one of the major problems to be solved. One of the more power consuming features in a MANET is file transfer. When an application running on some node (say A) requests a file (File.jpg) to the owner node (B), such a file has to be routed through all nodes in the path connecting the file owner to the requesting one. To optimize
Figure 1. Intercepting file request Considering the situation in Figure 1, five nodes along the routing path from A to B are involved in the request and delivery of File.jpg: if File.jpg is already cached in some node in the routing path, e.g. node C because of a previous request, it would save time and energy if A’s request is served by C rather than by B. If not, when File.jpg is forwarded to A through nodes in the routing path, some of them may cache it, for serving future requests. To perform such operation without additional messages, nor with a flooding message, node C must be made aware of file
requests performed by A, but such information is known at the Network layer, not at the Application layer. MobEYE, described in this paper, proposes an innovative way to solve this problem with respect to other proposals, maintaining the ability to work with any kind of routing protocol and operating system, without requiring explicit information from the underlying layers, nor any modification to them. Moreover, the system works even if not all the nodes of the MANET are collaborative: at any moment a node can decide to join MobEYE (by running MobEYE Agents and sharing its own cache), or a MobEYE node may decide to leave it without interrupting the file request/transfer chain. MobEYE performance has been simulated, and main simulation results are presented. A possible extension of MobEYE to improve replica discovery in a MANET is also discussed.
2 Related work Proposed strategies for file caching may be classified as Proactive or Reactive. In the first case, local requests are periodically analyzed, and cached copies of the most requested files are eventually redistributed. Additional energy for file transfers is required, to anticipate (and save energy) in future requests [4, 8]. In the second case, when a file is requested by a node, it is also locally cached, and it is made available when another node requests it, without requiring additional energy consumption for the placement. MobEYE implements a reactive caching. Services needed to implement such kind of caching are: a Cache Maintenance Service (CMS), to decide both the cache maintenance policy and kind of information to be cached (the whole file replica, a fragment or a representative of it), and a Replica Location Service (RLS), supporting the search for the closest replica. Some of the most representative works are discussed in the following. In [9] nodes cooperate in exchanging web pages which can be locally cached. The RLS is organized in threephases, requiring a specific routing protocol, ZRP (Zone Routing Protocol). In the first phase a broadcast is issued within the proactive zone of the node; if the file is not found in these caches, the request is forwarded to some outside node, possibly sharing the same interests. Finally, the request is issued to the server owning the file, or connected to the Internet. ORION (Optimized Routing Independent Overlay Network) is a system presented in [6]. Routing paths for accessing the file server are recomputed at the application level, using a reactive routing protocol, thus building a network overlay structure. Each node maintains a table with
the location information about the owners of the replicas, used by the RLS to reach the closest useful node. [10] describes a (not implemented) CMS, comparing two caching policies: CacheData and CachePath, where intermediate nodes in the path connecting the requesting node to the file owner (as shown in Figure 1) may cache the whole file, or the path to the closest node with a cached replica of the file. With respect to the RLS, a cross layer interaction between the application and the network layers is assumed, to allow nodes along the path to be aware of file requests. These proposals require either the use of a specific routing protocol, or the re-implementation of the routing protocol at the application layer, or, at least, an explicit interaction with the routing protocol, belonging to a different OSI layer. MobEYE, instead, proposes an innovative way to solve this problem, maintaining the ability to work with any kind of routing protocol, without requiring explicit information from the underlying layers, nor any modification to them.
3. Proxy cache implementation In order to implement cache cooperation at the application level, the application must be aware of messages in transit through the node. Such awareness implies, in principles, some form of cross-layer cooperation. In MobEYE, this is made possible by sniffing, a mechanism allowing to pass an incoming message up through the layer stack until the application layer. Sniffing incoming packets on a wired network is almost impossible and would overload the CPU, unless some hardware filter discards most of them. In a MANET the situation is better, because each application on a node can only sniff messages coming from neighboring nodes. In the Linux kernel the BPF (BSD Packet Filter) [7] facility gives user-level program defined access to raw, unprocessed network traffic, thus greatly reducing CPU load. In such a way, MobEYE knows when a file request is in transit locally, and in order to cache a local copy, it should know that a file is being routed through the local node. These two tasks are performed by a specific component, the Interceptor Agent, which is ’sniffing’ in-transit messages, as we shall see below. In more details, MobEYE can be decomposed into four components: the HTTP Agent, the ICP Agent, the Cache Manager and the Interceptor Agent. The HTTP Agent interacts with the local web browser, using Web message redirection. It looks at the local cache to check if the file is already there: if so, the HTTP Agent creates an HTTP response for the browser with the requested file. If the file is not in cache, it forwards a query for the file to the ICP Agent on the remote file owner.
The ICP Agent acts as Web Server, answering the remote queries and performing file transfers to the client when needed. File queries and file downloads are managed by the ICP Agent using a suitable protocol, very similar to the Internet Cache Protocol (ICP) standard. For our purposes we decided to design a simpler protocol, avoiding unused fields. The ICP Agent does not send immediately the file, in response to the query; rather, it sends an ack message to notify the client node that it is reachable and that the file is available. Each MobEYE node also runs the Interceptor Agent, that captures the queries (and possibly the files) being routed or transmitted by neighboring nodes (see Figure 2). Finally, the Cache Manager handles the cache (as a local directory) with LRU policy and answers to any message (query or file transfer request) issued by the other agents.
messages. The first message (the query)is a very short message, but its presence may increase the overall time to achieve file transfer. A possible, different behaviour which we have not implemented, would require to stop message forwarding at the first node that may satisfy the query. The reason for not implementing such policy is based on two considerations. First, we may stop such a message - by blocking its forwarding by iptables manipulation, risking to stop also other messages not related to MobEYE, - or by modifying the routing algorithm, - or by acting inside the Linux kernel, e.g. with the netfilter function. The latter two alternatives are incompatible with the idea of being independent from the underlying routing or OS version, which is central to MobEYE. Second, assuming that the query message has been stopped, a further problem may arise if some link is asymmetrical: in such a case, answers to requests need not be forwarded along the same path where the request came from. On the other hand, if more than one ack is received after a query, it is possible to select what is the most convenient, for example by considering the return path as well. File transfer is performed with UDP protocol so that if a node disconnects during transmission, it can be substituted by another node who has a copy of the file. At present no file compression is performed, but it is obviously possible to include it.
3.1. Simulation results
Figure 2. MobEYE architecture Following a query, all the MobEYE nodes which intercepted it, and which have a cached copy of the file, together with the file owner, participate in a handshaking with the MobEYE client, in order to decide where the file must be downloaded from. All such nodes send the ack message ”I have the file” to the client HTTP Agent. We implemented the simplest possible selection for file transfer, that is fetching from the first one to answer (possibly the closest, or the one which has a larger bandwidth for its communication path). The HTTP Agent issues a file transfer request to that node only, and discards other ack messages received after the first one. When the file has arrived, the HTTP response is created for the client browser. The variant we use of the ICP protocol operates in two phases, first a query message is issued, which contains the name of the desired file; then, the most convenient among ack answers is chosen, and actual file request is sent to such node only. This is a distinguished feature of MobEYE, with respect to other systems that use only one type of file request
We are experimenting the behaviour of MobEYE using ns2 (http://www.isi.edu/nsnam/ns/) simulator. In the following, some results are reported, considering 40 and 80 nodes, moving according to the Random Waypoint mobility model, using the two-ray ground propagation model and transmission radius of 180 meters. For scenarios generation, the BonnMotion system (http://web.informatik. unibonn.de/IV/Mitarbeiter/dewaal/BonnMotion) has been used, considering rectangular areas (with ratio 0.7 between the two sides) selected in order to have each node with out degree in [6, 7], speed chosen randomly between [0.5, 1.38] and pauses in [0, 60]. The considered outdegree interval generates dense communication graphs, where the probability for every pair of nodes to be disconnected is about 0.1. In these tests, we assumed to have 6 server nodes owning a total of 60 files for the 40 nodes MANET (respectively, 8 servers with 80 files for the 80 nodes MANET), each file size being about 10 KB. We considered different cache sizes, respectively containing 5, 10, 15 and 20 percent of total file size. Results have been collected considering several runs with the same request templates: the average number of randomly chosen file requests for each node
(servers included) is 31. Results collection is started after some time since the simulation has begun, so that caches have already been filled. Since we are mostly interested in energy saving, two kinds of results have been considered: the decrease in the number of file requests satisfied by the servers (MobEYE allows different nodes to answer the requests, spreading energy consumption over non server nodes), which is shown in Figure 3, and the decrease in energy consumed by the whole network to transmit files over the routes, which is shown in Figure 4. The latter directly depends on the probability to find a replica in the local cache (then on cache size) and on the length of the communication paths (MobEYE reduces path length when replicas are found in intermediate nodes). Vaues reported in Figure 4 are obtained by multiplying the average hop length of the communication routes by the length of transmitted files (not found in the local cache). Lines labeled as ”Normn” refer to results obtained with n nodes MANETS without MobEYE, while ”Mobn” labeled lines consider MANETs with MobEYE. Energy consumed by the servers 2000
Server Hits
1500
1000
500
Norm40 Mob40 Norm80 Mob80
0 5
10
15
20
Cache Percentage
Figure 3. Number of server hits
Network Energy for file transfer 120
Avg. hops
100 80 60 40 20
Norm40 Mob40 Norm80 Mob80
0 5
10
15
20
Cache percentage
Figure 4. Energy for files transfer
As shown in Figures 3 and 4, MobEYE allows to reduce energy consumption from both points of view, at the cost of short additional query and ack messages, sent to file servers before file transfer.
4. Replica discovery With respect to the proposals discussed in section 2, MobEYE could be viewed as an implementation of the method presented in [10]. However, the technique we implemented, besides not requiring an explicit cross layer interaction, also allows a wider approach for the Replica Location Service. In fact, the same intercepting mechanism used in MobEYE can be employed not only by nodes involved in the routing path, but also by other nodes located in the transmission range of such path nodes. This result can be achieved when the WNIC is set to promiscuous mode, so that all packets in the transmission radius can be received, rather than filtering only those containing the same MAC address as destination. Some authors have questioned the use of promiscuos mode, since promiscuous mode operation, which is irrelevant to bandwidth utilization, incurs some energy cost. In fact, in promiscuous mode the WNIC is always in receive status, rather than being kept in idle status when no message is transmitted to that specific node (sleep mode can be used for power saving in structured networks, but it cannot be used for MANETs). However, a comparison of available data on power saving shows that the difference between idle and receive status is relatively small, becoming even smaller when transmission speed increases. In [2] we found, for instance, that for Lucent IEEE 802.11 Wavelan PC card (11 Mbps) power consumption data are: Sleep Mode 10mA, Idle Mode 156 mA, Receive Mode 190 mA, Transmit Mode 284 mA. Remark also that certain routing algorithms, like for example DSR, already require the use of promiscuous mode to significantly improve the performance, as remarked in [1]. If this mode is already available, file searching and caching algorithms of MobEYE can benefit from it. The use of sniffing in promiscuous mode can impressively increase the number of nodes involved in a file search, thus increasing the probability to find a closer replica, as shown in the following example. Let us consider n nodes uniformly distributed, each one having a communication radius R. Depending on the ”range density” RD, that is the number of nodes included in the transmission range of a node, the network can be completely or partially connected. Looking at the results given in [3], if RD=10 we have a very high probability to have a completely connected communication graph.
Figure 5. Covered transmission area
nodes R and O, plus the m = 3 nodes in the path, plus 13 more neighbouring nodes, that is 5 more times the number of nodes considered by caching systems relying only on nodes in the routing path. Using a cache that contains only 5% of the files and random file requests, we derive a probability p=0,05 to find a given file in such a cache. In the above example, the probability of finding the requested file in at least one of the 4 nodes in the routing path is (1 − (1 − p)4 ) = 0, 19 while the probability of finding it in one of the 13 ”sniffing nodes” is (1 − (1 − p)13 ) = 0, 49.
5. Conclusions
Figure 6. Geometry of the path area
Assume now that the routing path linking two nodes R and O (respectively the requester of a file and the owner of it) is composed by m intermediate nodes, and that the underlying routing algorithm is a minimum hop one, like DSR or AODV. Applying the considerations made in [5], the average geometric distance between two intermediate √ nodes of such path is RM = R/ 2. In this way, all the N nodes falling inside a ”strip” around the path linking R with O will listen to the search message. This ’strip’ results from the m + 2 circles with radius R centered in the path nodes. Recalling that the average distance is RM , these circles will be partially overlapped, and the number of nodes contained inside them shall be proportional to the overall area AStrip, with the relationship N = n/A ∗ AStrip. Figure 5 illustrates this situation for m = 3, in the simplified assumption that the centers are on the same line. In such case, AStrip is the overall area of the m+ 2 circles, (m+1)∗πR2 , minus the areas of the m overlapped portions. We observe that the circles overlap by intersecting two circular sectors with an angle of 43 π. Referring to Figure 6, this overlapping area can be computed as the difference between the areas of the two sectors adb and acb and that of √ the quadrilateral abcd. The area of such quadrilateral is 7 ∗ R2 /4 and that of one circular sector is 83 πR2 , so √ AStrip = (m + 1) ∗ πR2 − m ∗ ( 34 πR2 − 7 ∗ R2 /4). Considering m = 3, R = 180 meters and RD = 10, the above formula gives approx. N = 18, that is the two
MANETs may become a very practical way to extend infrastructured wireless networks beyond their physical reach, or for collaborative activities where no infrastructure is present. New tools are needed to cope with such environments, thus we have implemented a proxy cache system, called MobEYE. It aims at reducing latency and increasing battery lifetime when exchanging files on a MANET. MobEYE code can be downloaded from http://sealab.disi.unige.it/Krakatoa/MobEYE. It has already been tested in a MANET composed by up to 10 nodes of different computation and memory features, like laptops (under Linux) and PDAs (under Pocket PC and Familiar Linux). At present we are simulating MobEYE to estimate the best implementation parameters and caching policy. Acknowledgements The work reported in this paper has been financially supported by the Italian Ministry of Research and University (MIUR) within the projects WEB-MINDS and IS-MANET. The authors are grateful to A.Mura, L.Pastorino and M.Pupino for their implementation efforts.
References [1] T. Camp, J. Boleng, B. Williams, L. Wilcox, and W. Navidi. Performance comparison of two location based routing protocols for ad hoc networks. Proc.IEEE,INFOCOM, 2002. [2] L. Feeny and M. Nilsson. Investigating the energy consumption of a wireless network interface in an ad hoc networking environment. Proc. INFOCOM, 2001. [3] V. Gianuzzi. Data replication effectiveness in mobile adhoc networks. Proc.ACM Workshop PEWASUN, 2004. [4] T. Hara. Effective replica allocation in ad hoc networks for improving data accessibility. Proc.IEEE,INFOCOM, 2001. [5] M. Hollick, J. Schmitt, C. Seipl, and R. Steinmetz. The ad hoc on-demand distance vector protocol: An analytical model of the rote acquisition process. Proc. WWIC 2004, LNCS 2957, 2004.
[6] A. Klemm, C. Lindemann, and O. Walhorst. A special purpose peer-to-peer file sharing system for mobile ad hoc networks. Proc. VTC 2003, 2003. [7] S. McCanne and V. Jacobson. The bsd packet filter: a new architecture for user-level packet capture. Proc. Winter USENIX Conference, 1993. [8] P. Nuggehalli, V. Srinivasan, and C. F. Chiasserini. Energy-efficient caching strategies in ad hoc wireless networks. Proc. 39th IEEE A Design Automation Conference (DAC’02), 2002. [9] F. Sailhan and V. Issarny. Energy-aware web caching for mobile terminals. Proc. 22nd International Conference on Distributed Computing Systems Workshops (ICDCSW), 2002. [10] L. Yin and G. Cao. Supporting cooperative caching in ad hoc networks. Proc. Infocom, 2004.
