Hari Balakrishnan

24 February 2005

MIT CSAIL

UC Berkeley / ICSI

IRIS Project

Peering Peer-to-Peer Providers

Scott Shenker

Michael Walfish

Academic P2P: An Abridged History• Early days: B.Y.O.I. (Bring Your Own Infrastructure)

• Recently: proposals to use P2P technology (DHTs resolve flat names) for core network services Examples: CoDoNs, HIP, P6P, DOA

<0x2da7, 8.2.9.2>

<0x2da7, >

<k2,v2>

<k1,v1>

DNS client CoDoNS node

CoDoNS node

DNS client

DHT

DHT

Academic P2P: An Abridged History, Cont.

• The DHT still has to run somewhere• But core network services cannot (or should not) depend on teenagers with cable modems …

• Solution?

CoDoNS node

CoDoNS nodeDHT

A New School of DHT ResearchOpen DHT [IPTPS04]:

• DHT nodes should be managed

• Run DHT as shared service Running one is complex Reuse minimal put-get iface

• From B.Y.O.I. to Frat Party Open DHT is a communal keg

Sean Rhea

So What’s the Problem?Sean has made Open DHT a stable, available, high-performance infrastructure …

… but can’t afford to run it by himself, forever

Shared infrastructure should be supported by a market, not by a benevolent donor

Shared, Commercial DHT Service?• Must present users with a uniform “DHT dialtone” … • … in a competitive market for DHT service

• Can multiple, competing providers coordinate? Analogy: competing ISPs peer to give IP “dialtone”

• Imagine: DSPs (DHT Service Providers) do likewise For now, assume market demand exists

• Investigate: federated P4 Infrastructure (Peering Peer-to-Peer Providers) of DSPs

Requirements for a Global DHT Dialtone

Customer pays its DSP for this service:• Puts of <k,v> accessible to all other P4 customers• Gets on keys will be fulfilled, no matter which provider serviced the put of <k,v>• Best effort service model

put(k,v) get (k)

vCustomer Customer

P4 Infrastructure

DSP DSP

Outline

I. P4 Design Spectrum

II. Challenges

III. Conclusion

Scenario

• Each DSP owns hosts, stores subset of {<k,v>}• Customer/provider interface: P4 Proxy (like DNS)• Assume for now DSPs all talk to each other• We now discuss possible relationships …

CompanyHome User

v1 = get(k1)DSP DSP

DSP

put(k1,v1)

P4 ProxyP4 Proxy <k5,v5>

<k2,v2>

<k4,v4>

<k3,v3>

<k1,v1>

Possible DSP Relationships (First Two)• All one DHT

Existing DHT mechanisms workNo incentive for DSP to contribute resources

• Administrative separation (separate DHTs)

DSP coded into key right incentivesDSPs store <k,v> only for customersSwitching DSPs means switching keys

DSP ID Rest of the key

Possible DSP Relationships (Third)• Now assume:

Every DSP runs own lookup infrastructure Keys don’t encode DSP

• Therefore: DSPs must exchange customers’ <k,v> pairs We believe this 3rd relationship is the tenable one

• But how will it work?

(For now, assume small set of top-level DSPs)

<k,v>put (k, v) <k,v>

<k,v>

2. Put-broadcasting of <k,v>; local gets

3. Put-broadcasting of keys only; forwarded gets

<k,v>put (k, v) <k,*>

<k,*>

<k,v>put (k, v) get (k)

1. Get-broadcasting; local puts (can cache <k,v>)

get (k)

get (k)

Different Exchange Regimes

provider’s id

More on the Regimes

• They split put and get bandwidth differently

• Can and should coexist; putter chooses regime

• Different pricing schemes?

Outline

I. P4 Design Spectrum

II. Challenges

III. Conclusion

DSPs’ Incentives• Incentive to be honest?

Commercial relationships; market discipline No different from DNS or IP service today

• Incentive to peer?Settlements (i.e., payments between two peers): Needed if two DSPs gain unequally from peering Preclude caching and put-broadcast Introduce complexity

• Paper argues DSPs gain equally from peering

w/out settlements?

Coherence and Correctness1. <k,v> inserted by a customer must be visible to customers of other providers

Discussed earlier2. Customers must not be able to own the same key or overwrite each other’s <k,v> pairs

Inherit from existing DHTs, especially Open DHT k=hash(v), k=(salt, pubkey), e.g. Cryptography unaffected by # of providers

Market Structure and Scale

Forest structure (ISP analogy again)• Top-level DSPs do put- and get-broadcasting• Children of top-level DSPs either:

Redirect customer put/get requests to top-level Maintain a local lookup service

Top-level DSPs

Child DSPs

Outline

I. P4 Design Spectrum

II. Challenges

III. Conclusion

Conclusion• P2P: technical revolution, yes. Economic novelty?

• A social theory of DHTs (compare with Marx):Anarchism (B.Y.O.I.)Communism (benevolent entity)Capitalism (P4 a form of privatization)

• Our goals: DHT dialtone for customers, proper incentives for providers

• Peering arrangements necessary but not sufficient Market requires demand, too

Appendix Slides

DSPs Gain Roughly Equally From Peering• Assume DSP’s benefit proportional to:

Its customers’ benefit from reads in other DSPs Its customers’ benefit from having their data read

• Case I: avg. benefit to a customer from a “get” is equal to avg. benefit from having its “put” read• Case II: avg. benefits not equal. Under certain assumptions, # of “gets” in each direction equal.

# from A to B (smaller fraction of larger #)

# from B to A (larger fraction of smaller #)

# “gets” from DSP B# “gets”

from DSP A

Latency• Puts: customer talks to P4 Proxy. Low latency.• For gets, separate by exchange regime:

Get-broadcast:• Latency can be high• But opportunistic caching can mitigate

Put-broadcast of key; forwarded get: (same.) Put-broadcast of <k,v>; local get:

• All DSPs have copies of <k,v>; low latency

• Adaptive algorithm to decide which propagation regime is optimal for a key?

Can’t Google Do This?• Sure.• Will they charge for the service?

If not, great! If so …

• This talk: whether P4 infrastructure could emerge• Not whether P4 infrastructure will emerge

(We assumed market demand exists.)