One-sentence summary:

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.

Overview/Main Points

• 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 repository.
• 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 origin servers.
• 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 identity, etc.
• 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 performance levels.

Relevance

Straightforward (thus, potentially useful) framework for managing content distribution.

Flaws

No experimental data to support the benefit claims.