On Incentive Mechanisms for Resource Sharing in Community Clouds

(1)

UNIVERSITAT POLITÉCNICA DE CATALUNYA

Facultat d’Informática de Barcelona

On Incentive Mechanisms for Resource Sharing in

Community Clouds

Ümit Çavuş Büyükşahin

Dissertation submitted in partial fulfillment of the requirements for the European Master in Distributed Computing Programme

Supervised by

Prof. Felix Freitag, Universitat Politécnica de Catalunya (UPC) Amin Khan, Universitat Politécnica de Catalunya (UPC)

Jury

Prof. Leandro Navarro, Universitat Politécnica de Catalunya (UPC) Prof. Johan Montelius, Royal Institute of Technology (KTH)

Prof. David Carrera, Universitat Politécnica de Catalunya (UPC)

(2)

(3)

Abstract

Community networks have been growing as an open network where citizens of the com-munities share their communicational infrastructure for building the network. The built community-owned network presents ease of accessing internet and benefiting from local ser-vices to its participants via IP-based wireless connections. Although the shared infrastructure network has been successful to create IP connectivity between the citizens, the idea behind the rising technology cloud computing which is provision of services has not appeared in com-munity networks yet. In this thesis, it is proposed to build a comcom-munity cloud architecture which can provide Infrastructure-as-a-Service (Iaas) by using resources of participants of com-munity networks. In addition to this, it is also focused on developing an incentive mechanism to influence the participants on being cooperative for contributing their storage and com-puting as cloud resources to a community cloud. In order to study resource incentive-based assignment regulation, a round-based simulator which can be adaptable to different regula-tory approaches is implemented. In addition to the simulator, a prototype is implemented on real testbed nodes of community networks based on evaluation results from the simulator to determine the feasibility of the developed incentive mechanism. Moreover, in order to be able to observe the behavior of the developed incentive mechanism in realistic scenarios, the prototype implementation is deployed on large-scale in a single machine using multi-thread technique; according to its experimental results, improvements of the incentive mechanism are developed. From the experimental results of the different approaches, it is suggested that a hierarchical distributed architecture using super nodes is suitable to build a community cloud and it should have a mechanisms to incentive the participants for contributing to the system for the sustainability of the community cloud.

(4)

ii Abstract

Keywords

Community Network Community Cloud Incentive Mechanism

(5)

To my parents Fevzi and Zeynep Buyuksahin, everything dear as always; to my younger brother Ugur Buyuksahin and cousin Ahmet Buyuksahin, beloved invariably;

(6)

(7)

Acknowledgements

I would like to express my deepest gratitude to my thesis advisor Prof. Felix Freitag, who gave me the opportunity to study in this project, for always helping with all his kindness and for his guidance throughout the research. His continued support led me to accomplish this study. I also benefited greatly from interactions and discussions with other member of this project, Amin Khan, to whom I am deeply indebted.

I would like to thank also the members of the CLOMMUNITY and CONFINE projects in UPC for having helpful meeting and for keeping their room open to me whenever I needed their support.

I am intensely grateful to my family for their immense supports which are the bases of my achievements. I am also heartily indebted to my big family, Sahinogulları for their graceful moral and material supports. I wish also thank to my great friends from Kırsehir Science High School and EMDC being one of the greatest experience in my life for their invaluable technical and nontechnical conversations. Last but not least, the special thanks to my girlfriend who gave me her unconditional support and love through all this long process.

(8)

(9)

Contents

1 Introduction 1

1.1 Contributions . . . 2

1.2 Results . . . 2

1.3 Research Context . . . 3

1.4 Organisations of this Thesis . . . 3

2 Background 5 2.1 Community Network . . . 5

2.2 Community Cloud . . . 6

3 Related Work 9 3.1 Cloud Computing Systems . . . 9

3.2 Incentive Mechanisms . . . 11

3.2.1 Inherent Generosity Schema . . . 11

3.2.2 Fixed-Contribution Schema . . . 12

3.2.3 Reciprocity-Based Schema . . . 12

3.2.4 Monetary-Payment Schema . . . 13

4 Community Cloud Design 15 4.1 Requirements . . . 16

4.2 Distributed Architecture Using Super Nodes . . . 17

4.3 Design Details . . . 18

4.3.1 Community Cloud Manager . . . 18

(10)

viii Contents

4.3.2 Cloud Coordinator . . . 19

4.3.3 Super Node (SN) . . . 20

4.3.4 Ordinary Node (ON) . . . 20

5 Incentive Mechanism Design 21 5.1 Requirements . . . 21

5.2 Discussion of Related Work . . . 23

5.3 Effort-Based Incentive Mechanism . . . 24

5.4 Assumptions . . . 25

5.5 Formulations . . . 25

5.6 Algorithm . . . 26

6 Exploration of Effort-Based Incentive Mechanism 29 6.1 Round-based Simulator Implementation . . . 29

6.2 Evaluation . . . 30

6.2.1 Efficiency . . . 31

6.2.2 Fairness . . . 33

7 Prototype for Regulation Mechanism 35 7.1 Implementation . . . 35

7.2.1 One SN-Zone Scenario . . . 41

7.2.2 Multiple SN-Zone Scenario . . . 44

8 Large-Scale Simulation 47 8.1 Multi-thread Simulator Implementation . . . 47

9 Conclusion 57 9.1 Discussion . . . 58

9.2 Future Work . . . 59

(11)

List of Figures

2.1 Super-node network topology of Guifi.net . . . 6

4.1 Hierarchical architecture of community cloud with super nodes(SN) and ordi-nary nodes(ON) . . . 17

4.2 Conceptual overview of the Community Cloud Manager . . . 18

4.3 Components of Cloud Coordinator . . . 19

5.1 Data flow of handling a request in a super node . . . 27

6.1 Conceptual overview of Round-based Simulator . . . 30

6.2 Experiment results in high-demand scenario . . . 32

6.3 Experiment results in low-demand scenario . . . 33

6.4 Success ratio of both large-resource and small-resource nodes in different in-centive mechanisms . . . 34

7.1 Components of ordinary node and super node implementations . . . 36

7.2 Structre of JSON document in ON_List database . . . 37

7.3 Structre of JSON document in SN_List database . . . 38

7.4 Overall resource utilization of the four ordinary nodes . . . 42

7.5 Ratio of fulfilled and rejected requests for each ordinary node . . . 43

7.6 Resource assigned over different SN zones . . . 45

8.1 Handling a request query in a super node . . . 50

(12)

x List of Figures

8.2 Breakdown of responses to requests from nodes with effort and contribution based mechanisms . . . 53 8.3 Resource utilization along 24 minutes . . . 54 8.4 Success ratio comparison of provider ON selection strategies . . . 54

(13)

List of Tables

5.1 Comparision of existing incentive mechanisms for community cloud . . . 23

7.1 Messages between nodes in prototype implementation . . . 39

7.2 Resource capacity of nodes . . . 41

