RE: Chaining of Callout Servers

["Joseph Hui" <Joseph.Hui@xxxxxxxxxx>]

> From: Markus Hofmann [mailto:markus@xxxxxxxx]
> 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'd share the sentiment to place priority on catching up with
the schedule first, and keeping the callout semantics simple
for now will serve that purpose well.

Joe Hui
Exodus, a Cable & Wireless service
=========================================


> -Markus
> 
>