Re: Constraints for multicast

noah_mendelsohn@us.ibm.com wrote:
> David Hull writes:
>
>   
>> Because the MEP looks like a single operation to the sender, I'm 
>> skeptical of a multi-MEP solution.  AFAICT, the sender would be 
>> participating in a composite operation consisting of 0 .. N MEPs, 
>> which all look identical to it.  The zero case looks especially 
>> troublesome.  Even if there's no one to hear it, the tree still 
>> falls.  Maybe I'm missing something, but this seems like it would be
>> a pain to word precisely, and it doesn't seem particularly close to 
>> the ether model.
>>     
>
> I agree completely with your premise, but not our conclusion.  You seem to 
> be providing a very careful analysis of why, someday somewhere there 
> should be at least one multicast MEP.  
Not at all.  I want it yesterday.  Multicast implementations exist right
now.  IM chat room-like situations would be a third example.
> You correctly describe what it will 
> look like from sender and receiver, even correctly noting that it is in 
> many respects similar to one way, but differs in a least one visible way, 
> which is in the possibility of multiple or partial failures as seen from 
> the sender.  What I don't think you've shown at all is why this should be 
> the same MEP as the one way.  
Economy.  We've already done it, unless you see holes in the current
proposal.  I haven't heard it yet.  If you can demonstrate concretely
what complexity this has added, I'll be glad to try to address it, but
so far I've just heard the assertion that this is adding complexity.
> I don't doubt that its use at sender and at 
> receiver will be quite similar, as seen in an application API, but an MEP 
> is largely a specification for how to write a binding.  The binding sends 
> the messages, and what it does for multicast, particularly on certain 
> transports, is quite different than for one way.  
What would be an example of such a transport?   At worst, don't bind
those transports and do something else.  There are certainly transports
where both the sender's and receiver's views of unicast and multicast
are substantially the same (or indeed, there is no distinction).

BTW, isn't the distinction between "multicast" and "unicast"?  Both are
one-way, this being exactly the commonality we've captured and which I
would like to keep captured.
> Furthermore, I think 
> trying to do multicast inside the one way will complicate the 
> specification of edge conditions in the one way, it will complicate 
> terminology like destination address(es) and so on.
>   
Please be more specific.  Let's try some use cases and see if this
complexity pans out.
> I think the right design point is:  do a one way MEP.  Someone somewhere 
> does a multicast MEP (maybe more than one), and tries to make sure that 
> it's semantics are such that it will be really easy for senders and 
> receivers to support the one way and the multicast using application apis 
> that are as similar as possible.
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>