Processing points (Re: OPES issues)

Processing "points" seem to me to be architectually defined, and
if there are to be subdivisions of the four points, they would be
again, architectually defined in terms of ordering: before protocol
operates on message, after protocol operates on message.
If the OPES box is a proxy cache, these points are necessary,
whether they have names or numbers.  OK, if you want to be
formal about it, then define at least one OPES box role, proxy
cache, and have that role define 8 variables, 
"is-client-request-before-protocol-processing",
"is-client-request-after-protocol-processing",
etc., and have the rules written as
'if is-client-request-before-protocol-processing AND protocol = http
 AND request-url-domain matches "*.foo.edu" THEN ....'

There may be another point at which administrative
functions are performed, things like "enable (or disable) some rules",
or "set variable used in some rule predicates".  Maybe that's also
a processing point.  All OPES systems need this.

For other kinds of OPES boxes, it's possible that the processing
points could be different.

As Lily pointed out at the workshop, many "points" can be easily
created by rule ordering and appropriate preconditions.

Hilarie

> > > "Lee Rafalow" <rafalow(_at_)raleigh(_dot_)ibm(_dot_)com> 06/11/01 11:36AM 
> > > > > >
Once we make the decision that we may need more than 4 processing points and
that they should be names rather numeric ids, we're quite close to the
concept of a Policy Role.  From the terminology draft:

     An administratively specified characteristic of a managed element (for
example,
     an interface). It is a selector for policy rules and PRovisioning
Classes (PRCs)
     to determine the applicability of the rule/PRC to a particular managed
element.

The key question for us, I think, is whether this an administratively
defined chararcteristic or an architecture defined characteristic.  I
believe we should relinquish control of this and use our understanding of
the 4 currently defined policy roles (if I may call them that) in examples
that help clarify their use or even as some predefined roles suggested for
use in proxies (i.e., MAY).


----- Original Message -----
From: "Menon, Rama R" <rama(_dot_)r(_dot_)menon(_at_)intel(_dot_)com>
To: "'Sherif Kottapurath'" <Sherif(_dot_)Kottapurath(_at_)sun(_dot_)com>;
<Rajnish(_dot_)Pandey(_at_)sun(_dot_)com>; <ietf-openproxy(_at_)imc(_dot_)org>; 
"Menon, Rama R"
<rama(_dot_)r(_dot_)menon(_at_)intel(_dot_)com>
Sent: Friday, June 08, 2001 12:08 AM
Subject: RE: OPES issues


