Co-operative Infrastructures: An Economic Model for Providing Infrastructures … · Co-Operative Infrastructures: An Economic Model for Providing Infrastructures for Social Cloud

Co-Operative Infrastructures: An Economic Model for Providing Infrastructures for Social Cloud Computing

Christian Haas Karlsruhe Institute of

Technology [email protected]

Simon Caton Karlsruhe Institute of


Kyle Chard University of Chicago

[email protected]

Christof Weinhardt Karlsruhe Institute of


Abstract Social Cloud Computing is an emerging online

collaboration paradigm which is characteristic of many socially oriented electronic platforms. The operation of such a platform requires computational infrastructure to facilitate the platform itself as well as the services enabling its basic operation. While this infrastructure currently requires capital-intensive investments, we believe it is possible, and even advantageous, to use a co-operative model where the platform (i.e. its computational infrastructure) is provided by the users themselves. In this paper, we define a formal economic model for a co-operative infrastructure in the context of a socially oriented platform and analyze (through simulation) the model with respect to its feasibility and scalability. Using Social Clouds as a use case, we demonstrate in several scenarios that the co-operative approach does not only have advantages over dedicated infrastructures, but also is a particularly suitable model for providing core infrastructure in social (computing) platforms.

1. Introduction

The increasing pervasiveness of social networks has led to a world in which many relationships and interactions are also represented online. These social digital relationships have created new opportunities to define socially oriented computing paradigms. One such example is the Social Cloud computing model [1],[2]: a collaborative resource sharing model built upon a social network. In this paper, we propose a novel co-operative infrastructure on which similar socially oriented platforms, and potentially even social network platforms, can be supported, without incurring the overhead or costs of provisioning dedicated infrastructure resources. Instead of using dedicated, out-sourced, or third-party infrastructure, the platform is hosted upon the computational resources it manages.

Like any computing model, all forms of social, volunteer and collaborative computing require coordination mechanisms to facilitate their basic

functionality (user management, resource allocation, etc.). Such coordination mechanisms can take many forms, for example market-orientated structures, scheduling algorithms, and bilateral exchanges between participants and therefore they have varied resource requirements. To support coordination mechanisms, a computational infrastructure is needed.Typically, this is provided by dedicated hardware or aCloud infrastructure. Providers and/or owners of the infrastructure are generally administrators, institutions or third parties, and are therefore detached from the system users. Consequently, supporting a distributed computing platform requires an initial investment,research grant, advertising, or the introduction of fees. In a social context, such methods are undesirable, a considerable hurdle to overcome, or counterproductive, as the effort needed to sustain the platform detracts from its development.1 Therefore, we pose the following questions: 1) How can these platforms be supported? 2) Who should provide this support?

Instead of traditional co-ops that allocate capital for a certain goal, we propose a new application of co-opmodels for computing platforms to facilitate sustainable platforms without capital investments:

A co-op is a scalable computing platform where all (computational) resources constituting the platform's infrastructure, as well as those made available over the platform, are owned and/or managed by its users.

We argue that a co-operative scenario is particularly fitting for social and volunteer computing, as users are providers as well as beneficiaries of the platform. In our setting, resources are defined as the computational capabilities needed by the collaborative platform to function, which in the simplest case includes: (v)CPUs and storage. This can also be extended to services like (distributed) databases and peer-to-peer overlay networks. Although aspects like reliability, redundancy, and technical instrumentation are important, we do not focus on them in this paper. Instead, we focus on the economic methods to address 1 For example, [27] show that users are often unwilling to pay even small fees when free alternatives are available.

2013 46th Hawaii International Conference on System Sciences

1530-1605/12 $26.00 © 2012 IEEE

DOI 10.1109/HICSS.2013.147

728

2013 46th Hawaii International Conference on System Sciences

1530-1605/12 $26.00 © 2012 IEEE

DOI 10.1109/HICSS.2013.147

729

system availability and redundancy. For technical details we refer to the implemented prototype of a Social Storage Cloud (in [1]). Note that we do not use their economic model, but concentrate on the provisioning of infrastructure resources to facilitate a Social Cloud.

This paper is structured as follows: section 2 discusses related work; section 3 presents the concept of a Social Cloud, as a use case for our co-operative model; section 4 presents our economic model for co-operative infrastructures; section 5 presents an simulation driven evaluation of our model; section 6 summarizes our findings and outlines future work.

2. Related Work

Co-operative (co-op) business models are prevalent in a range of domains including grocery stores, credit/banking unions, health care and even housing. The core premise of a co-op model is distributing ownership, management and profit across its members.

The question as to why co-ops are formed has been studied from an economic point of view in [4]. This work investigated the efficiency of co-ops compared to other organization forms based on empirical data from US fluid-milk-processing firms. The authors compared different efficiency metrics (price, scale and managerial efficiency) and found that non-cooperative firms tend to be more efficient than co-ops. These metrics are, however, not applicable in our scenario.

In computer science, co-operative models are sometimes used as a means of distributing decisions between autonomous agents, for example in P2P networks. In these models, agents co-operate to achieve a given goal. However, this deviates from the social and business definition of a co-op, in that members do not own and manage the infrastructure.

