The Case for Semantic-Free Referencing

Hari Balakrishnan Scott ShenkerMichael Walfish

MIT & ICSI/UCBIRIS Project

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– <img src=http://www.mit.edu/ocw.jpg>– service:printer:lpr://slp-print.mit.edu

– [service=printer [organization=MIT] [building=ne43 [room=510]]]

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!

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”

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?

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 referencingSearch methods can compete, but the shared routing

scheme should be tussle-free

Separate user-level names from referencingSearch methods can compete, but the shared routing

scheme should be tussle-free

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”

Comparisons

Location- indep.

Not human-readable

Shared

IP addrURL

NO Yes Yes

DNS URL Yes(Obj rtg needs

baroque hacks)

NO Yes

URN(no single proposal)

Yes No…Yes…

(depends)

NO

SFR Yes Yes Yes

Think of SFR as a URN scheme with only semantic-free “names” and a flat namespace

Think of SFR as a URN scheme with only semantic-free “names” and a flat namespace

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?