7.3 Resource distribution in the system . . . 44

8.1 Configuration for each ordinary node in a zone . . . 52

8.2 Percentage of successful requests for different node configurations with effort and contribution based incentive mechanisms . . . 53

(14)

(15)

CHAPTER

1

Introduction

C

ommunitynetworking offers a novel way for IP-based wireless connectivity of

communi-ties with a shared communication infrastructure. This sharing approach has triggered the rising of the concepts behind community cloud. These concepts have been explained in the generic forms before. For example, the study [24] has considered community cloud as a cloud deployment model in where participants have both consumer role in the sense of who utilize from other participant’s resources and producer role in the sense of who share own-resources with other participants.

The presented community cloud in this thesis is a cloud model which will be deployed on a community network by providing its participants’ storage and computation to its con-sumer participants. Therefore, this cloud approach has to consider challenges of community networks:

• Variety of Hardware: The participants in community network exhibit a heterogeneous view with diversity of devices and physical equipment

• Decentralized Structure: The physical layer of the community network is composed of participants’ resources which are managed by users. Because of that, it is very likely that there is no central authority to manage the provision of resources.

• Dynamic Overlay: There are large number of participants who are spread on a wide

geographic area and the network can be easily changed when the nodes change their status such as, joining to system or leaving from system, crash, and the others.

(16)

2 Introduction

Although community networks have these and more challenges, it seems that they have reached a success level in the sense of the number of participants. Recent studies [6] have indicated that community networks which are located in Europe such as Guifi.net [1], AWMN [4], FunkFuer [2], Freifunk [5] have from 500 to 20000 nodes.

The community networks present a practical platform for resource sharing. However this sharing could not go beyond sharing the node’s bandwidth in the reciprocal manner as IP networks. In this thesis, it is visioned that nodes in the community networks can have storage and computing resources to share them with other nodes and there are some powerful and critical nodes manages this reciprocity sharing. For this purpose, this thesis proposes a distributed architecture for community clouds. In addition, in order to provide sustainability of it, an incentive mechanism is developed to encourage the participants for being cooperative in cloud sharing platform.

1.1

Contributions

There are two main contribution of this thesis. In the first one, by considering the community network topology, a hierarchical decentralized architecture is created. In this architecture, there are many ordinary nodes which represents end users having cloud resources in the net-work. The other sort of nodes are called super nodes, managing resource sharing regulation for an assigned set of ordinary nodes in the centralized sense, and communicating with other super nodes for building cloud in the decentralized sense. In the second one, this thesis is focused on the way of incentivizing participants to bring together their storage and compu-tation resources into community cloud. A regulation mechanism which is located in super nodes is developed based on reciprocal computational resource sharing. By the help of this mechanism, it is targeted that a participant can benefit from cloud resources as much his/her effort in the system.

1.2

Results

The outcomes of this thesis are a proposed hierarchical architecture for community cloud and the prototype of one of its key component, the regulation mechanism which responsible for managing resource assignments between nodes. In addition, to analyze the prototype on larger scale scenarios, a multi-thread simulator which deploys the prototype implementations on threads is implemented. The effectiveness of the developed designs in the manner of

(17)

1.3 Research Context 3

fairness, efficiency are demonstrated through experimental evaluations conducted with the implementations and their different configurations.

1.3

Research Context

The research and development described in this thesis was done within the Distributed Systems Group at Computer Architecture Department (DAC) of Universitat Politecnica de Catalunya (UPC), Barcelona. The papers that describe part of this work are listed:

• Support Service for Reciprocal Computational Resource Sharing in Wire-less Community Networks. U. Buyuksahin, A. Khan, F. Freitag. In The 5th International Workshop on Hot Topics in Mesh Networking (IEEE HOTMESH 2013), co-located with WoWMoM, June 4, 2013 Madrid, Spain.

• [submitted]Incentive-based Resource Assignment in Community Clouds with P2P Coordination. A. Khan, U. Buyuksahin, F. Freitag. IEEE International Con-ference on Peer-to-Peer Computing. September 9-11, 2013. Trento, Italy.

• [submitted]Towards Incentive-based Resource Assignment and Regulation in Clouds for Community Networks. U. Buyuksahin, A. Khan, F. Freitag. 10th Inter-national Conference on Economics of Grids, Clouds, Systems and Services. September 18-20, 2013. Zaragoza, Spain.

1.4

Organisations of this Thesis

The remainder of this thesis is organized as follows. Chapter 2 describes the background for this thesis. Chapter 3 provides an overview of the related work. Chapter 4 explains the architecture for community clouds. Chapter 5 describes the design details of the developed incentive mechanism. Chapter 6 presents the results obtained from the exploration of effort-based incentive mechanism. Chapter 7 examines the implemented prototype for the regulation mechanism component of community clouds. Chapter 8 explains the details of the large-scale simulator with the prototype and shows its evaluation results. Lastly, Chapter 9 concludes the thesis and describes future work.

(18)

(19)

CHAPTER

2

Background

2.1

Community Network

Recently, the popularity of community networks has been increasing, and it has been growing rapidly. There are several reason of that: Firstly, a community network offers a low-cost connectivity which is based on the participation of citizens. Especially, those who are living in underdeveloped regions or areas far away from commercial network providers can benefit from community network facilities. Besides of them, the continued growth in usage of the internet and wireless devices have brought community networks as an alternative solution to popular wireless connectivity approaches. Guifi.net [1], FunkFeuer [2] , Seattle Wireless [3] are a few successful deployment of community networks in the world. According to [6], Guifi.net is one of the largest community mesh network with more than 17000 operational nodes and it is claimed that it has been exponentially growing.

In the community network topology, there two main types of nodes which are playing different roles in the community network: client nodes which represent the end user in the network and super nodes which form the backbone. A super node is used to connect to other super nodes with wireless link and distributes the signal via access points to client nodes. In order to be able to supply good services, they are located at strategic positions in the network which can be either community network participant’s premises or independent third party locations. The topological analyses of Guifi.net [6] shows that 7% of Guifi.net nodes are composed of super nodes. This topology is indicated in Figure 2.1 which is retrieved

(20)

6 Background

Figure 2.1: Super-node network topology of Guifi.net

from the Guifi.net tutorial web page1 .

Since a community network is based on reciprocity connectivity of nodes, social aspects take an important place in its deployment. The clients have to be in collaboration with other clients. Therefore, the participants of community network are not only consumer but also producer. Most of the members contribute to the system in the manner of infrastructure e.g bandwidth and their technical knowledge to maintain the IP network. For example, when a new node joins the network, the neighbouring client nodes have to create a connection with the new one, in order for it to have interaction with other client nodes. Although technical support contribution is based on voluntariness of participants, resource sharing in community networks is ruled by a kind of membership agreement. For instance, Wireless Commons License (WCL)2 which is mostly used by many community networks remark that the members who extend the networks have to allow the traffic of other participants to pass over their own network resource.

