Catnet Project Review Project participants:  T. Eymann, M. Reinicke Albert-Ludwigs-University, Freiburg (D)  O. Ardaiz, P. Artigas, L. Díaz de Cerio, F. Freitag, R. Messeguer, L. Navarro, D. Royo Technical University of Catalonia, Barcelona (ES) IST-FET-Open Assessment project:  26 mm, 100K€  Contract no.: ITS  1 year: March

Review Agenda 1. Motivation 2. ALN Background 3. Economic background 4. Overview of the Work done 5. Simulation overview 6. Simulator 7. Methodology 8. Experiments 9. Conclusions

Review objectives Present work we have done during this assessment project Get scientific recommendations for future work Get support for submitting a full proposal

Motivation CatNet Review Meeting Barcelona, April 25th, 2003

The future heads to Utility computing:  On-demand computing and services  require dynamically/real-time/on-the-fly provisioned resources  Demand cannot be planned in advance  A complex and large market of services and resources. Convergence of Grid, P2P and Web Services

A Future Application Scenario How to match clients and services in a utility network? (MS Word) service clients Acrobat PDF converter service providers

Centralized vs. Decentralized Approaches

Centralized Approaches Employ a centralized coordinator, who matches clients and service providers according to some optimization rule Examples  Globus and the Nimrod-G extension (simulation possible using GridSim) Global coordination explicitly achieved by coordinator

(Buyya 2003, p.4)

Cast of Characters Node Network Layer Client Resource SC MSC Middleware Application Resource Request service With centralized message flow

Decentralized Approaches Clients select service provider from received responses according to some local optimization rule Examples  Peer-to-Peer Networks, e.g. Gnutella Optimization rule applied by human user Catallaxy approach: Local economic optimization leads to global coordination

Cast of Characters Node Network Layer Client Resource SC Middleware Application Resource Request service With decentralized message flow

Goal of the Assessment Project Compare performance of centralized vs. decentralized approach by simulation  Using an easy simulator implementation  Using a hypotheses-based framework Check feasibility of „Full Project“ proposal If decentralized approach outperforms centralized approaches  for creating generic „Catallactic“ middleware for Application Layer Networks

ALN background CatNet Review Meeting Barcelona, April 25th, 2003

ALN Background Aplication Layer Networks Programmable Infrastructures for ALN Resource Allocation Problem Related work, Resource Allocation in Grids and P2P

Application Layer Networks ALNNodes: Application Server Links: TCP Virtual Circuits Web Proxy Caching HierarchySquid ServerParent-Child Conn. Chat Server NetworkIRC serverchannel distribution conn.

ALN deployment on a Programmable Infrastructure Motivation: ALN have dynamic demands -> Need to be deployed to adapt to changes. Deployment Requirements: 1.Programable Infrastructure: Nodes with BW, Storage & Processing Resources. 2.Deployment Mechanisms: Resource Allocation Algorithm, ….

Application Deployment Example Web Proxy Caching Hierarchy: 6 servers each requires 1 Mbits net capacity, 200 Mbytes Storage, Demand Regions: A,B,C,D,E Programmable Infrastructure: 30 nodes each 10 Mbit net capacity, 2 GByte Storage Resource Allocation Algorithm

Resource Allocation Problems Centralized RA is computationally intensive (and a single point of failure). And it will get worse:  Very Dynamic Infrastructures (Nodes come and go frequently): dial up nodes, mobile nodes,...  High Node Density Infrastructures (Many nodes with little resources): pervasive computing,.. Solution Requirement:  Decentralized autonomous RA.

Related Work: Resource Allocation in Grids Grids are programmable infrastructures for Computationally intensive apps. (demand CPU resources). Grids RA: Condor-G, DMR-broker:  centralized heuristic based dispachers. Nimrod-G Broker:  centralized budget constraint sheduler. DataGrid OptorSim:  centralized economic based optimizer.

Related Work: Resource Allocation in P2P systems P2P - Grid:  [Foster et al, IPTP03]: P2P are Grids with thousands of resource nodes, but only 1 service: file transfer, datamining,... P2P RA:  [ Gu et al, HPDC 2002]: simulated n-hop service aggregation in P2P

Economic Background: the Catallaxy CatNet Review Meeting Barcelona, April 25th, 2003

Application Observations on Decentralized Networks Grid Nodes Mobile Devices Networked Household Appliances Resource Networks Smart Chips Ubiquitous Computing Technology

