Alex, from prior e-mails we agreed the use case I described fits within the opes
framework (basically we agreed on items 1, 2 and 3 but not item 4 in my last e-mail). I
am now trying to resolve item 4, I have been looking over the last couple of e-mails and
the 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 (I am assuming that application protocol refers to any protocol enveloped by TCP or UDP). The comment that "each application protocol needs its own tracing profile and some
application protocols will not be able to support embedded tracing at all." is very significant. I find it unrealistic to expect all application protocols (or even a significant number in common use today) will support embedded tracing any time soon. Also, it seems using tracing would be "overkill" for this problem.
B) HTTP Metadata - While HTTP flows support the in-band transfer of small
amounts of metadata this may not practical. The size and volume of the metadata
could be too much for HTTP. Also, this does not provide a complete answer
because HTTP is not the only application protocol we might have to consider.
This suggestion does not seem to be the best general purpose approach.
C) OCP - OCP can't handle any proxy to proxy exchanges because there are no
OCP profiles for proxy to proxy flows.
D) Load Balancer changes - Load balancers are usually high performance boxes and anyone
building a load balancer would most likely object to adding additional processing to deal
with "address translations". It seems impractical and risky to require the
addition of new code into load balancers to support opes (even if it is only to append
and replace IP addresses). Also load balancers will not be balancing metadata if the
metadata is targeted to return to a particular proxy. 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).
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 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. Your thoughts are greatly
appreciated. Thanks again.
Regards John