Billing the Grid – Kick Off Meeting. Billing the Grid – Kick Off Meeting – 04.08.2006 Folie 2 Agenda UhrzeitThemaZuständigkeit 11.00-11.15Begrüßung &

Billing the Grid – Kick Off Meeting

Billing the Grid – Kick Off Meeting – 04.08.2006 Folie 2

Agenda

Uhrzeit Thema Zuständigkeit11.00-11.15 Begrüßung & Vorstellung Christof Weinhardt

11.15-11.30 Vortrag Günter Quast

11.30-11.55 Vortrag Christian v.d. Weth

11.55-12.10 Vortrag Arun Anandasivam

12.10-12.50

Zielsetzung und Organisation: Weichenstellung Erste Schritte Reporting / Meetings Interne Verrechnung

Alle

12.50-13.00 Fazit Alle


Agenda





12.10-12.50


Alle


4

A Unifying Framework for Behavior-based Trust Models

Christian von der Weth, Klemens Böhm

Universität Karlsruhe (TH), Germany{weth|boehm}@ipd.uni-karlsruhe.de

Christian von der Weth, Klemens Böhm: "A Unifying Framework for Behavior-based Trust Models"

5

Motivation

• Many fields of research require resource-intensive applications (analysis, simulation, visualization, etc.)

Real driving force: Particle Physics

• Solution: Grid Computing

Participants (institutes, firms, persons, etc.) provide their own resources and share them with others

A participant can interact with partners to use their resources to run his own applications

• Characteristic of Grid communities

Participants have full control over their entities

A partner can impair the outcome of an interaction by behaving uncooperatively, maliciously or defectively(close access to his resources, limit bandwidth/CPU/…)


6

Motivation

• Goal: Mechanism that allows entities autonomously to distinguish good from bad partners

• Promising approach: Behavior-based trust

Trust: "One's subjective degree of belief that a partner can and will perform a specific task in a certain situation."

Behavior-based: The trust in a partner is derived from the knowledge about his behavior in previous interactions

• Basic Idea:

Enabling users to define their own policies whether a partner is trustworthy or not ( trust policies) and

Making these policies explicit to their controlled entities


7

Behavior-based Trust Policies

• Example policies:

Alice: "I deem a partner trustworthy to use my resources if the average feedback value about him is positive."

Bob: "A partner can have 100% of my idle CPU time if there is no negative feedback about him within the last 24h."

Carol: "I only perform the task of others if their performance of complex tasks was satisfactorily."

Dave: "A partner can have limitless bandwidth if the k most reputable entities recommend him."

Eve: "I share my resources only with the k entities that have the highest PageRank."


8

What can we learn from the examples?

• Requirement 1: Representation of knowledge that describes the behavior of a partner: behavior-specific knowledge

Different types of behavior-specific knowledge

Feedback, Reputation, Recommendation, Trust

Consideration of various aspects of the behavior-specific knowledge

(e.g., context, age of knowledge, etc.)

• Requirement 2: Mechanism makes trust policies explicit to controlled entities

Different user have different trust policies

Trust policies may require complex operations (e.g., aggregation or centrality computation)


9

What can we learn from the examples? (2)

• Representation of knowledge as directed graph G(V,E)

V…set of participants

E…set of edges based on behavior-specific knowledge

• Example:

Application of graph algorithms to find trustworthy partners

e.g., EigenTrust (Schlosser et al., 2003), PageRank (Brin and Page, 1996)

A

BC

DE

Feedback

Recommendation

Trust


10

Status Quo

• Existing behavior-based trust models

Definition of the representation of behavior-based knowledge

Definition of a fixed evaluation scheme to derive the trust in a partner

A fixed evaluation scheme contradicts the subjective nature of trust

• Common approach for making trust policies explicit: Logic-based trust policy languages

Definition of rules and clauses to derive the trustworthiness of a partner

Existing languages cannot satisfactorily cope with complex operations required by various behavior-based policies


11

A Framework for behavior-based trust models

• Aspects of our framework

Relational representation of behavior-specific knowledge

Algebra-based language for the formulation of behavior-based trust policies

• Advantages

Supports the definition of arbitrary user-defined trust policies for behavior-based trust models

۰ Including all existing evaluation schemes from literature we are currently aware of

Relational representation allows for a straightforward implementation


12

Agenda

• Introduction