2.2

Community Cloud

Cloud computing is the rising internet based technology that offers unlimited resources for the provision of services. Because of that, it is has a rapid increase in its popularity with datacenters growing enormously and in its usability with dependence of many organizations on the cloud vendors. However, this growing and dependence come with many doubts on cloud technology such as, security, economical and environmental concerns, and the others [7]. The community cloud idea offers an new architecture with a novel approach in the cloud

1

http://ca.wikibooks.org/wiki/Guifi.net._Tutorial/Introducció

2

(21)

2.2 Community Cloud 7

paradigm. This novel approach, which primarily combines the idea behind Grid Computing [8] and Cloud Computing together, aims to utilize underutilized personal devices as provider, rather than constituting huge datacenters.

In the community cloud approach, the heterogeneous nodes create a collaboration for the sustainability. Therefore, each of them has potentially all roldes among provider, consumer, and coordinator in the cloud system.

(22)

(23)

CHAPTER

3

Related Work

In this section, a survey of the literature is presented as related to subject of this thesis. The related studies can be divided into two groups: (1) studies which are related to community cloud computing on the level of complete system, (2) studied which are related to incentive mechanism for resource sharing.

3.1

Cloud Computing Systems

After cloud computing technology has achieved great success, the interest in supplying ser-vices from cloud has been exponentially increasing. In order to be able to provide feasible services to clients, the cloud vendors set up huge data centers which are using excessive amount of resources [24]. Those resources are provisioned to the clients who pay for to utilize cloud services.

There are several alternative approaches to these commercial clouds which form the dis-tributed multi-owned computing platforms, such as PlanetLab [25] and Seti@Home [26]. In PlanetLab, the users have to contribute a defined minimum amount of resource before uti-lizing from system. The Seti@Home is primarily dependent on voluntariness of participants. However, none of these approaches imply equivalent situation with community network.

When the whole system of community cloud computing is considered [24], there are several similar research prototypes. However, none of them targets wireless community networks.

Skadsem et al. [27] uses local cloud services for providing applications to users. This

(24)

10 Related Work

prototype deploys social mechanism which evaluates trustworthiness of members in the com-munity. With the this side, it is similar to our system. However, they do not deploy any incentive mechanism for their nodes, unlike our work. In their studies, it is envisioned that there are two different cases of utilization of cloud applications in rural communities. The first case is distributed storage system which is an online sharing platform where the mem-bers of communities can share their files. They claimed that this has been succeeded. In the second case, it is aimed to operate high compute-based operations collaboratively.

The Cloud@Home [28] project aims to create new cloud paradigm by combining the viewpoint of commercial clouds with volunteer based approach. The commercial cloud idea is used in where the credit-based incentive mechanism is designed to ensure Quality of Service (QoS). Since this prototype does not only provide enough resources to meet user requests but also consider QoS requirements, its implementation is more complicated as compared to similar prototypes. However the sufficient design information about this incentive mechanism are not provided in their report.

The CuteCloud [29] is an evolving project which has similar goals with community cloud computing such as, breaking dependency to commercial clouds, improving resource availabil-ity and increasing resource utilization. The project aims to transform underutilized comput-ing resources in commodity’s devices into self-provisioned dedicated community servers. Like Seti@Home, they do not deploy any incentive mechanism, because it assumes that partici-pants voluntarily share their resource. resource.

The Clouds@home [30] ensures Quality of Services for providing computation and storage resources of volunteer participants, like Seti@Home. The several of these ensured services are durability and availability of data, performance in access and the others. However, it does not consider any incentive mechanism to regulate resources and users’ request in the system.

The P2PCS [31] is an ongoing project which has an implementation of an decentral-ized Peer-to-Peer Cloud system prototype. This prototype is working as Infrastructure-as-a-service (IaaS) by providing simple service for managing Virtual Machines (VM). Mutliple VMs are grouped and connected to a single networks. The information of these groups of VMs are managed using sort of gossip protocols. However, through these operations it does not deploy any incentive mechanism.

(25)

3.2 Incentive Mechanisms 11

3.2

Incentive Mechanisms

The decentralized self-organized resource systems rely on resource contribution of volunteer nodes who are self-determination. Because of that, sustainability and performance of the systems is mainly dependent on level of collaborative decision of nodes. The recent studies on P2P networks [12], where the peers’ roles are both service provider and consumer, showed that the peers’ conducts are self-interesting and their independent decision always attempt to maximize their own network utilization. For example, in 2000 et al. [9] indicated that approximately 70% of the peers in the Gnutella network never share any resources and 63% of the peers were sharing uninteresting resources which were not requested. And moreover, approximately 50% of request queries were supplied by just 1% of the peers. There are two most well-known peers non-cooperative conducts. The first one is thefree-riders [9] who are benefiting from a system without adding value to the system. The second one is the white-washing attack [13] which is applied by free-riders in order to avoid from punishment targeted to free-riders by leaving and rejoining to the system. However, it seemed that increasing in individual rationality decreases the collaboration between nodes , thereby degrading the social welfare in the system.

There are many researches [10],[11] revealed that nodes’s rational conducts and the ab-sence of a deployed incentive mechanism are the main factors that lead to having a non-collaborated systems. In order to canalize the nodes to be more cooperative, those systems develops incentive mechanisms.

There are various type of incentive mechanism in literature [14],[15],[16] each of them is developed to meet specific requirements for a having sustainable volunteer-based system. These existing incentive mechanisms are classified into four schemes:

3.2.1 Inherent Generosity Schema

This schema primarily targets to extract behavior of selfish nodes in the system. The au-thors in [17] has developed strong mathematical models to analytically estimate percentage of selfish nodes in the system. This estimation is compared with a threshold value which shows societal generosity level. If the estimation exceeds the threshold, the functionality of the system is stopped. Therefore, not only selfish nodes but also cooperative nodes are also penalized. Besides, stopping the whole system does not create a smart way to have sustain-ability. Because of that, its deployment in the real life is not very practical where there are many selfish nodes.

(26)

12 Related Work

3.2.2 Fixed-Contribution Schema

In this schema, nodes are obligated to contribute a fixed amount of resources at least to be able to participate the system. This fixed amount is specified by a central unit which also monitors the nodes. Direct Connect [18] which is a file sharing protocol applies the fixed-contribution incentive mechanism. In this protocol, sharing minimum amount of resources and supplying minimum upload bandwidth are required to be part of system. Although the implementation of this schema is simple, it is just for single service applications, such as file sharing. Moreover, the centralized structure prevents it to reach many number of nodes, degrades the availability and performance. Besides, it does not bring with a concrete solution against free-riders.

3.2.3 Reciprocity-Based Schema

The nodes in this schema hold contribution histories of other nodes. By utilizing these history information, further resource allocation decisions are made. According to the way where a node get histories of the transaction partner nodes, the schema is divided into two different approaches:

Direct Approach

