The%20Case%20for%20Semantic-Free%20Referencing

1
The Case for Semantic-Free Referencing

• Hari Balakrishnan Scott 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
• ltimg srchttp//www.mit.edu/ocw.jpggt
• serviceprinterlpr//slp-print.mit.edu
• serviceprinter organizationMIT
  buildingne43 room510

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

• References should not embed location semantics
• Required to support replication and migration of
  data
• References should not embed human-readable
  semantics
• RRS network infrastructure should not become a
  branding mechanism and point of contention
• 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
• Todays 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
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

O-record
18.31.0.8280
DHT-based RRS
0xf01212099abc0531ab
papers/sfr.ps
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 addrURL NO Yes Yes
DNS URL Yes(Obj rtg needs baroque hacks) NO Yes
URN(no single proposal) Yes NoYes(depends) NO
SFR Yes Yes Yes
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?
• Cant bad guys mess up O-records?
• Arent 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 cant reach your Web site if a random RRS
  server dies?
• Wont 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!