A co-op metacomputer was first introduced in [5]. In this system contribution is voluntary but intended to be mutually beneficial for users. More recently, in Grid and Cloud computing, federations have been created that span multiple institutions allowing resources to be shared amongst members of a virtual organization (VO). In these domains, novel co-op approaches to resource management and task allocation such as the Community Scheduler Framework (CSF) [6] and the DRIVE metascheduler [7] have been proposed. Both CSF and DRIVE utilize community contributed resources for core metascheduling tasks such as resource allocation. Considering the feasibility of that approach, we showed in [8] that secure and privacy preserving auction protocols can be used in a co-operative metascheduling architecture to conduct trustworthy resource allocations on potentially untrusted resources. Unlike the Social Cloud model,

these metaschedulers are designed to support job submission in a large scale, comparably static, Grid environment where providers have huge resource pools and can provide explicit availability guarantees.

The concept of a co-op is implicit in the definition of a Social Cloud, as members benefit directly from resource sharing with one another. A Social Cloud differs from many other resource sharing architectures as it leverages the relationships defined in a social network. However, Social Clouds and therefore the co-op infrastructure are not free from risk, as friendships can change over time. The implications for security in dynamic Social Cloud environments have been investigated in [9]. Socially based systems are also becoming increasingly common in both academic and commercial applications. For example, social networking principles are commonly employed for coordinating ad hoc research communities such as MyExperiment [10], nanoHub [11], and GlobusOnline [12]. While commercial applications such as FriendStore [13] and AmazingStore [14] offer distributed file storage provided by a user's friends. Diaspora2 is a first step towards creating a Facebook-like social network platform relying on content resources (e.g. images) provided by its members (rather than dedicated resources). Our model builds upon this idea, by also capturing the computational resources needed to run the system, providing a platform free of dedicated centralized servers.3

3. Use Case: Social Cloud Computing

As a use case for our co-operative model, we use the Social Cloud paradigm which is defined as: “aresource and service sharing framework that utilizes relationships established between members of a social network” [2]. A Social Cloud is a dynamic environment through which (new) Cloud-like provisioning scenarios can be established based upon the implicit levels of trust that transcend inter-personal relationships digitally encoded within a social network. The vision of a Social Cloud is motivated by the need of individuals or groups to access specific resources they are not in possession of, but that can be made available by connected peers. In simple words, Social Clouds use social networks as mechanisms for collaboration and resource sharing. Moreover, Social Clouds rely on social incentives to motivate sharing

2 https://joindiaspora.com/3 While this might be feasible from a computational point of view, some of the allocation or registration algorithms of the system might require a (minimal) trust anchor. See [29] for a further discussion on the aspect of trust in the context of Social Cloud Computing.

729730

and non-malicious behavior, as users leverage their existing networks to share capabilities and resources.

In the Social Cloud model, a Social Marketplace is responsible for facilitating sharing between members. The marketplace is not necessarily economically focused, rather, it is designed to support a wide variety of both economic and non-economic protocols, such as reciprocation, reputation, posted price, and auctions. Due to its intrinsic nature of sharing, we argue that, based upon our definition of a computational co-op, aSocial Cloud is a fitting use case for a co-opinfrastructure, as the questions of who can support the “marketplace” and how is critical for the implementation of a Social Cloud. Therefore, a Social Cloud provides a unique setting to explore and evaluate co-operative infrastructures. The initial prototype, presented in [1], was designed to share storage between Facebook friends and was hosted on a dedicated infrastructure. This prototype demonstrated the feasibility of the model. It has since been enhanced to share computation resources [15] and support volunteer computing projects [16]. In [2], additional use cases for a Social Cloud were proposed. In this paper, we lay the foundations for a co-op infrastructure to support a combined view of these use cases.

4. A Co-operative Economic Model for Social Clouds

Previous literature on co-operative models focuses either on the organizational level ([3],[4]), or the individual member level [17]. As we cannot base our study on existing organizational data, we follow the approach of [17] and look at individuals’ incentives to participate in the co-op.4 To do this, we need to specify the following aspects: 1) the users and their characteristics (e.g. endowment, utility function, etc.) [17]; 2) the resource requirements of the distributed system [5], in this case the Social Cloud platform; and 3) the contribution schemes through which users are encouraged to join the co-op and provide resources [17]. We elaborate upon each of these aspects in the following 3 subsections to create a co-op model that is adequate for our scenario. As discussed, we consider only computational infrastructure resources in the co-op model, not software requirements such as databases.

4 We note here that this is only one possible approach. The fact that economic actions are influenced by the social relations of a user has long been recognized (see e.g. [30]). Yet, we argue that these approaches (taking social embeddedness into account) are especially helpful when applied to (economic) network analysis based on observed data. However, as we simulate the actions of individual users without existing data, we rely on specific behaviors instrumented through theoretically grounded and context fitting utility functions.

4.1 Modeling Users

In our co-op model, each user i has an endowment of (computing) resources �� available, which is known to the platform. To avoid only homogeneous resource levels, we draw the level of endowment of a user from a uniform distribution with mean �� and range ��, �� . We also model users as having a rate of availability ��, in which their resources are available to the Social Cloud. These two aspects constitute our notion of quality of (a contributed) service (QoS), as a higher endowment represents a more powerful resource, and availability is a standard QoS measure.