In this reciprocity approaches, a node determines its behavior against a transaction partner based on only partner’s behaviors in the previous trade. This schema can be in real time, if the transaction partners evaluate each other’s behavior during transaction. The well known example of this schema is tit-for-tat which BitTorent uses [19]. In this exchange based mechanism, a node can only allocates resources to other nodes as much as they supply. Since the nodes’ behaviors directly affects the amount of allocated resources, the nodes who want to utilize from the shared resources increases the collaboration in the system. However, the applicability of this approach of incentive mechanism is mostly depend on other services on the system, such as finding partner node in the network. The another disadvantage of this approach is to be service oriented, such as only file sharing. Lastly, free-riders problem is one of the biggest challenging for this approach. The methodologies which apply this approach in their system develop their own partial solutions against the this problem such as,Suspect Tableimplementation of this project [23] which holds every nodes meta data with their probability of being free-rider.

(27)

3.2 Incentive Mechanisms 13

Indirect Approach

In this approach, not only transactional partners, but also other nodes’ behaviors on re-questor are taken into consideration during resource management evaluation. Therefore, this approach can also be referred as reputation-based system. The reputation, which is cal-culated by using transactions of a node in the past, is using for predicting the requestor’s behaviors in future. Moreover, trust-based systems, like EigenTrust [20] are also considered in this approach. For example, it calculates global trust values as reputation for each node in the system. Although indirect approach increases scalability as compared to direct reci-procity approach, it suffers from depending on trustworthiness of third parties which can cause of the spammer voter problem. Moreover, it is really hard to put a solution against the white-washing problem in this approach.

3.2.4 Monetary-Payment Schema

The users pay for getting specific services to provider in where the payment event is or-ganized by a third-party. This schema is mainly depend on strong economical models and microeconomic infrastructure. It has two type of approaches in the way how the payment is handled:

Token-Based Approach

In this approach tokens are used as virtual currency and bought from a centralized third-party. PPay [21] can be classified in this approach, which develops self-organized, transferable tokens, called coins. Although this schema is easy to implement, the centralized structure and the dependence on the third-party is the biggest disadvantages. Besides, the third-party has to keep track of each transactions which leads to scalability challenge.

Account-Based Approach

In this approach, every nodes has an account and a broker which organizes authorization of payment transactions. The well known successful deployment of this schema is PayPal [22] which manages nodes’ account by using the broker rather than keeping track of each transactions. Even though the account-based approach is more scalable as compared to the token-based approach, it needs to have a complex account management model in order to be able to carefully deal with some economical problems such as inflation and deflation. Besides, it has to have a robust security service to protect user account information.

(28)

(29)

CHAPTER

4

Community Cloud Design

In community clouds, there can be a number of independent cloud systems, which are not necessarily be connected, using by different kind of communities. In addition to this, in each of these cloud systems communities can be varied in terms of resource capacity, quality of resources. The biggest reason of this is the heterogeneity of the participants in these communities. Because of that, community cloud systems differs greatly from the public deployment model of commercial cloud systems which are composed of almost homogeneous devices deploying on datacenters. Similarly, the community clouds are also different from hybrid and private deployments models in commercial cloud systems , since they are able to unite as a larger group. For example, in hybrid cloud case there can be very few number of participants, each of them might have hundreds number of machines. On the other side; the participants of community cloud system in excess of one hundred might have tens number of machines individually. In addition to them, it is noticed in the related work studies Section 3.1 that this cloud system is mostly different from the existing cloud computing systems in the way of proposing and discussing clouds within wireless mesh community networks. Therefore, these differences should be carefully handled while setting requirements of community cloud case.

In the next sections, the necessary requirements for setting up the design and architecture of the community cloud system are explained. To be able to deploy a successful community cloud case on community networks, they are needed to be satisfied.

1

This chapter is based on the paper [51]

(30)

16 Community Cloud Design

4.1

Requirements

1. Autonomy: This requirement is one of the most important one which imply that each individual clouds in community cloud have their own owners who are charged for man-aging and operating the corresponding one. This means, each individual cloud owner works independently, the others can not play a role on his/her decisions. However, there are several rules that these owner has to obey to participate the community clouds. For example, each individual cloud owner should use provided API by com-munity clouds.

2. Security: Security is the one of the hottest topic in both commercial and community clouds with many challenges to be overcomed for ensuring participants’ trust [32]. In community coud case, it became vital due the fact that there are many independent cloud owner operators [33]. The cloud system should ensure to protect consumer’s applications or data which are located on other community participants’ machines against unauthorized access. Likewise, providers’ machine should not be affected from the consumer’s applications and data which deployed on it.

3. Self-Management: Since the participants in the community clouds are self-determination means that they can behave as they want e.g join to system or leave from system any time, having a self-management feature in the system is very important to maintain the services without any failure.

4. Utility: In order for participants to widely internalize the community cloud, the pro-vided applications and services should be qualified and varied to meet all participants’ interest as much as possible. In addition, they should be effortless to manage and use to easy overhead on users.

5. Ease of Use: When the most of the participants are considered in community cloud, it can not be expected from them to have a technical background about cloud infrastruc-ture. Therefore creating and managing nodes should be as much as simple to anyone who can easily do. Moreover, the API provided by community cloud should also be easy-to-use.

6. Incentives for Contribution: The community cloud requires its own incentive mech-anism to influence the participants for sharing their computation and data resources with the system. This mechanism is very important for community cloud to be a sustainable system.

(31)

4.2 Distributed Architecture Using Super Nodes 17

Figure 4.1: Hierarchical architecture of community cloud with super nodes(SN) and ordinary nodes(ON)

properties e.g. high CPU and RAM values, large storage spaces, there can be machines which are suffered from physical limitation. This heterogeneity in the physical capacity level has to be seamlessly handled. Similarly, the differences on the software level which can be necessary for managing cloud systems such as the the provided API should be impeccably approached.

4.2

Distributed Architecture Using Super Nodes

As explained in Background Section 2 in detail, there are different level nodes in the com-munity networks. For instances, Guifi.net [1] which is the largest comcom-munity mesh network includes two different level nodes: terminal nodes and hubs. While the terminal nodes sym-bolize the end users in community network, the hubs are responsible for serving traffic to the terminal nodes which are assigned to it.

Since community cloud will be deployed on community networks, its topology explained in the above has to be considered with the explained requirements in the previous section to have a concrete architecture. As a result, a hierarchical architecture [34] is proposed for community clouds. With this architecture, the cloud includes two node types which are depicted in the Figure 4.1: super node which is in charge of managing and operating set of the assigned nodes and ordinary node which has a unique connection to a super node representing end users. With the point of view of one super node architecture, the cloud services are centrally managed. The distributed architecture is achieved by connecting super nodes with others in the network.

(32)

Figure 4.2: Conceptual overview of the Community Cloud Manager

