Service level agreement as a complementary currency in peer-to-peer markets

Future Generation Computer Systems 28 (2012) 1316–1327

Contents lists available at SciVerse ScienceDirect

Future Generation Computer Systems journal homepage: www.elsevier.com/locate/fgcs

Service level agreement as a complementary currency in peer-to-peer markets Ioan Petri a,∗ , Omer F. Rana b , Gheorghe Cosmin Silaghi a a

Babeş-Bolyai University, Business Information Systems, Cluj–Napoca, Romania

b

Cardiff University, School of Computer Science & Informatics, Wales, United Kingdom

article

info

Article history: Received 8 December 2010 Received in revised form 7 September 2011 Accepted 17 September 2011 Available online 29 September 2011 Keywords: Complementary currency Service level agreements Electronic markets P2P market simulation

abstract Service level agreements (SLAs) have demonstrated to be efficacious tools for managing resources. They provide a valuable basis for establishing contractually binding interactions within peer-to-peer systems. Such SLAs are particularly useful when considering interactions in environments with limited trust between participants. In recent research, we observe a move from the use of SLAs as simple documents handled manually to the use of automated mechanisms for handling SLAs, appropriate for different business profiles. Complementary currencies, on the other hand, have proven to be useful for facilitating exchange among selfish peers. We identify how an SLA can itself be used as a complementary currency to encourage resource sharing between peers. Our work demonstrates how an SLA can be used as a medium of exchange and used to establish a market for computational resources. The value of an SLA can vary based on the demand for particular types of resource. By simulating a process of trade, we investigate several economic indicators. We demonstrate how the economic benefit (in terms of profit and loss) evolves based on varying levels of demand. We describe how a variation in value of an SLA can influence the overall ‘‘welfare’’ within a peer-to-peer system, and how such welfare is dependent on the overall demand for services and the redemption time associated with the SLA. © 2011 Elsevier B.V. All rights reserved.

1. Introduction The notion of commodity money [1] and the associated concept of ‘‘complementary currencies’’ have proved to be useful instruments to facilitate economic regeneration. Complementary currencies are recognised by their ability to add value to a community, and to improve the scalability of trade beyond bartering. In the context of a local economy (i.e. where trading is restricted to participants who are nearby, and does not involve global entities such as central banks), goods or services can themselves represent tradable objects. Complementary currencies generally describe a group of currencies or scrips designed to be used alongside standard currencies. They can be valued and exchanged in relationship to national currencies but also function as a medium of exchange on their own. Complementary currencies have also found applicability in peer-to-peer (P2P) networks as powerful instruments to promote exchange, particularly to avoid the need for accessing central servers. Complementary currencies have different rates of exchange and scopes of circulation. The value of a complementary currency can change over time, and in most instances is also related to the

∗

Corresponding author. Tel.: +40 742153099. E-mail addresses: [email protected] (I. Petri), [email protected] (O.F. Rana), [email protected] (G.C. Silaghi). 0167-739X/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.future.2011.09.007

value of some real resource (such as commodities, i.e. gold, oil, or services). The relationship of such a currency to a ‘‘service’’ is particularly interesting, as the value of the currency is based on the time required to perform a service in hours, notwithstanding the potential market value of the service. Such a currency is primarily used for mapping ‘‘human time’’ for performing a task into an economic value in a local context. Complementary currencies can also devalue over time (e.g. through the use of negative interest), to stimulate market exchange, thereby encouraging greater participation in the market. Devaluation also prevents storage of wealth (hoarding) of currency and encourages spending as the value continues to decay. Other experimental complementary currencies use high interest fees to promote heavy competition between participants, and the removal of wealth from long-term wealth-holding structures (natural/material wealth, property, etc.) to aid competitive innovation and better use of resources across various members of a community. Within an economic market that operates within a local community, participants can generate their own currency by using a valuable service as an exchangeable object [2]. Local, in this context, implies that the participants are known to each other, and therefore utilise pre-existing trust relationships. Several experiments, such as Wärgl in 1932 (stamp scrip [3]), Comox Valley in 1983 (LETS: Local Exchange Trading System [4]) and in Ithaca since 1991 (Ithaca Hours [5]) used the barter of complementary currencies for supporting values such as volunteer work, daily

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

help, or skills that are often not regularly utilised within a financial market. Facilitating the exchange of computational and data services by using complementary currencies has become an alternative solution for P2P networks as powerful instruments to promote exchange. iWAT [6], Geek Credit [7], and Ripple [8] are examples of systems that use such complementary currencies for exchanges of computational service such as storage, computational capacity, and network bandwidth. Within such a market, a peer node can exchange capability that it does not immediately need for an alternative service, thereby enabling a better sharing of overall capacity between participants in the market. A service level agreement (SLA) provides a contract between a service provider and one or more users. An SLA contains guarantee terms that need to be satisfied by a provider, and a payment that needs to be made by a user when such guarantees have been met. As an SLA refers to a service that is to be provided in the future, it is possible to consider an SLA-based options market, and thereby use an SLA itself as a complementary currency. Whereas iWAT, by a ticketing mechanism, or Samsara [9] by the mechanism of claims, require strategies to control the environment, SLAs provide such functionality by their design. An SLA defines responsibilities of the parties involved within an exchange, and thereby reduces the overall risk associated with the exchange to an adequate level. Unlike other complementary currency systems, our SLA-based approach provides a formal description of the service specifying the quality of service (QoS) to be delivered. In addition, the mechanism of penalties and rewards can control the exchange and therefore reduce the risk of not receiving the required functionality. An SLA therefore provides all the relevant features to serve as a model for an exchange process and attempts to minimise risk between participants within an untrusted environment. In particular, the SLA payment model eliminates several inconsistencies in actual systems, as the payment mechanism used may be brokered through an intermediate (trusted) third party. In P2P systems using SLAs, we can use economic benefit as a metric to identify whether profit or loss has been incurred based on an initial configuration at start time. Several system configurations are experimented with in order to observe the reaction of the system in the context of different market scenarios. Our market simulation investigates how the issuing intervals can affect the overall benefit and how different SLA types can induce profit or loss. Large-scale systems are also evaluated for identifying the scalability of our approach. Within a P2P market, a variation in demand for particular types of service can impact the value of the traded object. If the traded object is an SLA, the value of an SLA can decay or increase over time based on this demand fluctuation; consequently, we introduce a ‘‘welfare’’ parameter in order to measure the status of the system at each stage of exchange. The level of welfare can be aggregated across the entire P2P system, or a subset of nodes, and reflects the value benefit achieved by the system (or subset). We are also interested in identifying how differing levels of demand and system configurations cause a change to the level of welfare. In this particular contribution, we focus on identifying the value of an SLA as the number of participants within a community increases, and utilise a PeerSimbased simulation to show how community welfare can change over time. For conducting experiments, we use a probability distribution for controlling how the SLAs are issued and forwarded (re-sold). We assume that all participants are willing to contribute to community benefit and to reveal their welfare values in order to benefit themselves. Peers can also state which other peers they trust: an assumption here is that trusted entities associated with an entity are also trustworthy. Building trust among peers or using pre-existing relationships for identifying the trustworthiness of peers is outside the scope of this paper.

