eco-dns: expected consistency optimization for dns chen stephanos matsumoto adrian perrig © 2013...
TRANSCRIPT
© 2013 Stephanos Matsumoto 1
ECO-DNS:Expected Consistency Optimization for DNS
Chen ChenStephanos Matsumoto
Adrian Perrig
© 2013 Stephanos Matsumoto 2
128.2.136.200128.2.136.200128.2.136.200128.2.136.200
128.2.136.200128.2.136.200
Motivation
Caching Server
ece
cmu
edu
.
cs
com
Client 1 Client 2
ece.cmu.edu ece.cmu.edu
128.2.129.29
Client 3
Inconsistency
© 2013 Stephanos Matsumoto 3
Motivation
• DNS caching is critical to reducing server load• However, cached records can be inconsistent• Currently, inconsistency can only be controlled
by time-to-live (TTL)
© 2013 Stephanos Matsumoto 4
Motivation
• Inconsistent records for popular sites affect many users
• Server operators "set and forget" TTLs• These problems will likely get worse due to…– Content delivery networks (CDNs)– Dynamic DNS (DDNS)– Future Internet proposals (Mobility First, SCION)
© 2013 Stephanos Matsumoto 5
Contributions
• Expected Aggregate Inconsistency (EAI)– Consistency metric that considers a record's
update frequency and popularity• ECO-DNS– Consistency control mechanism for DNS– Preserves "pull-based" nature of DNS– Backwards-compatible
© 2013 Stephanos Matsumoto 6
Key Ideas
• Considering a record's update frequency and popularity tells us what inconsistency we need to focus on
• ECO-DNS considers these factors to create an automated, backwards-compatible, flexible consistency control mechanism
• Remember this if you remember nothing else
© 2013 Stephanos Matsumoto 7
Outline
• Model– Defining an Inconsistency Metric– Caching server topology– Assumptions– Model and optimization
• System Design• Evaluation• Future Work and Conclusion
© 2013 Stephanos Matsumoto 8
Defining an Inconsistency Metric
• Inconsistency is caused by stale DNS records• How bad is this inconsistency?• More specifically:– How stale is a record when it is returned?– How many stale records are returned overall?
• TTLs can only approximate these factors
9
Defining an Inconsistency Metric
• Inconsistency:
• Expected aggregate inconsistency (EAI)
© 2013 Stephanos Matsumoto
# of updates to rbetween t and tq
All queries for r in time interval T
© 2013 Stephanos Matsumoto 10
Outline
• Model– Defining an Inconsistency Metric– Caching server topology– Assumptions– Model and optimization
• System Design• Evaluation• Future Work and Conclusion
© 2013 Stephanos Matsumoto 11
Caching Server Topology
• Records are generally cached directly from the authoritative server
• Caching from other caches is discouraged, but future schemes may change this
• Thus we consider caching in a logical cache tree
© 2013 Stephanos Matsumoto 12
Caching Server Topology
© 2013 Stephanos Matsumoto 13
Caching Server Topology
Inconsistency "cascades"
© 2013 Stephanos Matsumoto 14
Outline
• Model– Defining an Inconsistency Metric– Caching server topology– Assumptions– Model and optimization
• System Design• Evaluation• Future Work and Conclusion
© 2013 Stephanos Matsumoto 15
Assumptions
• Query and update arrivals can be modeled by a Poisson Process
• Query patterns of different caching servers are independent
• Caching servers proactively cache (prefetch) new record before expiration
© 2013 Stephanos Matsumoto 16
Outline
• Model– Defining an Inconsistency Metric– Caching server topology– Assumptions– Model and optimization
• System Design• Evaluation• Future Work and Conclusion
© 2013 Stephanos Matsumoto 17
Model and Optimization
• How does our Poisson process assumption help us calculate the inconsistency?
• Over time period of length ΔT:– Expected query arrival time: – Expected missed updates for each query:– Expected number of queries:
• EAI for a single cache:
© 2013 Stephanos Matsumoto 18
Model and Optimization
Inconsistency "cascades"
© 2013 Stephanos Matsumoto 19
Model and Optimization
© 2013 Stephanos Matsumoto 20
Model and Optimization
• Based on the Poisson Process assumption, the EAI over a time interval is
© 2013 Stephanos Matsumoto 21
Model and Optimization
© 2013 Stephanos Matsumoto 22
Model and Optimization
• The TTL minimizing the cost function is:
© 2013 Stephanos Matsumoto 23
Outline
• Model• System Design– Parameter Monitoring and Aggregation– Setting the TTL– Prefetching DNS Records
• Evaluation• Future Work and Conclusion
© 2013 Stephanos Matsumoto 24
Parameter Monitoring/Aggregation
• What information is necessary to find the optimal TTL?
• Which nodes need to keep track of this information?
© 2013 Stephanos Matsumoto 25
Parameter Monitoring/Aggregation
Set update frequency μ
Collect λ's from children
Estimate λ from queries
© 2013 Stephanos Matsumoto 26
Parameter Monitoring/Aggregation
• Estimate λ using a sliding window for queries• Send λ using special DNS message
© 2013 Stephanos Matsumoto 27
Outline
• Model• System Design– Parameter Monitoring and Aggregation– Setting the TTL– Prefetching DNS Records
• Evaluation• Future Work and Conclusion
© 2013 Stephanos Matsumoto 28
Setting the TTL
• Two choices for TTL:– Record-specified TTL (current method)– Locally calculated optimal TTL
• What are the pros and cons of each?
© 2013 Stephanos Matsumoto 29
Setting the TTL
• If we only use the record-specified TTL– Very little consistency control– Cache poisoning attacks can last a long time
• If we only use the locally calculated TTL– Unpopular records have a very large TTL
© 2013 Stephanos Matsumoto 30
Setting the TTL
• Solution: set TTL to be the minimum of the two values
• Record-specified TTL becomes an upper bound
© 2013 Stephanos Matsumoto 31
Outline
• Model• System Design– Parameter Monitoring and Aggregation– Setting the TTL– Prefetching DNS Records
• Evaluation• Future Work and Conclusion
© 2013 Stephanos Matsumoto 32
Prefetching DNS Records
• Pros and cons of prefetching records– Latency for a cache miss can be an order of
magnitude more than a cache hit– Prefetching an unpopular record provides little
benefit for the extra cost in bandwidth overhead
© 2013 Stephanos Matsumoto 33
Prefetching DNS Records
• Solution: prefetch only the most popular records– Popularity can be measured by query rate
parameter λ or relative to other records– Saves cache space by evicting unpopular records
© 2013 Stephanos Matsumoto 34
Outline
• Model• System Design• Evaluation– Goals and Methodology– Single-Level Caching– Multi-Level Caching– Dynamic Parameter Changes
• Future Work and Conclusion
© 2013 Stephanos Matsumoto 35
Goals and Methodology
• Three main questions:– Does ECO-DNS achieve better consistency than
today's DNS for the same bandwidth overhead?– Is multi-level caching more consistent than single-
level caching for the same bandwidth overhead?– How well does ECO-DNS adapt to dynamic
parameter changes?
© 2013 Stephanos Matsumoto 36
Goals and Methodology
• Simulations based on real-world data– KDDI (a large Japanese ISP) provided DNS trace
data for 10 minutes every 4 hours over 2 days– CAIDA provided inferred AS relationships, which
may model the topology of logical cache trees
© 2013 Stephanos Matsumoto 37
Outline
• Model• System Design• Evaluation– Goals and Methodology– Single-Level Caching– Multi-Level Caching– Dynamic Parameter Changes
• Future Work and Conclusion
© 2013 Stephanos Matsumoto 38
Single-Level Caching
• Use KDDI traces for query arrival times• Compare normalized reduced cost U for
various c and μ
© 2013 Stephanos Matsumoto 39
Single-Level Caching
© 2013 Stephanos Matsumoto 40
Outline
• Model• System Design• Evaluation– Goals and Methodology– Single-Level Caching– Multi-Level Caching– Dynamic Parameter Changes
• Future Work and Conclusion
© 2013 Stephanos Matsumoto 41
Multi-Level Caching
• Generate logical cache trees from CAIDA data• Compare the cost of each node against the
cost it would have in today's DNS• We set the TTL in today's DNS to be the best
possible value and compared it to ECO-DNS
© 2013 Stephanos Matsumoto 42
Multi-Level Caching
© 2013 Stephanos Matsumoto 43
Outline
• Model• System Design• Evaluation– Goals and Methodology– Single-Level Caching– Multi-Level Caching– Dynamic Parameter Changes
• Future Work and Conclusion
© 2013 Stephanos Matsumoto 44
Dynamic Parameter Changes
• Simulate random queries at the mean rate for each 4-hour period recorded by KDDI
• Use two schemes to estimate λ:– Time-based: divide number of queries in the past
n seconds by n– Count-based: keep track of the nth most recent
query time and divide n by the time interval
© 2013 Stephanos Matsumoto 45
Dynamic Parameter Changes
© 2013 Stephanos Matsumoto 46
Dynamic Parameter Changes
© 2013 Stephanos Matsumoto 47
Outline
• Model• System Design• Evaluation• Future Work and Conclusion
© 2013 Stephanos Matsumoto 48
Future Work and Conclusion
• Future Work– Full implementation– Security considerations• What if nodes misrepresent their estimates of λ?• What if nodes do not respect their TTL?
© 2013 Stephanos Matsumoto 49
Future Work and Conclusion
• Conclusion– Our consistency metric EAI allows us to explore
the tradeoff among various parameters– Out model based on EAI allows us to automate
optimization of the TTL to specified inconsistency and bandwidth costs
– ECO-DNS is lightweight, backwards-compatible, and flexible to real-time network changes