In addition to well adaptation of the hierarchical design in community cloud architecture, it has many advantages for resource sharing based systems in consequence of being categorized between pure decentralized and centralized systems [34]. For example, it benefits from both efficient search and control characteristics of the centralized systems in its one super node architecture and load-balancing, scalability, availability characteristics of the decentralized systems in its connected super node architecture. There are many successful large scale applications which are designed in the hierarchical manner, such as Skype[35] and Kazaa[36].

4.3

Design Details

In the explained architecture at above, the self-organized super nodes are managed and operated independently from each other. Additionally, ordinary nodes principally can change their connectivity status and have self-determination about contribution. Due the the these facts, the infrastructure of the community clouds should be enough robust.

4.3.1 Community Cloud Manager

It is proposed to deploy a cloud management platform attributed to super nodes in community cloud in order to enable to have it in community networks. The layered overview of proposed cloud management platform is indicated in the Figure 4.2 being composed of four different layer.

Since ordinary nodes are not only consumers but also providers in the system, they are represented in the hardware layer of the cloud design. The core layer placed in super nodes in the design is responsible for managing virtual machines by the help of special softwares.

(33)

4.3 Design Details 19

Figure 4.3: Components of Cloud Coordinator

The cloud coordinator residing in super node is designed for resource management. The last layer, front end is created for providing interface of services (Iaas) to end users.

The main part of cloud manager is the virtual machine manager (VMM) whose compo-nents are resided into both super nodes and ordinary nodes. VMM is designed for instantiat-ing, scheduling and monitoring the virtual machines locate on hosts. The number of existing cloud management platforms has been rising with increasing popularity in cloud systems to meet different requirements. The well-known ones are OpenNebula[37] and OpenStack[38].

4.3.2 Cloud Coordinator

Each super node has its own cloud coordinator component which can also named as super node controller. It coordinates resources assignment policy in community cloud by creating connectivity with both other super nodes and the set of attached ordinary nodes. While it visualizes itself to other super nodes as a resource storage, it has a centralized cloud system in the local view.

The Figure 4.3 depicts the cloud coordinator components. The ordinary node man-agement is responsible for registering ordinary nodes to corresponding super nodes in the

ON_List databases. Resource requests are evaluated in the regulation mechanism which uses information in resource utilization and contribution of corresponding ordinary node, be-fore assigning the resources. On the super node side, in order to have a decentralized approach super nodes create connectivity between them by discovering themselves using gossip-based algorithms. Moreover, the request which can not be locally satisfied is directed to another super node which is chosen among the SNs in the SN_List databases.

(34)

4.3.3 Super Node (SN)

The greater responsibilities are assigned to super nodes (SNs) in the point of view of cloud manager platform. Therefore, it is suggest to assign powerful or stable machines to SNs eg, the hubs in Guifi.net scneario [1]. It is required to install the cloud manager software indicated in the Figure 4.2 inside SNs so that they can provide virtual machines and manage them in ordinary nodes.

A set of ordinary nodes are attached to each SNs as showed in the Figure 4.1 and their metadata is stored in a databases called ON_List of the parent SNs, such as connectivity information, resource capacity amount, and available resource amount. In addition to the ON_List, each SN has also another database calledSN_List which holds published informa-tion and metadata of other SN, e.g by gossiping.

4.3.4 Ordinary Node (ON)

Ordinary nodes play host role for executing virtual machines, even though they can not manage them due to the fact that there is not any introduced virtual machine manager (VMM) in ONs. Therefore, each ONs are assigned to a SN called parent-SN which can manage virtual machine operations.

The users can contribute their own PCs or laptops and also the communities in universities or any organization can share their research machines with the cloud system for building it up.

When an ON sends a register message to its parent-SN, it declares its amount of capacity and amount of resources that it is eager to share. Besides, since ONs are also consumer in the system, they send resource request to their own parent-SN.

(35)

CHAPTER

5

Incentive Mechanism Design

The community cloud is primarily rely on voluntariness of the participants on sharing part of their resources. In order to have a sustainable cloud system, these volunteer participants have to be encouraged to be collective for resource sharing. Because of that, deploying an incentive mechanism in the community cloud to regulate sharing operations is very necessary and crucial [39]. This regulation mechanism is aimed to be deployed in the cloud coordinator component of the cloud manager indicated in Figure 4.3.

An incentive mechanism can achieve sustainability with the way of increasing the partici-pant interests and the system benefits. While doing that, it has to consider the heterogeneity of the system and evaluate the participants’ status in a fair way. Therefore, before designing an incentive mechanism, the necessary requirements are determined and explained at the below:

5.1

Requirements

1. Decentralization: As the community cloud has an decentralized structure, the incentive mechanism should be self-management, that means it should not dependent a central authority. In this way, both scalability and availability properties can be preserved in the community cloud system.

2. Adaptability: The incentive mechanism which is deployed on the community cloud

1

(36)

22 Incentive Mechanism Design

system should not have an effect on the underlying community cloud’s resource search and sharing mechanisms. Furthermore, after deploying the incentive mechanism, the participants should have any technical and nontechnical burden.

3. Generic: In community cloud the participants are not only heterogeneous with regard physical environments, but also they have expectation of variety applications and services from the system. To cope with this different demands of the heterogeneous participants in a collaborative way, high service diversity should be efficiently supplied by the incentive mechanism.

4. Rewarding: Rewarding is one of the most effective method to incentivize the partici-pants in a collective way. Reward assignment processes are varied in the way of both participants’ information collection such as, trust-based, exchange-based, third-party-based and evaluation approaches such as, contribution-third-party-based, effort third-party-based. However, evaluation of the collected participant information should be carefully done to achieve fairness and high resource utilization in the system.

5. Punishment: It is noticed that applying a penalty policy against free-riders or selfish participants in the system is very necessary regardless of how powerful a rewarding policy is deployed [40]. Therefore, the incentive mechanism should have an ability to detect the non-cooperative behaviors such as, free-riders, white-washing, selfish and perform a punishment for them.

6. Lightweight: The deploying incentive mechanism should keep overhead of the system lower. This overhead definition includes the amount and the number of messages between participants; calculation of the rewarding and punishment policies for the participants; and the cost of additional processing performed by participants.

7. Fairness: The incentive mechanism should take into the heterogeneity of the commu-nity cloud consideration, because the participants can have different physical capabil-ities and limitations. With this consideration, it is aimed to evaluate the participants’ contribution in a equity way which considers their capacities in the evaluation. 8. Maximization of social welfare: The main purpose behind developing and deploying an

incentive mechanism is to have a sustainable system. Incentive mechanism can success it as it increases the social welfare of the system. Because the volunteer participants who can benefit from systems want to keep or increase this utilization in the system. As a result, to be able support high social welfare, the incentive mechanism should increase overall benefits of all type of participants.

(37)

5.2 Discussion of Related Work 23

Table 5.1: Comparision of existing incentive mechanisms for community cloud

Incentive Requirments

Mechanism DC AD GN RW PN LW FN