1317

The rest of this paper is organised as follows. In Section 2, we discuss related work, in particular the iWAT system that uses the notion of tickets as a tradable object between peer nodes. In Section 3, the general ideas behind our approach are outlined, in particular relating some of our concepts to the WSagreement protocol. The exchange protocol and associated stages are discussed in Section 4. Our experiment methodology and results are provided in Section 5. 2. Related work Complementary currencies provide an important mechanism to support the use of computational and data services. The possibility of using complementary currencies for exchanging services within P2P networks have been investigated by many studies. The WAT system [10] provides an alternative currency to facilitate local exchanges. WAT is a debt-oriented system using WAT tickets as mediums of exchange. These tickets are issued by participants and they are used for mediating exchanges. iWAT [6] is an Internet version of the WAT system, and it implements the core aspects of WAT, focusing specifically on the problem of ticket exchange. As an issued ticket can circulate between a number of different users within the WAT system, the party responsible for issuing the ticket is also responsible for validating its authenticity, as the redeemer of the ticket may be different from the one to whom the ticket was initially issued. The system also provides incentive mechanisms for keeping users online, thereby providing a large enough population of users to enable ticket exchange [11]. In iWAT, there are two key events, (1) reduction, and (2) multiplication, which can result in a change to the value of a ticket. Multiplication is used to support the exchange of those services that are likely to have higher demand in the future than the present. Saito et al. [12] analyse the problem of ticket multiplication in the context of P2P systems, discussing a participant’s states during the exchange. A reduction is based on the idea that the value of an exchangeable good deteriorates over time, and (in some ways) models the decay of perishable physical goods. It is therefore necessary for a seller to offload these goods by a certain time. A reduction in the value of tickets accelerates spending [13], as buyers are able to purchase at a lower perceived cost. However, ticket circulation becomes restricted, as users often refuse to sell at a cost lower than the price they initially paid. The study illustrates the users’ intention to minimise their loss and to defer redemption in the hope of being able to sell at a higher price in the future. It also accurately specifies the expectations of the participants and the risks they incur. Instead of tickets, we use an SLA as the tradable object that can be exchanged between participating nodes. Samsara [9] concentrates on establishing service relationships between peers, minimising risk due to failure and claim, to ensure equivalence between the contribution and consumption of peer nodes. Establishing symmetric storage relationships leads to fairness and is handled as a central goal. Samsara is similar to the WAT system; however, although designed as a mechanism to support exchanging objects for storage replication, it is preoccupied with fairness, rather than offering an accurate payment representation. The Ripple protocol [8] enables trustworthy ‘IOU’ exchanges defining particular trusted connections for each currency. Each currency operates on a separate user network, but participants also have the authority to accede in different currency networks. It is assumed that one unit of a product has equal significance for all the participants. In most cases, this assertion represents only an assumption; e.g. one commodity has one significance for A but probably has different significance (utility) for B. For alternative currency systems, trust implications have been considered in more

1318

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

detail than the representation of the exchanged object [14,15]. Another related issue is counteraction against whitewasher peers that may damage the exchange [16]. Whitewashers are defined as an undesirable category of participants that strategically leave and rejoin the system by changing identities, and therefore impact system welfare. The MCS (Mutual Credit System) [17] is a debtoriented model that allows participants to credit themselves. In the MCS and the WAT system, welfare is strongly related to the bankruptcy rates and the percentage of whitewashers. Five different evasive strategies are introduced in the context of iWAT ticket exchange to reduce this cost. Saito et al. [16] measure the welfare for each evasive strategy and identify the strategy with positive effects for the participants. It is demonstrated that the use of reduction tickets accelerates trades and reduces bankruptcies while multiplication provides limited benefit for ticket issuers and should be carefully used. In the context of micropayments, PPay [18] implements a protocol for coin assignment at the level of peer nodes using signature generation, verification, and network messages. PPay aims to obtain a secure and efficient payment process by implementing a strategy for coin transfer. The experiments record considerable efficiency from the perspective of security, placing PPay as a micropayment solution in P2P applications. By introducing an additional authority to approve exchanges and transform real money into specific PPay digital coins, PPay hypothesises that security should be a major concern in the context of digital currency systems. PPay demonstrates the requirement that a complementary currency must be transformable into real currency. 3. Motivation and approach An SLA may be used to specify quality of service terms, the measurement criteria, reporting criteria, and penalty/reward clauses between participants. Within an electronic market, an SLA may be used (i) as an expression/proof of debts as well as credits: debts to the client and credits to the service provider; (ii) as a token of exchange between participants; and (iii) as an identification of responsibilities of participants involved (such as the client and service provider). Establishing an SLA between two parties (client and service provider) implies that the service provider has agreed to provide a particular capability to the client within some quality of service. In return, the client must provide a monetary payment (most often) or credit to the provider once the service has been delivered (subject to a penalty, often also monetary, in case the quality of service terms have not been adhered to). The credit may be made at the beginning of service provision (the pay-beforeuse model) or after (the pay-after-use model). It is useful to note that an SLA refers to a service provision that must take place some time in the future. The SLA creation process starts when a client (the initiator) sends a request to a potential provider. The provider issues an SLA template, specifying agreement terms and obligations, containing service level objectives, quality terms, and business values associated with particular service level objectives. Penalties and rewards are also parts of the SLA template. The initiator fills the template with the required service, asking the provider for a price. The agreement is finalised when the initiator accepts the price from the provider. The underlying protocol can be found in the WS-agreement specification [19]. In the context of an electronic market, the SLA expresses a commitment for a service delivery that is scheduled to start sometime in the future. Fig. 1 shows the overall time line from the creation of an SLA to its subsequent use. From Fig. 1, 1T = T3 − T0 represents the overall time over which an SLA exists, where T3 is the time when the SLA ends (i.e. the service provision that has been identified within the SLA

Fig. 1. SLA time management.

has completed) and T0 is the time when the SLA has been created. Within this overall interval 1T , the subinterval 1T0 = T1 − T0 identifies the period over which an SLA is held by the initial client. At T1 , the client node decides that it no longer needs the service identified in the SLA and can exchange/forward the SLA. Alternatively, the node holding the SLA (the client) may get an offer from another node for the service identified in the SLA. The client node therefore decides to forward the SLA to another node, and in return receives a monetary payment. This forwarding (and payment) process may continue a number of times, and is identified by the time interval 1T1 . Over this time interval, the value of an SLA may change (similar to the change in value of an iWAT ticket) a number of times. Eventually, an SLA may either be redeemed or expire. T2 is the time at which the SLA has been redeemed (i.e. the service identified in the SLA is invoked). 1T2 = T3 − T2 is the period after the redemption process has occurred, and the value of the SLA can no longer change. 1T2 represents the time over which service execution takes place, and at T3 the SLA expires and is no longer valid, and therefore has an economic value of zero. In this model, it is possible for an SLA to never be redeemed, and therefore for T2 and T3 to overlap. 4. Protocol We assume that a provider can deliver two categories of services within a trusted environment: (i) those that it provisions through its locally owned resources (direct provisioning); (ii) those that it defers to other providers through previously acquired SLAs (indirect provisioning). The first category corresponds to SLA creation while the second involves advertising SLAs that a provider already holds with others. Within a predefined time interval (1T , see Fig. 1), one SLA can experience the following operations: (1) SLA issuing, (2) SLA forwarding, and (3) SLA redemption. Issuing reproduces the economic process of supplying the system with tradable objects (SLAs), whereas redemption represents the final stage of acquiring the service identified in the SLA. Between these there can be multiple stages involving SLA forwarding between nodes. Fig. 2 explains how one SLA can be exchanged among different nodes and is based on the WS-agreement protocol [19] and makes use of creation constraints, expiration time (associated with the SLA), and monitoring of agreements. An SLA life cycle consists of the following stages (see Fig. 2): (1) SLA issuing, t0 –t1 , (2) SLA forwarding, t1 –t2 , t2 –t3 and (3) SLA redemption, t3 . Issuing reproduces the economic process of supplying the system with exchangeable units (SLAs), whereas redemption represents the final stage of acquiring the service identified in the SLA. Between these there can be multiple stages involving SLA forwarding between nodes. Issuing: as illustrated in Fig. 2, node A, the initiator, asks node B for the services it can provide (directly or indirectly). In Fig. 2, [T (B), {t1 , t2 , . . . , tn }] identifies the list of services that node B can provide, where ti = SLAXB is an SLA that node B has with node X, and which node B is willing to trade. Hence, node B advertises both services it can offer, along with those SLAs that it holds with other nodes. While node A is able to chose the properties

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

