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 DNS client CoDoNS node DNS client 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 DHT

A New School of DHT Research Open 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 P 4 Infrastructure (Peering Peer- to-Peer Providers) of DSPs

Requirements for a Global DHT Dialtone Customer pays its DSP for this service: Puts of accessible to all other P 4 customers Gets on keys will be fulfilled, no matter which provider serviced the put of Best effort service model put(k,v) get (k) v Customer P 4 Infrastructure DSP

Outline I.P 4 Design Spectrum II.Challenges III.Conclusion

Scenario Each DSP owns hosts, stores subset of { } Customer/provider interface: P 4 Proxy (like DNS) Assume for now DSPs all talk to each other We now discuss possible relationships … Company Home User v 1 = get(k 1 ) DSP put(k 1,v 1 ) P 4 Proxy

Possible DSP Relationships (First Two) All one DHT Existing DHT mechanisms work  No incentive for DSP to contribute resources Administrative separation (separate DHTs) DSP coded into key  right incentives DSPs store only for customers  Switching DSPs means switching keys DSP IDRest 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’ pairs  We believe this 3 rd relationship is the tenable one But how will it work? (For now, assume small set of top-level DSPs)

put (k, v) 2.Put-broadcasting of ; local gets 3.Put-broadcasting of keys only; forwarded gets put (k, v) put (k, v) get (k) 1.Get-broadcasting; local puts (can cache ) 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.P 4 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 Correctness 1. inserted by a customer must be visible to customers of other providers  Discussed earlier 2.Customers must not be able to own the same key or overwrite each other’s 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.P 4 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 (P 4 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 P 4 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 ; local get: All DSPs have copies of ; 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 P 4 infrastructure could emerge Not whether P 4 infrastructure will emerge  (We assumed market demand exists.)