|Dinseh C. Verma, Sreaphin Calo,
IEEE Network Magazine, 16(2):34-39, March 2002
Proposes a way to manage content using CDNs via centrally-stored,
administrator-dictated policies; policy agents reside at the CDN caches and at
the origin servers.
- There are 3 main approaches to improve performance of apps that
use the network: Integrated Services/RSVP, Differentiated Services,
and CDNs. The common problem across all these approaches is the
maintenance of a common configuration and behavior across a large
number of widely distributed devices.
- The IETF is defining a policy architecture for IntServ and
DiffServ for policy-based networking. Policies are a set of
rules that specify how the devices in the netowrk should deal with
different types of traffic. The architecture consists of a
policy repository (e.g., implemented as an LDAP directory), policy
enforcement points (function inside routers that makes QoS decisions
e.g. by marking packets according to DiffServ), and policy decision
points (sw module inside routers that decides which set of DiffServ
markings to make active at any given point). Finally, there is a
policy mgmt tool used by administrators to populate the policy
- Policies take the form of "if <condition>
then <action>" rules, with the <condition>
indicating a specific situation encountered by the device, and
<action> represents what the device needs to do in response.
Policy conditions can be thought of as keys indexing a table of
actions. The authors use this same tabular model for CDN policies.
- A problem with CDNs is that caching is adequate for static data,
but not for dynamic content. There is, however, an increasing
trend for CDNs providers to add support for dynamic content, such as
executing cgi-bin's, servlets, or JSPs on the cache nodes.
- The problem that policies solve is deciding what content should be
cached in the CDN vs. what content should be served directly from
- A CDN policy's <action> field would
indicate whether a piece of content is cacheable, along with a
consistency model for it (different apps have different cache
consistency requirements, but the total number of interesting
consistency models and protocols that actualize those models is rather
small, so they can be listed in the policy table).
- A static policy's <condition>
field (index in the table) would contain things like: source IP,
destination IP, destination port, protocol field, accessed URI, user
- A dynamic policy's
<condition> field could have
additional items pertaining to network conditions. For instance,
one could decide to make content cacheable if the request arrival rate
at the origin server exceeds a given threshold, but revert to
non-cacheable when it drops below the threshold. Dynamic
policies require network performance monitoring, which is assumed to
be done at the origin server.
- The paper models the cost savings obtained with dynamic policies
with an M/M/1 model (Poisson arrivals/exponential service time/single
server). It shows the approach is useful particularly with CDN
providers (e.g., Akamai) that charge proportionally to the amount of
content they deliver from their caches. Dynamic policies can
minimize cost while optimizing caching ratio to meet the required
Straightforward (thus, potentially useful) framework for managing content
No experimental data to support the benefit claims.