Projekt:Mechanismus Design:Netzwerke:Spielmodell
Inhaltsverzeichnis |
Modellierung
Momentan haben wir 2 Ansätze, die es wohl zu vereinen gilt - den vom Treffen und einen der zumindest schon mal nach Mechanism Design kriterien gebaut ist. In jedem Fall sollten wir an der Modellierung da noch was tun.
vom Treffen(Jörn)
Modellkomponenten:
- Zentrale Instanz(en): ein oder mehrere (jeweils zuständig für einen Cluster) Verwaltungsserver, die durch wechselnde Peers realisiert werden (rollierend); Schlagwort "cluster representatives"
- Diskrete Zeitlinie
bzw.
- Individueen bzw. Spielermenge
- Zustände Z = {C,S}, d.h. ein Peer kann in Runde t genau eine Rolle "Client" oder "Server" annehmen
- Auswahlfunktion zur Rollen- bzw. Zustandsauswahl je Runde:
- Historien (Zeitindex unten wie üblich):
- Reputationsfunktion bzw. -statistik:
bzw.
für Individuum i
- Aktionsmenge (vgl. gemischte Strategie): A = {c,d} (cooperate, defect)
- Wahrscheinlichkeit der Interaktion mit Individuum j, in Abhängigkeit der Reputation (aktuell im Zeitpunkt t):
; hier
![]()
- Strategiefunktion des Individuums (wahlweise):
- fest (vgl. evolutorisches Spiel), d.h. die Strategie des Individuums ist in dessen Genen kodiert: konstante Funktion
- variabel, d.h. z.B. abhängig von eigener (i) und/oder der Reputation des Kommunikationspartners (j) zum aktuellen Zeitpunkt:
- fest (vgl. evolutorisches Spiel), d.h. die Strategie des Individuums ist in dessen Genen kodiert: konstante Funktion
- Nutzenfunktion des Basisspiels: Payoff-Matrix, d.h.
; hier: u(c,c) = (7, − 1),u(c,d) = u(d,c) = u(d,d) = (0,0)
- Nutzenfunktion des Gesamtspiels bzgl. Individuum i:
Mögliche Erweiterungen:
- Strategieerweiterungen:
- Request file erst in Runde
- Request file erst in Runde
- Private history und subjektive Reputationseinschätzung des Individuums i bzgl. der anderen.
- Bandbreite einschränken (im Moment gar nicht modelliert)
Mechanism Design / Social Choice (Flo)
Überlegungen:
Was ist das Ziel des Systems?
Das Sharing zu maximieren, also: Viele Sachen sharen mit viel Bandbreite. D.h. insbesondere zunächst:
- Für einen genehmigten Download möglichst viel Bandbreite zur Verfügung zu stellen. Es wird zunächst nun ein Mechanismus entworfen der eben genau einen Download regelt.
In wiefern kann der Mechanismus die subjektiven Wertvorstellungen der Agenten antizipieren?
Prinzipiell diese speziell gar nicht, da es sich um rein individuelle, teils auch in der nicht-rationellen Psyche, zumindest aber in einer dem Mechanismus nicht bekannten Information begründete Wertvorstellungen handelt. Ein Agent möchte eben gewisse Daten downloaden, andere eventuell nicht.
Das einzige, das der Mechanismus annehmen kann ist, dass ein Agent prinzipiell filesharing nutzen will - sonst wäre er nicht am System beteiligt.
Daher wird der Nutzen über Downloadmöglichkeiten geregelt und der Mechanismus nimmt an, daß mehr Downloadmöglichkeit auch einen Nutzengewinn für den Agenten bedeutet.
sollte das nicht gelten, so gibt es 2 Fälle:
- Es wird angenommen, daß ein Agent der gerade nichts downloaden will und der mit seinem Kontostand zufrieden ist, nicht am System teilnimmt, bis sich dieser Zustand wieder ändert.
- Ein Agent der downloaden will, aber einen Kontostand hat der hoch genug ist, wird bei rationalem Handeln seinen Upload sperren. Ein Eingreifen hier ist in diesem Fall vom (diesem) Mechanismus nicht möglich, da er dem Agenten keine Anreize bieten kann. Außerhalb des Mechanismus kann hier jedoch eingegriffen werden um die Häufigkeit dieses Falls zu verringern (Verfall des Downloadguthabens etc.).
Modellierung
Hier wird der Mechanismus M = {Σ,g,p1,...,pn}betrachtet, der einen einzelnen, von einer Zentralinstanz (Unterschied zum bisherigen Modell!) genehmigten Download der Datei (mit D als Menge der Dateien) optimiert, indem Anzahl der Uploader und deren Bandbreite maximiert werden.
Typ
- Ein Agent hat in jeder Zeiteinheit einen Typ
, wobei D die Menge der filesharingrelevanten Dateien eines Agenten ist und die für den Upload verfügbare Bandbreite als reelle Zahl modelliert wird.
- Beachte: Der Typ stellt die maximalen Möglichkeiten eines Agenten dar. Wie er handelt folgt im nächsten Punkt.
Strategie
ist hier "direct revealing", d.h. . Ein Agent gibt seinen Typ an. Hier kann er jedoch einen Typ angeben der weniger Dateien oder eine geringere Bandbreite hat.
Ergebnis
Von welchen Peers die Datei heruntergeladen wird.
- Der Ergebnisraum O hat folgende Gestalt
wobei o = (o1,...,on) und die Indikatorfunktion ist, die angibt, ob Agent j die gewünschte Datei hat oder nicht.
- Im Klartext: jedem vorhandenen/angegebenen Typ eines jeweiligen Agenten wird eine Zahl zwischen 0 und 1 zugeordnet. Hat der Typ das File nicht, so ist dies Null. Die Summe all dieser Zahlen ist 1. Der Ergebnisraum beschreibt, wieviel Prozent der Datei von welchem Agenten heruntergeladen werden.
Social Choice Function
- Wählt
so, dass die Gesamtbandbreite maximal wird (und die Übertragungszeit somit minimal wird).
- Also gilt für
- Im Klartext: Jeder Agent bekommt seinen prozentualen Anteil an der verfügbaren Gesamtbandbreite zugewiesen.
Ergebnisfunktion
- Sie soll der Social Choice Function so nahe wie möglich kommen, hat jedoch im Gegensatz zur SCF nur Zugriff auf die Strategien, nicht auf die Typen.
- D.h.:
Nutzenfunktion, Value, Payment
- Upload per se bringt keinen Nutzen, d.h. für die individuelle value
gilt
- Damit teilgenommen wird muß für die individuelle Nutzenfunktion
gilt
- hieraus folgt bei quasilinearer Nutzenfunktion
direkt für das individuelle payment pi, daß
- Es sollte klar ersichtlich sein, daß das payment sich aus Sicht des Mechanismus, der den wahren Typ der Agenten nicht kenn nur nach den Strategien richten kann, also
Wahl des Payments und Wirksamkeit des Mechanismus
- Wählen wir einfach
, so gibt es keinen Anreiz einen falschen Typ anzugeben. Jedoch auch keinen den richtigen anzugeben. Da wir davon ausgehen können, daß eine falsche Typangabe bezüglich höherer Bandbreite als verfügbar oder nicht verfügbarer Dateien ausgeschlossen werden kann (sei es technisch oder sei es mit drakonischen Strafen in der Paymentfunktion), werden im Zweifel nur kleinere Werte angegeben. Will man Angabe des richtigen Typs erzwingen und nicht nur Angabe des falschen Typs unrentabel machen, so muß man eben die payment Funktion so wählen, dass mit
gilt, daß
, da so mit zunehmender Bandbreite zunehmend Gewinn gemacht wird.
- Von additiven konstanten ist abzusehen, da daß die Strategie
attraktiv machen kann.