As Social Cloud implementations are still in their prototype phase, no traces of user behavior within the context of a Social Cloud exist. Consequently, we cannot analyze the performance of a Social Cloud based upon production user data. However, to develop a co-op model we can assume that user behavior within a Social Cloud is similar to behavior patterns in Volunteer Computing, as both rely on ad-hoc user communities donating spare computing capacity.

Therefore, to model users we selected the SETI@home [18] host availability traces for the years 2007-09, which contain information for over 220,000 hosts.5 These traces have been the subject of many analytical studies [19], [20], [21], motivating their selection, as they provide a solid foundation to base aSocial Cloud context upon. Statistical analysis of the data in [21] reveals that 21% of the monitored hosts exhibit statistical independence in their availability. The authors also provide probability distributions for these hosts as well as for several clusters that can be distinguished within these 21% of hosts. We use these clusters to define different user types in our co-op model. Based on these results, [21] deduced a distribution of the length of availability intervals, which we also use to simulate the availability of users. Table 1 summarizes the statistics of the six clusters, providing their relative size, average availability and the distribution functions of the interval lengths.6

Table 1: List of User Cluster based on [21]Cluster Relative

SizeAverage Avail-ability

Availability Interval Distribution

Unavailability Interval Distribution

1 0.042 83.9% Gamma(0.289,311.711) Hyper-Exponential2 0.108 82.2% Gamma(0.340,152.216) Hyper-Exponential3 0.658 26.0% Weibull(0.431,1.682) Hyper-Exponential4 0.004 91.7% Gamma(0.347,371.622) Hyper-Exponential5 0.094 72.3% Gamma(0.342,89.223) Hyper-Exponential6 0.094 56.7% Gamma(0.357,43.652) Hyper-Exponential

In addition to availability, we assume that each user needs to reserve a certain percentage of their

5 Available: http://fta.inria.fr6 The specifics of the unavailability interval distributions can be found in [21].

730731

endowment for other uses, such as to work, chat, play games, etc. Let �� denote this percentage of user i's endowment that are reserved for other purposes7, and �� denote the percentage of endowment allocated to infrastructure resources.

Users are also characterized by their utility functions which specify the benefits they receive from consuming and providing resources. Based on empirical findings (see e.g. [22]), a classic self-interest utility function often used in economics does not fully capture actual user behavior. The theory of social or other-regarding preferences (see e.g. [23], [24]) thus incorporates additional aspects such as altruism or reciprocity in the utility function.

Our model makes use of utility functions studied by [25], as they provide general utility functions that can explain findings from economic experiments in which a significant amount of subjects exhibit altruistic behavior, which is in contrast to the traditional economic principle of self-interest and rational utility maximization.8 More specifically, a user exhibits altruistic behavior if he “is willing to sacrifice his own resources in order to improve the wellbeing of others”[22]. This is the case when users provide resources for the infrastructure, as they incur costs (not being able to use the resources themselves) but their contribution increases the performance of the system. [25] shows that through correct parameterization of the following utility function, altruism can be included in economic decision making. We use their approach for two reasons: 1) our setting closely resembles a public goods game where users incur costs for providing resources to the public (here: the co-operative infrastructure), and in this case it is often assumed that self-interest and altruism are the most relevant parameters that characterize the behavior of users. 2)their utility function is able to capture various forms of utility functions, from classic substitutive and Leontief to convex utility functions, making it very flexible. The resulting utility function is:

��(��, ��) = ��,�(��)� + ��,�(��)��/� (1)

In this utility function, ��,� is the user’s benefit from consuming their resources for specific purposes, ��,� is the benefit from providing resources to the co-operative infrastructure, � specifies the convexity of the preferences, and � defines the level of altruism that a user has. Note that we do not explicitly consider a

7 Leaving resources idle is implicitly included in ��.8 Based on certain assumptions, it is common in economics to describe the preferences that users have with respect to an outcome (such as resource allocation) with a utility function that implements these preferences [25]. [25] also showed that this utility function is able to explain empirical data of several laboratory games which are conceptually very similar to our scenario.

cost term in the utility function, which may be unexpected. This is because users in social contexts don't necessarily make their resource usage dependent on costs, especially when costs are variable and sometimes unknown, for example energy cost.Similarly, the additional cost of providing resources to the co-operative infrastructure can be modeled through the relative price p of resource provisioning. Theconsumer is, however, restricted by their resource endowment, this is incorporated into the following optimization problem:

��,�(��) + ��,�(��) = �� (2)where the resource endowment of user i is ��, and p is the relative price for providing resources to the co-operative infrastructure. The higher p, the higher the relative cost to the user for resource provisioning. The following requirement has to be fulfilled for all users:

�� + �� = 1 (3)Hence, each user will choose their individual

optimal value depending on their level of altruism and the convexity of their preferences. Note, however, that we also consider that a user wishes to reserve a minimum level of their endowment, ��,��, for private use. Hence the actual percentage of contributed endowment is given by: �� = min (��

∗, ��,��). In order to realistically model user types according

