October 25, 2001 Stanford Networking Seminar

Aging Through Cascaded Caches:

Performance Issues in the Distribution of Web Content.

Edith CohenAT&T Labs-research

Haim KaplanTel-Aviv University

October 25, 2001 Stanford Networking Seminar

HTTP Freshness Control

• Cached copies have:– Freshness lifetime– Age (elapsed time since fetched from

origin)• TTL (Time to Live) = freshness lifetime – age• Expired copies must be validated

before they can be used (request constitutes a ”cache miss”).

Body(content)

headerCache-directives

October 25, 2001 Stanford Networking Seminar

Aging of Copies

Origin server

Freshness Lifetime = 10 hours

Age = 0TTL = 10

8:00am

October 25, 2001 Stanford Networking Seminar

Aging of Copies

Origin server

Freshness Lifetime = 10 hours

Age = 1TTL = 9

9:00am12:00pm

Age = 4TTL = 6

3:00pm

Age = 7TTL = 3

October 25, 2001 Stanford Networking Seminar

Aging of Copies

Origin server

Freshness Lifetime = 10 hours

6:00pm

Age = 10TTL = 0

October 25, 2001 Stanford Networking Seminar

Aging thru Cascaded Caches

reverse-proxy cacheorigin

server

8:00am proxy cache

s

Age = 0TTL = 10

October 25, 2001 Stanford Networking Seminar

5:00pm

Age = 9TTL = 1

Aging thru Cascaded Caches

reverse-proxy cacheorigin

server

proxy cache

s

October 25, 2001 Stanford Networking Seminar

6:00pmAging thru Cascaded Caches

reverse-proxy cacheorigin

server

proxy cache

s

Age = 10TTL = 0

October 25, 2001 Stanford Networking Seminar

6:00pmAging thru Cascaded Caches

reverse-proxy cacheorigin

server

proxy cache

s

Age = 0TTL = 10

October 25, 2001 Stanford Networking Seminar

TTL of a Cached Copy

Freshness-lifetime

t

TTL

Requestsat client cache:

From OriginMMFrom CacheM M M

October 25, 2001 Stanford Networking Seminar

Age-Induced Performance Issues for Cascaded Caches

• Caches are often cascaded (path between web server and end-user includes 2 or more caches.).

• Copies obtained thru a cache are less effective Copies obtained thru a cache are less effective than copies obtained thru an origin server.than copies obtained thru an origin server.

Reverse proxies increase validation traffic !!Reverse proxies increase validation traffic !!• More misses at downstream caches mean:

– Increased traffic between cascaded caches.– Increased user-perceived latency.

October 25, 2001 Stanford Networking Seminar

Research Questions• How does miss-rate depend on the

configuration of upstream cache(s) and on request patterns ?

• Can upstream caches improve performance by proactively reducing content age ? how?

• Can downstream caches improve performance by better selection or use of a source?

• Request sequences: Arbitrary, Poisson, Pareto, fixed-frequency, Traces.

• Models for Cache/Source/Object relation: Authoritative, Independent, Exclusive.

Our analysis:

October 25, 2001 Stanford Networking Seminar

Basic Relationship Modelscache/source/object

•Authoritative: “Origin server:” 0 age copies.•Exclusive: all misses directed to the same cache.•Independent: each miss is directed to a different independent upstream cache.

Cache-3 Cache-2 Cache-1

www.cnn.com

Cache-BCache-A Cache-C Cache-D

October 25, 2001 Stanford Networking Seminar

Basic Models…

Theorem: On all sequences, the number of misses obeys: Authoritative < Exclusive < Independent

•Authoritative age(t) = 0 •Exclusive age(t) = T - (t+a) mod T•Independent age(t) e U[0,T]

Object has fixed freshness-lifetime of T. Miss at time t results in a copy with age:

Theorem: Exclusive < 2*AuthoritativeIndependent < e*Authoritative

October 25, 2001 Stanford Networking Seminar

TTL of “Supplied” Copy

Freshness-

lifetime

t

TTL

RequestsReceivedat source:

ExclusiveAuthoritative

Independent

Source:

October 25, 2001 Stanford Networking Seminar

How Much More Traffic?

Log\Model Authoritative Exclusive Independent

NLANR UC 47% 55% 57%

NLANR SD 52% 60% 62%

Miss-rate for different configurations

October 25, 2001 Stanford Networking Seminar

Rejuvenation at Source CachesRejuvenation: refresh your copy pre-term once its TTL drops below a certain fraction v of the Lifetime duration.

t

TTL

Requests at client:

24h

12h

v=0.5

no rejuv.

source

client

October 25, 2001 Stanford Networking Seminar

Rejuvenation’s Basic Tradeoff:

Is increase/decrease monotone in V (?)

•Increases traffic between upstream cache and origin (fixed cost)

originUpstreamcache

DownstreamClient caches

•Decreases traffic to client caches (larger gain with more clients)

October 25, 2001 Stanford Networking Seminar

Interesting Dependence on V…

• Independent(v) <> Exclusive(v)• Independent(v) is monotone: if v1 > v2, Independent(v1) > Independent(v2)• Exclusive(v) is not monotone

(miss-rate can increase !!)• Integral 1/v (synchronized rejuvenation): Exclusive(v) < Independent(v) and is monotone (Pareto, Poisson, not with fixed-frequency).

October 25, 2001 Stanford Networking Seminar

October 25, 2001 Stanford Networking Seminar

October 25, 2001 Stanford Networking Seminar

How Can Non-integral 1/v Increase Client Misses?

Freshness-

lifetime

t

TTL Upstream CacheDownstream Client Cache

Copy at client is not synchronized with source.When it expires, the rejuv source has an aged copy.

Requests atClient cache:

Pre-termrefreshes

October 25, 2001 Stanford Networking Seminar

Why Integral 1/v Works Well?

Freshness-

lifetime

t

TTL Upstream Cache

Cached copies remain synchronized

Requests atUpstream cache:

Downstream Client CachePre-termrefreshes

v=0.5

October 25, 2001 Stanford Networking Seminar

Some Conclusions• Configuration: Origin (“Authoritative”) is best.

Otherwise, use a consistent upstream cache per object (“Exclusive”).

• “No-cache” request headers: resulting sporadic refreshes may increase misses at other client caches. (But it is possible to compensate…).

• Rejuvenation: potentially very effective, but a good parameter setting (synchronized refreshes) is crucial.

• Behavior patterns: Similar for Poisson, Pareto, traces, (temporal locality). Different for fixed-frequency.

• For more go to http://www.research.att.com/~edith Full versions of: Cohen, Kaplan SIGCOMM 2001 Cohen, Halperin, Kaplan, ICALP 2001