ietf-openproxy
[Top] [All Lists]

RE: [Pcs] Re: some questions and comments on draft-barbir-opes-sp cs-01.txt

2002-04-01 12:55:17
Hello Lily

-----Original Message-----
From: Yang, Lily L [mailto:lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com]
Sent: Monday, April 01, 2002 11:22 AM
To: Penno, Reinaldo [SC9:T327:EXCH]; Yang, Lily L; 'The Purple Streak
(Hilarie Orman)'; ietf-openproxy(_at_)imc(_dot_)org
Cc: Knight, Paul [BL60:1A00:EXCH]; 'pcs(_at_)eng(_dot_)registro(_dot_)br'
Subject: RE: [Pcs] Re: some questions and comments on draft-barbir-opes-sp
cs-01.txt


Reinaldo -- I am not fully convinced yet that you need to dynamically change
the rules for things like location services etc. In my mind, the changing
parameters do not necessarily mean changing rules. They are conceptually at
two different levels. The rules can be still quite static as to say "Apply
location service for User A at news.com and weather.com ", and then OPES
engine will send the actual location parameters to the callout server in
real time. So the callout server can use that dynamic information to adapt
the service accordingly. The same goes for the user profile, network
condition, etc. They are the parameters that callout server need to have,
but they don't need to be present at the rule level in the OPES engine --
rule is more about when to invoke what service for whom under what condition

 
Humm....the fact is that rules will change (even users can change some of
their "rules" at will today, this is true for content filtering). So, I
think maybe what we are discussing is if the OPES engine can have some
intelligence to or receive updates/compile/bypass the rules for certain
conditions or it would always send the content to the callout even if it
would say "I'm not going to do anything with that" ; or receive the rules
pre-compiled by the admin server.
 
For example, this "condition" could be for instance where you are located,
what is the status of the network, what device you are using, etc. You could
have a rule saying "apply this rule only if I'm at most 30 milles from my
house". Do you consider this a static rule (the engine need to know if you
are at most 30 milles from your house even to apply the rule in the first
place)?  Or, "if I'm indoors do not adapt my weather service".  Or "apply
this rule only if my bandwdith is X or my profile is Y". 
 
regards,
 
Reinaldo
 
 , but it doesn't deal with the specific adaptation intelligence inside each
service. The service itself deals with such detail -- so the video
transcoder would decide what frame rate, bit rate to use under what kind of
network condition, the location service would decide the location
granularity it use to adapt the content, the personalization service would
decide what info it uses from the user profile to adapt the contet, etc. I
think separating those service-specific detail out from the OPES rule engine
is beneficial in several ways. It provides scalability by keeping the OPES
rule base size manageable and stable while allowing the callout server to
change its internal implementation intelligence without affecting the OPES
engine most of time. It probably can avoid requirements like dynamic rule
loading all together (I am just guessing without any detail analysis yet)
which certainly simplifies things a lot and also helps the performance.
Lily

-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno(_at_)nortelnetworks(_dot_)com]
Sent: Monday, April 01, 2002 11:01 AM
To: Yang, Lily L; 'The Purple Streak (Hilarie Orman)';
ietf-openproxy(_at_)imc(_dot_)org
Cc: Paul Knight; 'pcs(_at_)eng(_dot_)registro(_dot_)br'
Subject: RE: [Pcs] Re: some questions and comments on draft-barbir-opes-sp
cs-01.txt



Hello Lily, 

the dynamic loading of rules need to occur even without personzalition. For
instance, in the case of location based services (news, weather, etc) where
the user is mobile, we need to dynamically load rules (whether in the
callout server, whether in the intermediary) in real time.

Services like virus scanning and content filtering are pretty static in
relation to the rules, but services that depend on changing parameters like
the location of the user, current performance of the network (bandwidth,
jitter, etc), user profile,  and others need dynamic rules anyway.

regards, 

Reinaldo 

-----Original Message----- 
From: Yang, Lily L [ mailto:lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com
<mailto:lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com> ] 
Sent: Monday, April 01, 2002 10:14 AM 
To: 'The Purple Streak (Hilarie Orman)'; ietf-openproxy(_at_)imc(_dot_)org 
Cc: Knight, Paul [BL60:1A00:EXCH]; 'pcs(_at_)eng(_dot_)registro(_dot_)br' 
Subject: RE: [Pcs] Re: some questions and comments on 
draft-barbir-opes-sp cs-01.txt 


