RE: Efficacy of rule specification, processing

> Could someone give me an example of the sorts of services you 
> thought OPES could provide for streaming media (RTP) sessions ?
- A/V transcoding
- Re-encoding w/ video insertion for add or other stuff
- Rate adaptation to network or other conditions
- ...

> -----Original Message-----
> From: Jayanth Mysore 
> [mailto:Jayanth_Mysore-CJM110(_at_)email(_dot_)mot(_dot_)com]
> Sent: Wednesday, June 13, 2001 7:09 AM
> To: Yang Lily L
> Cc: Maciocco Christian; 'Markus Hofmann'; 'Gamze Seckin';
> 'ietf-openproxy(_at_)imc(_dot_)org'; Jayanth.Mysore
> Subject: Re: Efficacy of rule specification, processing
>
>
> Hi Lily,
>
> I am fully aware that end-to-end rate adaptation and specific 
> application level
> content adaptation mechanisms
> exist. RealPlayer's SureStream mechanism, for example, 
> maintains media files in
> multiple formats and switches across the formats based on 
> end-to-end feedback.
>
> I would like to restate that the example quoted was ONE 
> illustration of a bigger
> concept - that supporting dynamic
> rule injection will probably be very important to support if 
> you truly intend to
> support long running media
> rich sessions (which is what most RTP sessions are), in heterogenous
> networking/device  environments.
>
> Could someone give me an example of the sorts of services you 
> thought OPES could
> provide for streaming
> media (RTP) sessions  ?
>
> Thank you,
> Jayanth
>
>
> "Yang, Lily L" wrote:
>
> > 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