to their preferences, we use the findings of [25] to model six different types of users, each with a distinctive form of utility function. The form of the utility function and the corresponding values for � and � are summarized in Table 2.

Table 2: List of Utility Function Types based on [25]Type Function Size Θ β Description

1 �� = ��,�(��) 0.227 - - Selfish2 U� = min�Π�,"; Π�,#$ 0.142 - - Leontief3 �� = ��,� + ��,� 0.062 - - Perfect Substitutes4 See equation 1 0.245 0.319 0.621 Weak Selfish5 See equation 1 0.162 0.529 -0.350 Weak Leontief6 See equation 1 0.162 0.736 0.669 Weak Perf. Substitutes

While the user types in Table 2 are found in experimental games, one might ask if this is a realistic setting for our case of co-operative infrastructures. Hence, we also compare this setting with another user type distribution which considers sharing in Peer-to-Peer networks. The basis for this distribution is obtained from [26], which presents a study on free-riding in Gnutella, a then-popular Peer-to-Peer platform, and shows that in this platform approximately 70% of the users do not share at all. Therefore, we have introduced another scenario in which 70% of users have a selfish utility function of type 1, and the remaining 30% share to some degree (according to utility function type 6).

731732

4.2 Modeling System Resource Requirements

Determining the feasibility of users providing the computational infrastructure of a platform requires knowledge of the platform’s resource requirements (i.e., the resources required to guarantee the functionality of the platform). In general, we can model system requirements %(&) as %(&) = '�*(&) +'-, where '�*(&) specifies the increase in resources based on the number of users (n) and '- is the minimum amount of infrastructure resources needed for the platform. This is a reasonable base model as the computational requirements for necessary platform tasks generally increases with the number of users (and transactions), while some base functionality must also be provided at all times (e.g. database services).

A realistic model of required resources is essential for the co-op model and the evaluation results. Hence, the system requirements function is modeled based on certain assumptions as well as empirical observations from the Social Cloud prototype presented and evaluated in [1]. In [1] we studied several aspects of the deployed prototype, such as resource (CPU, memory) usage, on which we base our requirements function. In abstract terms, the system requirements are calculated for one time period. In this time period, each of the n users participates in y transactions which are typical for the platform. For example, this could be the computation of an auction for a particular resource. We consider the reverse second-price-sealed-bid auction as implemented in [1] as a proxy for the transaction. This assumption is reasonable because this type of auction protocol is well suited to the Social Cloud context, and is also known to be resource-demanding and has high resource requirements.

Every transaction requires a certain amount ofresources for execution. From [1] we empirically derived that an average computer (denoted by ��)

requires *(&) = �� .�02

3 resources for one transaction.9

As it is unrealistic that all transactions in one time period have to run simultaneously, the parameter 4denotes the percentage of transactions that require resources at the same time. If �� denotes the minimum number of resources that have to be provided regardless of supporting basic functionality, then the system requirements function can be expressed as:

%(&) = 4 ∗ 5 ∗ & ∗ �� √&-2

7 + �� (4)

9 The exact function was found using curve fitting in Matlab, which yields 7=933 and a goodness of fit of 0.97. Note that [1] provides values for up to 50 users, but the findings strongly suggest that the general trend of the curve can be extrapolated for more users.

Equation 4 assumes that all users participate in every transaction. If for example, only half of the users, on average, participate in transactions then the system requirements function will be:

%(&) = 4 ∗ 5 ∗ & ∗ �� .(&/2)-2

7 + �� (5)

4.3 Contribution Schemes

Considering the social context of the Social Cloud paradigm, it can be argued that the goal of such a system should be to provide sufficient resources to run the platform, but at the same time not burden users with too much effort or high costs. In order to acquire the required infrastructure resources by the co-op’s members, we consider the following two contribution schemes:

Enforced fixed contribution: Users are required to provide a certain quantity of resources to the infrastructure as a membership requirement.

Voluntary variable contribution: Users may freely choose what percentage of their endowment they are willing to contribute, i.e. no minimum is given.

4.3.1. Enforced Fixed Contribution. For fixed contribution schemes, two alternatives are possible: either the contribution can be fixed independent of the user's resource endowment, or the contribution can be proportional to the user's endowment. In this paper, we use the latter case to calculate the fixed percentages, because it is more considerate of users with low resource endowments, which otherwise would have to allocate most of their resources for the infrastructure.

Hence, each user has to provide a certain percentage ��

∗ of their endowment to the co-opinfrastructure. The minimum necessary percentage per user, taking their average availabilities into account, can then be calculated as:

��∗ = ��

∗ ∗ (1 − ��) (6)

��∗ = %(&)

∑ (1 − ��) ∗ �� ∗ ��(7)

4.3.2. Voluntary Variable Contribution. In this contribution scheme, users choose their level of contribution based on their individual preferences for resource usage, considering for example altruistic motivation. This scheme addresses the key motivation of a Social Cloud, that is, users voluntarily choose to provide resources to friends.

732733

If we use the utility function described earlier (Eq. 1) and the resource constraint (Eq. 2 + 3), we can solve the optimization problem for user i, with the basic assumption that �� ≥ 0, and obtain the following result:

>��(��, ��)>��

= 01� (��)

��?� @��,�

