1. The Case for Semantic-Free Referencing Hari BalakrishnanScott Shenker Michael Walfish MIT & ICSI/UCB IRIS Project

2. Links in Distributed Systems Cornerstone of the Web Links are far more general than the Web –File systems, remote object invocations, sensor networks, device/service location, … All links contain a directive and a reference – –service:printer:lpr://slp- print.mit.edu –[service=printer [organization=MIT] [building=ne43 [room=510]]]

3. Reference Resolution How should references be resolved? –Reference Resolution Service (RRS) converts references to locations –E.g., DNS converts (part of) Web URL to IP address Desirable features –Integrity: Reference must point to unique target –Scalability –Ability to handle target replication –Dynamic updatability (e.g., due to migration) –Reasonable performance A good RRS solves these hard problems!

4. The Semantic-Free Referencing (SFR) Thesis 1.References should not embed location semantics –Required to support replication and migration of data 2.References should not embed human-readable semantics –RRS network infrastructure should not become a branding mechanism and point of contention 3.The RRS infrastructure should be shared –Common, hard problems should be solved exactly once We call a referencing system that has properties 1 & 2 “semantic-free”

5. The Problem with Human-Readable References DNS URLs are not semantic-free, they are laden with location or origin semantics DNS names are being used as branding mechanisms –Tremendous legal contention for ownership, ICANN politics, tussles to control the root –Stressing the DNS structure in complex ways –Getting a “suitable” domain name is becoming a bottleneck –A plethora of social problems: “name squatting”, “typo squatting”, trademark infringement, reverse infringement, … How important are human-readable DNS URLs, anyway?

6. Two Kinds of Names The community has often confused two kinds of names –User-level names are how users/apps find things –References are how targets are named Today’s user-level naming –Search engines, “AOL keywords” –Hyperlinks –Links sent through email, etc. User-level names resolve to a set of references Separate user-level names from referencing Search methods can compete, but the shared routing scheme should be tussle-free Separate user-level names from referencing Search methods can compete, but the shared routing scheme should be tussle-free

7. SFR Proposal Recall our goals –Location-independence –Not human-readable –Shared, lightweight infrastructure Unstructured keys make ideal references –DHTs suggest an approach for good RRS routing Search services: user-level name  SFRTag 0xf01212099abc0531ab DHT-based RRS 18.31.0.82:80 papers/sfr.ps “O-record”

8. Web-over-SFR Can resolve objects, not just domains Pick SFRTag randomly – no admin delegation Enables easy replication of content O-record generalizes easily to other apps

9. Comparisons Location- indep. Not human- readable Shared IP addr URL NOYes DNS URLYes (Obj rtg needs baroque hacks) NOYes URN (no single proposal) YesNo… Yes… (depends) NO SFRYes Think of SFR as a URN scheme with only semantic- free “names” and a flat namespace

10. FAQ (and not-so-FAQ) Operations/Deployment –Are you saying we should get rid of DNS? –How are you ever going to deploy this? Integrity/Security/Authentication/Confidence –Can you ensure reference integrity without delegation? –Can’t bad guys mess up O-records? –Aren’t you undermining “confidence” by eliminating human- readable URLs? Usability –How usable is the system for content publishers? –How do you handle dynamic content? Performance –I can’t reach your Web site if a random RRS server dies? –Won’t this have bad performance?

11. Summary We argue that links are useful in systems beyond the Web RRS should be shared References should be semantic-free –Location-independent –Human-unfriendly Separate user-level naming from referencing P2P-inspired DHTs suggest a great way to achieve an SFR infrastructure!