RE: Efficacy of rule specification, processing

I agree with Christian here. Remember that the rule engine is in the data
path and should not be overburdened with many service-specific controls. 
 
Many of the dynamic behavior can be achieved with a set of carefully written
rules -- the rules are static but the run time matching will result in
dynamic behavior accordingly.
Some other dynamic behavior can be achieved by the service itself. As
someone working on video codec algorithms for 5+ years, I know for a fact
that today's codec itself can indeed adjust video quality to the network
condition dynamically without any help from a control device like OPES.
Maybe it does not go to the extreme of converting color video to
balck-and-white yet, but on the other hand, OPES can not claim to satisfy
all of your wildest dream either. 

We need to consciously draw a line between what OPES infrastructure provides
and what the services themselves provide.

Lily

> -----Original Message-----
> From: Maciocco, Christian 
> [mailto:christian(_dot_)maciocco(_at_)intel(_dot_)com]
> Sent: Monday, June 11, 2001 5:49 PM
> To: 'Markus Hofmann'
> Cc: 'Gamze Seckin'; 'ietf-openproxy(_at_)imc(_dot_)org'
> Subject: RE: Efficacy of rule specification, processing
>
>
>
> This will probably be the default behavior of devices having 
> requests load
> balancing capabilities without requiring a rule. 
>
> I'm not against requiring state variables. The issue I see are:
> - What will be the scope, e.g. network conditions, internal 
> I/O conditions,
> CPU load, ...
> - Rule system will have to support arithmetic expression to 
> do so or very
> limited otherwise.
> - Rule module can be written by independant parties. Are we 
> requiring all
> the OPES devices to provide network monitoring, I/O 
> monitoring capabilities,
> and what will be the default behavior for the one which don't 
> provide the
> feedback information.
>
> Christian
>
> > -----Original Message-----
> > From: Markus Hofmann [mailto:hofmann(_at_)bell-labs(_dot_)com]
> > Sent: Monday, June 11, 2001 4:52 PM
> > To: Maciocco, Christian
> > Cc: 'Gamze Seckin'; 'ietf-openproxy(_at_)imc(_dot_)org'
> > Subject: Re: Efficacy of rule specification, processing
> >
> >
> >
> > "Maciocco, Christian" wrote:
> >  
> > > It looks like that by inserting state variables about 
> > external environment
> > > into the rules we're expecting the OPES device to control 
> > services behavior.
> > > I think that the OPES device should instead only decide 
> > whether or not a
> > > service needs to be launched and have the service itself 
> > take care about
> > > adapting to dynamic behavior, for example by communicating 
> > the required
> > > information to the service itself.
> > Hm, what about a scenario in which the same service is available
> > locally (i.e. on the OPES device) as well as remotely (i.e. on a
> > callout server). In this case, it would be nice to have a something
> > like "if my local system load is below a certain threshold, 
> I call the
> > local service, otherwise I use a remote callout". How would you
> > implement this if only the service itself takes care about 
> adapting to
> > dynamic behavior? And, no, I do NOT like the idea of 
> chaining multiple
> > services :)
> >
> > -Markus