Application Communication Cooperation Application Services Network Services Physical Services Observations on Decentralized Networks Common Properties (1) Individually owned (mobile) autonomous devices with access to open, decentralized networks

Application Communication Cooperation Application Services Network Services Physical Services Observations on Decentralized Networks Common Properties (2) Messaging using SOAP instead of RMI Individually owned (mobile) autonomous devices with access to open, decentralized networks

Application Communication Cooperation Application Services Network Services Physical Services Observations on Decentralized Networks Common Properties (3) Exchanging Property Rights for Utility Maximization Negotiation/Messaging vs. Commands/Method Invocation Individually owned (mobile) autonomous devices with access to open, decentralized networks

Application Communication Cooperation Application Services Network Services Physical Services Observations on Decentralized Networks Selected Application Domains Service Webs P2P Storage & Collaboration Mobile Commerce Exchanging Property Rights for Utility Maximization Negotiation/Messaging vs. Commands/Method Invocation Individually owned (mobile) autonomous devices with access to open, decentralized networks

Application Observations on Decentralized Networks Implementing Coordination (1) Economic Processes, e.g. Distributed Resource Allocation, Multi-Commodity Flow Problems Communication Cooperation Application Services Network Services Physical Services Negotiation/Messaging vs. Commands/Method Invocation Exchanging Property Rights for Utility Maximization ? Individually owned (mobile) autonomous devices with access to open, decentralized networks

Application Observations on Decentralized Networks Implementing Coordination (2) Economic Processes, e.g. Distributed Resource Allocation, Multi-Commodity Flow Problems Communication Cooperation Application Services Network Services Physical Services Negotiation/Messaging vs. Commands/Method Invocation Exchanging Property Rights for Utility Maximization Individually owned (mobile) autonomous devices with access to open, decentralized networks Coordination A mechanism to resolve interdependencies between participants sharing resources

Implementing Markets A market is a mechanism to resolve interdependencies between participants and to allocate resources in economic theory  Market as the abstract point of matching supply and demand, as opposed to “marketplace” or “market platform”  Result is market clearance, supply and demand are satisfied  Evaluation Criteria Utility of all participants is maximized: Social Welfare Utility No participant can get a better result without another losing utility: Pareto Optimum But the market mechanism is not fully understood, so how to implement it in a technical environment?  Computable General Equilibrium (“top-down”) Rooted in Neo-Classical Theory, Walras “tâtonnement process”  Agent-Based Computational Economics (“bottom-up”) Neo-Austrian Economics, Evolutionary Economics, Adam Smith’s “invisible hand”, Hayek’s “spontaneous order”, Walras’ “non-tâtonnement process”

How to implement a “market”? (1) The „market“ as a decentralized, dynamic coordination mechanism WALRAS‘ian Auctioneer Multiagent systems Economic Concept Technical Implementation just distribution of utility by a central arbitrator decentralized action of utility-maximing agents using a central auctioneer direct agreement between negotiating agents

How to implement a “market”? (2) The „market“ as a decentralized, dynamic coordination mechanism Multiagent systems Economic Concept Technical Implementation Market-Oriented Programming WALRAS‘ian Auctioneer MISES/HAYEK‘s Catallaxy decentralized action of utility-maximing agents using a central auctioneer direct agreement between negotiating agents Nimrod-G

How to implement a “market”? (3) The „market“ as a decentralized, dynamic coordination mechanism WALRAS‘ian Auctioneer Multiagent systems Economic Concept Technical Implementation MISES/HAYEK‘s Catallaxy Market-Oriented Programming Catallactic Information Systems

Catallaxy Catallaxy is an alternative word for „market economy“ (coined by Mises and Von Hayek of the Neo-austrian economic school) “Fundamentally, in a system in which the knowledge of the relevant facts is dispersed among many people, prices can act to co-ordinate the separate actions of different people in the same way as subjective values help the individual to co-ordinate the parts of his plan.” (Friedrich A. von Hayek, The Use of Knowledge in Society, 1945) An economic metaphor for complex adaptive systems (CAS)  Coordination and a stable environment are emergent features of the market  Pursuing local goals alone already stabilizes and coordinates the system  Economist Research: Agent-Based Computational Economics

