• Abstract and Figures
• Public Full-text

Storage Tradeoffs in a Collaborative Backup Service for Mobile Devices Ludovic Courtès, Marc-Olivier Killijian, David Powell To cite this version: Ludovic Courtès, Marc-Olivier Killijian, David Powell. Storage Tradeoffs in a Collaborative Backup Service for Mobile Devices. 2006. hal-00187069 HAL Id: hal-00187069 https://hal.archives-ouvertes.fr/hal-00187069 Preprint submitted on 13 Nov 2007 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Storage Tradeoffs in a Collaborative Backup Service for Mobile Devices† Ludovic Courtès Marc-Olivier Killijian David Powell fi[email protected] LAAS-CNRS 7 avenue du Colonel Roche 31077 Toulouse cedex 4 France Abstract Our goal is to leverage the ubiquity of communicat- ing mobile devices to implement a collaborative backup service. In such a system,devices participating in the ser- Mobile devices are increasingly relied on but are vice would be able to use other devices’storage to back used in contexts that put them at risk of physical dam- up their own data. Of course, each device would have to age, loss or theft. We consider a fault-tolerance ap- contribute some of its own storage resources for others proach that exploits spontaneous interactions to imple- to be able to benefit from the service. ment a collaborative backup service. We define the con- Internet-based peer-to-peer systems paved the way straints implied by the mobile environment,analyze how for such services. They showed that excess resources they translate into the storage layer of such a backup available at the peer hosts could be leveraged to support system and examine various design options. The paper wide-scale resource sharing. Although the amount of concludes with a presentation of our prototype imple- resources available on a mobile device is significantly mentation of the storage layer, an evaluation of the im- smaller than that of a desktop machine, we believe that pact of several compression methods,and directions for this is not a barrier to the creation of mobile peer-to-peer future work. services. They have also shown that wide-scale services could be created without relying on any infrastructure 1. Introduction (other than the Internet itself), in a decentralized, self-ad- Embedded computers are becoming widely avail- ministered way. From a fault-tolerance viewpoint, peer- able, in various portable devices such as PDAs, digital to-peer systems provide a high diversity of nodes with cameras, music players and laptops. Most of these de- independent failure modes [13]. vices are now able to communicate using wireless net- In a mobile context, we believe there are addition- work technologies such as IEEE 802.11, Bluetooth, or al reasons to use a collaborative service. For instance, Zigbee. Users use such devices to capture more and access to a cell phone communication infrastructure more data and are becoming increasingly dependent on (GPRS, UMTS, etc.) may be costly (especially for them. Backing up the data stored on these devices is of- non-productive data transmission “just” for the sake of ten done in an ad hoc fashion: each protocol and/or appli- backup) while proximity communications are not (us- cation has its own synchronization facilities that can be ing 802.11, Bluetooth, etc.). Similarly, short-distance used when a sister device, usually a desktop computer, is communication technologies are often more efficient reachable. However, newly created data may be held on than long-distance ones: they offer a higher through- the mobile device for a long time before it can be copied. put and often require less energy. In some scenarios, This may be a serious issue since the contexts in which infrastructure-based networks are simply not available mobile devices are used increase the risks of them being but neighboring devices might be accessible using lost, stolen or broken. single-hop communications, or by ad hoc routing. Our target service raises a number of interesting is- sues, in particular relating to trust management,resource accounting and cooperation incentives. It raises novel is- † This work was partially supported by the MoSAIC project (ACI S&I, French national program for Security and Informatics; see sues due to, for instance, mostly-disconnected operation http://www.laas.fr/mosaic/) and the Hidenets project (EU-IST- and the consequent difficulty of resorting to centralized FP6-26979). or on-line solutions. A preliminary analysis of these is- systems and what we envision: connectivity. Although sues may be found in [6,14]. In this paper, the focus is on these Internet-based collaborative backup systems are de- the mechanisms employed at the storage layer of such a signed to tolerate disconnections, they do assume a high- service. We investigate the various design options at this level of connectivity. Disconnections are assumed to be layer and discuss potential trade-offs. mostly transient, whether they be non-malicious (a peer In Section 2, we will detail the requirements of the goes off-line for a few days or crashes) or malicious (a cooperative backup service on the underlying storage peer purposefully disconnects in order to try to benefit layer. Section 3 presents several design options for this from the system without actually contributing to it). layer based on the current literature and the particular In the context of mobile devices interacting spon- needs that arise from the kind of devices we target. In taneously, connections are by definition short-lived, un- Section 4, using a prototype of this storage layer, we will predictable, and very variable in bandwidth and reliabil- evaluate some storage layer algorithms and discuss the ity. Worse than that, a pair of peers may have a chance necessary tradeoffs. Finally, we will conclude on our encounter and start exchanging data, and then never current work and sketch future research directions. meet again. To tackle this issue, we assume that each mobile de- 2. Collaborative Backup for Mobile vice can at least intermittently access the Internet. The Devices backup software running in those mobile devices is ex- pected to take advantage of such an opportunity by re- This section gives an overview of the service envis- establishing contacts with (proxies of) mobile devices en- aged and related work. Then we describe the require- countered earlier. For instance, a contributor may wish ments we have identified for the storage layer of the to send data stored on behalf of another node to some service. sort of repository associated with the owner of the data. 2.1. Design Overview and Related Work Contributors can thus asynchronously push data back to their owners. The repository itself can be implemented Our goal is to design and implement a collaborative in variousways: an email mailbox,an FTP server,a fixed backup system for communicating mobile devices. In peer-to-peer storage system, etc. Likewise, data owners this model, mobile devices can play the role of a con- may sometimes need to query their repository as soon as tributor, i.e., a device that offers its storage resources to they can access the Internet in order to pull back (i.e., re- store data on behalf of other nodes, and a data owner, store) their data. i.e.,a mobile device asking a contributor to store some of In the remainder of this paper, we will focus on the its data on its behalf. Practically, nodes are expected to design of the storage layer of this service on both the contribute as much as they benefit from the system;there- data owner and contributor sides. fore, they should play both roles at the same time. For the service to effectively leverage the availabil- 2.2. Requirements of the Storage Layer ity of neighboring communicating devices, the service We have identified the following requirements for has to be functional even in the presence of mutually sus- the mechanisms employed at the storage layer. picious device users. We want users with no prior trust re- Storage efficiency. Backing up data should be as lationships to be able to use the service and to contribute efficient as possible. Data owners should neither ask to it harmlessly. This is in contrast with traditional habits contributors to store more data than necessary nor send where users usually back up their mobile devices’ data excessive data over the wireless interface. Failing to do only on machines they trust, such as their workstation. so will waste energy and result in inefficient utilization This goal also contrasts with previous work on col- of the storage resources available in the node’s vicinity. laborative backup for a personal area network (PAN), Inefficient storage may have a strong impact on energy such as FlashBack [19], where participating devices are consumption since (i) storage costs translate into trans- all trustworthy since they belong to the same user. How- mission costs and (ii) energy consumption on mobile ever, censorship-resistant peer-to-peer file sharing sys- devices is dominated by wireless communication costs, tems such as GNUnet [2] have a similar approach to se- which in turn increase as more data are transferred [28]. curity in the presence of adversaries. Compression techniques are thus a key aspect of the stor- Recently, a large amount of research has gone into age layer on the data owner side.

Load more

  11

Copy Link