Inherent Generosity No No Yes No Yes No No Fixed-Contribution No Yes No Yes Partially Yes No

Reciprocity-Based Yes direct : No indirect : Yes

direct : No indirect : Yes

Yes Partially No No

Monetary-Payment No Yes Yes Yes Yes No No

DC:DecentralizationAD:AdaptabilityGN:GenericRW:Rewarding

PN:PunishmentLW:LightweightFN:Fairness

5.2

Discussion of Related Work

In the Related Work Section 3.2, it is attempted to provide a survey of the existing in-centive mechanisms deployed on the different platforms to meet different requirements. In the Table 5.1, these incentive mechanism methodologies are investigated based on the ex-plained requirements above in order to figure out the limitations and capabilities of them for incentivizing the participants in the community cloud.

Since the inherent generosity methodology is mainly focused on a very strict penalty policy which is ceasing the system in the case of having unbounded number of selfish users, it can not meet the most of the requirements. The functionality of the fixed contribution based incentive mechanisms can not handle high service diversity, since it is designed for service-oriented applications, such as file sharing. Moreover, the punishment property is assigned as partial, because it can not come with an effective solution for preventing the free-rider and white washing problems. Because of these reasons, this mechanism can not be purely applicable for community cloud case. However, its main principle can be adopted to the intended mechanism. That is; a node is obligated to contribute the community before utilizing from other participants’ resources.

The direct reciprocity based incentive mechanisms are service oriented like fixed contri-bution based ones. For example, the well known application of this mechanism, BitTorrent [19] is only designed for the applications which can share separable resources such as files. Therefore, it is not feasible for sharing infrastructure between participants in the community cloud systems. On the other side, the indirect reciprocity based incentive mechanisms suffer

(38)

from the white-washing attacks. Additionally, the success of the applications which apply such mechanisms such as, trust-based and reputation-based, depends on trustworthiness of other participants. Because of that, the applications of this mechanism can be exposed to the varied form of attacks e.g spam voter. However, the main idea behind the indirect approach which evaluates the former behaviors of participants against the whole system can be applied into the incentive mechanism deployment of community cloud to provide fairness and high social welfare.

The applicability of the monetary payment mechanism in the community cloud case largely depends on the great effort on security issues and the strong economical background which is necessary to have a solid economical model. Because of that, the monetary payment model is not enough feasible to be deployed in this case. However, the broker system of the token-based approach which is responsible for managing transactions and recording their information can be adopted to the incentive mechanism of the community cloud case. It does not only provide easy management ability to the system, but also it is highly applicable to be deployed in the hierarchical architecture of the community cloud.

5.3

Effort-Based Incentive Mechanism

The related work analysis in the Section 5.2 shows that those existing solutions can not exactly satisfy the requirements. Especially, none of them targets fairness requirements in their design issues where they mostly reward users according to their contribution volumes. When a contribution based incentivizing approach is performed in such a heterogeneous systems, high collaboration and welfare values have been reached only by the users who contribute more into the system [41]. Therefore; if the community cloud system rewards the participant according to their absolute amount of contribution, the participants having limited physical capacity benefit from system less than those who have greater physical capacity. This discrimination against the participants with the scarce resource leads to an unfairness.

In community cloud case where the participants vary in terms of capacity, it is proposed to deploy aneffort-based incentive mechanismwhich considers the participants’ relative con-tribution instead of their absolute concon-tribution in the regulation schemes. That is, the system takes participants’ capacity into account.

The effort-based incentive mechanism is successfully applied in this study [42] to share resources in BitTorrent application. It is inspired by Participatory Economics (Parecon) eco-nomic model which is developed by Michael Albert [43]. This model suggests that rewarding

(39)

5.4 Assumptions 25

should be based on participants effort and sacrifice by this sentence “Payment according to effort and sacrifice” [43].

When the effort-based incentive mechanism is adopted into the community cloud case the participants is able to benefit from the system as much their efforts or how much they sacrifice themselves for the community. Because the effort-based approach evaluates the participants’ contribution regarding their capacity, it provides fairness in the way that all type of participants are compared in an equal condition.

As a results, considering the explained requirements and their analyses, it is proposed a service which provides an effort-based reciprocal computational resource sharing in the community cloud system.

5.4

Assumptions

In the design of incentive mechanism, variations of network topologies has not been taken into account to be able to focus its effectiveness on the resource sharing regulation. Therefore, a static network is considered with homogeneous and stable links between nodes.

It is assumed that powerful machines are assigned to super nodes which the incentive mechanism is deployed on. Because, there might be many resource requests from ordinary nodes to be satisfied. On the other side, ordinary nodes might be asymmetric in terms of physical capabilities. Similarly, it is not necessary that they have similar resource requests.

In the initial idea of the community cloud design, nodes share/request sliver(virtual ma-chine instance) as resource. Therefore, resources refer sliver in this study. Besides, it is assumed that total amount of resource capacity can be detected by a software installed in each ONs’ machines.

5.5

Formulations

In the proposed community cloud, each ordinary node has a credit which reflects its con-tribution to the system. The credit of a node CRi depends on the amount of resources Ri

the node shared and the cost of transaction which is calculated by the time Ti during what

amount of these resources SRi were shared. If the corresponding node shares resources, the

transaction cost is added to its credit, otherwise it is charged.

(40)

where r and t coefficients are the factors for the shared amount of resources and the time spent for sharing, respectively. The importance of variables in the formulation could be arranged by changing these coefficients.

In the effort-based incentive, the effort of a nodeEi expresses its relative contribution to

system, thus the capacity of nodeCi has to be taken into account.

Ei =        crediti Cc i , if crediti Cc i < 1 1 , otherwise

where the coefficient c is a factor for the capacity that the node has. As a consequence, a node with low capacity will put in more effort than a node with high capacity even if they both donate the same amount of resources to system. To lay weight on effort, c must be chosen in the range (0,1).

The total amount of shared resources Ω in the system will be equal the to sum of the shared resources at each nodeωi.

Ω =

all nodes

X

i

ωi (5.2)

Finally, the maximum amount of resources a node can utilize from the system is calculated depending on its effort.

∆Ri =Ei×(Ω−ωi) (5.3)

5.6

Algorithm

The flowchart in the Figure 5.1 shows the general process of request handling in super node. In the flowchart only resource request query operations is handled because the incentive mechanism is deployed when resource request is received. When a SN receives a request from an ON, it first calculates ∆Ri value indicated in the Equation 5.3 which shows maximum

demandable resource amount for theONi. Then, the SN checks whether this value is bigger

than the requested amount. If it is not bigger, the request is rejected. Otherwise, the query is evaluated in the decision function..

The main functionality of decision mechanism is to find best suitable participants for accessing the request. With this idea, the corresponding SN firstly calculates the amount of shared resources in the local SN-Zone where it is responsible for, which is indicated in the

(41)

5.6 Algorithm 27

Figure 5.1: Data flow of handling a request in a super node