Catallaxy Characteristics Software agents act selfish, because their human owners do: Competition is the norm. Software agents keep their utility function private: If made public, the agent can be exploited. Software agents communicate directly: Centralized control institutions can always be bypassed. Cooperation is always pareto-eliciting (increases utility of all participants) No free lunch: everyone has a utility function (business model), even centralized institutions Information is not free or public (every participant operates on private knowledge and subjective private values) Utility is the difference between transaction price and private value

Example: CatNet Clients negotiate with Service Copies (SC)  Goal of Client is to buy service access for the lowest price  Goal of SC is to sell service access for the highest price Node Network Layer Client Resource SC Middleware Application Resource Request service

Application Coordination Communication Cooperation Application Services Network Services Physical Services The Negotiation Protocol and the Goal Function Negotiation Protocol: Monotonic Concession Protocol, based on Alternating Offers between Buyer and Seller Goal Function: maximize the spread between input and output prices

Principles of Software Agents Environment, e.g. Market Agent Sensor, e.g. received offers Effector, e.g. sent offers (Intention: increase own utility) Reasoning, e.g. calculation of a counter-offer using heuristics (may become arbitrarily complex, e.g. AI)

Negotiation Protocol - Example Buyer Seller cfp (service access) propose (service access, p S =$24) propose (service access, p B =$18) propose (service access, p S =$21) accept-offer(service access, p B =$21) commit (service access, p S =$21) time Client SC

Application Coordination Communication Cooperation Application Services Network Services Physical Services Heuristic-Adaptive Reasoning: Parameters Negotiation Strategy: Achieving utility maximization setting e.g. concession rate, concession amount, time pressure in relation to market (and the transaction partner). Concession Probability Continuation Probability Concession Amount Market Price Learning Weight Mark-up

Heuristic-Adaptive Reasoning: Example for a Seller (1) propose (service access, p S =$24) Update Market Price Valuation propose (service access, p B =$18)

Heuristic-Adaptive Reasoning: Example for a Seller (2) Should I leave the negotiation? propose (service access, p S =$24) propose (service access, p B =$18)

Heuristic-Adaptive Reasoning: Example for a Seller (3) Should I leave the negotiation? Should I make a concession? reject Yes No propose (service access, p S =$24) propose (service access, p B =$18)

Heuristic-Adaptive Reasoning: Example for a Seller (4) Should I leave the negotiation? Should I make a concession? What amount should I concede? reject propose (service access, p S =$24) Yes No Yes propose (service access, p S =$24) propose (service access, p B =$18)

Heuristic-Adaptive Reasoning: Example for a Seller (5) Should I leave the negotiation? Should I make a concession? reject propose (service access, p S =$24) propose (service access, p S =$21) propose (service access, p S =$24) propose (service access, p B =$18) Yes No Yes „costs of life“ (tax) will be deducted in discrete time slots

Heuristic-Adaptive Reasoning: adaptation by evolutionary learning Send „plumage“ (  profit x, Genotype x )     profit 1 Genotype 1  profit 2 Genotype 2  profit 3 Genotype 3  profit 4 Genotype 4 Create agent (Genotype  Genotype 1 ) select Genotype (  profit x )

Preliminary Results Catallaxy works in a small scale for a multiagent system simulation (B2B- OS)  (Demonstration possible if time permits)  Coordination can be achieved emergently without a central coordinator (auctioneer) if the software agents reason in an economical sense about alternative actions implement feedback learning and adapt reasoning and price-setting strategies Further research from here  Evaluate approach in different application domains and network technologies (  CatNet)  Construct Institutions to control and secure open multiagent system environments (  reputation tracking, emergent norms)  Formalize approach (  Agent-Based Computational Economics)  Optimize heuristics and learning mechanisms

Hypotheses on using Catallaxy Catallaxy should  Be more scalable than a centralized coordinator Because all computation is decentralized  Be more flexible Because all actions are based on local knowledge only Because agents are able to adapt strategies  Use more bandwidth Because negotiations need more communication  Grow better results over time Because agents begin with inferior results and then adapt Optimal results may only be reachable in static scenarios

Baseline shows stable results

Catallaxy shows development over time

What can it be used for?  Application areas where a centralized marketmaker is impractical or not feasible trade items are commodities, interactions are numerous  Examples are Distributed resource allocation problems like e.g. markets for communication bandwidth, computational resources, natural resource exchanges, low-value procurement markets Multi-commodity workflow, e.g. agile/holonic manufacturing, telecommunications network routing, supply network coordination  Systems implementing this concept could be called Catallactic Information Systems (cf. Hayek’s Catallaxy)

