[Top] [All Lists]

RE: comments on draft-dracinschi-opes-callout-requirements-00

2002-03-04 12:56:06

-----Original Message-----
From: Mark Nottingham [mailto:mnot(_at_)mnot(_dot_)net]
Sent: Friday, March 01, 2002 9:42 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: OPES list
Subject: Re: comments on draft-dracinschi-opes-callout-requirements-00

Hi Reinaldo,

IMO you have an external callout server for the some of the same
reason we have caches in the first places: offload processing,
reliability issues, technologic specialization issues, etc...

In the technologic specialization front, for instance, if you want
Virus Scanning you will need to process periodic updates, port
somebody's else code in to your box, etc, etc. Are you going to put
this on the OPES box per se or let somebody that knows how to do it
best take care of that for you? You can extend this to a lot of
other services: content adaptation, geographic services, Content
Filtering, and so forth.

True; I wasn't saying that there isn't a need for callouts, just an
exploration of how they're used. Perhaps because of OPES' early
history with ICAP, I get the feeling that some people think that
OPES = callouts, which isn't true.

There are a few costs to using a callout protocol; the most obvious
are overhead (both in packaging the messages and in delivering them
over the network) and security, but also there are issues in the
failure modes, etc. 

yes, that's true. Altough failure problems would also apply in the case
everything in bundled in the "local" device. If the local device goes down
you stop offering any OPES services. If the remote callout goes down you
stop offering that specific, it's always a tradeoff

As for the overhead of packaging, thre is no way around it. 

that the network introduces. Also, it's difficult
to make all of the information that's available to the local
environment available to the remote environment. [1] has some
interesting things to say in this regard.

I agree, altough IMHO the "local" environment wouldn't have access to all
information either. In a network with possible thousands of subscribers
where different OPES services are selective applied depending on time of
day, geographic location, accessed file, bandwidth, etc the most scalable
form would a distributed databased where the remote callout server and also
the OPES local environment could query whatever information they needed. 

In this way they could query whatever information they needed separately,
not depending on each other for this specific purpose. 

The benefits seem to be centred around flexibility and segmentation;
you are able to deploy services and have them effected in different
places on the network, and you're able to rigidly separate services
from each other and other messages, and have services provided from
administrative domains which are different than the intermediaries'.

I think that most scenarios will preclude deploying services far away
from the intermediaries; unless they provide exceptional value, and
are sparingly applied, the latency cost is too great, and the added
network traffic is undesireable. OTOH, deploying them in close
proximity to intermediaries gives nice segmentation, as you point
out. These deployments will have to overcome the cost of running two
boxes to provide a service, though (especially considering the
advances in JVMs and virtualisation in general).

agreed, deploying callouts "away" from the local env wouldn't be common, but
it's very possible. Which brings the question that if the callout is
crossing a possible large network, should it be congestion aware and
reliable? Possibly yes, otherwise it would restrict network deployments or
we would need to put this functionality on the callout protocol itself.

Perhaps part of the decision will be the nature of the service. Your
arguments for third-party proprietary services support the need for a
callout protocol. One of the things that I'd like to see more of is
the standardisation of common service definitions for things like
caching, transcoding, etc., so that they can be run on an
intermediary without moving code around; these kinds of services lend
themselves more to running locally. 

I would also like to see that. 

Just my .02. Am I missing other benefits (or costs) of using

see above, I added some text. Summarizing everything I think the pros and
cons reside on fail-over, packaging overhead, segmentation, information
distribution and flexibility.

Is there anything else?


just downloaded. Will read it.



Mark Nottingham