�?� − ��?�� − ��,��?�A = 0

@��,��?� − ��?�� − ��,��?�A = 0

��,� = �?�

�?�

�?�

�?� + �?�

�?�� (8)

Hence, the relative contribution to the infrastructure depends on several factors: 1) the importance of donating resources to the infrastructure (θ, the level of altruism), 2) the convexity of the utility function (β), and 3) the relative price for giving resources to the infrastructure. In particular, the more expensive it is to allocate resources to the infrastructure, compared to consuming them (i.e. � > 1), the lower the users’ contribution to the infrastructure.

5. Evaluation

Having developed a comprehensive economic co-op model, the focus of our evaluation is to investigate the following aspects of a co-op infrastructure for a Social Cloud: 1) the average utility of users between the contribution schemes, and 2) the effect of specific parameters, especially price, in our proposed contribution schemes. Additionally, two QoS factors of the platform are studied: system availability (as the percentage of time periods in which the resource requirements are met) and the redundancy level (as the ratio of provided to required resources).

An analytical study of the two contribution schemes is infeasible; therefore we use a simulation approach to compare their implications. All simulations consider Social Cloud sizes from 10 to 400 users, in order to study the scalability of each approach. Note that these numbers are much smaller than the hundreds of millions of users that are registered on Facebook, however individual Social Clouds represent individual social network islands, and not the entire social graph.

5.1 Evaluation Methodology

The general simulation framework is implemented as follows. In total we performed 100 simulation runs per scenario, and averaged the results, in order to account for possible simulation bias with respect to the

initialization of users. At the beginning of a simulation run, users are created according to the clusters in Table 1, and their resource endowments are drawn uniformly from the interval [5, 15]. This interval is used because the average resource endowment is then �� = 10,which is an input in the system requirements function R(n), and the minimum amount of resources to run the system is assumed to be half of an average user's resource endowment (i.e. 50% computation power of an average computer). The percentage of endowment that users reserve for other purposes is randomly set to �� ∈ [0.1, 1.0]. ��,�� = 0.1, which captures the minimum endowment reserved for everyday purposes. For the enforced fixed contribution scenario, ��

∗ is calculated according to the equations in Section 4.3.1.

All scenarios include 10,000 simulated time periods. In the first period, it is determined whether users are initially available (or not) based on the average availability of the cluster, and the length of the first (un)availability interval is drawn according to the respective distribution. In every following time period, the amount of resources provided for the infrastructure is calculated, and if an (un)availability interval ends, the availability of a user is switched and the next interval is determined. The simulation requires approximately 50-500 time periods to reach a steady state, so only the results of the time periods 500-10,000 are considered for the evaluation.10

All scenarios were run with two different system resource requirements functions in order to study the robustness of the findings. First, the worst case scenario where we take R(n) as given in Equation 4 with 4 = 1, 5 = 1, �� = 10 and �� = 5. In this case, every user participates in every transaction and all transactions have to be computed simultaneously. The values for �� and �� are determined because users' endowments are drawn from [5, 15]. Second, to study the dependency of the results on R(n), the second system requirements function is determined by Equation 5 (only half of the users participate in each transaction), and 4 = 0.5, which is still a high load for the system.

5.2 Enforced Fixed Contribution

In this contribution scheme, each user has to provide a certain percentage of their endowment to the system. For the evaluation, we simulate the actual resource contributions when users provide exactly the minimum percentage (as calculated in Equation 7), and also when they must provide 10%, 20% and 50% more than the minimum percentage.

10 This is a common approach to address the startup problem in simulations, see e.g. [28], pp. 508ff.

733734

Figure 1 shows that the results of this contribution scheme depend on several factors: first, the minimum contribution percentage initially decreases with the number of users, but if the system size surpasses 50 users ��

∗ begins to increase again (Figures 1b and 1e). Second, although on average, the number ofprovided resources is higher than the amount of required resources (i.e. there is some level of redundancy, see Figures 1c and 1f), the average availability of the system is only between 50% and 65%, for the optimal contribution ��

∗ (Figures 1a and 1d). This is mainly due to the fact that the calculation of ��

∗ only considers average values of user availability, which does not account for the dynamics of the system (such as multiple users being unavailable simultaneously).

We can observe two issues with this contribution scheme: first, if the minimum contribution percentage is increased to account for dynamic (un)availability, the average availability of the system increases drastically, even reaching values close to 1 (Figures 1a and 1d). Second, the system is also scalable as the average system availability increases with the number of users. This can be explained by the fact that the more users contribute, the larger the pooling effects of (un)available users, which leads to a “smoothing” of provided resources and a higher probability that the system resource requirements are met at any point in time. Furthermore, the percentage of time periods where the system resource requirements are actually met does not seem to depend on the specific resource function as the comparison of Figures 1a and 1d shows. This is mainly due to the fact that the (un)availability interval distributions determine the number of contributing users, and the requirements function mainly affects ��

∗.

Overall, the results show that if an enforced fixed contribution scheme is used, it is better to set the required ρ higher than the minimum ��

∗. This leads to higher system availability even for small increases of ρ because the larger individual user contributions alleviate the unavailability of other users.

5.3 Voluntary Variable Contribution