Overview of the Work done CatNet Review Meeting Barcelona, April 25th, 2003

Objective of the project Objective: Evaluation of a decentralized mechanism for resource allocation, based on economic paradigm: Catallaxy.  (compare against a centralized mechanism using an arbitrator object) Methodology: Simulation

Persons and Institutions Institutions:  Albert-Ludwigs-Universität Freiburg, Institute for Computer Science and Social Studies (UF-IIG).  Technical University of Catalonia (UPC), Computer Architecture Department (DAC). Persons involved in the project:  UF-IIG: Torsten Eymann, Michael Reinicke.  UPC-DAC: Oscar Ardaiz, Pau Artigas, Luis Diaz, Felix Freitag, Roc Messeguer, Leandro Navarro, Dolors Royo.

Project Coordination & Management Collaborative Work with BSCW Code development using CVS Project meetings and research stays in Barcelona and Freiburg.

Project Development Simulator (WP1) Coordination mechanism (WP1) Application scenarios & measurement & simulations (WP2) Performance evaluation (WP3) Catallaxy evaluation (WP3)

The Catnet simulator (WP1) Agents  Client: computer program at host, requests service  Service Copy: instance of service, hosted in a resource computer  Resource: host computer with limited storage and bandwidth.

Coordination mechanisms (WP1) Messaging Protocol  Catallactic coordination  Baseline coordination Agent Strategy Strategy request(..,...,...) decision

Application scenarios: Mapping applications into a two-dimensional design space. Measurement: Criteria: Social Welfare, Resource Allocatio Efficiency, Response Time, Communication Cost Simulations: Base experiment and sensitvity experiments. Application scenarios, measurement & simulations (WP2) X 1... x n (density, dynamics, constants) dens. parameter dyn. dens.

Performance and Catallaxy Evaluation (WP3) Experimental results: Catallactic & Baseline model  Per scenario (indiv., design space)  Per criterion (SWF, RAE, REST, CC,...)  Sensitivity experiments

Project dissemination Participation in Workshops and Conferences  communities: MAS, Grids, P2P, Complex Systems Publication of papers  CatNet – Catallactic Mechanisms for Service Control and Resource Allocation in Large Scale Application-Layer Networks. Workshop on Global and Peer-to-Peer Computing on Large Scale Distributed Systems, 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid, May 2002, Berlin, Germany.  Decentralized vs. Centralized Economic Coordination of Resource Allocation in Grids. 1st European Across Grids Conference, February 2003, Santiage de Compostela, Spain.  Exploring decentralized resource allocation in application layer networks. Agent-based Simulation 4, April 2003, Montpellier, France.  Decentralized resource allocation in application layer networks. Workshop on Agent based Cluster and Grid Computing. 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid, May 2003, Tokyo, Japan.  2 more under review Project Webpage:

Project findings (summary) Catallactic coordination: + SWF, RAE - CC, REST + smooth performance + can solve complex system abstraction level Math. Simulation SW CATNET Real Application

Conclusions Development of the experimental simulator with Catallactic and Baseline mechanism. Simulation of Catallactic and Baseline coordination in different scenarios. Evaluation of the Catallactic coordination mechanism.

Future Work Catallactic coordination works and has robust performance in dynamic environments /2003 Catallactic prototype implementation in middleware service layer: Economic reasoning MAS Design and system characteristics of catallactic networks: Interface computer networks & economics

Simulation Overview WP2 CatNet Review Meeting Barcelona, April 25th, 2003

Simulation of ALN CDN P2P GRID A few, powerful A lot, modest Fixed networks Mobile, ad - hoc, overloaded networks Stable Changing node density node dynamics lowmediumhigh medium high CDN P2P GRID In an “abstract” simulator ALN

Configuration of simulator Dynamics  Connection and disconnection of SC Density  Number of Resources and ServiceCopies Total capacity of Resources is constant  Same amount of R / #resources Input: demand trace Initial conditions:  Initial budget, prices  Control mechanism, parameters

Parameters to measure Social Welfare (SWF):  Global figure: sum of utilities over all participants. Response Time (REST):  time observed by the client to get a service. Resource allocation efficiency (RAE):  ratio of service demands, for which the network provides a service to all sent service demands. Communication cost (CC):  number of hops used by the control messages. Price:  evolution of prices in the network during the simulation. Client-Resource assignment:  number of hops between a Client and Resource once a successful service provision is achieved.

