[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Processing points (Re: OPES issues)
I too think that the processing points must be architecturally defined for
interoperability and deployment. Most likely the rules will be written
generically and won't target any specific device. Otherwise we'll need to
establish a "rule to device" mapping capability.
Christian
> -----Original Message-----
> From: Hilarie Orman [mailto:HORMAN@xxxxxxxxxx]
> Sent: Monday, June 11, 2001 10:56 AM
> To: ietf-openproxy@xxxxxxx; rafalow@xxxxxxxxxxxxxxx
> Subject: 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@xxxxxxxxxxxxxxx> 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.r.menon@xxxxxxxxx>
> To: "'Sherif Kottapurath'" <Sherif.Kottapurath@xxxxxxx>;
> <Rajnish.Pandey@xxxxxxx>; <ietf-openproxy@xxxxxxx>; "Menon, Rama R"
> <rama.r.menon@xxxxxxxxx>
> 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.Kottapurath@xxxxxxx]
> > Sent: Thursday, June 07, 2001 8:59 PM
> > To: Rajnish.Pandey@xxxxxxx; ietf-openproxy@xxxxxxx;
> > rama.r.menon@xxxxxxxxx
> > 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.r.menon@xxxxxxxxx>
> > >To: "'Rajnish Pandey'" <Rajnish.Pandey@xxxxxxx>,
> "'ietf-openproxy@xxxxxxx'"
> >
> > <ietf-openproxy@xxxxxxx>
> > >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@xxxxxxx?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.Pandey@xxxxxxx]
> > >Sent: Wednesday, June 06, 2001 2:02 PM
> > >To: ietf-openproxy@xxxxxxx
> > >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)
>