Fwd: ESI Invalidation, RUP

For non-WEBI folks interested in ESI...

> Date: Tue, 7 Aug 2001 08:55:05 -0700
> From: Mark Nottingham <mnot(_at_)akamai(_dot_)com>
> To: webi(_at_)lists(_dot_)equinix(_dot_)com
> Subject: ESI Invalidation, RUP
> User-Agent: Mutt/1.2.5i
> Sender: owner-webi(_at_)equinix(_dot_)com
>
>
> As promised, a discussion of rup and ESI invalidation, regarding
> requirements, commonalities, etc. I use the terms 'cache' and
> 'authority' to identify the participants here, for clarity - these
> shouldn't be considered normative (although we do need to discuss
> this issue!).
>
> It would be compelling to be able to send an ESI-invalidation-style
> message to a gateway (say, for your CDN), and then have it propogated
> to all of the nodes in that CDN via RUP mechanisms. I hope to
> illustrate why that isn't practical here.
>
> ESI invalidation requires a request/response message exchange
> pattern, initiated by the content's authority (e.g., Web Server).
> There is no concept of channels - each invalidation message is
> self-describing as to what is being invalidated (through the
> selectors). The response (from the cache to the authority) is used to
> transmit metadata about the invalidation's status, or to raise faults
> if an error has occured (e.g., authentication, invalid selectors,
> etc.)
>
> This can be modeled with the following messages:
>
>   Invalidation                 (authority -> cache)
>   InvalidationResponseOrFault  (cache -> authority)
>
> To contrast, RUP seems to be moving to a model whereby caches decide
> to subscribe to a channel by some means, and then invalidations are
> sent from the authority to the caches as entities become stale.
>
> This could be modeled with the following messages:
>
>   SubscribeChannel  (cache -> authority)
>   ChannelHeartBeat  (authority -> cache)
>   Invalidation      (authority -> cache)
>
> There are variations here (such as using polling, etc.), but the
> flows are fundamentally the same. This is partially because it
> becomes quickly unreasonable to manage state about a large number of
> caches at the authority, therefore it must reside (as "what channels
> am I subscribed to") at the cache.
>
> Both models, therefore, have an Invalidation message flowing from the
> authority to the cache. However, ESI Invalidation messages contain
> state about what resources are to be invalidated (as the
> selector(s)), and assume that the authority keeps state about who is
> subscribed. RUP Invalidation messages have no such facility; they may
> only contain an identifier (e.g., a URI) to identify the channel that
> is invalidated, and assume that the cache keeps state about the
> association between resources and channels, and possibly the channels
> subscribed to.
>
> This is a fundamental difference; ESI invalidation is practical for
> cases where there are few caches for the authority to keep state
> about. RUP needs mechanisms to manage this state to enable messages
> to be distributed among a number of caches. As a result of this, RUP
> has a specialized message exchange pattern, and a level of
> indirection (channels) to make it manageable across a large number of
> devices.
>
> If the RUP mechanisms were used for ESI's purposes, it would require
> the introduction of a level of introduction (via channels) that may
> be felt as onerous by application servers; instead of a simple SOAP
> API which they can describe invalidations to, for example, they'd
> need to expose an interface (perhaps still with SOAP, although it
> would need to poll if it were using existing implementations) that
> described a channel, allowed subscriptions, maintained a heartbeat,
> etc.
>
> Conversely, if ESI message formats were used for RUP, it would
> require that all invalidation messages be propogated to all caches,
> and there would be issues in scaling the protocol, introducing
> intermediaries, etc.
>
> The question, then, is whether hybrid message formats would be
> useful. Personally, I feel that there is limited utility in combining
> what amount to a) different goals and b) different message exchange
> patterns. ESI Invalidation is useful for point-to-point,
> cross-administrative-domain invalidation; RUP, as far as I can see,
> is primarily useful for intra-CDN invalidation.
>
> The messages may have the same semantic ("invalidate something"), but
> that semantic is quite simple; the cruft around it (what do I
> invalidate? what information do I give back? etc.) is specific to
> these different use cases, and probably not too useful to standardize
> among them. In short, ESI is aimed at making life easy for content
> providers; RUP is geared towards managing distribution of messages
> among a large network.
>
> Regarding the 'ESI Invalidation to gateway, RUP mechanisms out to the
> surrogates' scenario above; I believe it is possible, if the gateway
> has a certain amount of intelligence about forming a channel from the
> selectors, making decisions about the ESI InvalidationResponse, etc.
>
> What may be interesting to discuss among the efforts is "what is the
> semantic of invalidation?" I.e., does it mean purge the object, or
> just mark it as stale? and so forth. There may be some atomic
> metadata regarding this that the efforts can share, in time.
>
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)
Michael W. Condry
Director,  Network Edge Technology