Federation: Beyond Distributed Control Kevin Lai HP Labs 27/10/05 - PowerPoint PPT Presentation

Federation: Beyond Distributed Control Kevin Lai HP Labs 27/10/05 page 1

[Clark, Wroklawski, Sollins, Braden 2002] “...we focus on design principles that deliver such virtues as robustness, scalability and manageability in the face of complexity, component failures, growth, and other challenges. However, as the Internet becomes mainstream it inevitably moves from being an engineering curiosity to being a mirror of the societies in which it operates .” [emphasis added] 27/10/05 page 2

27/10/05 page 3

27/10/05 page 4

Distributed Control ● necessary for federation ● Problem: distributed control inevitably leads to disagreements (“tussles”) – no traditional CS solutions ● Distributed MgmtAuth and SliceAuth tussles: – the quality and type of hosts to be added – the number and requirements of users 27/10/05 page 5

Tussles resource owner  user compensation resources  MgmtAuth resource owner compensation management service  SliceAuth user ? ? 27/10/05 page 6

[Clark, et al 2002] “The challenge ... is to recognize and leverage this reality ... to use it to strengthen the technical architecture. ...[it] must accommodate the tussles of society, while continuing to achieve its traditional goals of scalability, reliability, and evolvability.” [emphasis added] 27/10/05 page 7

Possible Solutions ● “it's a policy issue” – set manually, send email or call when conflict – time-consuming, slow, invites retaliation ● barter economy – n^2 equivalence problem ● service level agreements – worked for the Internet – difficult to specify, slow to change – PL has many more types of resources than ISPs – PL relationships are more transient than ISP peering 27/10/05 page 8

27/10/05 page 9

Markets ● you get what you pay for – users bid on resources – price varies depending on supply and demand ● user has incentive to only request necessary resources ● owner has incentive to provide desirable resources ● automated ● agile ● many different types of resources 27/10/05 page 10

Markets and Federation ● Bank: stores all users' account information ● Newly joined node owners receive initial currency ● Determine global macro-economic policies – initial host owner currency allocation, taxation rate, allocation of taxes back to host owners ● Original tussles – the quality and type of hosts to be added – the number and requirements of users 27/10/05 page 11

Status ● Federated pseudo-PL already exists: Tycoon – similar ssh-based interface – different node interface ● Fair, efficient, agile market distributed on each host ● Bank, multiple MgmtAuth – Singapore, Sweden, Intel, HP all have independently administered hosts ● cluster status: http://tycoon.hpl.hp.com/pulse 27/10/05 page 12

Future Work ● Some operations should not be permissible at any price ● Elevate tussle even more: multiple currencies – tussle reduced to deciding exchange rate among currencies 27/10/05 page 13

27/10/05 page 14

Tussle Design Principles ● Modularize along tussle boundaries ● Design for choice ● Visible exchange of value ● Exposure of cost of choice ● Visibility (or not) of choices made 27/10/05 page 15

Why Federate? ● more network externalities ● more node and user diversity → more statistical multiplexing ● diversity in administrative policies ● leveraging from common infrastructure services ● some resource owners require it 27/10/05 page 16

27/10/05 page 17

Market-Based Proportional Share ● Basic idea [Kelly, Johari]: – Users have a limited budget of credits – Users spend these credits to buy more weight b i : bid for user i t t b i w i t = t =  r i t R r i t R  b  w ● Complexities – bid for weights – payments and partial usage – multiple resources 27/10/05 page 18