Billing the Grid – Kick Off Meeting. Billing the Grid – Kick Off Meeting – 04.08.2006 Folie 2...

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

12.50-13.00 Fazit Alle

Agenda

12.10-12.50

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"

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/…)

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

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."

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)

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)

Feedback

Recommendation

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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:

0.50.2

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

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

Centrality Operator - Example

0.50.2

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

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

Introduction

- Basic Idea

Experiments

Summary&Outlook

Recommendation Entity

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

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

600 800 1000 1200 1400 1600 1800 2000

size of population

PageRankPositional Weakness Function

AuthorityProximity

Integration

Introduction

Experiments

Summary&Outlook

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)

100000

120000

140000

10000 20000 30000 40000 50000 60000 70000 80000 90000 100000

size of population

PageRankPostional Weakness Function

Introduction

Experiments

Summary&Outlook

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

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

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

Thanks for your interest!

Questions?

Agenda

12.10-12.50

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

Mitarbeiterstruktur

Christian

v. d. Weth

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

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

Billing the Grid – Kick Off Meeting. Billing the Grid – Kick Off Meeting – 04.08.2006 Folie 2...

Documents

Development of a billing framework for D-Grid Prof. Dr. Gabriele von Voigt, Dr. Claus-Peter Rückemann, Wolfgang Müller Cracow Grid Workshop 2006 (CGW2006)

The Narragansett Electric Company d/b/a National Grid ... › eventsactions › docket › 4770-NGrid-DR... · 5180E National Grid Elec. Services 5180 SERVCO 5190S LIPA TSA Billing

Recurring Billing - Oracle · Recurring Billing 1 Recurring Billing Recurring Billing Overview Billing Process Multi-Queue Support for Recurring Billing Batch Processes

Virtual Training 3 Billing - lexisnexis.com · A new billing profile requires a nickname, description, and billing frequency. The Billing Template box defaults to the billing template

Spatial sampling strategy MODIRISK. MODIRISK Kick-off-meeting Basis for sampling strategy Grid of 10X10 km = 326 cells Three samples per grid cell = 978

· 1) How to punch and kick a. Jab, Cross, Hook, Uppercut b. Front Kick, Side Kick, Round Kick, Cut Kick, Thrust Kick, Crescent Kick,

Page 1 Billing Drop Shipments RLM System. Page 2 Drop Ship Billing Drop Ship billing is very similar to Outside Contractor Billing, except that billing

Untitled-2 [] · 2017. 8. 14. · GODFREY PHILLIPS Ficosa Ltda Ltda future smP INTERNATIONAL K KKK KICK KICK ICICICICICICICKKKKKKKK KKK tskinskinskinskin KICK KICK KICK KICK K Casting

SUBSCRIPTION BILLING SUITE SUBSCRIPTION BILLING SUITE

dostaekwondo.com · Taegeuk Ee Jong .. Taegeuk Sam Jong . 1300 BASIC TECHNIQUE 111 338 919 Axe Kick Drag Kick Crescent Kick Round House Kick Front Round House Kick Reverse KicK Yellow

Websoftex, Online Billing Software, Free Billing Software, Stores Billing Software , Billing Software, Retail Billing Software

Medical Billing Services | Leading Medical Billing ......Billing Solution for Gastroenterology Cost-effective & Revenue-Maximizing Medical Billing Services Years Quality Healthcare

How many different kinds of “Kicks”? Kick Off = Free Kick After Safety/Punt= Free Kick Punt = Scrimmage Kick FG = Scrimmage Kick Try = Scrimmage Kick

Stewardship Billing Deferral - fs.fed.usStewardship Billing Deferral ... ATSA transaction required to set SC-Billing Indicator to Y or N. System will discontinue billing ... Billing

Podiatry Billing, Urology Billing - Hippocratic Solutions

Express Billing Finance Business Solutions. Agenda What is Express Billing? Standard vs. Express Billing Express Billing Set Up -Personalize Page

SAP ISU Billing - SAP ISU Billing errors.pdf

Web viewsample case report forms, etc. ... UPs & Deviations/Violations Documentation and Reporting ... Coverage Analysis / Billing Grid development support,

Grid Modernization 11/14 Kick-Off Workshop

Medicaid Billing Module Physical Therapy Billing Form