Hilarie -- Maybe you are right to call it a matter of terminology than 
architecture. But I am a bit confused now about the role of 
Admin server and 
the callout server and how much now they overlap with each 
other. I am also 
concerned about the performance implication of dynamically 
loading rules to 
the OPES engine by callout server in the content path in real 
time. In a 
separate thread, you mentioned the slow XML parsing 
performance. Whether or 
not that is indeed true remains an ipen issue. But having the 
callout server 
dynamically loading the rules onto the OPES engine requires 
that the rules 
being transported over the wire is in standard formats (IRML?) 
instead of 
the internal format between the Admin Server and the OPES engine. That 
imposes some extra (XML?) parsing overhead in the content path. 
All these have implications that I think deserve some careful 
consideration 
in the requirement gathering phase. 
Lily 

-----Original Message----- 
From: The Purple Streak (Hilarie Orman) [ 
mailto:ho(_at_)alum(_dot_)mit(_dot_)edu
<mailto:ho(_at_)alum(_dot_)mit(_dot_)edu> ] 
Sent: Thursday, March 28, 2002 2:38 PM 
To: ietf-openproxy(_at_)imc(_dot_)org 
Cc: 'paknight(_at_)nortelnetworks(_dot_)com'; 
'pcs(_at_)eng(_dot_)registro(_dot_)br' 
Subject: [Pcs] Re: some questions and comments on 
draft-barbir-opes-spcs-01.txt 


This seems like a matter of terminology more than architecture. 
The OPES intermediary can trigger on the event "begin user 
session" and have the action "notify personalization server" or 
"notify user services admin server" as basic policy rules.  The 
communication can use the OPES callout protocol, and the returned 
items can be rules.  OPES policy can state that rules are 
only accepted 
from a trusted callout server list, and they can implement the policy 
that the returned rules can apply only to the user session for which 
the callout server was invoked.  This doesn't seem particularly 
dangerous.  It does put more requirements on the OPES engine 
to enforce 
local policy, but I thought it was going to be a policy enforcement 
engine, anyway. 

Hilarie 

Yang, Lily L wrote: 

Hi, Paul -- 

Just went through draft-barbir-opes-spcs-01.txt. Sorry that 
I couldn't do 
that earlier -- Looks like I got a lot to catch up. 

First of all, I am not sure that I fully understand the 
exact role of the 
OPES Service Personalization Callout Server (SPCS) and how 
it should be 
treated in the OPES framework. My understanding of the 
draft is that, to 
achieve service personalizaiton, we actually need to deploy 
two kinds of 
callout servers within the OPES framework. One is the SPCS, 
its role is to 
generate dynamic rule modules to upload onto the OPES 
intermediary based 
upon subscriber profile and content profile. But the actual 
rules (which are 
dynamically generated by SPCS) will possibly invoke some 
content adaptation 
service that is to be carried out by the Callout Server 
(per the diagram 
depicted in Figure 1 on page 12). These Callout Servers are 
the second kind 
of callout servers. At the surface, both are callout 
servers and should be 
treated as such by the OPES framework. However, they are 
VERY different in 
what they actually do. 

In my mind, callout servers only do adaptation service for 
the content, they 
don't control/alter the behavior of OPES intermediary (the 
engine). So only 
the second kinds are the real callout servers in that 
sense. The first kind 
(SPCS) is not, at least not according to my understanding 
of the callout 
server definition. Allowing a callout server to dynamically 
upload or delte 
rules from the OPES engine sounds like asking trouble to 
me. Allowing them 
to adapt the content is already a riksy business! This is 
10 times worse 
than that. To me, SPCS sounds much more like one instance 
of the OPES admin 
server. Admin Server is the entity that can control/alter 
the behavior of 
OPES engine and it requires a much tighter security/trust 
model between the 
Admin Server and the OPES engine. . 

The description of the SPCS's functions are very much the 
same as the Admin 
Server, but with some important exceptions -- the purpose 
of SPCS is much 
narrower of the Admin Server; and there is the "real-time, 
in the content 
path" aspect of SPCS that is not required (in general) by 
the Admin Server. 
My understanding is that SPCS needs to generate and upload 
the dynamic rules 
in real time at the beginning of the "SP-session", and then 
SPCS is not 
involved for the rest of the session before its 
termination, is it correct? 
At the middle of the session, the rules that is just 
uploaded would govern 
the actual content adaption (for personalization). It seems 
that somewhere 
the text also suggests the profile might change mid-session 
and does that 
mean the rules will be generated again mid-session? 

Maybe I misunderstand the whole concept -- otherwise, I 
have some serious 
concern about some of these issues. 

Lily 






_______________________________________________ 
Pcs mailing list 
Pcs(_at_)eng(_dot_)registro(_dot_)br 
http://eng.registro.br/mailman/listinfo/pcs
<http://eng.registro.br/mailman/listinfo/pcs>  

_______________________________________________ 
Pcs mailing list 
Pcs(_at_)eng(_dot_)registro(_dot_)br 
http://eng.registro.br/mailman/listinfo/pcs
<http://eng.registro.br/mailman/listinfo/pcs>  


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