1319

• Service terms: details about the service being provided. • Guarantee terms: details such as service level objectives, qualifying conditions for the agreement to be valid, penalty terms, etc.

Fig. 2. Protocol workflow.

(quality terms) for capability that node B provides, it cannot modify the properties of an existing SLA that node B holds (which is advertised on a take-it-or-leave-it basis). Node A chooses to acquire the service that node B can provide directly; therefore, B forwards the agreement template T (B). After creation, node B commits to provide the service in T (B) and node A credits node B with the monetary value identified in the SLA before service provisioning begins. At this point, node A holds an SLA with B (SLABA ) which has a monetary value (equivalent to what node A has paid node B). Node A can now present the service specified by SLABA in its own list of available services that can be provided indirectly. The value of this SLA, however, will change over time depending on the demand for services being provided by B. The SLA is therefore a token of exchange that may be used by A to purchase additional capability from other nodes, if node A does not use this capability directly. Forwarding: in the second stage of the exchange, node C now requests a service from node A. Node A responds with the list [T (A), {t1 , t2 , . . . , tm }]. Within this list, T (A) is the template specifying the service that node A can provide directly. Node C chooses to acquire the service specified in t1 and pays A based on the advertised price for this SLA. Node B must now provide a service to C in accordance with the SLA that was previously agreed between nodes A and B. The client of the agreement has changed, as SLABA becomes SLABC , and the value of SLABA is different from SLABC . After node A forwarded the SLA to C, a transfer of obligations from A to C is invoked. Therefore, the provider (node B) has an obligation to the current holder (node C) of the SLA; as we assume a trusted environment, the redeemer of an SLA can change to any trusted participating nodes. At this point, node C is able to list the service defined by this SLA as a service that can be provided indirectly. The process of forwarding occurs between the creation of an SLA and its expiration. From Fig. 1, 1T1 identifies the interval over which an SLA can be forwarded. Redemption: this is the final stage of the exchange, and it involves using the capability identified in the SLA (it occurs after an SLA has been agreed between two parties, and may take place after several forwarding operations). As illustrated in Fig. 2, node D redeems the SLA with provider B. These stages can be encoded with WSagreement; for instance, after receiving a service request from node A, node B responds with a WS-agreement template which node A is expected to complete with the following information:

• Name/ID: a unique identifier for the agreement. • Context: metadata associated with the agreement, such as the agreement initiator, agreement responder, the expiration time, etc.

The guarantee terms specify which is the obligated party, to which service this guarantee applies, the service level indicators and service level objectives as an assertion over service descriptions, and the business value associated with these objectives. The key difference is the client who finally invokes the service based on the terms in the agreement. We consider a particular kind of SLA, where the provider remains the same and the client can change over time (thereby assuming that all clients who forward SLAs between themselves are trusted). The redeemer is the entity which invokes the service described in the agreement. When issuing an SLA, the service provider commits to provide a capability sometime in the future. The property of the SLA is changed among clients based on a credit/debit payment mechanism (when the SLA is forwarded a payment to the initial SLA holder is performed), with each client having the freedom to exchange the SLA with other parties. The service provider is interested in the redeemer to whom a service capability has to be provided and has no interest in identifying intermediate clients. The SLA issued by providers is therefore unique, as clients cannot issue a new SLA on behalf of providers unless they hold the same service capability themselves. The exchange works on the basis of market mechanisms of supply and demand. The market mechanism affects the value of the SLA as well as the decision of clients to resell (forward) or consume (redeem) an SLA. When an increase of demand for a service (or the capability or reputation of a service provider) takes place, the value of the associated SLA associated with the service (or issued by a particular service provider) also increases, enabling clients to consider whether reselling the SLA would be of benefit to them. Assumptions. For this exchange, we make the following assumptions.

