ietf-openproxy
[Top] [All Lists]

RE: QoS decisions made on Rule Engine or Adaptation Service?

2001-08-31 01:08:00

Hi Markus and Rama,

Thanks for the replies. See my responses in-line.

To summarise, my views are that as far as content adaptation are concerned:
(1) the adaptation services are usually written by content providers as they
know best how to adapts the content
(2) the content providers are usually not the implementers of the OPES
Intermediary
(3) content adaptation is best carried out at the Intermediary than at the
Source (that's why we are here, isn't it? :)

Since the adaptation service is written by thrid party, I think it would be
asking too much for the service authors to handle QoS/Network measurment
within the service.
A viable approach, IMHO, is for OPES to provide a simple interface (such as
environment variables) for the adaptation service to access.
In actual fact, I would prefer that decisions to make what kind of
adaptation to be done on the rule engine, rather than on the adaptation
services.  I acknowledge that efficiency is a critical consideration.  In
compromise, I would urge the working group (are we one yet?) to consider my
sub-system proposal so that OPES-implementors can choose the optimal
combinations they want.


Comments welcomed.

/cwng


Markus Hoffman Wrote:

Well, the view is more that the rule engine itself should not do
network monitoring or performance measurements. However, the rule
engine can make use of system variables that hold the actual results
of such measurements (we just extended this in the lates IRML draft).
For example, there might be a rule that says "if 'network_load'
matches 'high' then do 'adaptation_for_high_load'". The
system-variable 'network_load' can be set by another (local) service
module or my an independent piece of software running on the OPES
intermediary (or whatever we end up calling this box).

No, I am not suggesting the rule engine should perform network monitoring.
And I applause the inclusion of the system variables.
However, I do feel that the regex-only matching is limiting, and the number
of different system variables might not be sufficient.


Defining mechanisms for obtaining network conditions seems to be
out-of-scope for OPES. OPES will define the framework that allows you
to plug-in service modules that can do such measurements, but it does
not tell those modules HOW to do it (that's a "local" implementation
decision). OPES might also provide means to consider conditions
obtained through network measurements in rule matching - for example
through system variables. A missing piece now remains a "protocol"
that let's you set system/service variables on OPES intermediaries -
something for OPES to look at?


Yes, I agree that defining the mechanism should be implementation specific.
I am just advocating that OPES, especially the rule engine, provides a
standard way of referencing these measurements, which can be (and should be)
as simple as "environment variables".

A side note on the calling of adaptation Services.
Currently, the only way of passing information to the servlets are though
URL.
However, if the decisions to make content adaptation is the responsibility
of the adaptation services, then there should be a way to pass variables to
the adaptation services.


Menon, Rama R wrote:


There is value in OPES support for means to get/set parameters & values -
like network load conditions (may be there are a few others?) for the
benefit of other services in addition to the one brought out for
use by the
Rule Engine. Whether these values are made available through environment
variables or an explicit protocol needs to be discussed.

If we need sup[port through protocol, some of the existing network
management protocols (like SNMP) might be considered? Is there
any objection
to "going lower than session layer"?



I am more inclined towards the use of environemnt variables, as it is much
more simpler for rules author, and providers of adaptation services.
These (rules and services) are basically residing on the application layer,
and most likely to be written by third-party.
It is my feeling that for them to handle MIBs/SNMP (under the session layer)
would be quite complicated.