The variable voluntary scheme in Section 4.3.2 allows each user to calculate their optimal individual contribution for infrastructure resources, based on individual preferences, according to Equation 8. In the following experiments the relative price of resource contribution p was also varied between 1.0 and 3.0.(Prices � < 1 would mean resource provisioning has to be subsidized, a case we do not consider in this paper.)

In order to study system behavior in a more realistic setting, each user is assigned to a certain availability cluster and is given a particular type of utility function, according to Table 2. The type of utility function also determines the optimal contribution level, given the optimal condition based on the resource endowment constraint. Using the user type distribution from [25], we obtain the results shown in Figure 2. The simulation shows several interesting results. On one hand, the intuition that higher relative contribution prices leads to fewer contributions, is confirmed in Figures 2b and 2e. The average contribution decreases with increasing relative prices for provisioning, a result which seems to be independent of the system resource requirements. On the other hand, system availability as well as the average amount of contributed resources strongly depend on the relative prices that users bear for providing resources.

a) System availability, worst case requirements

00.050.1

0.150.2

0.250.3

0.350.4

0.45

10 20 50 100 200 400

Con

trib

utio

n Pe

rcen

tage

Number of Users

rho_star rho_star*1.1 rho_star*1.2 rho_star*1.5

b) Average contribution of users, worst case requirements

00.20.40.60.8

11.21.41.61.8

10 20 50 100 200 400Perc

enta

ge P

rovi

ded/

Req

uire

d

Number of Users


c) Provided vs. required resources, worst case requirements

00.10.20.30.40.50.60.70.80.9

1

10 20 50 100 200 400

Avai

labi

lity

Perc

enta

ge

Number of Users


d) System availability, average requirements

00.050.1

0.150.2

0.250.3

0.350.4

0.45

10 20 50 100 200 400

Con

trib

utio

n Pe

rcen

tage

Number of Users


e) Average contribution of users, average requirements

00.20.40.60.8

11.21.41.61.8

10 20 50 100 200 400Perc

enta

ge P

rovi

ded/

Req

uire

d

Number of Users


f) Provided vs. required resources, average requirements

Figure 1: Simulation Results for Enforced Fixed Contribution

00.10.20.30.40.50.60.70.80.9

1

10 20 50 100 200 400

Avai

labi

lity

Perc

enta

ge

Number of Users


734735

If relative prices are too high users choose to provide only a small number of resources, which leads to the decrease in system availability as shown in Figures 2aand 2d. This also affects the scalability of the system;if prices for contribution are roughly similar to prices for self-consumption, the contribution scheme is scalable with the number of users.

Furthermore, on average, significantly more resources are provided than required, leading to higher redundancy levels (Figures 2c and 2f). Along with the previous finding this indicates that the incentive-based scenario would be especially vulnerable when only a few users contribute to the system. Although individually they might contribute a significant amount

of resources, the system is more dependent on these few contributors. In case of their unavailability the resource requirements might not be met. In addition, the results do not qualitatively change if the minimum amount of endowment that is reserved for personal consumption, ��, is increased from 0.1 to 0.5. Hence, we omit the graphs for this case, as the minimum amount of reserved endowment is not an influential factor in our simulation.

To study the dependency of the simulation results on the underlying distributions of user types (and hence, utility functions), we now compare the previous results with a more pessimistic distribution, as shown in Figure 3. As stated in Section 4.1, this distribution is

00.10.20.30.40.50.60.70.80.9

1

10 20 50 100 200 400

Avai

labi

lity

Perc

enta

ge

Number of Users

price=1.0 price=1.25 price=1.5 price=2.0 price=3.0


00.020.040.060.080.1

0.120.140.160.180.2

10 20 50 100 200 400

Con

trib

utio

n Pe

rcen

tage

Number of Users



0

0.5

1

1.5

2

2.5

3

3.5

10 20 50 100 200 400

Perc

enta

ge P

rovi

ded/

Req

uire

d

Number of Users



00.10.20.30.40.50.60.70.80.9

1

10 20 50 100 200 400

Avai

labi

lity

Perc

enta

ge

Number of Users



00.020.040.060.080.1

0.120.140.160.180.2

10 20 50 100 200 400

Con

trib

utio

n Pe

rcen

tage

Number of Users



0

1

2

3

4

5

6

7

10 20 50 100 200 400

Perc

enta

ge P

rovi

ded/

Req

uire

d

Number of Users



Figure 2 Simulation Results for Voluntary Variable Contribution

00.10.20.30.40.50.60.70.80.9

1

10 20 50 100 200 400

Avai

labi

lity

Perc

enta

ge

Number of Users



0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

10 20 50 100 200 400

Con

trib

utio

n Pe

rcen

tage

Number of Users



0

0.2

0.4

0.6

0.8

1

1.2

1.4

10 20 50 100 200 400

Perc

enta

ge P

rovi

ded/

Req

uire

d

Number of Users



00.10.20.30.40.50.60.70.80.9

1

10 20 50 100 200 400

Avai

labi

lity

Perc

enta

ge

Number of Users



0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

10 20 50 100 200 400

Con

trib

utio

n Pe

rcen

tage

Number of Users



0

0.5

1

1.5

2

2.5

