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

federation beyond distributed control
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

page 1 27/10/05

Federation: Beyond Distributed Control

Kevin Lai HP Labs

slide-2
SLIDE 2

page 2 27/10/05

[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

  • f the societies in which it operates.” [emphasis

added]

slide-3
SLIDE 3

page 3 27/10/05

slide-4
SLIDE 4

page 4 27/10/05

slide-5
SLIDE 5

page 5 27/10/05

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

slide-6
SLIDE 6

page 6 27/10/05

Tussles

resource owner  user

compensation resources

MgmtAuth  resource owner

compensation management service

 SliceAuth user

? ?

slide-7
SLIDE 7

page 7 27/10/05

[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]

slide-8
SLIDE 8

page 8 27/10/05

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

slide-9
SLIDE 9

page 9 27/10/05

slide-10
SLIDE 10

page 10 27/10/05

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
slide-11
SLIDE 11

page 11 27/10/05

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

slide-12
SLIDE 12

page 12 27/10/05

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
slide-13
SLIDE 13

page 13 27/10/05

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

slide-14
SLIDE 14

page 14 27/10/05

slide-15
SLIDE 15

page 15 27/10/05

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
slide-16
SLIDE 16

page 16 27/10/05

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
slide-17
SLIDE 17

page 17 27/10/05

slide-18
SLIDE 18

page 18 27/10/05

Market-Based Proportional Share

  • Basic idea [Kelly, Johari]:

– Users have a limited budget of credits – Users spend these credits to buy more weight

bi: bid for user i

  • Complexities

– bid for weights – payments and partial usage – multiple resources

ri

t=

bi

t

 b

t R

ri

t=

wi

t

 w

t R