Re: An opes services usage question

On Mon, 12 Apr 2004, John G. Waclawsky wrote:

> Alex, I am assuming, but just to make sure, that the "opes metadata
> exchange" protocol will include solving what I have been calling the
> flow participant discovery problem (finding out who to exchange data
> with is a big part of the problem). Is this correct?

It will include whatever _you_ want it to include since you are the
driving force behind this :-). I just gave it a, perhaps
inappropriate, label based on your last response. To avoid serious
misunderstandings, we would need some kind of a brief but well-thought
statement-of-work to put this work on the rechartering agenda (IMHO).

Alex.



> Alex Rousskov wrote:
>
> >John,
> >
> >	I agree that if your problem space consists of routable
> >proxies with strong client affinity, then that is what you should
> >address first (while keeping more general load balancing demands in
> >mind, iff possible).
> >
> >	My understanding is that we will start discussing OPES
> >rechartering very soon. Adding "OPES metadata exchange" protocol into
> >the discussion mix would be nice. Ideally, for the discussion to be
> >effective, there has to be a draft with a good outline of what the
> >problem space and possible solution directions are. Active
> >participation of interested parties in the WG would be key as well.
> >
> >Thank you,
> >
> >Alex.
> >
> >
> >On Mon, 12 Apr 2004, John G. Waclawsky wrote:
> >
> >
> >
> >>To get back to the discussion. It seems that many of the assumptions
> >>in the background of our discussions about load balancers are based
> >>on web load balancers that provide virtual addresses and hide the
> >>server cluster from the user. But, I have been thinking a little
> >>differently in considering usage of an opes framework in the mobile
> >>wireless market segment. This segment may be unique in that load
> >>balancers do not rebalance for every client connection. Instead they
> >>typically rebalance on a "per client" basis. This is done because
> >>the devices that are being balanced have client information
> >>associated with their traffic such as $, access rights, browser form
> >>factors, XML style sheets...etc. Affinity to a particular server is
> >>strongly maintained for each client. Once affinity is in place the
> >>load balancer could operate, for example, by just replacing the
> >>destination MAC address as the traffic arrives based on the source
> >>IP address (you could view the load balancer as just a "bump on the
> >>wire").  I believe this additional information should help clarify
> >>what I am thinking, a bit. I guess I am looking for the simplest
> >>solution for this environment and I keep thinking the most elegant
> >>solution would be lower layer one.... just some of my thoughts...
> >>
> >>It seems that of the two limitations you suggest, the best way to
> >>proceed (IMO) would be to assume proxies with exposed/routable
> >>adresses.  I am thinking this assumption is the best one because it
> >>probably provides a faster solution, would be more flexible, and
> >>satisfies small deployment needs that do not have load balancers but
> >>still need the metadata returned to a specific server. I think we
> >>are also in agreement that with either limitation we still need
> >>something to support the metadata information exchange. I was also
> >>wondering if anyone else has any suggestions or additional
> >>information to consider?
> >>
> >>Regards  John
> >>
> >>
> >
> >
> >
> >
>