From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Thursday, July 25, 2002 5:38 AM
To: Joseph Hui
Cc: OPES Group
Subject: Re: Chaining of Callout Servers
Joseph Hui wrote:
That said, I also believe, in consideration of security and privacy,
it'd be prudent to also require that the transitivity of trust
along a CSC be controllable to some reasonable extent by
the CSC caller.
Do I understand you correctly that this would require the OPES
processor to specify the callout server chain, i.e. the OPES
processor
decides which servers are in the chain and how they're
chained? If I'm
not mistaken, this would be different from Hilarie's viewpoint, where
"... the first service processor can plan the processing pathway...".
Marcus, you understood correctly. It's tantamount to the OPES processor
specifying a strict source routing metric for the processing pipeline.
Hilarie's viewpoint, if I'm not mistaken, is like loose source routing
(from the OPES processor's standpoint) in similar vein, where the
OPES processor relinquishes (or delegates, using a security
buzzword du jour) its prerogatives of server selections (other
than the first server) to the first server. (Because tracing
is a concern, the callout server(s) cannot be treated as
a blackbox. Otherwise, I could have use a blackbox metaphor.)
I believe the two cases can be generalized into one at a slightly
higher lever for the benefit of letting the OPES processor have
some sense of control. Whether such sense of control will amount
to some real value in terms of the OPES processor's managing its
trust transitivity (pertaining to the callout services) remains
to be investigated.
I'm using the "to some reasonable extent" phrase, because in
reality this will present a great challenge to the callout
protocol designers.
You seem to assume that this will have quite some impact on the
protocol, while Hilarie's viewpoint is that one additional header
would be enough. Can we somehow examine why we come to such different
views?
Yes, there will be impact on the protocol, in terms of
added complexity.
The value and usefulness of pipelined
processing can be trivially demonstrated, using a
Unix command line as an example, say, A|B|C. That's
a positive.
Well, if A, B, and C are servers, and the communication cost from the
OPES processor to each of the servers is minimal, than chaining
doesn't buy me too much - it might even be worse, e.g. if
communication cost between the servers is higher than between
the OPES
processor and the servers. So, it strongly depends on the deployment
scenario - and I was wondering what a typical OPES deployment
scenario
would be in which chaining would either be beneficial or a
disadvantage - I can see both, and I'm just wondering whether the
expected benefits in those specific scenarios would justify possible
added complexity.
It depends on the deployment scenarios. (Old news, of course.)
Sometimes the star configuration: OP->A->OP->B->OP->C->OP, wins.
Sometimes the pipeline configuration: OP->A->B->C->OP, wins.
We are unlikely to be able to get hold of enough empirical data
to support claims either ways. However, intuitively, the pipeline
style is more scalable, and provides a more fertile ground for
research projects and products, so I think it merits
serious consideration, at least as an option for future OPES
releases or something for the IRTF to look at down the line.
That said, in light that during the Yokohama meeting it was
mentioned OPES was four months behind its deliverables,
(which might also mean OPES was half year ahead of those that
were ten months behind, I guess, all things being relative ;-),
I share the sentiment to place priority on catching up with
the schedule first, and keeping the callout semantics simple
for now may serve that purpose well.
Joe Hui
Exodus, a Cable & Wireless service
=========================================
-Markus