Subject: An opes usage question.

From: "John G. Waclawsky" <[email-masked]>
Date: Wed, 07 Jan 2004 17:51:52 -0500

I have been looking over the opes drafts and trying to understand the 
efficiency of a distributed opes framework with a large volume of 
activity (and also trying to gauge how useful it would be for time 
dependent service execution activities). Consider an opes service where 
application data is transformed (or adapted) in some way. My question 
is, If I send the data flow to a callout server to perform some opes 
service task (or a string of call out servers), does the data always 
have to return to the data dispatcher at the opes data processor that 
directed the flow to the call out server in the first place (an 
ancillary question is: can just trace data and billing information only 
be sent back)?. Basically, will an opes framework allow the use of a  
piplining approach where once the service is complete at the call out 
server, the adapted application data can be forwarded directly to the 
data producer or data consumer (what ever the case may be)?  Any 
information, advice or council would be greatly appreciated. Thanks.
Regards   John

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 7 Jan 2004 16:55:55 -0700 (MST)

John,

	As far as I can see, your use case is 100% within the OPES
scope. However, you are probably thinking at the protocol level and,
hence, considering OCP protocol and not just OPES in general. If that
is the case, please read on.

	Your use case is a case of two application proxies using OCP
between each other: the data is pipelined via OCP from one application
hop to another, possibly with some other data returning to the first
hop. This use case has been discussed, but I do not think it was
explicitly documented.

	OCP protocol can be used to do what you want. You will need to
document and negotiate an OCP Core profile that specifies the details,
including sending trace data and billing information back to the first
proxy as an option. While doing that, you will need to be careful not
to be confused by terminology that targets classic "callout" rather
than classic "proxying" use cases.

	OCP protocol allows you to "pipeline" application messages
very efficiently. It has a few features targeted at classic "callout"
use cases, such as data preservation optimization. You will not
need/use those.

	You can take OCP Core and document an application profile that
changes OCP focus from callout to proxying. I cannot say whether OCP
is the best protocol for your needs since I do not know the details of
your environment. It may be a good candidate. Another option would be
to use the native/original application protocol in one direction and
return tracing/billing data via some other means.

	Please also see the following related message:
http://www.imc.org/ietf-openproxy/mail-archive/msg02830.html

	It would be great if you can contribute your use case (and
your OCP profile, if any) to OPES Framework. Please keep us posted on
your progress and do not hesitate to discuss any related issues on
this list.

Thanks,

Alex.

On Wed, 7 Jan 2004, John G. Waclawsky wrote:

> I have been looking over the opes drafts and trying to understand
> the efficiency of a distributed opes framework with a large volume
> of activity (and also trying to gauge how useful it would be for
> time dependent service execution activities). Consider an opes
> service where application data is transformed (or adapted) in some
> way. My question is, If I send the data flow to a callout server to
> perform some opes service task (or a string of call out servers),
> does the data always have to return to the data dispatcher at the
> opes data processor that directed the flow to the call out server in
> the first place (an ancillary question is: can just trace data and
> billing information only be sent back)?. Basically, will an opes
> framework allow the use of a piplining approach where once the
> service is complete at the call out server, the adapted application
> data can be forwarded directly to the data producer or data consumer
> (what ever the case may be)?  Any information, advice or council
> would be greatly appreciated. Thanks. Regards John

---

From: "John G. Waclawsky" <[email-masked]>
Date: Thu, 08 Jan 2004 13:15:17 -0500

Alex, thank you for your reply and the pointer. I agree with you that 
the use case I am interested in is not explicitly documented in the opes 
material. This gives the wrong impression, since all the examples show 
the data flows returning to the first hop data dispatcher. To restrict 
data flow in this way would be inefficient for high capacity 
applications and would tend to make the first hop a bottleneck.

