-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Thursday, July 25, 2002 8:26 AM
To: Hilarie Orman, Purple Streak Development
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: Chaining of Callout Servers
Hilarie Orman, Purple Streak Development wrote:
It's impossible to prevent it, it would be good to support
it. I don't
think there's any impact on the protocol beyond adding a
"This is part
of a callout chain" header.
What about the impact on policy enforcement and authorization and on
the underlying "trust assumptions"? For example, would you
assume that
the servers in the chain are explcicitly identified, or that
the first
callout server can freely decide to which other servers to chain? If
the callout servers are explicitely identified, who decides
whether to
do chaining or not?
Example: After rule evaluation, the OPES processor determines that
Service A on Server 1 has to be performed as well as Service B on
Server 2. Does the OPES processor decide to chain Server 1 and Server
2, or does the OPES processor leave this decision to Server 1? What
metric is used to decide whether Server 1 and 2 should be chained or
whether it would be beneficial to first callout to server 1 and then
to server 2? Is this a static configuration? If Server 1 decides, can
we assume that the user is fine with his decision to chain out to
server 2, i.e. is there an implicit trust relationship?
If yes, what are the impacts
with respect to complexity,
local configuration must show which servers are available for OPES
processing, but that's not part of the protocol we are developing
I was also thinking in terms of implementation complexity.
Wouldn't it
be necessary that callout servers now also temporarily store messages
until they come back from the chained callout server, for example in
order to avoid data loss in case the chained callout server fails
(just as the OPES processor does). What about handling failure of
chained allout servers in general, wouldn't that add complexity?
Somehow, a callout server chaining to another callout server reminds
me a little bit of an OPES processor (towards the chained callout
server)...
reliability,
might have more delays, more opportunity for broken connections
... and requires callout servers to temporarily store messages (until
they come back from chained callout ervers). As a result, a single
message might end up being stored in a chain of OPES processor and
callout servers (rather than just in a single OPES processor).
What about if a chaining callout server fails? Example: OPES
processor
does callout to Server A, and Server A chains to Server B
OPES processor --> Server A --> Server B
What happens when Server A has forwarded the message to Server B, and
suddenly Server A fails. What does Server B do with the message? Does
it know that it would have to be sent back to the OPES processor?
Would the OPES processor be able to handle a message coming from
Server B rather than from Server A? What about similar scenarios with
much longer chains? Seems like its getting more and more complex...
fault-tolerance,
slight increase in most cases, due to more machines being available
for processing
Hm, or vice versa, see above.
data integrity,
no change
Yup, also don't see an issue here.
privacy, security,
if machines are in the same admin domain, no change; would recommend
strongly that machines be restricted from communicating outside the
admin domain, but there's no way to enforce this
Hm, yup, agreed.
What are the specific scenarios in
which such a mechanism would be beneficial?
Anytime the communication overhead is much less than the
processing time
one will find that pipelining is a good idea. This also
relieves the
OPES data processor from having to maintain a map of the
services points
within the local infrastructure - the first service
processor can plan
the processing pathway, handle failure detection and failover, etc.
Ah, OK, this might answer my very first question. You seem to assume
that the OPES processor only knows the first callout server, and that
it is up to the first callout server to decide whether and how to
chain to other callout servers. Is this correct?
If so, does this have any impact on the policy enforcement framework?
Because now the overall control is no longer solely in the OPES
processor, but we've sort of a second "decision point" in the first
callout server.
And would the expected
benefits outweigh the additional complexity?
There's little complexity added to the protocol.
Well, maybe little to the protocol, but I'm not yet completely
convinced that there would also be little additional complexity to
implementations and also with respect to falure handling.
-Markus