3

10 20 50 100 200 400

Perc

enta

ge P

rovi

ded/

Req

uire

d

Number of Users



Figure 3: Simulation Results for Voluntary Variable Contribution, mostly selfish user types

735736

obtained from observed Peer-to-Peer systems, where 70% of users are purely selfish free-riders, and only 30% are willing to give resources to the infrastructure (types 1 and 6 in Table 2, respectively).

In this scenario, based on the high number of free-riders, the general level of system availability is much worse than in the previous case (Figures 3a and 3d). This is especially evident at peak times where resource requirements are high, as the high number of selfish users leads to a significant decrease in resource contribution. In the case of moderate resource requirements, the system performs well when contribution is not expensive (� ≈ 1). Moreover, both the proportion of provided to required resources (Figures 3c and 3f), and the average contribution per user (Figures 3b and 3e), are lower compared to the results in Figure 2, which explains the reduced system availability. It is noteworthy that despite the pessimistic distribution of user types, the system performs surprisingly well for moderate resource requirements and lower relative prices.

5.4 Discussion

Figure 4 shows a comparison between the average utility per user in the voluntary variable and enforced fixed schemes and for both resource functions. As predicted, the average utility is higher when users are allowed to choose their individual optimal level of contribution (rather than being forced into suboptimal levels of contribution).

2.8

2.9

3

3.1

3.2

3.3

3.4

3.5

3.6

10 20 50 100 200 400

Util

ity p

er U

ser

Number of Users

enforced, RF0 enforced, RF1 voluntary, RF0 voluntary, RF1

Figure 4: Utility per User for different scenarios

Based on our evaluation results, there are some further observations through which we can evaluate the feasibility and scalability of a co-op infrastructure. First, if a fixed contribution is enforced by the system, the (un)availability characteristics of the users have to be taken into account when the necessary contribution percentage is calculated. In this case there is an inherent trade-off between increasing the individual contribution ��

∗ and making the entire system perform better or more reliably. That is, the QoS factor availability is directly dependent on the chosen level of parameter ��

∗. For example, an increase in ��∗

significantly increases the system availability, but in this case individual contributions can be very high for large system sizes (up to 42% of the endowment).

Second, the results from the voluntary variable contribution scheme (see Section 5.3) indicate that even under worst case requirements, allowing users to select their contribution level, the system resource requirements are met in many time periods (corresponding to high availability, as well as a rather high redundancy factor as shown in Figures 2c and 2f).Furthermore, the average individual utility is higher than in the fixed scheme. However, based on the underlying distributions of user types, the system performance is much more dependent on the voluntary contribution of single users.

Hence, the system designer has to address the following trade-off: either force users to give a certain, fixed percentage of their endowment to the co-opinfrastructure, e.g. as a condition for participation, or let users choose freely their contribution. In the latter case, the average utility of users as well as system availability/redundancy tends to be higher, but one must carefully study the user type distribution to ensure that there are enough users willing to contribute.

6. Conclusions and Future Work

In this paper, we proposed a novel co-operative model for providing coordination infrastructures in social, distributed and volunteer computing platforms. To examine the feasibility of the approach, we used a simulation approach to study two contribution schemes. We found that both fixed as well as variable contribution schemes are feasible options, with a clear tradeoff between system reliability and user flexibility.

As future work we will investigate new scenarios and extend our co-op model to encompass a wider range of attributes. Two key examples are: 1),additional resources types to guarantee that transactions within the system are not dependent on the availability of single users, which depends on the number of users concurrently providing resources to the system; and 2) to analyze how specific incentives (e.g. reputation mechanisms, compensation for resource provisioning, etc.) alter the willingness of users to contribute. Finally, we aim to model both the setting of a co-op infrastructure in conjunction with resource sharing between users via a Social Cloud.

References

[1] K. Chard, S. Caton, O. Rana and K. Bubendorfer, "Social Cloud: Cloud Computing in Social Networks," IEEE 3rd International Conference on Cloud

736737

Computing, pp. 99-106, 2010. [2] K. Chard, K. Bubendorfer, S. Caton and O. Rana,

"Social Cloud Computing: A Vision for Socially Motivated Resource Sharing," IEEE Transactions on Services Computing, vol. 99, 2011.

[3] R. Spear, "The Co-operative Advantage," Annals of Public and Cooperative Economics, vol. 71, no. 4, pp. 507-523, 2000.

[4] P. K. Porter and G. W. Scully, "Economic Efficiency in Cooperatives," Journal of Law and Economics, vol. 30, no. 2, pp. pp. 489-512, 1987.

[5] W. Cime and K. Marzullo, "The computational Co-op: Gathering clusters into a metacomputer," Parallel and Distributed Processing, 13th International and 10th Symposium on, pp. 160-166, 1999.

[6] W. Xiaohui, D. Zhaohui, Y. Shutao and H. &. H. L. Chang, "CSF4: A WSRF Compliant Meta-Scheduler," nProc. of World Congress in Computer Science Computer Engineering, and Applied Computing, pp. 61-67, 2006.

[7] K. Chard and K. Bubendorfer, "A Distributed Economic Meta-scheduler for the Grid," Proceedings of the 8th IEEE International Symposium on Cluster Computing and the Grid (CCGRID), pp. 542-547, 2008.