Configuration of simulator Tcl scripts to set-up  physical network topology  application layer network  service demand Nucleus of the simulator in Java code  Client, Resource, ServiceCopy, MasterSC, strategy, Message, … Simulation infrastructure is JavaSim  Node, packet, link, …

Experiments Template of:  Input:  Topology:  Parameters:  Results:  Graphics:  Observations: Log files (monitor class) Network level  Nam movies CatNet level  Time series  Aggregated values = “Parameters” Comparison of Several scenarios

Simulator CatNet Review Meeting Barcelona, April 25th, 2003

Simulator - Javasim The Catnet simulator is build over JavaSim, JavaSim is a network simulator based in autonomous components. Javasim models every aspect of a real network: latency, bandwith, lost packets, routing, … It has some of the more common internet protocols like DV, TCP, UDP, … So our components can be easily modified to work in the real world changing the middleware to real sockets.

Simulator - Nodes R Port 101 A network in javasim: C Port 102 SC Port 103 UDP IP Our nodes: - Independent on each other at javasim level - Running as programs with a socket on a computer - Configuration made at startup script A network is composed of: Nodes: they can be routers or end nodes and you can decide the component composition of each node. Links: you can decide the latency and the bandwith.

Simulator - Components Generic behaviour on messages Using generic functions: - Bargain/RecommendedAction - Price management So changing strategies is easy Particular behaviour on some messages

Simulator - Messages InformResourceHost Status RequestService Cfp Reject Proposal Accept Confirm MoneyTransfer ProvideService Plumage

Simulator – Message Flow Baseline

Simulator – Message Flow Catallactic

Simulations - Broadcast It uses a broadcast mechanism with a ttl (time to live) to know the neighbour ServiceCopies.It is called also flooding. Example with a ttl of 3.

Simulator - Topologies This is the topology used for the experiments. There is a Resource in each node, but with different bandwith capacity. There is also a Client in every leave. The ServiceCopies are placed in different positions depending on the density parameter. The MSC is in the center. We used this topology: Easy to configure Easy to verify

Simulator – Alternate Topologies Diameter is bigger More connectivity We tested the simulator against other topologies, and also we modified the link latencies.

Simulator - Parameters Available parameters:  AllocationTime – the time the MSC waits to decide winner.  HopFactor – influence of distance on bandwith price.  MigrationOn – migration of ServiceCopies.  BaselineOn – Baseline/Catallactic.  MSCUpdateTime – time the ServiceCopies wait to send status.  DynamicParameters – initial % off, % change prob., change time.  LearningOff – learning between agents.  StockMarketOn – stock exchange market model.  HopLimit – maximum broadcast hop count (ttl).

Simulator - Values Change propability: 40% Change propability: 20% Change propability: 0% Service Copy

Simulator - Demand Creating demands  Random: # of demands # of serviceIDs Clients Average time betwen demands  Moving (random parameters +): Movement time Movement radius Movement percent

Simulation - Experiments Experiments done:  Normal – the base experiment used for the comparison.  Demand time – changing the demand rate.  MSC Update Time – changing the time that a SC waits to send the status message to the MSC.  MSC Allocation Time – changing the time the MSC waits till it decides the used ServiceCopy from the received “offers”.  Movement – testing a moving demand.  Migration – testing the SC migration feature.  Movement + Migration – testing the SC migration feature against a moving demand.  Hop Factor – changing how the distance affects the bandwith price.

Simulation - Configuration We use TCl to set-up the experiments:  Topology  Node configuration: wich components (C/R/SC/MSC) should be on each node.  Application Layer Network initialitzation  Agent parameters: bandwith, price ranges, money balance, genotype, …  Current experiments parameters

Simulations - Running Each time 18 simulations x number of configurations of the experiment  We used a cluster, using 9 dual PIII 1Ghz  Scripts for: Sending current data to nodes Viewing status Getting results Mixing results in a “spreadsheet-aware” file

Simulations – Data The simulations writes data to a log file and to a DB. DB is for debugging, and the results are recovered from the log. We also generated NAM traces. SC that served Response Time Price Distance between C and R RAE Average distance Average response time RAE Average distance Average response time SWF Communication Cost SWF Communication Cost For each demand For each experiment Computed Final info

Simulator - Graphics

