User-Perceived Latency

Long perceived latency is the most serious WWW performance problem

The delay from the time a request is issued until response is received.

HTTP Request-response

DNS lookup (address to name)

TCP connection setup

Server processing time +/ reverse DNS (access control)

Transmission timeRequest-response

RTT

TCP SYNTCP SYN

TCP ACKTCP ACK

ACK, HTTP GETACK, HTTP GET

HTTP responseHTTP response

HTTP/1.1

Persistent HTTP: TCP connection is re-used for additional HTTP requests

Pipelining: HTTP requests - responses are interleaved to save RTTs

HTTP GETHTTP GET

HTTP responseHTTP response

HTTP/1.0HTTP/1.0 : TCP connection for each : TCP connection for each HTTP request.HTTP request.HTTP/1.1HTTP/1.1: Persistence and Pipelining: Persistence and Pipelining

HTTP GETHTTP GET

HTTP GETHTTP GET

HTTP responseHTTP response

HTTP responseHTTP response

Proactive DNS Caching:Addressing a Performance Bottleneck

Edith CohenAT&T Labs-Researchhttp://www.research.att.com/~edith

Haim KaplanTel-Aviv Universityhttp://www.math.tau.ac.il/~haimk

Talk Overview

Overview and Motivation DNS architecture effect of DNS lookup latency

Proactive DNS caching Renewal Policies Simultaneous Validation

Conclusion

Domain Name System

Essential for Internet name-based communicationEssential for Internet name-based communication Many-to-many mapping (virtual hosting, mirrors, Many-to-many mapping (virtual hosting, mirrors,

aliases)aliases) Distributed database maintained by a hierarchy Distributed database maintained by a hierarchy

of name-serversof name-servers

hostname IP-addresswww.research.att.com 135.207.23.30

ns-1.amazon.comamazon.com

ns.research.att.comresearch.att.com

dnsprime.att.comatt.com

root.

DNS Hierarchy

LocalName-Server

resolving www.research.att.com

DNS Lookup

Root DNS server returns NS for att.com

dnsprime.att.com returns NS for

research.att.com

ns0.research.att.com returns IP-address for

www.research.att.com

Resolution may involve multiple remote name-serversResolution may involve multiple remote name-servers

Resolving Hostnames

Browser: if no answer in browser cache, query is sent to

the local DNS server.

Name-server: use own cache. For missing info, iteratively

query remote name-servers, while following referrals/

delegations.

DNS Caching Mechanism

Data is stored in Resource Records (RR) (NS, A, CNAME, Data is stored in Resource Records (RR) (NS, A, CNAME, SOA)SOA)

Each record has a Each record has a TTL value TTL value (Time To Live)(Time To Live) TTL values are assigned by respective domain administrators.TTL values are assigned by respective domain administrators. Record may be cached and used only for TTL duration.Record may be cached and used only for TTL duration.

Latency Effect of DNS Lookups All requests > 60 sec after previous, ATT log

Latency Effect of DNS Lookups (2) AltaVista referrals requests, ATT proxy log

Performance effect...

NLANR cache service times on AKAMAI servers: {a4,a111}.g.akamaitech.netdomain TTL

akamaitech.net 25hr

g 1000 sec

a4, a111 20 sec

Service Times DistributionURLs served by a4.g.akamaitech.net

0 to 3 seconds

7351 requests in 6 days, 90%<200ms, 95% < 500ms

3 to 6 seconds

4% > 3 seconds

Issues with DNS Latency

RTTs to (several) remote name servers Not addressed by fatter pipes, faster high-capacity content servers.

Highly sensitive to packet loss Inconsistent - fraction of lookups suffer long/pathological delaysAs Internet service improves, will increasingly become more noticeable.

Before DNS DNS

no lookup delay (data is available locally)

scalability problems: growing database size coherence single point of failure/load

Scalable & robust distributed

control distributed

presence lookup delays from

remote queries

one hosts.txt file:centrally maintainedftp’d where needed

Hierarchy of distributed name-servers.

Passive DNS caching

Query remote NS only to answer a Query remote NS only to answer a current client requestcurrent client request

Cache (use) results till TTL expiresCache (use) results till TTL expires

Used by BIND name-server software

Proactive DNS caching

Renewal Policies: auto-refresh entries just before TTL expires

Simultaneous Validation:Simultaneous Validation: Concurrently validate Concurrently validate & use “expired” address& use “expired” address

