WCDP: A protocol for web cache consistency Renu Tewari IBM Almaden Research Thirumale Niranjan IBM Software Group

WCDP Overview  More that just cache invalidations….  Updates via refresh  Different consistency levels  Scalability  Object groups  Distribution hierarchies origin Single/different admin domain Intermediaries CDNs, enterprise n/w, ISP Proxy Surrogate

WCDP Architecture WCDP Server WCDP Gateway WCDP clients HTTP/TCP Distribution hierarchy (optional) (optional protocol translation) Mirror Strong consistency Delta consistency

WCDP Design Features  Deployment cases  Work with CDN’s, ISP proxy caches,content mgmt engine, server-side software, publishing systems….  Delivery architectures  Point-to-point, application multicast, gateway across protocols and different servers  Invalidates and updates  Refresh directives, explicit expiration (default)  Atomic invalidates  Identify arbitrary groups of resources for consistency  using invalidation ids and group ids

WCDP Design Features …  Scalability  Group objects, messages and message distribution hierarchies  Different degrees of consistency  Strong, delta and explicit  Failure handling  Server and intermediary failure, network partition  Security  Plug-in based, default rely on SSL.  Subscription support  Explicit content group based or implicit based on external SLA

WCDP Protocol Example HTTP request GET HTTP response 200 OK Obj_inv_id: abc123 Content_grp_id: financial Register request content_grp_id = financial Register response WCDP client Server cnnfn cnnfn.com Invalidation request Obj_inv_id: abc123 Invalidate response

Message Types  Invalidate request/response  Invalidation action: refresh directive, delayed refresh, invalidate  consistency level: require commit  invalidation type: atomic, individual  Register request/response  Used of subscription  Join request/response  Used after failure and recovery  Commit request/response  Used for strong consistency  Heartbeat from server to client  Used for strong and delta consistency

WCDP Message Example  Invalidation request  Invalidation response

Object Invalidation Identity  Invalidation can address  Full-pages, fragments, groups  HTTP response include invalidation identifier  obj_invalidation_id  Opaque value with no semantic meaning  Same obj_invalidation_id for different variants of object  Cache maintains internal mapping  Obj_invalidation_id  obj_cache_id  Obj_cache_id same as external URL for static pages  Includes the HTTP header tags for fragments

Object Grouping  Objects in a group addressed as a unit for consistency maintenance or message scalability  HTTP response includes group identifier  obj_group_invalidation_id  E.g., all objects in a sub-directory  Atomic invalidates  Specify lock semantics to invalidate all objects in a group atomically  Implements mutual consistency  Individual invalidates  Each object in group treated separately

Content Groups and Subscription  Content group  Large aggregation of objects (by topics)  Intermediary can subscribe to a content group  Implicit subscription  External admin step  Explicit subscription  Use a register message  Discovering content groups  External LDAP directory  In the HTTP response

Consistency Support  Explicit  Default  similar to HTTP cache-control, expires tag  Strong  Two phase commit using invalidation acks and commit messages  Requires heartbeat  Delta  Invalidation with ack  Bounded message delay  Requires heartbeat  Mutual  Atomic invalidate of a group of objects

Strong Consistency Example WCDP client Invalidation request Obj_inv_id: abc123 Immediate Refresh=yes Consistency require_commit = yes Invalidate response Status:waiting_for_commit HTTP request GET HTTP response 200 OK Obj_inv_id: abc123 Content_grp_id: financial Commit request obj_inv_id: abc123 Commit response Status: OK WCDP Server

Failure and Recovery  Missing heartbeat from server (server failure)  Client reverts to explicit consistency  Send join message to re-subscribe  Missing invalidation response from client (client failure)  Remove from subscription group after timeout  No further heartbeats sent  Network partition  Client behaves as if server has failed  Server behaves as if client has failed  Reliable transport is assumed

Status and Future Work  Based partly on the content distribution framework of the Websphere Edge Server version 2.0  SOAP based implementation in future  Security enhancements to be added