[8] K. Chard and K. Bubendorfer, "Using Secure Auctions to Build a Distributed Metascheduler for the Grid," in Market-Oriented Grid and Utility Computing, John Wiley & Sons, Inc., 2009, pp. 569-588.

[9] S. Xu and M. Yung, "SocialClouds: Concept, Security Architecture and Some Mechanisms," in Trusted Systems, vol. 6163, L. Chen and M. Yung, Eds., 2010, pp. 104-128.

[10] D. D. Roure, C. Goble and R. Stevens, "The Design and Realisation of the myExperiment Virtual Research Environment for Social Sharing of Workflows," Future Generation Computer Systems, vol. 25, no. 5, pp. 561-567, 2009.

[11] G. Klimeck, M. McLennan, S. P. Brophy, G. B. Adams and M. S. Lundstrom, "nanoHUB.org: Advancing Education and Research in Nanotechnology," Computing in Science and Engineering, vol. 10, pp. 17-23, 2008.

[12] I. Foster, "Globus Online: Accelerating and Democratizing Science through Cloud-Based Services," IEEE Internet Computing, vol. 15, no. 3, pp. 70-73, 2010.

[13] D. N. Tran, F. Chiang and J. Li, "Friendstore: Cooperative Online Backup Using Trusted Nodes," Proceedings of the 1st Workshop on Social Network Systems, pp. 37-42, 2008.

[14] Z. Yang, B. Y. Zhaoy, Y. Xing, S. Ding, F. Xiao and Y. Dai, "AmazingStore: available, low-cost online storage service using cloudlets," Proceedings of the 9th Int. Conference on Peer-to-peer systems, p. 2, 2010.

[15] A. Thaufeeg, K. Bubendorfer and K. Chard, "Collaborative eResearch in a Social Cloud," E-Science, IEEE 7th Int. Conference on, pp. 224-231, 2011.

[16] K. John, K. Bubendorfer and K. Chard, "A Social Cloud for Public eResearch.," E-Science, IEEE 7th International Conference on, pp. 363-370, 2011.

[17] R. J. Sexton, "The Formation of Cooperatives: A Game-Theoretic Approach with Implications for Cooperative Finance, Decision Making, and Stability," American Journal of Agricultural Economics, vol. 68, no. 2, pp. 214-225, 1986.

[18] D. P. Anderson, "BOINC: A System for Public-Resource Computing and Storage," Proceedings of the 5th IEEE/ACM International Workshop on Grid Computing, pp. 4-10, 2004.

[19] D. P. Anderson and G. Fedak, "The Computational and Storage Potential of Volunteer Computing," Cluster Computing and the Grid Sixth IEEE International Symposium on, pp. 73-80, 2006.

[20] B. Javadi, D. Kondo, J.-M. Vincent and D. P. Anderson, "Mining for statistical models of availability in large-scale distributed systems: An empirical study of SETI@home," MASCOTS, pp. 1-10, 2009.

[21] B. Javadi, D. Kondo, J. Vincent and D. Anderson, "Discovering Statistical Models of Availability in Large Distributed Systems: An Empirical Study of SETI@home," Parallel and Distributed Systems, IEEE Transactions on, vol. PP, no. 99, p. 1, 2011.

[22] E. Fehr and K. M. Schmidt, "The Economics of Fairness, Reciprocity and Altruism - Experimental Evidence and New Theories," in Handbook of the Economics of Giving, Altruism and Reciprocity, vol. 1, S. Kolm and J. M. Ythier, Eds., Elsevier, 2006, pp. 615-691.

[23] G. Charness and M. Rabin, "Social preferences: Some simple tests and a new model," Economics Working Papers 441, 2000.

[24] E. Fehr and K. M. Schmidt, "A Theory Of Fairness, Competition, and Cooperation," Quarterly Journal of Economics, vol. 114, no. 3, pp. 817-868, 1999.

[25] J. Andreoni and J. Miller, "Giving According to GARP: An Experimental Test of the Consistency of Preferences for Altruism," Econometrica, vol. 70, no. 2, pp. 737-753, 2002.

[26] E. Adar and B. A. Huberman, "Free riding on Gnutella," First Monday, vol. 5, no. 10, 2000.

[27] K. Shampanier, N. Mazar and D. Ariely, "Zero as a Special Price: The True Value of Free Products," Marketing Science, vol. 26, no. 6, pp. 742-757, 2007.

[28] A. M. Law, Simulation modeling and analysis, McGraw-Hill, 2007.

[29] S. Caton, C. Dukat, T. Grenz, C. Haas, M. Pfadenhauer and C. Weinhardt, "Foundations of Trust: Contextualising Trust in Social Clouds," 2nd International Conference on Social Computing and Its Applications, forthcoming 2012.

[30] M. Granovetter, "Economic Action and Social Structure: The Problem of Embeddedness," American Journal of Sociology, vol. 91, no. 3, pp. 481-510, 1985.

737738

Documents

Co-operative Infrastructures: An Economic Model for Providing Infrastructures … · Co-Operative Infrastructures: An Economic Model for Providing Infrastructures for Social Cloud