> If it's naming for processing points, let the name domain (& sub domains)
be
> defined per service/application. Example suggestion:
>
> Base domain: (common for all OPES?)
> Point 1  - "Client Request IN"
> Point 2 - "Request to Server OUT"
> Point 3 - "Server Response IN"
> Point 4 - "Response to Client OUT"
> ... (not entirely sure if any other "basic point" needs to be
added/defined
> )
>
> sub-domain(s) per each basic "point"  can now be defined hierarchically by
> each service/appliaction rule(s). (is "pin" a better term than "point"?)
>
> - Rama
> *******
>
> -----Original Message-----
> From: Sherif Kottapurath [mailto:Sherif(_dot_)Kottapurath(_at_)sun(_dot_)com] 
> Sent: Thursday, June 07, 2001 8:59 PM
> To: Rajnish(_dot_)Pandey(_at_)sun(_dot_)com; 
> ietf-openproxy(_at_)imc(_dot_)org;
> rama(_dot_)r(_dot_)menon(_at_)intel(_dot_)com 
> Subject: RE: OPES issues
>
>
> I am actually in favor of removing numbers and putting descriptive names.
> This would make the rule file more readable and maintainable. Also the
> rule compiler/processor can spit out an error if it sees a name it
> cannot recognise or handle.
>
> sherif
>
> > From: "Menon, Rama R" <rama(_dot_)r(_dot_)menon(_at_)intel(_dot_)com>
> > To: "'Rajnish Pandey'" <Rajnish(_dot_)Pandey(_at_)sun(_dot_)com>,
"'ietf-openproxy(_at_)imc(_dot_)org'"
> <ietf-openproxy(_at_)imc(_dot_)org>
> > Subject: RE: OPES issues
> > Date: Thu, 7 Jun 2001 20:50:15 -0700
> > MIME-Version: 1.0
> > List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
> > List-Unsubscribe:
<mailto:ietf-openproxy-request(_at_)imc(_dot_)org?body=unsubscribe>
> > List-ID: <ietf-openproxy.imc.org>
> >
> >
> > On processing points:
> >
> > In my reading through the memo below (and hearing statements about
creating
> > multiple processing points with-in the OPES controller for processing
point
> > 1 - the situation similar to cache 3(a) and 3(b) processing points
> mentioned
> > below - during the OPES workshop on 6/7/01), I have few
> > comments/observations:-
> >
> > (1) Is the current thinking on 4 processing points outdated? Looks like
it.
> > (2) Cache is just one of the "applications"/"services" with-in the OPES
> > framework; what about those yet to be analyzed/conceived? Do we want to
> > imply that all new services/applications play by the current "N# of
> > processing points" model (N= 4 or 6 or 8)? Does this really need to
> > articulated as N?
> >
> > (3) Why not leave the # of processing points beyond the basic 4 as
> > service/application specific? IMHO, it is a question of logical
> > partitioning/hierachy of rules at each processing point that an
> > application/service might need to implement - we don't want to extend
that
> > to a variable # of processing points... at least in the model
definition(s)
> > Comments?
> >
> > - Rama
> > ******
> >
> > -----Original Message-----
> > From: Rajnish Pandey [mailto:Rajnish(_dot_)Pandey(_at_)sun(_dot_)com] 
> > Sent: Wednesday, June 06, 2001 2:02 PM
> > To: ietf-openproxy(_at_)imc(_dot_)org 
> > Subject: OPES issues
> >
> >
> >
> >        Caching issues related to the OPES architecture.
> >        ------------------------------------------------
> >
> >
> >
> > In present scenario, caching is done on the basis of object fetched
> > from origin server or other parent intermediary. Under OPES environment,
> > objects
> > fetched from origin server/ intermediary are processed( local or remote)
by
> > value added services such as language translation, content adaptation. To
> > reduce
> > latency, processed objects along with  the original object can be cached,
> > which
> > can be used to serve other requests.
> >
> >
> > CACHING
> > --------
> > Caching should be done on the basis of object along with services( +
> > version). For e.g. : url( uniform resource locators) + (service-version).
> > Version number must be taken into account while maintaining cache.This is
> > necessary because if a service gets upgraded , object processed by the
> > earlier
> > version of service becomes stale( logically). But time stamp of cached
> > document
> > shows the object as fresh.To make sure that, fresh object is
served,VERSION
> > number must be taken into consideration in maintaining cache.
> >
> > (Version and service can be taken from the description in the OMML)
> >
> > Under OPES environment, cache may have different forms ( due to
> > processing from various services) of objects. If the object retrieved
from
> > CP(content provider) is processed by four services ( s1-s4), then these
> > processed objects ( provided they are cachable)  CAN be cached along with
> > the
> > original object. And cache will have url, url +s1, url +s1 +s2, url +s1
+s2
> > +s3,url +s1 +s2 +s3 +s4.
> > These processed objects can be used later.
> >
> > How cached objects are used to serve requests.
> > --------------------------------------------------
> > Cache is used to serve requests for both type of objects.(original and
> > processed).
> > Consider few cases.
> >
> > Case 1: ( present scenario)
> >    A request comes for an object(url) without service.
> >    If the requested object is present in cache, it is served or origin
> > server
> > is contacted for the object and is served.
> >
> >
> > Case 2:
> >    A request comes for url + service1 and, cache has not got the
> > original document. Intermediary fetches the original object and processes
> > it.
> > The processed object is served to client. At the same time, processed
> object
> > is
> > kept into cache along with the original object. Original object must be
> kept
> > into cache provided its cachable. It can be used later(provided it
> > remains fresh), if request comes for the original document( url) or url
+s2
> > or url  +s2 +s3.It can be also used if the processed object is not
> > fresh.
> >    In this case,it can be used to execute services over it and serve
> > requests.
> >
> >
> > Case 3:
> >    Also, processed ( by services ) objects  can be used for further
> > service (different) processings.Suppose, cache has got url, url + s2 and
> > request comes for url + s2 + s3.Then, url + s2 can be used to generate
url
> > +s2 +s3 and serve client. At the same time, it can be maintained in cache
> > also, which can be used to serve same request or url + s2 +s3 +sn.
> >
> > In few cases, keeping original document doesn't help.
> > E.g, Content Provider sends compressed object and surrogate is supposed
> > to decompress the compressed object. Here it makes sense to keep the
> > processed object in form of original object and remove the original
object
> > fetched from content provider.For further requests, decompressed object
can
> > be
> > served.
> >
> > Suggested Solution :
> > ------------
> > To avoid the above problem, processing point 3 can be divided further
> > into two points : 3(a) and 3(b).
> >
> > 3(a) :It contains Rules applicable to response from origin server only.
> >
> > 3(b) :It contains Rules applicable to response from origin server or
> > cache( local/ ICP).
> >
> > Rules at point 3(b) would be applicable always irrespective  of source
> > of objects.  Processed objects at point 3(a) should be kept as original
> > object. In the above case, decompressed object can be kept as original
> > document
> > in cache and  can be used for serving requests.
> >
> >
> >
> > Modifications of cache related message( response) headers.
> > ---------------------------------------------------------
> > Caching under OPES environment must  obey all the cache related message
> > headers.
> >
> > A service can also affect caching behaviour of an object. It can make
> > the cachable object as non cachable and reduce the freshness time of an
> > object. But it must not make a non-cachable  object as cachable and also
> > must
> > not increase the freshness time of an object.
> > Cache related headers in request messages must not be modified.
> >
> >
> > SERVICES INACCESSIBLE TEMPORARILY.
> > ----------------------------------
> > Sometimes services may not be available temporarily. Consider a case in
> > which a client has asked for a remote service, but it is not available.
> >
> > Following are the actions that may be taken.
> >
> > --Fresh objects can be served without processing.
> >
> > --Processed but stale objects can be served from cache along with
> > warning.
> >
> > But, these actions should be specified by rule author in rule file(IRML)