To be a little more specific on my use case and to make sure I 
understand your response let me add more detail. Fundamentally, I wish 
to have an "open" IETF network environment. The second requirement is 
speed in adaptation processing, so I am thinking that callout will be 
faster than using a proxy (maybe this is an incorrect assumption). I may 
be a little confused about the distinction between classic proxy and 
classic call out in this situation (this word proxy isn't even mentioned 
in the opes architecture document as a consideration). Also, I have a 
requirement to adapt a large volume of content for numerous devices.

I expect that the volume of data will require a number of  adaptation 
(call out) processors. I estimate 10 of them and therefore I would need 
load balancing as part of the solution for directing data to the call 
out servers (doing the adaptation). I am looking at Figure 3 in the opes 
architecture draft and considering a load balanced collection of ten 
call out servers. As I had mentioned previously, I'd like to have 
parallel pipeline approach where the adapted data from each of the opes 
call out server is simply forwarded on, directly to the producer or data 
consumer (what ever the case would be). In addition each of the opes 
call out servers would then send billing and trace data back to the load 
balancer (or another network location). Is it realistic to expect that 
this could this be accomplished within the opes framework?  In fact a 
more fundamental question is the opes framework the best way to solve 
this problem and maintain an open system. I think this is what opes is 
all about.

Thanks for your interest in this use case problem and the discussion.
Regards  John

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 8 Jan 2004 13:12:43 -0700 (MST)

On Thu, 8 Jan 2004, John G. Waclawsky wrote:

> Alex, thank you for your reply and the pointer. I agree with you
> that the use case I am interested in is not explicitly documented in
> the opes material. This gives the wrong impression, since all the
> examples show the data flows returning to the first hop data
> dispatcher. To restrict data flow in this way would be inefficient
> for high capacity applications and would tend to make the first hop
> a bottleneck.

John,

	You are misreading OPES architecture diagrams because you are
thinking about a much "simpler" case than most diagrams attempt to
document and, hence, you assign wrong roles to "boxes" that may not
even exist in your environment. This is the architecture draft fault,
not yours. Let me try to explain.

Here is a "classic" OPES proxying case (horizontal lines are
application data/protocols being proxied, proxies may be adapting data
internally):

    Figure A.

        end -- proxy -- proxy -- ... -- end

Here is a "classic" OPES callout case (vertical lines are callout
data/protocols, proxy is not adapting data, callout servers may be
adapting data):

    Figure B.

        end --- proxy --- end
         _________|__________
         |        |         |
         |        |         |
      callout   callout   callout
      server    server    server

A combination of the above is possible and common, of course. In a
combined case, some proxies are adapting data internally and some use
callout servers to adapt.

In your particular case (the adapted data flows to the next hop), you
do not have callout servers. You have proxies that adapt data
internally. However, your case may not be a classic proxying case
because you may want proxies to use a protocol that differs from the
original application protocol (so that you can ship metadata and
perhaps pipeline more efficiently). I will use curly (~) lines to show
that new protocol below. You may also want to do some load balancing:

    Figure C.

                    ~~~~~ proxy1 ---
                   /
      end -- proxy ~~~~~~ proxy2 ---  ??  end
                   \
                    ~~~~~ proxyN ---

I do not know how the proxies will get application data to the right
"end", but it is not important for this discussion.

Note that the curly path may use a completely new protocol (e.g., OCP)
or can use a combination of the original application protocol to
deliver data and some other protocol for metadata (billing, etc.)
records.

The above is OPES, but not a callout case. There are no callout
servers, just proxies. Whether you want to use OCP for the curly path
depends on what kind of data/metadata you want to exchange and what
other protocols you have available.

> faster than using a proxy (maybe this is an incorrect assumption).

It's an incorrect question :-). Adaptations at the callout server can
be as "fast" or as "slow" as adaptations performed internally at the
proxy. The primary reason to use a callout server is to "outsource"
(from business, development, support, logistics, legal, etc. points of
view) adaptations. The primary reasons not to use a callout server are
security and overheads of the data having to return back to the proxy.

> I may be a little confused about the distinction between classic
> proxy and classic call out in this situation (this word proxy isn't
> even mentioned in the opes architecture document as a
> consideration).

