Re: An opes services usage question

Thanks for the clarification.  I understand... the ball (so to speak) is 
in my court...   :-)     Thanks
Regards  John

Alex Rousskov wrote:

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