ietf-openproxy
[Top] [All Lists]

RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt

2002-06-02 16:24:51
Hello,
 
by chaining of callout servers you are implying different physical boxes,
that provide different services, right?
 
Because a certain data channel can be setup to provide several services,
e.g., virus scanning, content filtering and langugage translation. The main
difference is that although they are different services, they sit on the
same box. 
 
On the other hand one could argue that a callout server and a opes data
processor can set up such a channel but what the callout server is actually
doing is saying "I know how to provide you with these services, but not
necessarily I'm doing everything". So, in the backend the "callout server
proxy" can use other callout servers to do the job. This callout server
proxy could even be a layer 7 switch which only establish the callout
protocol but relinquish everything to a pool of callout servers. The
responses then go back to the layer 7 switch, which send to some other
callout server on the pool for a different service.
 
So, I see a lot of borderline cases and different scenarios where there are
different meaning of "chaining callout servers" 
 
regards,
 
Reinaldo

 
 -----Original Message-----
From: Rochberger, Haim [mailto:Haim_Rochberger(_at_)icomverse(_dot_)com]
Sent: Friday, May 31, 2002 1:53 PM
To: Andre Beck
Cc: Markus Hofmann; OPES Group
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-
re qs-00.txt



Hi Andre, 

Thanks for the quick reply. 
I see your point, but since I see the callout servers as an "expert server"
who is giving a specific, non trivial service, 

then I can see a model of such service providers who own those servers, and
whoever has a trusting relations with - it may give that service to, and
charge for it.

Now I don't think the issue should be whether they are close by or not, but
since there could be a situation that performance both on a specific
message, and the OPES engine, is important, then the question is if I can
propose to add an OPTION for the OPES engine to specify in the callout
protocol (whatever it will be) a list of the trusted servers and their
order, and insert a security signature on the list so that the chain of
trust can be achieved, and billing too. and add mechanism so that each
server on the chain must notify the OPES engine  on his activity and status
in a secured way, This can eventually be an option that in the local domain
with no performance issues be ignored... but if the implementations WILL
need it and will not have it standardized - will not use this OPES mechanism
altogether.

I do understand that this is a "second stage" issue now - as the first
specification still on the way, but if someone volunteers to take this issue
under their wings...?

Are there other members who feel this should be at list optional ? 

Warm regards, 

Haim Rochberger 
System Architect 
Comverse 
Mobile Internet & Broadband Division 
Office: +972-3-766-9121 
Mobile: +972-54-970-504 
Email: Haim_rochberger(_at_)comverse(_dot_)com < 
mailto:Haim_rochberger(_at_)comverse(_dot_)com
<mailto:Haim_rochberger(_at_)comverse(_dot_)com> > 



-----Original Message----- 
From: Andre Beck [ mailto:abeck(_at_)bell-labs(_dot_)com 
<mailto:abeck(_at_)bell-labs(_dot_)com> ]

Sent: Fri, May 31, 2002 5:29 PM 
To: Rochberger, Haim 
Cc: Markus Hofmann; OPES Group 
Subject: Re: 
http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-
<http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol->  re 
qs-00.txt 


Rochberger, Haim wrote: 
Is it still possible to add this requirement ? I mean chaining callout 
servers ? 

This may improve the performance in case you have a few callout servers 
that need to handle a specific message in order. 

Callout server chaining would add a lot of complexity to callout 
transactions and callout servers, e.g. in terms of error handling, 
fail-over, tracing, trust relationships etc. I can only see performance 
benefits in cases where the distance between the callout servers is 
shorter than the distance between the OPES processor and the callout 
servers. However, I think whenever the performance of callout 
transactions is critical, it is much more likely that the callout 
servers will be co-located with the OPES processor, i.e. in the same 
domain. Hence the distance between the OPES processor and callout 
servers would be similar to the distance between the callout servers and 
there wouldn't be much of a performance benefit any more with callout 
chaining. 

-Andre 

<Prev in Thread] Current Thread [Next in Thread>
  • RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt, Reinaldo Penno <=