[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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) .
>
>If none of the services is accessible, then OPES may move forward and
>start processing for different rules.
>
>
>E.g : : Content provider has put a rule to access a decompression
>service.If the service is not available, then original object (
>uncompressed)
>SHOULD not be served.In this case, either stale object or some error
message
>
>SHOULD be given.
>
>
>There may be few cases.
>
>Case 1:
>------
>
>Request comes for url + service. url + service is not available in
>cache. Also, service is not available. Now, since service is not present,
>then
>rule in succession can be checked for match and action can be taken
>accordingly.
>
> But, few services are imperative. It is necessary to fire such
>services.For e.g: Content Adaptation.
>
>Suggested Solution :
>-----------
> An attribute "MANDATORY" can be added to element "ACTION". Possible
>values of this can be YES and NO.By default, its value will be NO. If this
>attribute is not mentioned, its value will be taken as NO, and message will
>be
>sent for validation against different rules.If it is YES, then this ACTION
>MUST
>be fired and if not accessible, then some error may be sent.
>
>
>
>Case 2:
>------
> Request comes for url + service . url + service object is available in
>cache, but is stale . Service is not available.Now decision has to be taken
>whether,stale object can be served or object without processing can be
>served.
>
>
> Suggested Solution :
>------------
>
> An attribute "CACHE" can be added to element "ACTION". Possible values
>will be YES and NO. By default, its value will be YES.This implies that,
>if
>attribute is not mentioned in rule file, then stale data can be
>served.If it is NO, then, original object should be served without
>processing.
>
>
>
> There should be provision of alternate services, which can be contacted
>when service mentioned in ACTION element is not available.
> It can be added as a new element such as <alt_action> or can be
>provided in the action element itself as ORing of different services.
>
>
>
>
>
>This is the existing format in IRML.
>
>
> <rule processing-point=3>
> <!- Is the requested Web resource an executable binary file? -->
> <property name="Content-Type" matches="application/">
> <!- Invoke virus scanning service on mcaffee.com -->
> <action>icap://mcaffee.com/viruscheck</action>
> </property>
> </rule>
>
>
>Changes suggested
>-----------------
>
>1.Addition of MANDATORY attribute for action
>
>
>
> <rule processing-point=3>
> <!- Is the requested Web resource an executable binary file? -->
> <property name="Content-Type" matches="application/">
> <!- Invoke virus scanning service on mcaffee.com -->
> <action name="MANDATORY" matches="YES">
> icap://mcaffee.com/viruscheck
> </action>
> // MANDATORY attribute being added
>
> </property>
> </rule>
>
>2.Addition of CACHE attribute for action
>
> <rule processing-point=3>
> <!- Is the requested Web resource an executable binary file? -->
> <property name="Content-Type" matches="application/">
> <!- Invoke virus scanning service on mcaffee.com -->
> <action name="CACHE" matches="NO">
> icap://mcaffee.com/viruscheck
> </action>
> //CACHE attribute added
> </property>
> </rule>
>
>
>3.1 Definition of Alternate service in "Action" element
>
>
> <rule processing-point=3>
> <!- Is the requested Web resource an executable binary file? -->
> <property name="Content-Type" matches="application/">
> <!- Invoke virus scanning service on mcaffee.com -->
> <action>icap://mcaffee.com/viruscheck |
> icap://foo.com/viruscheck
> </action>
> //Alternate service is provided in Action field only
> </property>
> </rule>
>
>
>
> But according to IRML draft,
> Action element is defined as "Only one service URI MAY be
>specified per "action" element. "
>
> 3.2 Definition of Alternate service in a different element within
>"Action" element
>
>
> <rule processing-point=3>
> <!- Is the requested Web resource an executable binary file? -->
> <property name="Content-Type" matches="application/">
> <!- Invoke virus scanning service on mcaffee.com -->
> <action >icap://mcaffee.com/viruscheck </action>
> <alt_action> icap://foo.com/viruscheck </alt_action>
> //this service is a substitution to service mentioned in
> //"action " element.
> </property>
> </rule>
>
>
>