Aditya Akella
03/16/2007
Supplemental slides

• Basically building a wide area distributed database
• Scalability
• Decentralized maintenance
• Robustness
• Global scope
– Names mean the same thing everywhere
• Don’t need
– Atomicity
– Strong consistency

• 23% of lookups with no answer
– Retransmit aggressively  most packets in trace for unanswered lookups!
– Correct answers tend to come back quickly/with few retries
• 10 - 42% negative answers  most = no name exists
– Inverse lookups and bogus NS records
• Worst 10% lookup latency got much worse
– Median 85  97, 90 th percentile 447  1176
• Increasing share of low TTL records  what is happening to caching?

• Hit rate for DNS = 80%  1-(#DNS/#connections)
– Most Internet traffic is Web
– What does a typical page look like?  average of 4-5 imbedded objects  needs 4-5 transfers  accounts for 80% hit rate!
• 70% hit rate for NS records  i.e. don’t go to root/gTLD servers
– NS TTLs are much longer than A TTLs
– NS record caching is much more important to scalability
• Name distribution = Zipf-like = 1/x a
• A records  TTLs = 10 minutes similar to TTLs = infinite
• 10 client hit rate = 1000+ client hit rate

• Hosts are tied to IP addresses
– Mobility and multi-homing pose problems
• Services are tied to hosts
– A service is more than just one host: replication, migration, composition
• Packets might require processing at intermediaries before reaching destination
– “Middleboxes” (NATs, firewalls, …)

• Thesis: proper naming can cure some ills
– Layered naming provides layers of indirection and shielding
• Many proposals advocate large-scale, overarching architectural change
– Routers, end-hosts, services
• Proposal:
– Changes “only” hosts and name resolution
– Synthesis of much previous work

• Two global namespaces: DNS and IP addresses
• These namespaces are host-centric
– IP addresses: network location of host
– DNS names: domain of host
– Both closely tied to an underlying structure
– Motivated by host-centric applications

• Host-centric names are fragile
– If a name is based on mutable properties of its referent, it is fragile
– Example: If Joe’s Web page www.berkeley.edu/~hippie moves to www.wallstreetstiffs.com/~yuppie, Web links to his page break
• Fragile names constrain movement
– IP addresses are not stable host names
– DNS URLs are not stable data names

1. Which entities should be named?
2. What should names look like?
3. What should names resolve to?

• Service identifiers ( SIDs ) are hostindependent data names
• End-point identifiers ( EIDs ) are location-independent host names
• Protocols bind to names, and resolve them

User-level descriptors
(e.g., search)
App-specific search/lookup returns SID
App session
Use SID as handle
Resolves SID to EID
Opens transport conns
Transport Bind to EID
Resolves EID to IP
IP
IP hdr EID TCP SID …
Application
App session
Transport
IP

1. Which entities should be named?
2. What should names look like?
3. What should names resolve to?

Flat
Stable-name principle: A stable name should not impose restrictions on the entity it names
• Flat names impose no structure on entities
–Structured names stable only if name structure matches natural structure of entities
–Can be resolved scalably using, e.g., DHTs
• Flat names can be used to name anything
–Once you have a large flat namespace, you never need other global “handles”

• SID abstracts all object reachability information
• Objects: any granularity (files, directories)
• Benefit: Links (referrers) don’t break
Domain H
10.1.2.3
<A HREF= http://f012012/pub.pdf
>here is a paper</A>
/docs/
(10.1.2.3,80,
/docs/)
(20.2.4.6,80,
Resolution /~user/pubs/)
Service
Domain Y
20.2.4.6
/~user/pubs/

• Global resolution infrastructure needed
– Perhaps as “managed DHT” infrastructure
• Lack of local name control
• Lack of locality
• Not user-friendly
– User-level descriptors are human-friendly

1. Which entities should be named?
2. What should names look like?
3. What should names resolve to?

• Names usually resolve to “location” of entity
• Packets might require processing at intermediaries before reaching destination
– Only element identified by packet’s IP destination should inspect higher layers

Resolution svc
Dest EID d f
Mapping f ipf
Packet structure (dests only) ipf EID d TCP hdr
Firewall
EID s
EID
IP f ipf
• Delegate can be anywhere in the network, not necessarily on the IP path to d ( ipd )
• SID/EID can resolve to sequence of delegates
EID
IP d ipd