I hope the above diagrams clarify the distinction. OPES processor is
the term closest to the "proxy", I think.

> Also, I have a requirement to adapt a large volume of content for
> numerous devices.

Both callout and builtin adaptations can handle large volumes of
content. There are many factors at play here, from legal concerns to
the kind of adaptation being performed.

> (call out) processors. I estimate 10 of them and therefore I would
> need load balancing as part of the solution for directing data to
> the call out servers (doing the adaptation).

Load balancing can be done with both callout and proxying schemes.
OPES mechanisms are usually per-message so any load balancing method
that does not split individual application messages should work just
fine.

> I am looking at Figure 3 in the opes architecture draft and
> considering a load balanced collection of ten call out servers. As I
> had mentioned previously, I'd like to have parallel pipeline
> approach where the adapted data from each of the opes call out
> server is simply forwarded on, directly to the producer or data
> consumer (what ever the case would be).

The latter makes the adapter a proxy, not a callout server (by
definition). See Figure C above.

> In addition each of the opes call out servers would then send
> billing and trace data back to the load balancer (or another network
> location). Is it realistic to expect that this could this be
> accomplished within the opes framework?

It is. The only question is what protocol(s) you will use between your
proxies (the curly lines in Figure C).

> In fact a more fundamental question is the opes framework the best
> way to solve this problem and maintain an open system. I think this
> is what opes is all about.

IMO, OPES framework accommodates, in principle, any intermediary
adaptation. Thus, your problem is within the framework. However, the
framework is not complete. It does not have ready-to-use tools for all
possible intermediary adaptations. I hope that you will find OCP Core
and OPES communications "tools" useful for your problems, but I lack
information to tell your whether they are the best.

The system is "open" if it uses "open standards". If current OPES
tools are not right for you, and there are no better open tools, then
we can work together, within the OPES Framework, on defining open
standards (protocols and interfaces) that will solve your specific
problem.

Alex.

---

From: "John G. Waclawsky" <[email-masked]>
Date: Thu, 08 Jan 2004 15:47:10 -0500

Alex, I very much appreciate your help and the additional  information. 
I need a little time to digest this and think some more about my problem 
and opes "needs".... 
Thanks.   Regards  John

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 8 Jan 2004 11:43:46 -0700

The expectation is that you will be able to use a load-balancer as you
describe.  There shouldn't be any particular OPES protocol
configuration issues involved in the setup.  If you find some, let us
know.

The tracing and billing informatio is slightly different.  You say
that it might go back to the OPES processor(?) (through the
load-balancer?) or to some other location.  This non-specifity of
destination is outside the OPES protocol, and you'd probably do best
to just have the callout servers open a direct connection to the
billing server.  However, you'll need to think about whether or not
the OCP message headers give you enough information to correlate the
billing with the connection that triggered the callout server.

If you simply attach the billing data to the adapted stream and let it
flow back to the OPES processor, you'll need to write code that
recognizes and detaches that data and sends it to your billing server.
You could use OCP to communicate with the billing server, I suppose,
but there are probably any number of other protocols that would be
just as good.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 8 Jan 2004 17:37:51 -0700 (MST)

Hilarie,

	Note that John does NOT want the data to go from the place
where it is adapted back to the proxy/dispatcher. Thus, this is a
proxying case, not a callout server case for which OCP was designed.
If John uses OCP to talk between two processors/proxies, then some
default OCP Core assumptions will not work and will need to be
overwritten in OCP profile.

	I agree that OCP can be used to send tracing and billing info
from one OCP agent to another, and that using OCP for such info makes
most sense if OCP is also used for application data.

Alex.

On Thu, 8 Jan 2004, The Purple Streak, Hilarie Orman wrote:

> If you simply attach the billing data to the adapted stream and let
> it flow back to the OPES processor, you'll need to write code that
> recognizes and detaches that data and sends it to your billing
> server. You could use OCP to communicate with the billing server, I
> suppose, but there are probably any number of other protocols that
> would be just as good.
>
> Hilarie
>