• A service provider does not care about the identity of the client, provided that the SLA that the client holds is valid and can be authenticated by the provider. This assumption would hold in a trusted environment, where the redeemer of an SLA can change to any trusted participating nodes within the system. Alternatively, during the forwarding process, a node may only decided to purchase indirectly provided services from nodes that it trusts. • A client does not directly purchase capability from a provider, and instead asks for indirect provisioning (as identified in the ‘‘Issuing’’ phase above), as this may be cheaper. If a node decides that it no longer needs the service identified in an SLA that it has previously negotiated with a provider, it needs to recover its initial investment by forwarding/selling this SLA to other nodes. If it does not, it will make an economic loss equivalent to the total cost it paid for the service. Therefore, there is an incentive for a node to sell off the SLA at a lower cost than the initial price it paid (and cheaper than the current cost being advertised by the provider). • Although an SLA has a ‘‘value’’ at a given time (depending on demand), it is necessary for this value to be eventually mapped to a physical currency (as in the PPay system discussed in Section 2). In our system, this is achieved when an SLA is initially issued, and then subsequently sold as an indirectly provisioned service. Hence, as indicated in the Issuing phase identified above, it is necessary for a client to pay a provider when an SLA is created in a physical currency. 5. Design of simulation To validate our use of an SLA as a complementary currency, we use a PeerSim-based [20] simulation. PeerSim is an open-source,

1320

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

Java-based simulation framework for developing and testing P2P algorithms in a dynamic environment. A PeerSim-based simulation allows us to develop hypotheses that can be applied in the context of complementary currencies. The simulation is developed within a particular network infrastructure where peers can play different roles: issuers, recipients, or redeemers. The value of an SLA can change over time, and we use a Poisson distribution to model this increase (or decay). In order to express a number of exchange events that can occur in a fixed period of time, a Poisson distribution is used. The Poisson distribution is applied when counting the number of discrete events and the random variable can only take non-negative integer values. It is closely connected to the exponential distribution, which (among other applications) is used to measure the time between arrivals of the events. The Poisson distribution was chosen from the need to simulate expected events (SLA processes) that occur independently and have a low frequency in the system, and when the number of participants is high. Every SLAs has (i) an issuer (Is ); (ii) a specific price (Ps ); (iii) a creation time Ts ; (iv) an (age); and (v) a time to live (ttl). As an SLA has an expiry time (age) associated with it, there is a limited time over which an SLA can be exchanged with other nodes. During this time interval, the SLA can either increase or decrease in value, based on the prevailing market conditions. Each peer node has a unique identifier in the simulation. They can have multiple states and are designed to be repositories of services, although only one service can be provisioned at a specific time. It is assumed that a node acquires only those SLAs that represent an immediate benefit. An immediate benefit is the SLA that brings a certain level of welfare or contains a desired level of service. During the exchange, one node can perform the following operations: submitting or issuing SLAs at each cycle according to a predefined configuration, spending or forwarding SLAs, and redeeming SLAs.

SLA is assigned with a ttl (time-to-live) parameter defining the time interval over which an SLA can be exchanged between nodes. The algorithm handles redemption as an event scheduled to occur at a specified ttl time. The operation of the algorithm in terms of issuing, forwarding, and redemption is identified in Fig. 2. These operations are carried out over a duration specified in the time to live (ttl) parameter. When an SLA’s age exceeds the specified ttl parameter, a redemption is automatically invoked. 5.2. Economic benefit—configuration The algorithm is cycle based, one node being scheduled to process one specific operation (issuing, forwarding, or redemption) at each cycle. During the experiment, the protocol uses the following parameters. (i) Simulation cycles ci , i = 1, n: the number of cycles over which the experiment executes. At cycle ck , k < n, the system records a level of benefit expressed in terms of profit Pk and loss Lk . (ii) size: the number of nodes in the experiment. (iii) time to live (ttl): the maximum allowed age for an SLA. (iv) The network topology: a specific network architecture. By default, the system uses a random connection topology. (v) nodes: the number of peers issuing SLAs. (vi) interval: average time interval between SLA submissions. (vii) number: maximum number of SLAs the system uses during the experiment. The economic benefit in terms of profit and loss: The benefit is defined as a function fx : X → B, where X is a set containing values specified by a configuration, and B is a set of peers that have made a profit or loss after multiple exchanges. Profit is defined as an auxiliary function defined by fx : X → Ps , where X is a set of configuration parameters and Ps is a list of peers in profit. Similarly, loss is defined as fx : X → Ls , where X is a configuration and Ls is a list of peers who have made a loss. Algorithm 2 Tracking the benefit of nodes 1:

5.1. Protocol execution

2: 3:

As SLAs are submitted according to a predefined probability distribution, the experiment requires sufficient cycles to ensure that an adequate number of submissions have been made. The issuing of an SLA is a process controlled by different configuration parameters within PeerSim. As illustrated in Algorithm 1, the transition between the issuing process and the forwarding process is performed based on an execution probability. Algorithm 1 Simulating the SLA Exchange Process 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:

for all i nodes from network size do if issuecontrol < executeprob and ttl < age and i < submissionnodes then issue(node, SLA); end if end for for all SLAs do if ttl < age and forwardcontrol < executeprob then forward(node, SLA); else redeem(node, SLA); end if end for

issuecontrol and forwardcontrol are generated as double variables taking random values from the interval [0, 1]. executeprob is a parameter included in the configuration file. It is the probability used to control the issuing and forwarding of SLAs. Thus, the number of SLAs that the system uses during the experiments are controlled with the executeprob parameter. At the same time, one

4: 5: 6: 7: 8: 9: 10: 11: 12:

for all cycles c do for all i nodes in scope do calculate Is and Cs if Is ≥ Cs then profittoken = true; return profit ++; else losstoken = true; return loss ++; end if end for end for

During the exchange two operations can occur at a node: (a) buying (acquiring) SLAs with costs: (Cs ) as a sum of SLA object k prices during stages of exchange: Cs = i=1 PSLAi , where PSLA represents the price of one acquired SLA and k represents the number of SLAs that are acquired during the experiment; (b) selling (spending) SLAs with income: (Is ) as a sum of SLA prices k that one node sells during stages of exchange: Is = i=1 PSLAi , where PSLA represents the price of a sold SLA and k represents the number of SLAs that are sold during the experiment. According to a probability distribution the system can express statuses by Profit Ps = Is − Cs and Loss Ls = Cs − Is . The algorithm handles the output by counting the number of peers in profit or loss after each cycle. In the simulation, an observer collects the information from various experiment stages and provides the simulation output. 5.2.1. Results Our approach uses an unstructured P2P architecture with peers operating services in the network. Each peer can deliver several

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

1321

Fig. 4. Simulating the economic benefit by profit at different levels of demand. Fig. 3. Simulating the economy dynamics when SLAs are submitted at different intervals.

