On Wed, 10 Mar 2004, John G. Waclawsky wrote:
current discussions around item 4 can be summarized around four
potential suggestions to the "flow participant discovery" problem
for the use case.
A) Tracing - My conclusion of this discussion is that tracing is not
a general purpose solution that will work with all application
protocols
Agreed. Tracing is one-way and what you want seems to be two-way
(tracing + notification).
B) HTTP Metadata ... This suggestion does not seem to be the best
general purpose approach.
Agreed. Piggybacking metainfo to HTTP is only good if your application
traffic is HTTP and you do not need notifications (only tracing).
C) OCP - OCP can't handle any proxy to proxy exchanges because there
are no OCP profiles for proxy to proxy flows.
OCP Core can handle proxy to proxy exchanges. One would need to write
a profile to document rules/messages specific to your environment.
D) Load Balancer changes ...
(D) is not a solution like A, B, and C. Whether you change load
balancers or not, you still need a [new] protocol to communicate your
metainformation. (D) is, IMO, an unavoidable requirement (see below).
Note that L7 load balancers have been doing content manipulation for
years. This is not a new requirement. The nature of a L4/7 load
balancer requires them to understand the protocol being load balanced.
Also load balancers will not be balancing metadata if the metadata
is targeted to return to a particular proxy.
Right. L7 load balancers (aka content switches) are used to such tasks
as keeping client-server affinity. Pure load balancing is only a part
of what they have to do.
Sending metadata through a load balancer will likely bring about
scaling issues. All that is required to transfer the metadata, in
this case, is simple out of band communication (once the correct
address is known).
A L7 switch or a proxy can do that and can do that fast. Of course, a
L2 switch can do that even faster, but I am not sure I would recommend
trading speed for exposing proxies behind a load balancer.
Architectural concerns usually trump performance optimizations.
Moreover, in most environments, the traffic would have to go through
the load balancer to the proxy because that is the only way to reach
the proxy. Thus, it would be impossible to bypass the load balancer
box in a typical network setup where proxies are load balanced. (Your
environment may not be typical though, not sure).
All this discussion bring me back to where I started with my initial
opes e-mail. It is apparent that a practical opes solution, useful
today, is not available for this use case.
I agree. No existing protocol seems to be able to support what you
want: bidirectional exchange of application-agnostic metainformation
among agents that are possibly being load balanced.
I recognize that the opes framework is not complete. But I would
really like to see the framework extended to handle this services
use case, which I believe will become one of the first opes
deployments. I continue to believe that the opes framework is the
best way to solve this services usage problem and maintain an open
system. I think this is what opes is all about.
Shouldn't we now look into how to extend the opes framework to
satisfy the need for a "flow participant discovery" solution?
Solving the flow participant discovery problem in the most general
way without dependencies on load balancers opens up lots of ways of
sending any metadata out-of-band between proxies.
Are the following three requirements correct?
1) Agents need to communicate metainformation to each other
2) metainformation is related to some application protocol, but
agent communication protocol should be application agnostic
(i.e., should work with many application protocols)
3) some agents are being load balanced with respect to the
application protocol in question
If yes, I conclude:
- some agents will not have IP addresses reachable from other
agents
And, hence,
- agent communication without assistance of load balancers
would be impossible in general
To resolve the conflict, you have two options, I think:
(a) require load balancers to handle part of the communication
(this is how HTTP, SSL, and ICAP are load balanced today)
(b) limit the environment to agents that are IP-reachable
despite being load-balanced
(this would exclude some (many?) load balancing environments)
Do you see what I am getting at? In short, if something is behind a
load balancer, that something may not have a routable IP address and,
hence, cannot communicate directly with the world.
Whether you chose (a) or (b), you still need a new protocol or new
protocol profile to support the metainformation exchange.
Alex.