One for each parameter commented before. So we can check the behaviour of any parameter based on the changes on the diferent series.

Methodology CatNet Review Meeting Barcelona, April 25th, 2003

Methodology 1. Select Scenarios 2. Create Hypotheses 3. Select Performance Criteria 4. Evaluate Hypotheses according to Criteria in Scenarios

Scenarios and Experiments Catallactic Baseline = 18 Scenarios in total

Dynamics Node density High (40% changes) Low (0% changes) Low (5 SC)High (75 SC)Medium (25 SC) (_00) (_22) (_10) (_20) Medium (20% changes) (_21) (_11) (_01) (_02) (_12)

Evaluation Criteria Social Welfare  Sum of all utilities over all participants, in a given timespan Clients subjectively value SC access Prices change due to “supply and demand”  Individual utility = transaction price – market value  Clients‘ utility  Service Copies‘ utility  Resources‘ utility

Evaluation Criteria RAE (Resource Allocation Efficiency)  The ratio of matched transactions divided by the number of all proposals: # "accepts“/ #"proposals“ REST (Response Time (Service Access Time))  How long does it take on average to fill a request: time between “cfp” and “accept” CC (Communication Costs)  How much communication is needed until the result: # messages * # hops.

Hypotheses Quasi-static Very dynamic Low node density High node density SWFResource Allocation Efficiency Communication cost Response time ~ C BBB C C C C C C B ~ BBB System

Experiments CatNet Review Meeting Barcelona, April 25th, 2003

Experimental Results: Quasi-static scenario (H1) In a quasi-static scenario using the Catallactic model  (H1.1) the SWF is nearly equal to the results of the Baseline model,  (H1.2) the RAE is slightly less than in the Baseline system,  (H1.3) the REST is slightly longer than in the Baseline system,  (H1.4) the bandwidth utilization is slightly higher than in the Baseline model.

Experimental Results: Highly dynamic scenario (H2) In a highly dynamic scenario using the Catallactic model  (H2.1) the SWF is higher than the results of the Baseline model,  (H2.2) the RAE is higher than in the Baseline system,  (H2.3) the REST is lower than in the Baseline system,  (H2.4) the communication costs are less.

Experimental Results: Low node density scenario (H3) In a low node density scenario using the Catallactic model  (H3.1) the SWF is slightly lower than the results of the Baseline model,  (H3.2) the RAE is less than in the Baseline system,  (H3.3) the REST is longer than in the Baseline system,  (H3.4) the CC are slightly higher.

Experimental Results: High node density scenario (H4) In a high node density scenario using the Catallactic model  (H4.1) the SWF is equal or better than the results of the Baseline model,  (H4.2) the RAE is slightly less than in the Baseline system,  (H4.3) the REST is higher than in the Baseline system,  (H4.4) the CC are lower.

Results Quasi-static Very dynamic Low node density High node density SWFResource Allocation Efficiency Communication cost Response time b c ~ bB b B C b b B b ~ CbB System

Comparing Results to Hypotheses Quasi-static Very dynamic Low node density High node density  Green: confirmed, Red: rejected SWFResource Allocation Efficiency Communication cost Response time ~ C BBB C C C C C C B ~ BBB System

Results by criterion – SWF

Results by criterion - SWF CatallacticBaseline

Results by criterion – RAE

Results by criterion - RAE CatallacticBaseline

Results by criterion – REST

Results by criterion - REST CatallacticBaseline

Results by criterion – CC

Results by criterion - CC CatallacticBaseline

Summary A mixed bag of results  Outcomes different than expected, but concise and repeatable By scenario  Significant differences between scenarios  Middle density scenarios show particular results for Baseline By criterion  Density has a greater effect than Dynamics  REST result shows underestimation of Catallactic communication and reasoning complexity

Sensitivity Experiments Demand Frequency on SWF

Sensitivity Experiments Demand Frequency on RAE

Sensitivity Experiments Demand Frequency on REST

Sensitivity Experiments Demand Frequency on Hop Count

Intermediate Conclusions Sensitivity results are explainable  (REST for Baseline shows repeatable experiment results) Networks behave as expected  Low density and slow demand allow good computation in both mechanisms  High density and high frequent demand pose a scalability problem Check other parameters  MSC Allocation Time for Baseline  Migration of Service Copies for Catallaxy

Sensitivity Experiments – MSC Allocation Time on SWF