services, and each service has a number of associated parameters. Services are delivered on the network on the basis of established SLAs among peers. We consider that every node holds a service distribution and it is linked with other nodes building virtual organisations. Each peer has (i) a predefined structure of links to neighbours, and (ii) a budget limit. Our algorithm uses a pay-beforeuse payment scheme. This means that every service delivery implies an advance payment. The simulations use a limited number of participants pk ∈ P, where P is a set containing nodes from the network. The model has a random network topology in which participants are linked together by some predefined paths. Each participant can reach others after some numbers of hops. Within the system, each participant can build an initial view of potential partners according to SLA properties (e.g. one node builds a view of all peers able to provide a particular type of operating system or processor). 5.2.2. Scenarios Various experiments (scenarios) are conducted to validate the system. The following scenarios illustrate how a local economy evolves when dealing with different market contexts. We identify how demand can affect the economic benefit especially when this demand is covered with different types of service. In particular, we investigate how a community reacts when the interval for trading services is varied. Identifying the status of the economy when the number of providers and consumers is increased helps us to understand how a local economy reacts to variation in competing service providers. In Experiment 1, we demonstrate how the economic benefit is influenced by the submission interval of service requests: the submission interval is incremented from 1 to 10. The experiment uses a configuration with 10 issuing nodes and a maximum of 10 SLAs per node. Fig. 3 confirms that the benefit is higher when SLAs are submitted with a time interval of 1 (at each cycle): there are always more SLAs in the system (over the monitoring interval); therefore the level of benefit is higher. With the submission interval of 10, the SLAs are injected with some latency (randomly at each 10 cycles) and the system reaches the maximum level after several cycles of exchange. We note that the benefit increases continuously after 60 cycles, indicating that the benefit is higher when SLAs are submitted over shorter time intervals, leading to greater overall circulation of SLAs within the system. For a real economy, the experiment validates that a high circulation leads to growth in terms of benefit. The highest level of benefit occurs when ϕ = 1, where ϕ = 1, 10 is the distribution frequency.

Fig. 5. Simulating the economic benefit when demand is covered with increasing SLAs.

Experiment 2: the economic benefit when demand is increased. This experiment (Fig. 4) investigates how the economic benefit, expressed as the total number of profitable peers, evolves when the number of requesting participants is increased. Fig. 4 show the profit and loss trend in the first 10 cycles. For the first 10 cycles, the system has enough requesting peers to operate trades. After cycle 10, the requests cause a gradual growth from cycle 10 until cycle 50. The growth trajectory then becomes linear as new participants are able to satisfy demand. Experiment 3: the economic benefit at different types of SLAs covering demand. These experiments reflect how the economic benefit is influenced by supporting particular types of SLAs. According to the SLA type, the system can record either profit or loss. These scenarios try to validate the relation between the benefit and the SLA types used to cover service demand. The following configurations use 10 issuing nodes and the number of SLAs is varied. Fig. 5 presents four different situations when demand is matched with an increasing number of SLAs. For five SLAs, the system reveals a certain level of benefit. Further, the output varies according to the number of participants. Because the number of decaying SLAs is stable, the overall level of loss remains the same. In the following experiment (Fig. 6), the number of decaying SLAs used to cover demand is increased in order to validate the connection between decaying SLAs and the system’s benefit. With these experiments we validated the assumption that the economy status is closely related to SLA types. Experiment 4: the economic benefit at different stages of demand. This scenario (Fig. 7) records overall system behaviour when the number of participating nodes change. In particular, we handled demand as the number of peers that request services.

1322

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

Fig. 6. Simulating the economic benefit when demand is covered with decaying SLAs.

Fig. 8. Simulating the economic benefit for different peer views.

Fig. 7. Simulating the economic benefit at different stages of demand.

The experiment uses 10 nodes generating SLAs and a maximum of 10 SLAs per node. Fig. 7 displays a proportional representation between the economic benefit and the level of demand measured in number of peers requesting SLAs. The experiment reveals the dependency between profit, loss, and demand. It is observed that new levels of demand cause new levels of benefit. Therefore, keeping a fixed number of participants, the system records values of 20–55 peers in benefit for levels of demand defined over the interval [25, 100]. Experiment 5: the economic benefit for different views of peers, where one view represents a collection of peers selected as potential trading partners. By modifying the number of proximate traders, we are able to induce a level of benefit. We are also interested in identifying how this view impacts the overall system benefit. The experiment uses a configuration with 10 nodes generating SLAs and a maximum of 10 SLAs per node. The experiment shows that expanding the overall view (i.e. possible potential trading partners) for one trader causes benefit. As a trader is able to interact with additional partners, the overall exchange within the system improves, leading to greater benefit. Fig. 8 illustrates benefit when the view oscillates from 5 to 20 peers. However, there is a maximum number of peers after which the benefit does not increase further. In this case, we are able to observe that for more than 20 peers in view the benefit remains stable. 5.2.3. Validation for large-scale systems In order to demonstrate the scalability of our system, we tested several scenarios by extending the network size. The following

Fig. 9. Simulating the economic benefit at different issuing intervals.

experiments are configured to use 1000 peer nodes, a maximum number of 50 SLAs per node, and a maximum of 10 nodes issuing SLAs. The simulator is scheduled to execute 60 rounds of exchange, where each round represents 10 cycles of simulation. Experiment 6: The economic benefit at different issuing intervals in the context of a large-scale system. This experiment uses a configuration with 50 SLAs and a maximum of 10 nodes. From Fig. 9, it is observed that, in the context of a largescale system, the interval has a major impact over the benefit distribution. When the simulator uses an issuing interval of 1, the system records a higher level of benefit than for an issuing interval of 10. This is caused by the latency of the SLA submission. At the threshold of 50 rounds of exchange, the benefit assigned for an issuing interval of 1 becomes stable. For an issuing interval of 10, the benefit is growing continuously, as the system has more SLAs to trade. Experiment 7: The economic benefit when the size of the system varies from 1000 peer nodes to 2000 peer nodes. This experiment uses a configuration with 50 SLAs per node and 10 issuing nodes. Fig. 10 presents a linear trend of the economic benefit for the first 45 rounds of exchange. After this threshold is observed how the benefit curve becomes stable in the context of a network size of 1000 peer nodes. When expanding the size to 2000 peer nodes the benefit increases continuously. This is explained by the fact that for a network size of 1000 peer nodes all the exchanges happen within

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

Fig. 10. Simulating the economic benefit at different network sizes.

Fig. 11. Simulating the economic benefit for different views of peers.

45 rounds of exchange. For 2000 peer nodes, the system performs further exchanges, and consequently the benefit grows up. Experiment 8: The economic benefit when the system experiences different views of peers. The view parameter is specified in the configuration file and it represents the number of proximate traders assigned for each peer node. Fig. 11 illustrates the level of benefit in the context of different views of peers. The experiment proves that the number of potential traders can be an important factor for the economic benefit. It is observed how the benefit increases when the view of peers is varied from 5 peers in view to 20 peers in view. Experiment 9: The economic benefit when the system uses different number of SLAs. This experiment tries to show that a higher number of SLAs (trading objects) induces a higher level of benefit within the system. Fig. 12 emphasises the increase in benefit when the number of SLAs is increased from 30 to 50. It is also observed that the system needs 50 rounds of exchange in order to consume all the SLAs that are scheduled to be exchanged. After 50 rounds of exchange, the level of benefit becomes stable. 5.3. Welfare at different demand levels This simulation consists of three different SLA operations (see Fig. 1): SLA issuing, SLA forwarding, and SLA redemption. The

