Download Data Storage, Transfers and Communication in Personal Clouds PDF

TitleData Storage, Transfers and Communication in Personal Clouds
Author
LanguageEnglish
File Size2.3 MB
Total Pages183
Table of Contents
                            Abstract
Kurzfassung
Acknowledgments
List of Tables
List of Figures
List of Abbreviations
Introduction
	Contributions
	Overview
	Collaborative work
	Previous appearance of this work
Background: Personal clouds
	Definition of a personal cloud
	Why work on personal clouds?
	Characteristics of personal clouds
	State-of-the-art in Personal Clouds
		Storage and Replication in Personal Clouds
		Naming in Personal Clouds
		Access control in Personal Clouds
		Computation in the Cloud
Storage & Replication in personal clouds
	Anzere Personal Cloud
	Related work and Motivation
	Target Scenario and Design Goals
	Anzere Design
		Data Representation and Device & Content-neutral Policies
		Layering and Structure of Anzere Policies
		Replication as constraint satisfaction
		Incorporation of Acquirable Resources
		Discussion
	System Implementation
		Resource sensors and knowledge base
		CLP solver and equivalence classes
		Data replication subsystem
		Overlay network and actuators
		Debugging/Using Anzere
	Anzere Evaluation
		Policy sustainability
		System resource overhead
		Steady-state tradeoffs
		Reactivity
		Optimization
		Summary
	Anzere Conclusion
Data transfers in personal clouds
	Introduction
	Background and Related Work
	Problem Description
		Money is a scarce resource
		Time is a scarce resource
		Energy is a scarce resource
	Approach
		Network Model
		Declarative Representation and Transfer Policies
		Formulating the optimization problem
		Output of the framework: Transfer schedules
	Implementation
	Evaluation
		Comparison of optimized and naive approaches
		Tuning the optimizer with policies
		Optimizer scalability and resource usage
	Conclusion and Future Work
Estimation models for personal clouds
	Introduction
	Understanding the Personal Cloud
		Diverse latency characteristics
		Power and money consumption characteristics
	Initial Approach
		Transfer time estimation model
		Monetary cost estimation model
		Energy cost estimation model
	Implementation
	Related Work
	An Initial Evaluation
	Future work
	Conclusion
Routing within & between personal clouds
	Introduction
	Routing within a personal cloud
		Motivation
		Approach
		Implementation
		Related Work
	Routing between personal clouds
		Background and Related Work
		Motivation and Challenges
		Design
		Implementation
	Evaluation: Simulation
		Potential benefits of the approach
	Evaluation: System Experiments
		Effect of increasing the number of advertised nodes
		Effect of exposing the topology between the advertised nodes
	Conclusion
Conclusions
	Directions for future work
Appendices
Appendix A
	An example set of Anzere replication policies
	A declarative implementation of Dijsktra
Curriculum Vitae: Ercan Ucan
                        
Document Text Contents
Page 1

Research Collection

Doctoral Thesis

Data storage, transfers and communication in personal clouds

Author(s):
Ucan, Ercan

Publication Date:
2014

Permanent Link:
https://doi.org/10.3929/ethz-a-010111223

Rights / License:
In Copyright - Non-Commercial Use Permitted

This page was generated automatically upon download from the ETH Zurich Research Collection. For more
information please consult the Terms of use.

ETH Library

https://doi.org/10.3929/ethz-a-010111223

Page 2

DISS. ETH NO. 21762

DATA STORAGE, TRANSFERS AND COMMUNICATION
IN PERSONAL CLOUDS

A dissertation submitted to

ETH ZURICH

for the degree of

Doctor of Sciences

presented by

ERCAN UCAN

Master of Science in Computer Science, University of Illinois at
Urbana-Champaign, USA

January 19, 1983

citizen of Turkey

accepted on the recommendation of

Prof. Dr. Timothy Roscoe, examiner
Prof. Dr. Gustavo Alonso, co-examiner

Dr. Anne-Marie Kermarrec, co-examiner

2014

Page 91

n900_1_tp_exp_latency.eps


72 CHAPTER 4. DATA TRANSFERS IN PERSONAL CLOUDS

the user. In Dexferizer’s approach, depending on the desired criteria, the optimizer
can be fed either type of function and be told to minimize cost or maximize utility.

As an initial representation of a cost or a utility function, Dexferizer uses a
2-dimensional matrix where the rows represent the destination and the columns
represent the source of a transfer. The value of element [x, y] of the matrix
denotes the cost or utility of performing a transfer from a source node y to a
destination node x. The matrix can be populated based on different optimization
criteria. One advantage of this model is the ability to flexibly plug custom cost
and utility calculation schemes into the framework. The section here mentions
some potential cost and utility functions that can be plugged into the formulation
as the optimization criteria.

1. Network latency as cost: One potential criteria for cost can be the
network latency among the nodes between which the transfers are to be
carried out. For instance, a cost matrix can be filled out with the shortest-
path values if the desired cost scheme was to use Dijkstra’s shortest path
algorithm to calculate the smallest latency paths.

2. Bandwidth as utility / Transfer time as cost: Bandwidth utilization
can be a criteria to maximize. This approach can also be represented as
a cost criteria where the cost is the completion time of the issued transfer
requests.

3. Money as cost: Another alternative for a cost criteria can be money, for
example using pricing models for 3G connections and rented cloud virtual
machines.

4. Power consumption as cost: Another optimization criteria can be the
power consumption as it is an important concern for mobile and hand-held
devices.

5. Cost as a combination of two or more parameters: Morever, an
approach for the cost function could also be to optimize for a combination
of parameters mentioned above. A user or developer can assign weights and
priorities to the parameters he wants to optimize for.

Incorporating routing information

The knowledge about and enumeration over the potential transfer endpoints alone
is not always sufficient for optimization. There are scenarios in which the solution
found by the optimizer would be sub-optimal; an example is illustrated in Fig-
ure 4.5. In this example there are four nodes in the network: a GoGrid virtual

Page 92

4.4. APPROACH 73

machine, a personal desktop, an EC2 virtual machine rented from Amazon and a
phone. A file residing on EC2 and GoGrid nodes needs to be transferred onto the
phone. The phone is connected to EC2 and GoGrid over a slow 3G link, and to
the desktop via a USB cable. The desktop PC is connected to EC2 and GoGrid
nodes over a fast internet connection. Here, looking at the bandwidth values the
links provide, the optimal transfer situation would be that the file gets copied in
parallel via the Desktop PC from EC2 and GoGrid machines over to the phone.

USB

GoGridEC2

Desktop Phone

3G

3G

0.3 MB/s

0.3 MB/s

4.2 MB/s

1
.0

M
B

/s

2.
1

M
B/

s

Figure 4.5: A use case for supporting the integration of routing information.

This scenario demonstrates that there are at least two dimensions to the prob-
lem space. The first dimension is the end points involved in the transfer of an
object. The second dimension involves the possible paths the transfers can be car-
ried out over, once the sources and destinations are determined. Considering only
the potential transfer endpointscannot completely capture the whole optimization
space.

Dexferizer captures the second dimension of the space by adding reasoning
about path and routing information into the optimization framework. The opti-
mizer contains flexible and tunable, declarative routing algorithms that run using
the existing declarative link and device information in the system. The optimizer
can generate multi-hop routes for the transfers based on one of the various metrics
such as latency, bandwidth, or monetary cost that it has been tuned for.

Similer Documents