Our Proposals:Our Proposals:

Guidelines:Respect TTL values (be transparent to client)Respect TTL values (be transparent to client)Minimize overhead to DNS serversMinimize overhead to DNS servers

Methodology and Logs Proxy logs Simulate associated DNS cache Separately issued DNS queries to obtain: Separately issued DNS queries to obtain:

TTL values, rate-of-change of IP-address.TTL values, rate-of-change of IP-address.

Requests (1000)

Hosts(1000)

period

AT&T489 10.5 11/8/96-

11/19/96

UC(NLANR)

10837 91 5/18/99-6/5/99

Performance of Passive caching

DNS misses(% HTTP req.)

First-seen misses(% DNS misses)

AT&T 32K 6.5% 33%

UC(NLANR)

941K 8.7% 9.7%

Renewal Policies

R-LRUR-LRU renew r times passed the most-recent cache hit renew r times passed the most-recent cache hit R-LFUR-LFU grant r additional renewals per hit ( TTL interval) grant r additional renewals per hit ( TTL interval) R-FIFOR-FIFO grant r renewals at entry time to the cache grant r renewals at entry time to the cache R-OPTR-OPT optimal omniscient offline renewal policy optimal omniscient offline renewal policy

- Issue a renewal query upon expiration.- Issue a renewal query upon expiration.- Policy determines when to renew.- Policy determines when to renew.- Tradeoff of overhead/reduced-latency.- Tradeoff of overhead/reduced-latency.

Performance of Renewal Policies ATT proxy log

Performance of Renewal Policies UC (NLANR) log

Renewal Policies: Conclusions from Experiments

R-LRU and R-LFU performed equally well across logs R-LRU and R-LFU performed equally well across logs R-FIFO did not perform as wellR-FIFO did not perform as well Reduction in misses corresponds to reduction in Reduction in misses corresponds to reduction in

long DNS query timeslong DNS query times More effective for more clients More effective for more clients

Renewal Policies: Implementation and Extensions

Most natural Implementation is within the name-serverMost natural Implementation is within the name-server Overhead control:Overhead control:

Pre-expiration renewals (usually 1 RTT)Pre-expiration renewals (usually 1 RTT) off-peak renewalsoff-peak renewals

Policies can be adapted to account for varying DNS Policies can be adapted to account for varying DNS resolution timesresolution times

TTL versus Rate-of-change

TTL values are set conservatively: Rate-of-TTL values are set conservatively: Rate-of-change of addresses is significantly lower than change of addresses is significantly lower than TTL value.TTL value.

So, when “expired” records are discarded, we So, when “expired” records are discarded, we often loose valuable and valid informationoften loose valuable and valid information

Challenge:How do we benefit from valid expired addresses while still respecting TTL values.

Simultaneous Validation

Keep expired address records.Keep expired address records. When a client request arrives, When a client request arrives, concurrentlyconcurrently::

Initiate a connection to host, using expired IP-address, Initiate a connection to host, using expired IP-address, and start fetching contentand start fetching content

Issue a validating DNS queryIssue a validating DNS query If validation is successful, serve the content to the clientIf validation is successful, serve the content to the client

SV Latency Gain

DNS lookupsession with Web server:

Establishing TCP connection(s), sending HTTP request(s), ...

Simultaneous Validationsuccess rate

SV success rate (out of DNS misses on

epreviously-seen hostnames)AT&T 97.9%

UC(NLANR)

99.1%

Simultaneous Validation:Implementation Choices

browser or proxy (with a separate DNS browser or proxy (with a separate DNS cache)cache) requires maintenance of a separate name-to-requires maintenance of a separate name-to-

address cacheaddress cache single-entity implementationsingle-entity implementation

name-server (using its internal cache)name-server (using its internal cache) requires protocol support for 2-phase requires protocol support for 2-phase

resolutionsresolutions requires separate proxy or browser support requires separate proxy or browser support

SV is more effective for a larger user base.SV is more effective for a larger user base.

Summary

DNS lookup delays can be addressed by increasing local availability of RRs

Renewal Policies incur overhead of additional queries simple limited deployment is effective inter-request-time < c * TTL

Simultaneous Validation minimal overhead more involved implementation inter-request-time < IP-address-lifetime

Future Work

Single, replicated, hostname database + SV

Co-operative DNS caching Distributed “local” name serverSV and Renewal at the RR levelCollect better data: name-server logs

combined with logged HTTP requestsRefreshment policies for Web content