1323

Fig. 12. Simulating the economic benefit for different numbers of SLAs.

system works with a specific number of peer nodes. Each peer node pi can provide one or more services si of type ti . A type in this instance can belong to a particular kind of storage, a particular configuration of a computational resource, etc. A particular type can also map into an aggregation of services; i.e. a combination of storage and computation can refer to a given type, for instance. By using types, we are therefore able to better represent the matchmaking process between requests and offers from clients and providers. The simulation works with a set P of peer nodes, P = {p1 , p2 , p3 , . . . , pn }, and a list of types, T = {t1 , t2 , t3 , . . . , tm }, where ti represents the type of service that a set of peers Pj = {p1 , p2 , p3 , . . . , pk }, (Pj ⊂ P ) can deliver during the exchange. A view parameter indicates how many peers are requesting a particular type of service at a given point in the simulation, and reflects the overall demand within the system. It is important to note that one peer node can support only one service type at any point in time (see Fig. 2). To support demand manipulation, where new requesting peers need to be added to the P2P system, the environment must be designed as a large dynamic network. Simulation in PeerSim is controlled through Java objects that can be scheduled for execution at certain points. These controllers typically initialise, observe, or modify the simulation. The initialisation phase is carried out by control objects that are scheduled to run only at the beginning of each experiment. In the configuration file, the initialisation is undertaken using a Scheduler object which identifies the simulation cycles, and when they are executed exactly. This object can also be used to configure a protocol or be executed in specific simulation cycles. It is also possible to control the order of execution of the components within each cycle. 5.3.1. Variation in SLA value The value of an SLA can fluctuate over time depending on the level of demand introduced into the system, a configuration parameter in the experiment. It is assumed that the level of demand is based on the number of peers requesting a specific service type, referred to as view. The fluctuation process is triggered when the number of peers requesting one SLA type is modified. Our framework is designed to modify the value of an SLA when new requesting peers are added to the system in the view of each participating node. Algorithm 3 presents the logic behind the SLA value fluctuation. The SLA values of one specific type is mapped in accordance

1324

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

Algorithm 3 Changing demand within the system 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:

for all i = 0; i < networksize; i + + do for all j = 0; j < SLAtypes; j + + do if view[j] > 0 then σ = nextDouble(view/100); value[i][j] = value[i][j] + σ ; end if age[i][j]=ttl-startcycle[j]; ϵ = nextDouble(1 − age/100); value[i][j] = value[i][j] − ϵ ; end for end for

with a demand level: V .typeci+1 = V .typeci ∗ f (d), where ci represents the ith cycle of the simulation. The demand is based on the view parameter assigned to each peer node offering a service of type ti as a set Pi consisting of {p1 , p2 , p3 , . . . , pk } indicating the number of peers requesting a specific service. In particular, the level of demand is varied by changing the view parameter assigned to a specific type of service. During the exchange, an SLA associated with a service of a given type can have an increase in value of σ , when the view parameter assigned for the nodes exchanging that type is continuously increased (view≫1). The decay in value for one SLA type is programmed as a continuous process that reduces the value of SLAs according to their ages. In Algorithm 3, nextDouble() is a method returning a value that is proportional to the view and ttl parameters. For this particular investigation, the PeerSim simulator uses separate source files for programming different needed controllers of the simulation process. In particular, our framework uses three different controllers. The first controller, controller1, defines the number of SLA types scheduled to be used during the simulation; the second controller, controller2, defines the network variation for each simulation cycle (e.g. how the size changes when injecting new peers) for each round of exchange. The last controller (controller3) is the observer that collects the results for each experiment. 5.3.2. Demand configuration Our framework is designed to handle demand as an economic process that can induce fluctuation for the value of exchanged objects. For simulating the variation of demand within the market, our framework uses several assumptions. Therefore, one specific level of demand is simulated by using one view parameter. The view is assigned to each node within the system. The view of any one peer is independent of other peers in the system. This parameter is adjusted (increased or decreased) during each cycle of simulation. A default value of 1 identifies the case of a regular (stabilised) demand, with no change in the value of an SLA. The variation of the demand was ensured by PeerSim controller2 (see Section 5.3), which can inject different numbers of requesting nodes at each simulation cycle. The following configuration parameters are used by this controller:

• • • • • •

control.c1 peersim.dynamics.DynamicNetwork control.c1.maxsize vmax control.c1.add vadd control.c1.step vstep control.c1.from vfrom control.c1.until vuntil

The DynamicNetwork is a module provided within PeerSim which helps the simulation process to work with a differing number of peer nodes at each simulation cycles. It includes various Java packages initialising a network or modifying it during simulation. It can also be used to model node churn. The maxsize

parameter represents the maximum number of peer nodes that one simulation process can use; the add parameter defines the number of peer nodes injected at each step. The step parameter defines the stage of exchange (i.e. creation/issuing, forwarding, or redemption) for each injected peer node. The parameter from specifies the starting number of peer nodes to simulate, while the until parameter defines the maximum limit on the number of peer nodes that the simulation can use. 5.3.3. Welfare calculation The value of an SLA is varied based on the level of demand injected into the system during different stages of exchange. In order to determine how the demand influences the status of the system, a ‘‘welfare’’ was introduced as a parameter for reflecting the value benefit observed by each peer over time. Within a set of peers P = {p1 , p2 , p3 , . . . , pn }, bi ∈ B is the budget of one peer node at a specific time (simulation cycle ci ). The concept of a budget was introduced to provide a base line for comparison, in order to determine how well a particular peer had performed (in terms of revenue generated) during the simulation. It is important to note that by default the system loads an initial budget distribution for all peer within the system, identified as the set B = {b1 , b2 , b3 , . . . , bn }, where bi is the budget of pi . After different stages of exchange, the initial budgets are updated according to the level of demand that the system is initially configured with. If, by default, the peer node pi is assigned with an initial budget bi after several exchanges, pi can have an updated budget bu = bi + δ , where δ is the budget variation (profit or loss) determined by the variation in the value of directly or indirectly provided (SLAs) that it has sold. Therefore, the system distinguishes two different sets of budgets: (1) the initial one, Bi = b1 , b2 , b3 , . . . , bn , and (2) the updated one, Bu = b1 , b2 , b3 , . . . , bn , both reflecting a specific level of welfare but at different stages of exchange. The welfare parameter W is a sum of the updated budgets that the system records at a specific simulation cycle. The welfare is calculated for each simulation cycle by summing the updated budgets of each peer node within the system: W =

