|
RE: Processing points (Re: OPES issues)
2001-06-11 13:05:51
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(_at_)volera(_dot_)com]
Sent: Monday, June 11, 2001 10:56 AM
To: ietf-openproxy(_at_)imc(_dot_)org;
rafalow(_at_)raleigh(_dot_)ibm(_dot_)com
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(_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)
|
|