ietf-openproxy
[Top] [All Lists]

Re: An opes usage question.

2004-02-27 13:05:46


John,

        OPES protocols do not have features specific to a
load-balancing environment, and I do not think they have any features
that do not work in such an environment. If your load balancer can
balance opaque TCP sessions, then OPES callout protocol should work
just fine with multiple callout servers. If you are proxying native
HTTP without outsourcing services via OCP, then load balancers can
balance HTTP "sessions" as well.

        OCP is easier to load balance than HTTP because it does not
have valuable state outside of the OCP connection. While HTTP claims
to be stateless, things built on top of HTTP often require
client/server affinity. Hopefully, OCP will not be abused in such a
way because it has mechanisms to maintain necessary state within the
connection.

HTH,

Alex.

On Fri, 27 Feb 2004, John G. Waclawsky wrote:

I have another question. Does an opes environment handle the
requirement of a peer interacting with another peer with a load
balancer between them. The situation is that I require two proxies
to provide a service.  An "A" proxy and a "B" proxy that are peers
in providing the service to a data flow. Because of the scale, the
likely deployment will involve multiple boxes of types A and B. This
means I will have two groups of boxes with a load balancer between
them. I wish to dynamically associate an specific box of type A with
a specific Box of type B (across the load balancer) and a particular
flow. Is it possible to perform peer discovery and the dynamic
association between the two peers and a flow within the opes
framework? Thanks for any help and guidance.

Regards  John

John G. Waclawsky wrote:

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

Alex Rousskov wrote:

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.



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).



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.



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).



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.






<Prev in Thread] Current Thread [Next in Thread>