• Representation of behavior-based knowledge

• Definition of a query algebra for trust

• Preliminary Performance Experiments

• Summary & Outlook

Introduction

Knowledge Representation

A Query Algebra for Trust

Experiments

Summary&Outlook


13

Types of behavior-specific knowledge (1)

• Feedback

An entity's (rater) rating of an interaction performed by a partner (ratee)

Alice: "The last download from Bob was very reliable."

• Recommendation

An entity's (recommender) opinion about the previous behavior of a partner (recommendee)

Alice: "For downloads I can recommend Bob."

Introduction


- Overview

- Aspects

- Relational Representation


Experiments

Summary&Outlook


14

Types of behavior-specific knowledge (2)

• Reputation

General opinion of the whole network towards a single entity

Global characteristic of an entity

Example: "With regards to downloads, Bob has an excellent reputation."

• Trust

An entity's (truster) degree of belief that a partner (trustee) will behave as expected

Alice: "I trust Bob regarding the provision of reliable downloads."

Introduction


- Overview

- Aspects



Experiments

Summary&Outlook


15

Aspects of Behavior-specific Knowledge (1)

• Value ∈ [-1,1]

Continuous valuation allows for a finer granularity

Alice: "The performance of Bobs last computation was quite good (~0.6)."

• Context

Allows to distinguish between different situations in which two entities can interact

Alice: "Bob provided fast downloads but his CPU performance was very poor."

• Facets of a context

Allows to distinguish between different perspectives of a context

Alice: "The connection for the last download was very stable but unfortunately very slow."

Introduction


- Overview

- Aspects



Experiments

Summary&Outlook


16

Aspects of Behavior-specific Knowledge (2)

• Timestamp

Allows to emphasize the impact of current knowledge

Alice: "Bobs early downloads were quite fast but recent ones were very slow."

• Certainty ∈ [0,1]

Allows to quantify the certainty of an assessment

Alice: "I am absolutely sure (e.g., ~1.0) that Bobs performance according to his last computation was good."

• Estimated Effort ∈ [0,1]

Allows to quantify the perceived complexity of an interaction

Alice: "Bob performed simple (e.g., ~0.2) computations quite good but complex ones (e.g., ~0.9) very poor."

Introduction


- Overview

- Aspects



Experiments

Summary&Outlook


17

Relational Representation of Knowledge