Equation 5.2. If the requested amount is less than the available resource in its own local SN-Zone, the request will locally evaluated. Otherwise, the SN check its SN_List databases to find the best suitable super node which can provide the requested amount and forward the request to it.

When the local SN-Zone has enough available resources to meet request, it performs an-other mechanism calledlow-credit-firstpolicy to determine the best suitable ONs as providers. In this policy, the active ONs in the community cloud with lower credits are given a priority to be chosen as providers. The main idea behind this policy is to have those ONs earned credits. Since the system allows the ONs with less credit to gain credit, they will have an op-portunity to satisfy their resource requests in future. Besides, the credit distribution among the ONs in the system can not be largely varied, because this policy does not allow ONs to be left out of the system due to a low credit.

After thelow-credit-first policy determines which nodes are assigned as providers, trans-action cost for each one is calculated. While this cost is charged from consumer’s credit account, they are deposited to providers’ ones for each transaction With the changed credits, occupied and provided resources, effort andONi values of each traded ONs are recalculated

(42)

(43)

CHAPTER

6

Exploration of Effort-Based Incentive Mechanism

Rahman et al. [42] performed an effort-based incentive mechanism to encourage peers to share their resource in the BitTorrent system. In this study, the resource is attributed peer’ network bandwidth and the incentive mechanism attempted to reward peers based on their effort which is determined by their relative bandwidth capacity. Although the results of this study are promising, the effort term opens questions due to lack of detail on its calculation and usage. In this chapter, the effort-based incentivizing approach is explored by applying the formulations explained in the Chapter 5. It is aimed to understand feasibility of effort based approach in super node resource assignment process by comparing the existing approaches. This feasibility is determined by how the response is given to the design goals of the incentive mechanism in the community cloud.

6.1

Round-based Simulator Implementation

In the light of th eexplained objectives, a simulator which regulates resource assignment in a super node zone is implemented 2 in C++ programming language. In this simulator, an SN-Zone is composed of a super node and many attached ordinary nodes. Moreover, there are several initialization files to have different configuration in the simulator. The initialization file of ordinary node includes:

1

2

The source code is publicly available athttp://redmine.confine-project.eu/projects/singlesnsimulator

(44)

30 Exploration of Effort-Based Incentive Mechanism

Figure 6.1: Conceptual overview of Round-based Simulator

– node id

– amount of resource capacity – amount of shared resource

at each entry. Similarly, configurable resource request file includes:

– node id

– requested amount of resource – duration

at each entry. After importing those configurations into the simulator, it starts to deploy the regulation mechanism whose algorithm is indicated in the Section 5.6.

This is a round-based simulator as seen in the Figure 6.1 where each round includes generated requests from ordinary nodes. Then, the super node evaluates all resource requests in a batch at each round. As a result, the round-based simulator performs all actions in the sequential manner.

In order to have variations in the experiments, the configuration files are able to be changed based on user requirements. In addition, the simulator is adoptable to deploy dif-ferent incentive mechanisms to compare the effort-based one with the others.

6.2

Evaluation

The implemented simulator is simulated with 1 super node and 250 ordinary nodes in a static network topology which is composed of stable and homogeneous links between nodes representing computing devices. There are different experiments performed with the different

(45)

6.2 Evaluation 31

configurations. The results are considered with success ratio metric which is the ratio of succeed number of queries over total number of queries. The simulation results are analyzed under the title of two main design goals proposed : efficiency andfairness.

The testbed for the evaluations consist of one x86 based PC with Ubuntu 10.04 operating system. The PC includes 2 cores with 2.53 GHz and 3Gb capacity RAM.

6.2.1 Efficiency

One of the main design goals of the incentive mechanism deployed on the community cloud is to maximize social welfare to be able to have sustainable system. Because, almost all participants of the community in the system having maximized social welfare can benefit from it. Namely; achieving a high efficiency in the system is the way of having overall benefits Therefore, the incentive mechanism should aims to increase the efficiency in the system.

Experimental Setup

In these experiments, the amount of resources are randomly distributed to the ordinary nodes by defining some range rules. There are three different resource distribution scenarios created by changing these rules: scarcity,random, andabundance. Whereas each node in the scarcity scenario is ruled to have at most 25% of their own capacity as shared resource, in the abundance scenario each node shares at least 75% of their own capacity in the system. In the normal resource distribution, each node is ruled to contribute their own 25%-75% capacity to the system. In total, 13%, 52%, 87% of all resources are shared in the scarcity, normal, abundance scenarios, respectively.

In this round-based simulator, experiments are performed over 200 rounds and each round includes 25 resource request queries from randomly chosen ordinary nodes. The resource requirements are analyzed in two different demand value: high-demandin where nodes request for at least 50% of their capacity, low-demand scenario in where this ratio is limited as at most. In addition, the needed number of rounds to allocate requested resources is determined randomly in the interval of 1 and 3.

Experiment Results

The Figure 6.2 shows the success ratio outcomes in high demand scenario. While the outcomes are analyzed in the Figure 6.2a by comparing effort-based incentive mechanism with the

(46)

(a) Comparision of overall efficiency in differ-ent incdiffer-entive mechanisms

(b) Comparision of overall efficiency in provider oridnary-node selection strategies

Figure 6.2: Experiment results in high-demand scenario

contribution-based one which is commonly used in the existing incentive techniques, the Figure 6.2b compares the provider node selection mechanisms. In both figures, when the amount of available resource are increased in the ONs, the ONs are succeeded more in their requests.

The Figure 6.2a indicates that the overall ONs which are evaluated with the effort-based approach have more success ratio as compared to the contribution-based approach. This higher efficiency happens in effort-based approach due to the fact that it targets to increase overall benefits rather than the benefit of those who have more capacity.

In the Figure 6.2b, the low-credit-first mechanism that is proposed strategy for the node selection in the community cloud case is compared with fifo (first-in-first-out) queuing tech-nique which selects first ONs in the list as providers. This figure indicates how important to select nodes as providers. Despite of increasing available resources in the system, the fifo technique can not increase the overall success ratio. Because many of the ONs suffer from inadequate credit problems. On the other side, since the low-credit-first approach gives pri-ority of being provider to the ONs with less credit, they can earn credits and overall ONs in the system can meet their requests.

In the Figure 6.3, same experiments are applied for the low-demand scenario. The overall success ratio results are naturally higher than the results in the Figures 6.2 due to the decreased demand amount. Except that the outcome of comparison are almost same. Like previous experiment results, the effort-based incentive mechanism showed in the Figure 6.3a with the low-credit-first policy indicated in the Figure 6.3b offer higher efficiency.

(47)

6.2 Evaluation 33

(a) Comparision of overall efficiency in differ-ent Incdiffer-entive Mechanisms

(b) Comparision of overall efficiency in provider oridnary-node selection strategies

Figure 6.3: Experiment results in low-demand scenario

6.2.2 Fairness

