eco-dns: expected consistency optimization for dns chen stephanos matsumoto adrian perrig © 2013...

© 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

© 2013 Stephanos Matsumoto 50

Thank you!

Questions?

smatsumoto@cmu.edu