• Relations that represent behavior-specific knowledge: Feedback, Recommendation, Reputation, Trust(Additional relation: Entity(ID)

• Alice: "I am quite sure that the download from Bob was very fast. It was a big file." New Feedback tuple

• In our scenario:

Only Feedback tuples reflect direct experiences

Other knowledge must be derived from feedback (including Trust tuples)

Goal: Trust policy language as mechanism to derive Trust, Recommendation and Reputation tuples

Introduction


- Overview

- Aspects



Experiments

Summary&Outlook

Rater Ratee Value Context Facet Time Certainty Effort

Alice Bob 0.95 Download Speed 12:09:45 0.75 0.8


18

Approach to an Algebra-based Policy Language

• Source: Relational representation of knowledge

• Evaluation of a trust policy = Query on the knowledge base

• Common way to deal with relations: Relational Algebra (RA)

Set of operators for the application on relations

Closure property of the operators allows for nesting of the operators to more complex algebra expressions

Basic Idea: Relational Algebra (RA) as basis for our trust policy language

Introduction



- Basic Idea

- Conventional Extensions

- Centrality Operator

Experiments

Summary&Outlook


19

Example Trust Policy

• Informal formulation:

"I trust you (idpartner) in context c and facet fc if your average feedback value from the 10 most reputable entities tops a specific threshold."

Only feedback tuples with a certainty>0.8 should be considered

Algebra expression of that policy:

PROJECTION[trusted](

MAP[trusted, (avg_value>threshold)](

GROUP[avg_value, AVG(Feedback.value), {ratee}](

JOIN[Feedback.rater=Reputation.entity](

TOP[10, Reputation.value](

SELECTION[context=c, facet=fc](Reputation)

SELECTION[ratee=idpartner, context=c, facet=fc, certainty>0.8]

(Feedback)

) ) );

Introduction



- Basic Idea



Experiments

Summary&Outlook


20

Algebra-based Policy Language

• Observation:

Basic operators of the RA are not sufficient for the formulation of behavior-based trust policies

Extension by means of additional operators are necessary

Clarification which further operators are essential to provide the desired expressiveness

• First step: Existing additional operators from literature

Top operator (e.g., Bertino et al., 2004)

Map operator (e.g., Aberer and Fischer, 1995)

Introduction



- Basic Idea



Experiments

Summary&Outlook


21

Conventional Extensions to the RA (1)

• Top Operator: TOP[k,attr](relation)

returns the k tuples with the highest value of a attribute attr

Example:

Introduction



- Basic Idea



Experiments

Summary&Outlook

ID … Value

Bob … 0.71

Carol … 0.95

Alice … 0.98

Eve … 0.75

Dave … 0.90

ID … Value

Carol … 0.95

Alice … 0.98

Dave … 0.90

TOP[3, Value](Reputation)


22

Conventional Extensions to the RA (2)

• Map Operator: MAP[attr,expression(A1,...,An)](relation)

Allows the execution of user-defined functions over the attributes of a relation

The functions are separately applied to each single tuple of the relation; the results are stored as a new attribute

Example:

Introduction



- Basic Idea



Experiments

Summary&Outlook

Rater Ratee … Value Effort

Alice Bob … 1.0 0.2

Alice Carol … 0.8 0.9

Rater Ratee … Value Effort Weighted

Alice Bob … 1.0 0.2 0.2

Alice Carol … 0.8 0.9 0.72

MAP[Weighted, (Value*Effort)](Feedback)


23

Centrality Indices

• Centrality index

Graph-based measure to quantify the importance of a vertex according to the graph structure

Different existing measures: Indegree, PageRank, Proximity Prestige, HITS, Integration & Radiality, etc.

Different measures yield different rankings

• Example:

A

BC

DE

1.0

0.9

0.50.2

0.9

1.0

0.1

0.20.6

Indegree PageRank

A 2.0 0.23

B 0.6 0.21

C 1.8 0.31

D 0.7 0.15

E 0.3 0.1

Introduction



- Basic Idea



Experiments

Summary&Outlook


24

An Operator for Centrality Computation

• Requirements for a centrality operator:

Flexible specification of the underlying graph

e.g., choice of the weight of an edge: "Value" vs. "Weighted"

Support of various centrality measures within one operator

Definition of centrality operator:

CENTRALITY[attr, Av, As, At, Aw, Measure](Rvertices, Redges)

Introduction



- Basic Idea



Experiments

Summary&Outlook

Rater Ratee … Value Effort Weighted

Alice Bob … 1.0 0.2 0.2

Alice Carol … 0.8 0.9 0.72


25

Centrality Operator - Example

A

BC

DE

1.0

0.9

0.50.2

0.9

1.0

0.1

0.20.6

Recommender Recommendee … Value

A C … 0.9

A E … 0.2

B A … 1.0

B D … 0.5

C B … 0.6

ID PageRank

A 0.23

B 0.21

C 0.31

D 0.15

E 0.1

CENTRALITY[PageRank, ID, Recommender, Recommendee, Value, PageRank] (Entity, Recommendation)

Introduction



- Basic Idea



Experiments

Summary&Outlook

ID

A

B

C

D

E

Recommendation Entity


26

Centrality Operator

• Nature of centrality computation

Very time-consuming and resource-intensive

Centrality computation is the most costly part of the evaluation of a trust policy

• Implemented centrality measures in PL/SQL (Oracle 10g)

PageRank, Positional Power Function (eigenvector centrality measures based on power iteration implementation)

Authorities, Proximity Prestige, Integration

• Experiments

Efficiency: Performance of our implementations

Quality of Centrality Measures: Comparison of ranking results

Introduction



- Basic Idea



Experiments

Summary&Outlook


27

Efficiency (1)

• Setup:

All centrality measures

Network sizes: 500, 1000, 2000 entities

• Measured value: time in sec

• Result

Performance varies significantly from measure to measure

Eigenvector centrality measures (based on power iteration implementation) show best performances

0

5000

10000

15000

20000

25000

600 800 1000 1200 1400 1600 1800 2000

tim

e in

se

co

nd

s

size of population

PageRankPositional Weakness Function

AuthorityProximity

Integration

Introduction



Experiments

Summary&Outlook


28

Efficiency (2)

• Setup:

Eigenvector centrality measures

Network sizes: 2000, 10000, 50000, 100000 entities

• Measured value: time in sec

• Result:

Again, huge difference between both measures

Main factor: error threshold of power iteration implementation (causes the number of iteration steps)

0

20000

40000

60000

80000

100000

120000

140000

10000 20000 30000 40000 50000 60000 70000 80000 90000 100000

tim

e in

se

co

nd

s

size of population

PageRankPostional Weakness Function

Introduction



Experiments

Summary&Outlook


29

Quality of Centrality Measures

• Setup: All centrality measures

Network size: 1000 entities

• Measured value: Difference between two rankings in % Mean distance between the position of an entity in both rankings

0%...equal rankings, 100%...maximum difference

• Result: Most measurements yield different rankings (except for Integration

and Proximity Prestige)

Choice of centrality measure might influence the result of trust policies significantly

PWF Authorities PPrestige IntegrationPageRank 6.2% 8.2% 5.3% 5.3%

PWF - 5.4% 9.5% 9.5%Authorities - - 9.7% 9.7%PPrestige - - - 0.0%

Introduction



Experiments

Summary&Outlook


30

Summary

• What have we done so far?

Collection of various meaningful behavior-based trust policies from literature and our own attempts

Motivation of an algebraic approach for the formulation of behavior-based trust policies

Definition of a relational representation of behavior-specific knowledge

Definition of a query algebra for trust۰ Listing of necessary operators from literature (basic

operators from the RA incl. existing extensions)۰ Definition of a centrality operator for the computation of

various centrality measures

Presentation of some first experimental results

Introduction



Experiments

Summary&Outlook


31

Open Questions

• How efficient is the evaluation of various trust policies?

Further efficiency test including various optimization techniques for centrality computation

Evaluation of trust policies in distributed architectures (i.e., structured Peer-to-Peer systems)

• How about effectiveness when entities with different trust policies interact repeatedly?

Introduction



Experiments

Summary&Outlook


32

Thanks for your interest!

Questions?


Agenda





12.10-12.50


Alle


Arun Anandasivam

Billing the Grid – Kick Off

Virtuelle Währungen als

Anreizmechanismus für Grids

Virtuelle Währungen als Anreizmechanismus für Grids Folie 35

Reputationsmechanismen

• Beispiel für Reputationsmechanismus: eBay

• Mechanismen für P2P: EigenTrust, PeerTrust, DMRep

• Ziel: bösartiges und egoistisches Verhalten minimieren

• Mehr Vertrauen des Käufers in Händler mit guter Reputation

• Anreiz für Teilnehmer: Verbesserung der eigenen Reputation und folglich mehr Umsatz

• Nachteile: • Erfüllung der Mindestanforderung ausreichend

• Kollusion

• White washing


Monetäre Mechanismen

• Leistung ↔ Gegenleistung in Geld

• Beschränkung und Kontrolle des Gesamtbudgets im System notwendig

• Anreiz für Teilnehmer:

Leistung anbieten → Geld verdienen → Leistung erhalten

• Preis spiegelt Knappheit wider

• Nachteile:

• Befürchtung im universitären Bereich: Bessere Ausgangssituation für finanziell gut ausgestattete Institute.


Stamp Trading [Nach Moreton und Twigg 2003]

• Jeder Nutzer in Besitz seiner eigenen, persönlichen Marken• Gleicher Wert für alle Marken (z.B. nur 10€ Scheine)

• Zahlung: Handel zwischen Person X und Person Y nur möglich mit Marken• Reputation: Abhängigkeit des Markenwertes von der Anzahl der Einlösung und

der Erfüllung der nachgefragten Leistung

• Regelung des Markenwertes durch eine zentrale Instanz für Wechselkurse• Bestimmung des Markenwerts durch eine geeignete anreizkompatible

Funktion, Bsp: w = m * rs / i

Reputationsmechanismen Monetäre Mechanismen

Stamp Trading (nach Moreton & Twigg)


Verteilung der Marken


Ausblick

• Vorteile:• Rückverfolgbarkeit möglich (Dokumentation der Zahlungsflüsse durch zentrale

Instanz)

• Reputation und Zahlung in einem System (Marken) erfasst

• Nachteile:• Zentrale Verwaltung der Wechselkurse notwendig

Nachteil der Skalierbarkeit

• Profilerstellung über die Nutzer durch zentrale Verwaltung.

• Systemabsturz durch technische (und juristische) Attacken auf die zentrale Einheit

• Eingelöste Marken nicht automatisch durch die andere Partei gelöscht

mehrmaliges Benutzen einer Marke (Double spending)

• Kollusionen und White washing möglich

Entwicklung eines dezentralen Ansatzes für Stamp Trading


Agenda





12.10-12.50


Alle



Mitarbeiterstruktur

EKP

IPD

AIFB

IISM

Christian

v. d. Weth

Arun

Anandasivam

A. Ankolekar

D. Neumann

Integration in AIFB durch

Besuch der Oberseminare

???

???

Integration durch …


Einordnung der Billing Dienste

Common Virtualization Middleware(Globus GT4)

Grid Applikation

Billing Dienst 2 (Virtuelle Währungen)

Billing Dienst 1 (Reputationsmechanismus)


Zielsetzung

Projektziel:

Entwurf und Realisierung einer anreizkompatiblen Billing-Infrastruktur

Praxis Theorie

• Anforderungsanalyse für Mechanismen

• Integration des Prototyps in bestehende Grid Middleware

• Feldexperiment

• Evaluation

• Konzeption eines Billing-Mechanismus

•Reputationsmechanismus•Virtuelle Währung• …

• Konzeption eines „Policy-basierte Bewertungsautomaten“

Anforderung an Infrastruktur

• Dezentral strukturierte P2P-Technologie für eine koordinatorfreie Datenhaltung und hohe Skalierbarkeit


Institut X

Billing the Grid und KIT

Cluster

Teilchenphysik

RZ Karlsruhe

(Juling)

RZ FZK

(Mickel)

Reputations-mechanismen

Adaption

und Veränderung

D-Grid

Integrationsprojekt

Zeit

CERN?

Ansprechpartner?

Pilotprojekt?

Vorhandene

Schnittstellen?


Meilensteine

04.08.2006 01.02.2007

Anforderungserhebung

Literaturrecherche

Erster Prototyp

01.08.2007

Erste Ergebnisse

Alternative Ansätze

01.02.2008

Feldexperiment

VerbesserterPrototyp

01.08.2008

Berichte

Folgeantrag

Meilenstein 1 Meilenstein 2 Meilenstein 3 Meilenstein 4

Phase „Forschung und Entwicklung“Phase „Vorbereitung“ Phase „Evaluation“


First steps (1/2)

Anforderungsanalyse für Anreizmechanismen (AP10) :

• Domänenstrukturierung- Erhebung Anreizprobleme

- Bösartiges vs. egoistisches Verhalten

- Identifikation Wissensressourcen

• Ableitung Anforderungen an Anreizmechanismus - Ziele

- Lösung der Anreizprobleme

- Performanz

- Usability/Sicherheit

- …

- Funktionale Anforderung- Prozessablauf

- Interaktion mit dem Benutzer

- …

• Grenzen vorhandener Anreizmechanismen • D-Grid Integrationsprojekt

• SORMA

• Definition geeigneter Metriken


First steps (2/2)

P2P Netzwerk (AP1)

• Konzeption eines strukturierten P2P Netzwerkes

• Content Adressable Network

• Speicherung von Feedback und anderen Metadaten

• Implementierung eines strukturierten P2P Netzwerkes

• Roll-Out


Organisation

• Regelmäßigkeit der internen Reports

• Externer Report (Abschlussbericht)

• Intervalle / Zeitpunkte

• Treffen aller Beteiligten (2x im Jahr?)

• Kleine Treffen (1x pro Woche bzw. Monat)

• Institutsintern oder institutsübergreifend?

Reports

Buchung

Meetings

PR• Inhalt der Homepage (www.billing-the-grid.org)

• Logo


Anschubfinanzierung

• „Landesschwerpunktprogramm erwartet Antragstellung“

• BMBF

• EU-Projekt FP7 IST

• DFG SPP

• DFG Forschergruppe

• Welches Ziel wird nach dem Projekt verfolgt?

• Ist ein Folgeprojekt erforderlich?

• Sorma EU-Projekt FP6 Call5

• Biz2Grid

• …


Agenda





12.10-12.50


Alle


Documents

Billing the Grid – Kick Off Meeting. Billing the Grid – Kick Off Meeting – 04.08.2006 Folie 2 Agenda UhrzeitThemaZuständigkeit 11.00-11.15Begrüßung &