n 

bi ,

i=1

where n represents the number of peers monitored from the beginning of the simulation and bi is the updated budget of peer pi at cycle cj . 5.3.4. Results For the current analysis, we use an unstructured P2P architecture with peers operating services in the network. Each peer can support one service that has a number of associated parameters. Services are delivered on the network on the basis of established SLAs among peers. We consider that every node holds a service distribution and it is linked with other nodes building virtual organisations. Each peer has a (i) predefined structure of links to neighbours, (ii) a budget limit. Our algorithm uses a pay-before-use payment scheme. This means that every service delivery implies an advance payment. The experiments are used to analyse the effect of demand and SLA value fluctuation on the overall welfare of a P2P community. The system uses different SLA types with different configurations of demand. Each experiment presents the welfare distribution in the context of different levels of demand assigned for each SLA type. The simulator is scheduled to work with an adjusted number of requesting peers for each simulation cycle. Each experiment uses a specific number of SLA types t1 , t2 , t3 , . . . , tn and one specific demand level view of peers requesting one type ti .

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

Fig. 13. Welfare distribution when demand is varied from 20 peers in view to 10 peers in view for each ti type.

1325

Fig. 15. Welfare distribution using different numbers of SLA types.

trading would have led to a decay in the value of SLAs held by the peers, and therefore a reduction in welfare. Experiment 2: The welfare distribution when the demand uses 10 peers in view for each ti type (for i = 2, 10) and the view for t1 is changed from 20 to 15 peers. The experiment uses a maximum of 10 issuing nodes and a maximum of 10 SLAs per node. We can observe in Fig. 14 how the overall system reacts when the demand for t1 uses 20, respectively 15, requesting peers and the demand for each of the remaining types ti is set to 10 requesting peers. The welfare changes as a direct consequence of the fluctuation in the value of a particular type t1 . This experiment verifies that the welfare can be modified (in our case increased) even when only one of the types (t1 ) has an increase in the level of demand.

Fig. 14. The welfare distribution when the demand uses 10 peers in view for each ti type, and the view for t1 is changed from 20 peers to 15 peers.

Different experimental scenarios are provided to demonstrate how the market mechanism of supply and demand induces fluctuation in the value of SLAs. These scenarios show how the system reacts to various demand configurations and types of service being made available in the market. On the other hand, the calculation of welfare enables us to measure how budgets for various peers in the system evolve during the exchange, thereby illustrating the economic status of each individual peer node as well as the overall status of the system. Experiment 1: The change in welfare distribution when the demand is varied from 20 peers to 10 peers in view for each ti , i = 1, 10. This experiment uses a configuration with a maximum of 10 issuing nodes and a maximum of 10 SLAs per node. Fig. 13 presents the variation of welfare for 100 simulation cycles. In order to map a specific demand level, the view for each peer type is set to 20 requesting peers. The experiment shows how an increase in the value of an SLA impacts the level welfare for different simulation cycles. The increase of demand attenuates the effect of welfare growth at approximately 60 cycles. With a demand (view) of 20 peers for each trader (issuer or forwarder), the SLAs gain in value, and hence the welfare increases. After 60 cycles, the welfare curve becomes stable as there are no SLAs being exchanged within the system. This experiment demonstrates how welfare is influenced by an increase in trading between peers. No

Experiment 3: The welfare distribution when the system works with different number of SLA types. The experiment is configured to use a maximum of 10 issuing nodes and a maximum of 10 SLAs per node. This experiment presents the welfare distribution when the demand is configured at 10 requesting peers for each ti , i = 1, 10, in the context of 5, respectively 10, SLA types. By keeping the demand at the level of 10 requesting peer nodes, the experiment demonstrates that homogeneity (a diversity in the supported types) represents an important factor for one local system. Fig. 15 demonstrates that, when demand varies, the system records a higher level of welfare when using fewer SLA types. With this experiment, we validate the hypothesis that the status of an economy trading SLAs is related to the types of product that are exchanged. Experiment 4: The welfare distribution when the system works with different execution probabilities. The execution probability (see Algorithm 1) is used to control the transition between the issuing and the forwarding process. The experiment is configured to use a maximum of 10 issuing nodes and a maximum of 10 SLAs per node. The demand is configured to 20 requesting peers for each ti type, i = 1, 10. As Fig. 16 illustrates, a variation in the execution probability can induce new level of welfare. It can be seen how a higher value for the execution probability determines the level of welfare within the system. This reaction happens because of the increment in the number of the issuing and forwarding operations. By increasing the value of the execution probability from 0.25 to 0.30, a greater exchange takes place, with a demand of 20 requesting peers for each SLA type. This reaction is caused due to the higher variation in the value of an SLA, and therefore a great incentive for clients to buy.

1326

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

Fig. 16. Welfare distribution using different execution probabilities.

6. Future work Complementary currency systems have been analysed by related studies from the prospective of different strategies that a peer can apply during the exchange. Various strategies can be identified at the peer level in the context of untrusted peer-to-peer exchanges.

• Maximising social welfare in reselling actions. • Profit maximisation when peers behave selfishly and try to maximise their profit from reselling, arbitrage, or hedging.

• Satisfying demand by buying the cheapest SLAs. • Increasing the size of the trusted network by purchasing

client may decide to trade this on an open market to recover some of its loss, or make a profit (if the demand for the service identified in the SLA increases after issuing). Using simulation, we demonstrate that system benefit is influenced by the number of participants, the level of demand, and the type of SLA used. The experiments show that the view of peers (i.e. how many partners a peer can trade with), as a configuration parameter, induces benefit. Further, it was demonstrated that the system experiences a level of benefit directly related to the SLA submission interval, indicating that a higher circulation (i.e. lower submission interval) in the system improves overall benefit. On the other hand, starting from the assumption that demand plays a major role in the welfare determination, we analyse the problem of fluctuation in SLA values over time. Therefore, we present the welfare level in the context of different demand configuration in order to expose the dependency between the demand of services and the system status in terms of welfare. We also discover that the heterogeneity of types (products) can represent an important factor that can induce new levels of welfare. It was also confirmed that the number of exchanged SLAs can be the cause for a variation in system welfare variation as the overall fluctuation of values is closely related to the level of welfare. Acknowledgements We acknowledge support of the Romanian National Authority for Scientic Research under the project IDEI_2452. Ioan Petri acknowledges support by the Sectorial Operational Programme Human Resources Development, Contract POSDRU 6/1.5/S/3: Doctoral studies: through science towards society ’’.

