Re: An opes usage question.

To Alex or anyone from the opes group.

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