Sensitivity Experiments – MSC Allocation Time on RAE

Sensitivity Experiments – MSC Allocation Time on REST

Sensitivity Experiments – MSC Allocation Time on avg. Hops

Sensitivity Experiments – Migration of Supply and Demand Two migration cases add even more dynamics to system  Moving SCs between resources (left)  Moving SCs & oscillating demand queue (right) Caveat:  Different parameter settings than in basic experiments  Migration only for Catallactic experiments (left bars)

Sensitivity Experiments – Migration RAE results are similar to SWF  Allowing migration is better for Catallactic, even more in the moving demand case

Sensitivity Summary Other parameters affect either Baseline or Catallaxy  May change relations on inter-mechanism comparison E.g. MSC Allocation Time even reverses statements on Baseline and Catallactic comparison „Correct“ settings of these parameters should be  Practically, „like in real applications“  Theoretically, such that they have no effect on the outcome  Requires further research and experimentation either by building a practical application Or by creating a more abstract simulation

Soundness of Criteria Interdepencies  SWF and RAE are dependent Every transaction adds to SWF More transactions add to RAE  SWF and CC are dependent Higher CC lowers SWF  SWF and REST are dependent Higher REST means more transactions More transactions add to RAE and SWF SWF captures all costs and revenues Dependencies are an emergent feature of the system  No direct links have been implemented: economic reasoning works „bottom-up“ in an ACE sense

Conclusions CatNet Review Meeting Barcelona, April 25th, 2003

Achievements of the project Developed an experimental simulator to compare different allocation mechanisms in ALN (Grid, P2P) Defined a comparison framework consisting of two dimensions: Dynamics and Density Conducted an experimental evaluation study of two allocation mechanisms

Experimental Simulator Abstracts from a concrete application and implementation. Allows „plug-in“ of different „middleware“ resource allocation mechanisms, Allows easy changes of  decentralized agent strategies or  centralized allocation mechanisms in the MSC. Ability to create Real Applications with little additional work.

Comparison Framework Dynamics and Density explain most changes in the experimental results. It is possible to categorize Grids, P2P, … in that framework. Existing ALN can principally be categorized and evaluated against each other. Allows evaluation of non-technical criteria.

Evaluation Study Initial simulation results show that a decentralized, economic model has some advantages in certain situations.  Improvement is measured as combination of factors (SWF)  Other parameters (REST, CC) can also be studied in detail, but are mostly includable in SWF Practicability depends on concrete network and application  Characteristics of promising applications Large scale network, large number of participants Highly dynamic supply and demand  No statement possible for real existing ALN

Potential Limitations for practical use Currently, no micropayment solution exists. Current ALN do not control problems of tragedy of commons, free riding, oscillatory behaviour. No security models for malicious clients, service providers, malicious resource brokers. Assumption: other research will address these issues, so future work can head either in a …

Future Research Directions for CatNet Practical Direction  Build middleware in „real“ Grid With realistic setting of „constant“ parameters, „real“ topology In comparison to the „real“ centralized resource broker Increases practicability of statements  FET Global Computing Theoretical Direction  Build more abstract simulation Increase theoretical understanding by formal approach Get rid of implementation and topology restrictions  FET Complex Systems

Future Work Catallactic coordination works and has robust performance in dynamic environments /2003 Catallactic prototype implementation in middleware service layer: Economic reasoning in Grids Design and system characteristics of catallactic networks: Interface computer network theory & Economics

Theoretical: Catnet++ Course of Work  Create more formal description of both allocation mechanisms  Restrict simulator functionality and parameters  Make assumptions on missing parameters  Investigate shortcuts to potential limitations for Catallaxy Monopolies, Tragedy of commons, Free riding Pro  Generalizable statements for (AL) networks may be achievable Contra  Practicability of results for „real“ networks doubtful Propose full project to „FET Complex Systems“

Practical: Catnet++ Course of Work  Create „Catallactic“ resource allocation middleware  Include in Globus or DataGrid  Measure performance of original and Cat. Allocation Examples  Catallactic Resource Allocation in Grids Implement catalaxy between Globus or DataGrid resource providers and service clients.  Catallactic Resource Allocation in P2P Peers configure their resources for maximum revenue, best service, Pro  Take parameters, utility functions, topology from real application Contra  Complex questions yield complex answers  Maybe no generalizable statement Propose full project to successor of „FET Global Computing“

Thanks!