forwarded SLAs that originate from unknown providers. As peers can have different unpredicted behaviours which can reduce the overall benefit of the system, the following actions have been proposed [16]: (i) Elimination—Always try to use an SLA that a (trusted) partner peer has issued if there is one; (ii) Stretch— Always try to receive an SLA whose chain of endorsement is longer than those of others; (iii) Matchmaking—Prefer selecting a partner among the issuers of acquired SLAs; (iv) Forwarding— Always try to use an SLA whose loss of value will be greater than those of others if not used at the present time; (v) Deferring— Always try to avoid using an SLA against its issuer if the variance of its value over time has not stopped. Identifying specific behaviours in untrusted peer-to-peer exchanges and associated strategies addressing these behaviours will be discussed in a future study. 7. Conclusions This study identifies how an SLA can be used as a complementary currency (exchangeable token) between participating nodes within a P2P network. As an SLA represents provisioning that must take place in the future, an SLA may be circulated within a community of trusted peers. This may occur either because a peer speculates that the capability offered by another peer may be at a higher demand at some time point in the future, or if a peer no longer needs the capability that it requires from another peer (but for which an SLA has already been generated). Trusted, in this context, implies that any client within the domain can redeem the SLA, and not necessarily the initiating peer. SLAs may also be used in this way by brokers for aggregating capacity from various peers within a network. In a pay-before-use model, the client has already paid the provider for the capability it has identified in the SLA. Therefore, rather than make an economic loss by abandoning the SLA, a

References [1] Silvio Gessel, The Natural Economic Order, The Free Economy Publishing Co., 1913, Also available at: http://www.appropriate-economics.org/ebooks/neo/ neo2.htm (last accessed: June 2010). [2] Kenji Saito, Eiichi Morino, Local production, local consumption storage economics for peer-to-peer systems, in: Proceedings of the 2008 International Symposium on Applications and the Internet, IEEE Computer Society, 2008. [3] Fritz Schwarz, Das experiment von Wärgl, 1951. Available at: http:// userpage.fu-berlin.de/roehrigw/woergl/ (Shortened English Translation by Hans Eisenkolb is available at: http://www.sunshinecable.com/eisehan/ woergl.htm (last accessed: June 2010). [4] Sidonie Seron, Local exchange trading systems 1—creation and growth of LETS. Available at: http://www.gmlets.u-net.com/resources/sidonie/home.html (last accessed: July 2010). [5] Paul Glover, Ithaca Hours. Available at: http://www.ithacahours.com. [6] K. Saito, i-WAT: the Internet WAT system—an architecture for maintaining trust and facilitating peer-to-peer barter relations, Ph.D. Thesis, School of Media and Governance, Keio University, February 2006. [7] A. Komarov, Geek Credit. Available at: http://home.gna.org/geekcredit/. [8] R. Fugger, Money as IOUs in social trust networks and a proposal for a decentralized currency network protocol, 2004. Available at: http://ripple.sourceforge.net/. [9] Landon P. Cox, Brian D. Noble, Samsara: honor among thieves in peer-to-peer storage, in: Proc. of 19th ACM Symposium on Operating Systems Principles, ACM Press, 2003, pp. 120–132. [10] Watsystems homepage. Available at: http://www.watsystems.net,. [11] Kenji Saito, Eiichi Morino, Jun Murai, Incentive-compatibility in a distributed autonomous currency system, in: AP2PC, in: LNCS, vol. 4118, Springer, 2005, pp. 44–57. [12] Kenji Saito, Eiichi Morino, Jun Murai, Multiplication over time to facilitate peer-to-peer barter relationships, IEEE Computer Society Press, 2005, DEXA Workshops, pp. 785–789. [13] Kenji Saito, Eiichi Morino, Jun Murai, Reduction over time: easing the burden of peer-to-peer barter relationships to facilitate mutual help, in: Computer Supported Activity Coordination, INSTICC Press, 2005, pp. 28–37. [14] Tim Moreton, Andrew Twigg, Trading in trust, tokens, and stamps, in: Proc. of the First Workshop on Economics of Peer-to-Peer Systems, 2003. [15] Kenji Saito, WOT for WAT: spinning the web of trust for peer-to-peer barter relationships, IEICE Trans. Commun. 88 (2005) 1503–1510.

I. Petri et al. / Future Generation Computer Systems 28 (2012) 1316–1327

Omer F. Rana is Professor of Performance Engineering in School of Computer Science & Informatics at Cardiff University and Deputy Director of the Welsh e-Science Centre. He holds a Ph.D. in ‘‘Neural Computing and Parallel Architectures’’ from Imperial College (University of London). He has worked in industry, as a software developer at Marshall BioTechnology Limited and then as an advisor to Grid Technology Partners. His research interests extend to three main areas within computer science: problem solving environments, high performance agent systems and novel algorithms for data analysis and management.

[16] Kenji Saito, Eiichi Morino, The brighter side of risks in peer-to-peer barter relationships, Future Gener. Comput. Syst. 26 (2010) 1300–1316. Elsevier Science Publishers B.V. [17] Jorim Schraven, Mutual credit systems and the commons problem: why community currency systems such as LETS need not collapse under opportunistic behavior, International Journal of Community Currency Research IJCCR 5 (2001) Available at: http://www.geog.le.ac.uk/ijccr/. [18] Beverly Yang, Hector Garcia-Molina, PPay: Micropayments for Peer-to-Peer Systems, ACM Press, 2003, pp. 300–310. [19] Antoine Pichot, Oliver Wäldrich, Wolfgang Ziegler, Philipp Wieder, Dynamic SLA negotiation based on WS-agreement, in: Proceedings of WEBIST, vol. 1, 2008, pp. 38–45. [20] Márk Jelasity, Alberto Montresor, Gian Paolo Jesi, Spyros Voulgaris, The peersim simulator. Downloadable at: http://peersim.sf.net.

Ioan Petri graduated from the Faculty of Economics and Business Administration at Babes-Bolyai University of Cluj–Napoca in 2007. He has a Master’s degree in Informational Systems, and currently he is a Ph.D. Student in the Business Information Systems department. His doctoral research in Service Collaborative Systems is developing a framework for supporting the exchange of computational services. He is interested in programming languages, and particularly enjoys using new Java development frameworks.

1327

Gheorghe Cosmin Silaghi is an Associate Professor at the Babes-Bolyai University of Cluj-Napoca, Romania. He received a Bachelor degree in Business Information Systems in 2000 and his Engineering degree in Computer Science in 2002. In 2002, he received his M.Sc. in Artificial Intelligence from Free University of Amsterdam. G.C. Silaghi completed his Ph.D. in 2005. He joined the BabesBolyai University in 2000 and currently he is the Head of the Business Information Systems department. His current research interests are focused on resource management techniques in untrusted distributed environments, like peer-to-peer systems.