Since the most of the incentive mechanism rewards participants according to their contribu-tion regardless of their capacity, the participants with less capacity can not have opportunity to benefit from the system as much as those who have large capacity. When the node het-erogeneity is considered in community cloud, this unfair situation should be handled.

Experimental Setup

In these experiments, nodes are equally categorized according to their capacities: 125 of all nodes are resourced in large, the other 125 nodes are resourced in small. While the large-resourced nodes can have at least 75% of the defined maximum capacity value as resource, small-resourced nodes can have at most 25% of it. Namely, the large-resourced nodes have approximately 4 times more resource than the small-resourced nodes. In order to able to see power of fairness in effort-based approach over contribution-based one, all nodes are arranged to share all their capacity in the system.

There are 200 rounds created like previous experiments, but in this experiment each round includes 20 requests. These requests are equally shared between two different capacity nodes, that is; while 10 of these requests comes from small-resourced nodes, the other 10 piece of requests in the round come from the large-resourced nodes. In addition, each node is allowed to request at most 50% of its capacity as resource with at least 1, at most 3 rounds.

(48)

Figure 6.4: Success ratio of both large-resource and small-resource nodes in different incentive mechanisms

Experiment Results

The Figure 6.4 indicates the success ratio results of both the small-resource and large-resource nodes under effort-based and contribution-based approaches along 200 rounds. It is clearly seen that whereas there is small difference between the success ratio of the large-resource and the small-resource nodes in the effort-based approach (avg.75,8%, 58,1%, respectively), there is a huge differences in the contribution-based approach where the average success ratio of the large-resource and the small-resource nodes are 71,4%, 21,3% , respectively. Even though the nodes with the small-resource share their all capacity with the system, the contribution-based approach unfairly punishes them. As seen in the figure, they can not even reach half as high the success ratio as the nodes with large-resource. The reason of that, contribution-based approach evaluates them regardless of their capacity. Unlike the contribution-based approach, the effort-based fairly approaches against all type nodes in the system by considering their physical device capabilities.

(49)

CHAPTER

7

Prototype for Regulation Mechanism

After the study of effort-based incentive mechanism exploration gave promising results, it is aimed to implement regulation component of cloud coordinator in cloud manager examined in Section 4.3.2 by following the algorithm 5.6 which is also used in implementation of the simulator. The objective of this implementation are twofold: firstly evaluate the prototype operation related to the effort-based incentivized resource assignment algorithm in a local cloud scenario. Secondly, analyze and study the distributed resource assignment management between super nodes.

7.1

Implementation

The regulation component prototype 2 in the cloud coordinator component is deployed in the Community-Lab [44] testbed supplied by CONFINE [45] European Project. Therefore, the prototype implementation has to consider the limitations and capabilities of the real community network devices on where it is deployed. For example, python programming lan-guage is chosen to do this implementation, because the OpenWRT which is the operation system in the research devices does not support many other programming language, e.g Java. Moreover, in order to store the SN_List and the ON_List in databases, CouchDB NoSQL open-source databases [46]. The biggest reason to use CouchDB is that there are several

1

2

The source code is publicly available athttp://redmine.confine-project.eu/projects/prototype

(50)

36 Prototype for Regulation Mechanism

Figure 7.1: Components of ordinary node and super node implementations

ongoing studies which might be combined with this study under the Community and Cloum-munity projects are using it as a database. In addition to it, CouchDB offers lock-free conflict resolution mechanism which makes it faster, schema-less structure via JSON document store which allow us to store arbitrary structured data, and easy-to-use for developing. Besides, the communication between nodes are handled by using xmlrpclib python library which uses remote procedure call method with XML.

In this prototype, resources are attributed to slivers which refers to instances of virtual machines. However, this prototype does not provide or consume any sliver. These operations have to be handled by the core and hardware layer of the cloud manager. In the prototype implementation, they are simulated as if slivers are consumed or provided.

The prototype is composed of an ordinary node and a super node implementations which are explained in detail in the following sections. In addition to this, the Table 7.1 summaries messages between nodes in the prototype implementation.

ON - Implementation

This implementation is aimed to be installed into the Ordinary Node machines which are proposed to be used in the community cloud. As seen in the Figure 7.1, there are 3 main components inside ON implementation:

• CLI (Command Line Interface): This is the front-end component where users directly issue commands and observe the outcomes of the commands. These commands are: registerwhich is for registering to a parent-SN;requestwhich is for requesting sliver from the parent-SN; anddiscard_capacitywhich is for revealing the corresponding ON’s capacity.

• Sliver exploration: This component is responsible for revealing the information about slivers on the machine. The user can use this component by the help ofdiscard_capacity

(51)

7.1 Implementation 37

Figure 7.2: Structre of JSON document in ON_List database

command in order to learn its capacity. When a user wants to send a register message to its parent-SN, this component automatically put slivers capacity information into the message.

• Connector: In Connector component, there is a one rpc-client channel which is ac-cessed by the user to connect to the parent-SN. This channel is responsible for delivering the messages to the parent-SN what the user commands on the CLI. Similarly, there is a one rpc-server channel which is listening the parent-SN address to receive message from it.

SN - Implementation

This implementation represents the cloud coordinator component which regulate resource assignments. It is obligated for each SN machines to install this implementation. As seen in the Figure 7.1, it is composed of 7 main component:

• ON_List DataBase : It stores the all information including metadata about ONs which are assigned to it. This database is accessed in each operation regarding trans-actions. The stored information in ON_List database is indicated in the Figure 7.2:

(52)

38 Prototype for Regulation Mechanism

Figure 7.3: Structre of JSON document in SN_List database

the number of slivers on the corresponding ON and shared indicates how many of its capacity is shared in the system. credit and effort are recalculated by following formu-lations examined in Section 5.5 after each transaction operations. In addition to them, each ON Json document also stores information about the other ON nodes where it provided resources from and where it supplied resources to.

• SN_List DataBase: This database stores necessary information including metadata about other SNs which is indicated in the Figure 7.3. For example, their connection information such as ip address and port number is store in theid entry; the amount of their available resources and total number of credits inside them are stored inmaxAvail

and totalCredit entries, respectively. The last two entry is used for selecting a SN as a remote-provider.

• Main Connector: This component deploys a rpc-server on a particular address which is responsible for receiving queries from its own ONs and the forwarded request queries from the other SNs. The received queries are directed to Query Handler component to be accessed.

• Query Handler: This component is responsible for handling following queries which are directed from Main Connector components:

1. register: An SN is received this query from an ON which wants to be part of a SN-Zone. It includes connection information of that ON with its amount of capacity and amount of shared resources. When an SN receives it, a docu-ment is created in the ON_List database for that ON where these information is stored. After that, the registered ONs are able to ask for resources and serve their resources to the community.

(53)

7.1 Implementation 39

Table 7.1: Messages between nodes in prototype implementation

Message Arguments Direction Description

register

ip_address, amount of capacity, amount