CoDoNs A High-Performance Alternative for the Domain Name System Emin Gün Sirer Venugopalan...
-
Upload
robyn-mclaughlin -
Category
Documents
-
view
215 -
download
1
Transcript of CoDoNs A High-Performance Alternative for the Domain Name System Emin Gün Sirer Venugopalan...
CoDoNs
A High-Performance Alternative for the Domain Name System
Emin Gün SirerVenugopalan Ramasubramanian
Computer Science, Cornell University
introduction
caching is widely-used to improve latency and to decrease overheadpassive caching caches distributed throughout the
network store objects that are encountered
not well-suited for a large-class applications
problems with passive caching
no performance guaranteesheavy-tail effect large percentage of queries to unpopular
objects ad-hoc heuristics for cache management
introduces coherency problems difficult to locate all copies weak consistency model
domain name system (dns)
part of critical Internet infrastructureresolves names to addresses “www.cnn.com” 67.45.223.12
also resolves other flat queries hostname to mail server mappings hostname to owner information ipaddress to hostname and others
based on a static hierarchy of servers
dns operationroot
edu milgovcom org
cornell upenn
cs math ece arts
www syslab
•namespace partitioned into hierarchy
•lookup occurs from the top down
•through delegations
•static, manually-crafted, fragile hierarchy
•lookups are expensive
•no bounds!
cnn
ns1.verisign.com
a.root-servers.net
cit.cornell.edu
ns.cs.cornell.edu
dns band-aidsroot
edu milgovcom net
cornell upenn
cs math ece cit
www syslab
•replicate nodes at the top of the hierarchy
•13 root servers•13 com, mil servers•2 org servers
•use passive caching for dns records
•at every possible location
•associate a TTL with every dns record
•no invalidations
dns problemsperformance bottleneck cold misses lead to high latencies
vulnerable to DDoS attacks November 2002 attack on root servers can target branches of the name tree
high load on nodes close to the root tree not a scalable data structure
manual maintenance expensive, error prone DNS hierarchy full of errors
coherency guarantees at odds with performance low TTL enables dynamic updates
reduces performance
a better solution?
distributed hash tables (DHTs) can help self-organizing scalable worst-case performance bounds
but average-case performance for scalable DHTs is too high
0122
prefix-matching DHTsobject 0121
0121 = hash(“www.cnn.com”)
2012
0021
0112
map all nodes into an identifier space
map all objects into same space based on key
logbN hops several RTTs on the Internet
DHT properties
scalable DHTs not suited for DNS Morris, Balakrishnan et al.
O(log N) overlay hops is too slow for critical, latency-sensitive applications
need faster lookups proactive, model-driven caching can
help
Outline
Problem passive caching DNS: a motivating example DHTs
Beehive approach analytical model distributed implementation evaluation
CoDoNs overview & operation evaluation
Summary
overview of beehive
general replication frameworksuitable for structured DHTs decentralization, self-organization, resilience
properties high performance: O(1) average lookup time scalable: minimize number of replicas and
reduce storage, bandwidth, and network load adaptive: promptly respond to changes in
popularity – flash crowds
key intuition
tunable latency adjust extent of
replication for each object
fundamental space-time tradeoff
2012
0021
0112
0122
analytical model
optimization problemminimize: total number of replicas, s.t.,
average lookup performance C
configurable target lookup performance continuous range, sub one-hop
minimizing number of replicas decreases storage and bandwidth overhead
target domainzipf-like query distributions number of queries to rth popular object 1/r
fraction of queries for m most popular objects (m1- - 1) / (M1- - 1)
commonly encountered in practice dns, web
typically between 0.80 and 1.00 MIT DNS trace = 0.91
trace Dec UPisa FuNet UCB Quest NLANR
0.83 0.84 0.84 0.83 0.88 0.90
level of replication
level of replication nodes share i prefix-digits with the
object
i hop lookup latency lower level means greater extent of
replication
replicated on N/bi nodes
optimization problem
minimize (storage/bandwidth)x0 + x1/b + x2/b2 + … + xK-1/bK-1
such that (average lookup time is C hops)K – (x0
1- + x11- + x2
1- + … + xK-11-) C
andx0 x1 x2 … xK-1 1
b: base K: logb(N) xi: fraction of objects replicated at level i
optimal closed-form solution
dj (K’ – C)
1 + d + … + dK’-1
11 - [ ]
x*i =, 0 i K’ – 1
where d = b(1- ) /
, K’ i K
K’ is determined by setting x*K’-1 1 dK’-1 (K’ – C) / (1 + d + … + dK’-1)
1
1
implications
O(1) average-case lookup performance C hops for Zipf-like distributions
bounded worst-case K’ forms upper bound
optimal number of replicas for 1 no wasted bandwidth, storage or
coordination
beehive: system overview
estimation popularity of objects, zipf parameter local measurement, limited aggregation
replication apply analytical model independently at
each node push new replicas to nodes at most one hop
away
beehive replication protocol
0 1 2 *
home node
EL 3
0 1 *0 1 * 0 1 *EB IL 2
0 *0 *0 * 0 * 0 * 0 * 0 * 0 * 0 *
A B C D E F G H I
L 1
object 0121
replication protocol
low-overhead mechanisms distributed, no consensus asynchronous performed in the background
modest state per object id (128 bits) home node indicator (1 bit) version number (64 bits)
mutable objects
leverage the underlying structure of DHT replication level indicates the locations of all
the replicas
proactive propagation to all nodes from the home node home node sends to one-hop neighbors with
i matching prefix-digits level i nodes send to level i+1 nodes
implementation and evaluation
implemented using Pastry as the underlying DHT evaluation using a real DNS workload
MIT DNS trace 1024 nodes, 40960 objects compared with passive caching on pastry
main properties evaluated lookup performance storage and bandwidth overhead adaptation to changes in query distribution
0 8 16 24 32 400
0.5
1
1.5
2
2.5
3
time (hours)
late
ncy
(hops)
PastryPC-PastryBeehive
evaluation: lookup performance
passive caching is not very effective because
of heavy tail query distribution and mutable objects.
beehive converges to the target of 1 hop
evaluation: overhead
0 8 16 24 32 400
0.5
1
1.5
2x 10
6
time (hours)
obje
ct t
ransf
ers
(#
)
PC-PastryBeehive
Object Transfers Storage
average number of replicas per nodePastry 40
PC-Pastry 420
Beehive 380
evaluation: flash crowds
32 40 48 56 64 72 800
0.5
1
1.5
2
2.5
3
Latency
time (hours)
late
ncy
(hops)
Pastry
PC-Pastry
Beehive
Outline
Problem passive caching DNS: a motivating example DHTs
Beehive approach analytical model distributed implementation evaluation
CoDoNs overview & operation evaluation
Summary
Cooperative Domain Name System (CoDoNS)
replacement for legacy DNS peer-to-peer DNS based on Beehive
incremental deployment path completely transparent to clients uses legacy DNS to populate resource
records on demand can operate without legacy DNS
deployed on planet-lab
CoDoNs operationhome node initially populates CoDoNs with binding from legacy DNS
CoDoNs will propagate the optimal number of replicas
Upon DNS record expiration, the home node checks binding for change
www.cnn.com
CoDoNs securitynot an issue in a single administration domain
e.g. akamai, google, msn, etc.
attacks targeted at the DHT Castro et al. ’02 work on secure DHTs
attacks targeted at Beehive outlier elimination limited impact
attacks targeted at CoDoNs DNSSEC signatures
dns trickeryserver-side computation akamai and similar companies reroute clients
to nearest nodes through dns dynamically computed records with low ttl not compatible with caching
CoDoNs supports this hack by not caching entries whose TTL is lower than a threshold but better to perform server selection on the
client side or not at all… CoDoNs already provides high
average case performance and load balancing
CoDoNs implicationsname delegations can be purchased and propagated independently of server setup
no static tree naming hierarchy independent of physical
server hierarchy
no manual configuration misconfiguration and broken delegations
unlikely
no ttl push updates at any time
no verisign
advantages of CoDoNShigh performance low lookup latency median latency of 7 ms for codons (planet-lab),
39 ms for legacy DNS
resilience against denial of service attacks load balancing around hotspots self configuring around host and network failures
fast, coherent updates no TTLs, updates can be propagated at any time
related work - DHTsPrefix-based
Plaxton, Pastry, Chord, Tapestry O(log N) lookup, O(log N) storage
deBruijn graphs Koorde, [Wieder & Naor 03] O(log N/log log N) lookup, O(log N) storage
Butterfly Viceroy: O(log N) lookup, O(1) storage
Farsite O(d) lookup, O(dn1/d) storage
Kelips Kelips: O(1) lookup, O(N) storage
Full knowledge [Gupta, Liskov, Rodrigues]: O(1) lookup, O(N) storage
related work - DNStraces and zipf distributions
web caching and zipf-like distributions: evidence and implications Breslau, Cao, Fan, Phillips, and Shenker [infocom’99]
popularity of gnutella queries and their implications on scalability Sripanidkulchai [2002]
caching and replication replication strategies in unstructured p2p networks
Cohen and Shenker [sigcomm’02] cup: controlled update propagation in p2p networks
Roussopoulos and Baker [usenix’03]
DNS development of DNS system
Mockapetris [sigcomm’88] DNS performance and effectiveness of caching
Jung, Sit, Balakrishnan, and Morris [sigmetrics’01] serving DNS using a peer-to-peer lookup service
Cox, Muthitacharoen, and Morris [iptps’02]
conclusions
model-driven proactive caching O(1) lookup performance with optimal replica
cost
beehive: a general replication framework structured overlays with uniform fan-out high performance, resilience, improved
availability well-suited for latency sensitive applications
CoDoNs: a modern replacement for DNS
http://www.cs.cornell.edu/people/egs/beehive/
evaluation: instantaneous bandwidth overhead
32 40 48 56 64 72 800
5
10
15
20
Object Transfers per sec
time (hours)
obje
ct t
ransf
ers
per
sec
PC-Pastry
Beehive
typical values of zipf parameter
MIT DNS trace: = 0.91Web traces:
trace Dec UPisa FuNet UCB Quest NLANR
0.83 0.84 0.84 0.83 0.88 0.90
comparative overview of structured DHTs
DHT lookup performance
CAN O(dN1/d)
Chord, Kademlia, Pastry, Tapestry, Viceroy
O(logN)
de Bruijn graphs (Koorde) O(logN/loglogN)
Kelips, Salad, [Gupta, Liskov, Rodriguez]
O(1)