ietf-openproxy
[Top] [All Lists]

RE: OPES issues

2001-06-07 21:09:01
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) .

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>






<Prev in Thread] Current Thread [Next in Thread>