Re: Constraints for multicast

David Hill wrote:

> 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 misunderstand.  I'm not encouraging delay.    I'm making the case that 
multicast is beyond the scope of what the WG has agreed to do, and I think 
it's architecturally more properly done as a separate MEP anyway.   I do 
think it's appropriate that the implied API (I.e. the info provided by a 
sending app or receiving ap) be as similar as possble between one way and 
multicast, but I think the implications for a specific binding to a 
transport are significantly different.   I do agree that the one way MEP 
we're creating will likely be helpful to someone drafting a multicast MEP; 
 I don't think the W3C necessarily has to do it, and I think it's in any 
case beyond the scope of our current effort.

So, for those reasons, I don't want this simple one way effort to 
experience feature creep and become a "one way with simple and multicast 
modes."  If the WG had agreed to do multicast then I would have no problem 
with us starting on it in parallel right now.  We haven't agreed to do 
that.   The WG was in bug fix mode when the WSA team came and said: "ooh, 
emergency, we need a one way MEP to keep our specs in sync".   XMLP said, 
OK, we're all busy, but if it's that important we'll do it.  We're still 
doing it a year later.  I want to do a good job on a simple one way, which 
I think we've about done, and go back into bug fix mode, with phonecalls 
every few months to triage issues and respond to emergencies, and an 
occasional review to see whether something so new and important has arisen 
that we should recharter the group for yet more work.

> > 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 think I made the case as well as I can.  Let's say I want to design an 
API that will drive any binding that implements one-way.  The MEP today 
tells me that I need a single destination address.  The proposal to allow 
multicast suggests that the API might need to allow multiple addresses. 
Maybe to do its job it would need to report apparent success in some of 
the transmissions but not the others. Maybe there would be buffering 
issues in arranging for each copy of the message to go to a different 
destination.  I'm not saying all of these would in practice be problems in 
each case.  I'm saying that even having to stop and think about whether 
they might be adds delay and at least conceptual complexity.  Bottom line: 
 I want the MEP to be written as a simple one way, with a single 
destination property, etc.  It may well be that in certain cases that MEP 
can be used to implement certain forms of multicast, e.g. if that single 
distination is a multicast group.  That's fine.  I just don't want to talk 
about it in the MEP.


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

I think we're getting dangerously close to word games in putting it this 
way.  If I have a program that sends 50 copies of a message to 50 
destinations, is it sending them "one way"?  I think that's a bit of a 
stretch;  it's sending them 50 ways, or at least that's an equally good 
reading of the English.  I think you are perhaps distinguishing "with 
responses" from "no responses", but our proposed MEP is not called "no 
response";  it's called, and the goal we agreed to in continuing the 
design work in the group was "one way", at least in my opinion.  If you 
had wanted an "all cases in which there's no response MEP", then that 
should have been discussed when we set our scope, I think.

> Please be more specific.  Let's try some use cases and see if this 
> complexity pans out.

I don't want to be unhelpful, but there's a time issue here.  Some of us 
budgeted our involvment in XMLP as a maintenance activity.  Then the 
"emergency" requirement came for a one way and we said "ok, we'll stretch 
our schedules, but only for the minimum necessary to declare victory". 
Then was added a long digression on whether state machines were needed and 
how to draft what was always conceived as and is turning out to be a 
pretty simple bit of business.  Please take no offense, but the part of 
this that doesn't work for me is spending the time on further discussion. 
I'm sure that's frustrating, but I just don't think multicast is what I 
signed up to do. 

If you're really uncomfortable letting it go, then I think we have to turn 
this into a process question, which as you know is what we do in W3C when 
these questions come up.  We need to go back to the scope of the charter 
and what it says we've agreed to do.  If it says multicast, then fine, I 
stand corrected (I'm on an airplane at the moment without a copy of the 
charter.)  If it doesn't, then I would ask that while you might have hoped 
that a one-way would provide enough of a banner under which to pursue 
multicast, that it isn't called out in the charter, that it isn't what the 
rest of us signed up to do, and that it's reasonable for us to ask that it 
remains out of scope until such time as the group is rechartered with that 
in scope. 

As I've said repeatedly, I have no problem with you or anyone drafting a 
multicast MEP, the text of would probably overlap to a significant degree 
with one way, and posting that on behalf of Tibco or some other group for 
public use.  I think you could have it together in a few weeks, and I 
suspect (you should check) there would be no unresolvable copyright issues 
in "stealing" much of the text from our one way.  As IBM representative, I 
should say that I am not implying that IBM would or would not want to join 
in promoting such a development.  If there is a groundswell of interest to 
standardize it through W3C, we can to through the appropriate process to 
see whether W3C member companies will commit the necessary resource.  If 
I'm wrong I sincerely apologize, but I really don't recall multicast being 
called out as a goal or success criterion for this phase of our work.  I 
don't feel it's what I signed up to do, and I haven't budgeted the time to 
work on it, look for holes in it, and get it right.  As I've said, even if 
I had, I would on architectural grounds want it to be a separate MEP.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








David Hull <dmh@tibco.com>
08/14/2006 05:16 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     "xml-dist-app@w3.org" <xml-dist-app@w3.org>
        Subject:        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
--------------------------------------

Received on Monday, 21 August 2006 04:53:54 UTC