Constraints for multicast

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Constraints for multicast

David Hull
Here is what I want to be able to capture about multicast.
  • Actual implementations do it.  If I publish a message, or send it to a mailing list, or send a broadcast or IP multicast packet, multicast will happen.
  • Multicast looks like a single operation to the sender.
  • Multicast looks like a single operation to each receiver.
  • The sender and all receivers are participating in the same operation, particularly for the purposes of logging and error reporting.
I believe the approach I've proposed, of the binding specifying a mapping from the address the sender gave to zero or more receivers, handles this cleanly, both in that it's close to what actually happens in implementations, and because it adds very little extra verbiage to the spec.  The current text reflects this approach, though it doesn't mention the mapping explicitly.

This approach is based on an ether model, which I believe captures what happens in real life in a wide variety of instances:  The sender sends a message into the ether.  Each receiver sees a message emerge from the ether.  What happens up in the ether is its business.  In the olden days, of course, we used to have black boxes to do this kind of thing, but ether suggests something more widespread and diffuse.  In real life, the ether could be the email infrastructure, with a mailing list handler inside, or the network itself, or your favorite messaging infrastructure, or a radio channel, or whatever.

Noah mentioned (at least to me), a model in which a single logical destination is embodied as multiple physical destinations.  I think this is very close to what I proposed, the main question being whether it can be separated out from the one-way MEP description proper.  From the sender's point of view, it definitely can.  The whole point of multicast is that at least in normal operation it looks the same to the sender.  What concerns me is the constraint that the receivers are all participating in the same MEP.  In particular, the sender may get error messages from multiple receivers for the same MEP (e.g., bounce messages for multiple members of a mailing list).

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.
Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

noah_mendelsohn

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

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





Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

David Hull
[hidden email] 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
--------------------------------------





  

Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

noah_mendelsohn

David Hill wrote:

> [hidden email] 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 <[hidden email]>
08/14/2006 05:16 PM
 
        To:     [hidden email]
        cc:     "[hidden email]" <[hidden email]>
        Subject:        Re: Constraints for multicast


[hidden email] 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
--------------------------------------





 



Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

David Hull
I think perhaps the major disconnect is here:
"The proposal to allow multicast suggests that the API might need to allow multiple addresses."
This is certainly not the intent of the proposed text.  To take an example, if I send email to {[hidden email], [hidden email]}, that would be two instances of the MEP.  If I send email to {[hidden email]}, that would be one instance, just as if I sent to {[hidden email]}.  In other words, there is exactly one ImmediateDestination per MEP instance, just as the table says.

What I'm trying to capture is that, in a number of significant realizations, a single ImmediateDestination can denote 0 .. N receiving nodes, in a way that is of interest to the binding.  For example, it doesn't matter whether I joined xml-dist-app by sending a request to xml-dist-app-owner, bribing someone at W3C, hacking into the W3C servers, or even subscribing my own mailing list as a member of xml-dist-app.  Neither does it matter exactly how the mail infrastructure causes messages to appear in people's mailboxes.  What matters is that if I send a SOAP message to a given address, 0 .. N SOAP nodes will, in normal operation, execute the SOAP processing model on what I sent.

I don't see how we can model these cases (email, chat-room, IP multicast, pub-sub etc.) without accounting for this basic behavior.   Particularly in cases like email and at least some flavors of pub-sub, there's generally no guaranteed way of determining whether you're sending to one or 0 .. N receivers and, conversely, you don't generally care greatly.

As far as I can tell, this work is and always has been part of properly describing SOAP over asynchronous protocols.  In other words, it looks to me more like old work.  I certainly don't want to rathole on it, but I've very concerned about what the world would look like if it were specifically put out of scope.  Would an email binding have to explicitly forbid mailing lists, pending further work by the committee?

Fortunately, it appears that all we need to do is tweak the existing language so as not to assume a strong coupling between sender and receiver.  In retrospect, it seems to me that moving away from the state machine was a very helpful step in this direction.  In terms of deltas to the current draft, I believe there are only two changes relevant to multicast.  The significant one is
"The sending node MUST send the SOAP Message provided in http://www.w3.org/2003/05/soap/mep/OutboundMessage to the node(s) identified by http://www.w3.org/2003/05/soap/mep/ImmediateDestination."
This is not how several likely binding protocols work.  If I'm sending email, I don't send to my recipients directly.  I go through a mail server, which then sorts it out.  Once I've sent the message to the server, I can hang up and do something else.  Likewise, if I'm jabbering or IM-ing, I'm talking to a server and my server is talking to yours.  As I've said, this model of "sender puts messages into the ether, each receiver sees messages come out of the ether" appears to be central to a significant portion net traffic.

However, if we change "The sending node MUST send" to something more like "The binding MUST manage delivery of", we're much closer to what's really happening.  As one particular consequence, the relation between the ImmediateDestination and the actual receiver(s) is now the binding's concern, not the sender's.  It's up to the binding whether to support multicast at all.  If it supports exactly one recipient per ImmediateDestination, then it's under no obligation to deliver to more.

The second change is just proofreading: change "the receiving SOAP node" in section 2.4 to "any receiving SOAP nodes".

Really, I still don't think we're very far apart here.  When you say:
"It may well be that in certain cases that MEP can be used to implement certain forms of multicast, e.g. if that single destination is a multicast group."
I agree, except that I tend to think the "certain cases" will be, if not the norm, at least a significant portion.  However ...
That's fine. I just don't want to talk about it in the MEP.
I don't quite agree.  I believe it's necessary, and sufficient, to leave a hook directly in the MEP, in the form of decoupling  sender from receiver and allowing for multiple receivers.  This includes noting that  the sender may receive both 0..N acks and 0..N naks for a given MEP instance, but this can happen in the point-to-point case as well (e.g., I can get multiple bounce/retry messages for a single point-to-point email).

The rest -- e.g., buffering of multiple messages or delivering multiple error messages -- is up to the binding.

[hidden email] wrote:
David Hill wrote:

  
[hidden email] 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 [hidden email]
08/14/2006 05:16 PM
 
        To:     [hidden email]
        cc:     [hidden email] [hidden email]
        Subject:        Re: Constraints for multicast


[hidden email] 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
--------------------------------------





 



  

Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

noah_mendelsohn

David Hull writes:

> "The proposal to allow multicast suggests that the API might need to
> allow multiple addresses."  This is certainly not the intent of the
> proposed text.  To take an example, if I send email to {dmh@tibco.
> com, [hidden email]}, that would be two instances of the
> MEP.  If I send email to {[hidden email]}, that would be one
> instance, just as if I sent to {[hidden email]}.  In other words,
> there is exactly one ImmediateDestination per MEP instance, just as
> the table says.

When I send an email to a local distribution list (e.g. to: xml-interest
or some such) it's not uncommon for my mailer to pop up a warning in the
spirit of the following, one I would never see in sending to an
individual:

        Warning: email addresses BobSmith, MaryJones, TommySlim not found,
continue sending to the other 53 users on this list?

If I send the same email to distApp, I tend not to get such bounces in the
course of sending (though I may of course get bounce replies, but we both
agree those are beyond the scope of either form one one-way MEP).

Sometimes the natural interface to a multicast is identical to the natural
interface for a unicast; sometimes not.  In the case above, the interface
to the multicast naturally included a "partially failure to send", "OK to
send to part of the mulitcast group, etc."  That's why my preference is to
not advertise anything to do with multicast in specing this MEP.  If your
particular flavor of multicast is so similar to one way that it fits, then
fine.  You can always model this as "sure I used that one-way MEP for my
multicast -- what I really did was send to one destination (the list) one
message (as sent);  it's an artifact of my implementation that we down
under the cover bits fanned out on what seemed to be multiple paths to
reach the distributed implementation of that one logical destination, I.e.
the multicast group.  I don't mind anyone using the MEP with multicast, I
just don't want to head down the slippery slope of implying that we are
going to undertake to add things to the MEP as necessary to make it work
with this or that flavor of multicast.

> What I'm trying to capture is that, in a number of significant
> realizations, a single ImmediateDestination can denote 0 .. N
> receiving nodes, in a way that is of interest to the binding.  For
> example, it doesn't matter whether I joined xml-dist-app by sending
> a request to xml-dist-app-owner, bribing someone at W3C, hacking
> into the W3C servers, or even subscribing my own mailing list as a
> member of xml-dist-app.  Neither does it matter exactly how the mail
> infrastructure causes messages to appear in people's mailboxes.
> What matters is that if I send a SOAP message to a given address, 0
> .. N SOAP nodes will, in normal operation, execute the SOAP
> processing model on what I sent.

If you look at it that way, I strongly feel that it's a different MEP.  If
you want to view the multicast group as one distributed/replicated
receiving node, that's up to you, but you'll have to deal with the fact
that you're stretching things.  Those N receivers may have different
notions of whether faults occurred, for example, and while the MEP won't
cause the sender to know, and omniscient observer will.

In fact this convinces me more strongly that one way is not multicast,
because you've acknowledged that N SOAP messages are being sent and the
SOAP processing model is being invoked N-e times (where e is the number of
failures to transmit), and the whole reason we invented MEPs was to be
able to tell how that's different from a single message with a single SOAP
processing invocation (or failure).

I'm not saying we couldn't have a multicast MEP with unicast as a
degenerate case.   I'm saying:

a) I'd call it multicast, not one way
b) I think we'd really loose something by not having a clear simple
separate MEP for the 90% case.

> However, if we change "The sending node MUST send" to something more
> like "The binding MUST manage delivery of", we're much closer to
> what's really happening.

I'm curious as to whether others in the WG consider that a useful
instruction as that main point of conformance for the sender.

Anyway, the TAG on it's mailing list guidelines has a suggestion which I
think is a good one, which is basically that when a conversation like this
goes back and forth about 3 times it's about time to stop.  I'm not saying
drop the issue, but stop batting emails back and forth.  I think readers
of this thread will well understand both of our concerns.  We've both had
a chance to set them out in some detail.  I would suggest that our chair
and the workgroup collectively consider our exchange and decide on:

a) whether enabling this MEP for multicast is the right course
technically, even assuming that the spec. work involved is as
straightforward as you suggest (my own intuition is that the immediate
changes to the spec would be indeed small, the philosphical change very
significant and in my view undesireable, and the risk of scope creep
moderate but real).
b) if the answer to the above is "yes in principle", then the group should
quickly estimate what work and risk will be involved, and confirm that not
only is this desirable in principle, but that the cost/benefit is positive
and that we want to take the time to attempt the appropriate redrafting.
c) if the answer to b is "yes", then we should go ahead and do it.

As noted, I am fairly strongly opposed to answering "yes" to (a), and so
can personally avoid most of the need to look at (b).  That said, if a
preponderance of the workgroup agrees with you that this should be done,
and if their analysis at the (b) level is that the cost/benefit is
favorable, I would not stand in the way.

In short, I propose that we stop now what has been essentially a two-way
exchange between us, and ask the group what they'd like to do.   I think
we've each set out pretty clearly the facts as we see them.  Thanks!

Noah


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





Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

Yves Lafon
In reply to this post by David Hull

On Mon, 21 Aug 2006, David Hull wrote:

> This is certainly not the intent of the proposed text.  To take an
> example, if I send email to {[hidden email], [hidden email]},
> that would be two instances of the MEP.  If I send email to
> {[hidden email]}, that would be one instance, just as if I sent to
> {[hidden email]}.  In other words, there is exactly one
> ImmediateDestination per MEP instance, just as the table says.

A mailing list address is far different from a multicast group, in the
case of a ML, you send a message to a kind of "replicator", ie: processing
is done, and you can see it (in the headers). I would recommend strongly
against trying to accomodate multicast and one way unicast in the same MEP.

--
Yves Lafon - W3C
"Baroula que barouleras, au tiƩu toujou t'entourneras."


Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

Anish Karmarkar
In reply to this post by noah_mendelsohn

[hidden email] wrote:

> David Hull writes:
>
>> "The proposal to allow multicast suggests that the API might need to
>> allow multiple addresses."  This is certainly not the intent of the
>> proposed text.  To take an example, if I send email to {dmh@tibco.
>> com, [hidden email]}, that would be two instances of the
>> MEP.  If I send email to {[hidden email]}, that would be one
>> instance, just as if I sent to {[hidden email]}.  In other words,
>> there is exactly one ImmediateDestination per MEP instance, just as
>> the table says.
>
> When I send an email to a local distribution list (e.g. to: xml-interest
> or some such) it's not uncommon for my mailer to pop up a warning in the
> spirit of the following, one I would never see in sending to an
> individual:
>
>         Warning: email addresses BobSmith, MaryJones, TommySlim not found,
> continue sending to the other 53 users on this list?
>

Isn't this a binding specific error?
One could get a simliar error when sending an email to an address which
is not a mailing list (without the question about 'continue sending').
Since we are really talking about fire-and-forget, I don't think these
errors or warnings have a relevance at the MEP-level.

I do share Noah's concern about feature-creep and finishing up our
one-way MEP work. I would prefer that our one-way MEP allow folks to use
it for multicast (our MEP spec should not prevent it), but we shouldn't
go into modeling it explicitly.

-Anish
--


<snip/>

Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

David Hull
I'm not entirely clear what "modeling multicast explicitly" means.

If it means acknowledging that multicast can happen, i.e., that a single act of sending a message can result in multiple acts of receiving the same message, then I don't see how we can avoid this and still produce useful bindings for several transports of interest.  Since it appears by example that we can produce a useful binding with such acknowledgment (in the English sense, not the protocol geek sense!) in the MEP, and no one has given anything concrete about how we might proceed without it, I'd say this point is pretty clear-cut by now.

If it means trying to talk about things like how one might join a multicast group, or how a binding might do fan-out or use network-level broadcast or whatever, then of course not.  That would complicate the architecture to no end and for no gain, and I would be strongly against it.

Anish Karmarkar wrote:
[hidden email] wrote:
David Hull writes:

"The proposal to allow multicast suggests that the API might need to
allow multiple addresses."  This is certainly not the intent of the proposed text.  To take an example, if I send email to {dmh@tibco.
com, [hidden email]}, that would be two instances of the
MEP.  If I send email to {[hidden email]}, that would be one instance, just as if I sent to {[hidden email]}.  In other words, there is exactly one ImmediateDestination per MEP instance, just as the table says.

When I send an email to a local distribution list (e.g. to: xml-interest or some such) it's not uncommon for my mailer to pop up a warning in the spirit of the following, one I would never see in sending to an individual:

        Warning: email addresses BobSmith, MaryJones, TommySlim not found, continue sending to the other 53 users on this list?


Isn't this a binding specific error?
One could get a simliar error when sending an email to an address which is not a mailing list (without the question about 'continue sending'). Since we are really talking about fire-and-forget, I don't think these errors or warnings have a relevance at the MEP-level.

I do share Noah's concern about feature-creep and finishing up our one-way MEP work. I would prefer that our one-way MEP allow folks to use it for multicast (our MEP spec should not prevent it), but we shouldn't go into modeling it explicitly.

-Anish
--


<snip/>


Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

Anish Karmarkar

I meant acknowledging it.

For example, the only difference between IP multicast and a IP unicast
(from a sender's viewpoint) is that IP multicast address is a separate
class D address (range: 224.0.0.0 - 239.255.255.255).

-Anish
--

David Hull wrote:

> I'm not entirely clear what "modeling multicast explicitly" means.
>
> If it means acknowledging that multicast can happen, i.e., that a single
> act of sending a message can result in multiple acts of receiving the
> same message, then I don't see how we can avoid this and still produce
> useful bindings for several transports of interest.  Since it appears by
> example that we /can/ produce a useful binding with such acknowledgment
> (in the English sense, not the protocol geek sense!) in the MEP, and no
> one has given anything concrete about how we might proceed without it,
> I'd say this point is pretty clear-cut by now.
>
> If it means trying to talk about things like how one might join a
> multicast group, or how a binding might do fan-out or use network-level
> broadcast or whatever, then of course not.  That would complicate the
> architecture to no end and for no gain, and I would be strongly against it.
>
> Anish Karmarkar wrote:
>> [hidden email] wrote:
>>> David Hull writes:
>>>
>>>> "The proposal to allow multicast suggests that the API might need to
>>>> allow multiple addresses."  This is certainly not the intent of the
>>>> proposed text.  To take an example, if I send email to {dmh@tibco.
>>>> com, [hidden email]}, that would be two instances of the
>>>> MEP.  If I send email to {[hidden email]}, that would be one
>>>> instance, just as if I sent to {[hidden email]}.  In other words,
>>>> there is exactly one ImmediateDestination per MEP instance, just as
>>>> the table says.
>>>
>>> When I send an email to a local distribution list (e.g. to:
>>> xml-interest or some such) it's not uncommon for my mailer to pop up
>>> a warning in the spirit of the following, one I would never see in
>>> sending to an individual:
>>>
>>>         Warning: email addresses BobSmith, MaryJones, TommySlim not
>>> found, continue sending to the other 53 users on this list?
>>>
>>
>> Isn't this a binding specific error?
>> One could get a simliar error when sending an email to an address
>> which is not a mailing list (without the question about 'continue
>> sending'). Since we are really talking about fire-and-forget, I don't
>> think these errors or warnings have a relevance at the MEP-level.
>>
>> I do share Noah's concern about feature-creep and finishing up our
>> one-way MEP work. I would prefer that our one-way MEP allow folks to
>> use it for multicast (our MEP spec should not prevent it), but we
>> shouldn't go into modeling it explicitly.
>>
>> -Anish
>> --
>>
>>
>> <snip/>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Constraints for multicast

David Hull

Anish Karmarkar wrote:
> I meant acknowledging it.
>
> For example, the only difference between IP multicast and a IP unicast
> (from a sender's viewpoint) is that IP multicast address is a separate
> class D address (range: 224.0.0.0 - 239.255.255.255).
Right.  The whole point in taking this on is that there's very little
difference from the point of view of the sender or from the point of
view of any particular receiver.  It's only when you have to talk about
the correlation between "sender sends" and "receiver(s) receive" that
there's any cause to mention cardinality.

To me, the important part that we're capturing is that a binding MUST
say "this is what you do to send" and "this is what you do when a
message comes in".  That information should be independent of exactly
how sending events are correlated with receiving events.  The email
binding sketch I sent basically says that, and also "senders are
connected to receivers via email" and "which of course means that there
can be multiple receivers for a given address".

IMO it's the message mapping information -- how the properties manifest
as parts of an email message -- that's the real value added.  Arguably,
if you're using email for transport you already know how email works.
What you don't know is the standard way to put SOAP into email and get
it back out again.

My objection to unicast only is that the mapping information is common
to both, and I don't want to have two separate MEPs saying "this is how
you put SOAP in a message sent to a single address" and "this is how you
put SOAP in a message sent to multiple destinations", when it's the same
in both cases.  Particularly if you can't tell the difference anyway.


>
> -Anish
> --
>
> David Hull wrote:
>> I'm not entirely clear what "modeling multicast explicitly" means.
>>
>> If it means acknowledging that multicast can happen, i.e., that a
>> single act of sending a message can result in multiple acts of
>> receiving the same message, then I don't see how we can avoid this
>> and still produce useful bindings for several transports of
>> interest.  Since it appears by example that we /can/ produce a useful
>> binding with such acknowledgment (in the English sense, not the
>> protocol geek sense!) in the MEP, and no one has given anything
>> concrete about how we might proceed without it, I'd say this point is
>> pretty clear-cut by now.
>>
>> If it means trying to talk about things like how one might join a
>> multicast group, or how a binding might do fan-out or use
>> network-level broadcast or whatever, then of course not.  That would
>> complicate the architecture to no end and for no gain, and I would be
>> strongly against it.
>>
>> Anish Karmarkar wrote:
>>> [hidden email] wrote:
>>>> David Hull writes:
>>>>
>>>>> "The proposal to allow multicast suggests that the API might need to
>>>>> allow multiple addresses."  This is certainly not the intent of
>>>>> the proposed text.  To take an example, if I send email to
>>>>> {dmh@tibco.
>>>>> com, [hidden email]}, that would be two instances of the
>>>>> MEP.  If I send email to {[hidden email]}, that would be one
>>>>> instance, just as if I sent to {[hidden email]}.  In other words,
>>>>> there is exactly one ImmediateDestination per MEP instance, just
>>>>> as the table says.
>>>>
>>>> When I send an email to a local distribution list (e.g. to:
>>>> xml-interest or some such) it's not uncommon for my mailer to pop
>>>> up a warning in the spirit of the following, one I would never see
>>>> in sending to an individual:
>>>>
>>>>         Warning: email addresses BobSmith, MaryJones, TommySlim not
>>>> found, continue sending to the other 53 users on this list?
>>>>
>>>
>>> Isn't this a binding specific error?
>>> One could get a simliar error when sending an email to an address
>>> which is not a mailing list (without the question about 'continue
>>> sending'). Since we are really talking about fire-and-forget, I
>>> don't think these errors or warnings have a relevance at the MEP-level.
>>>
>>> I do share Noah's concern about feature-creep and finishing up our
>>> one-way MEP work. I would prefer that our one-way MEP allow folks to
>>> use it for multicast (our MEP spec should not prevent it), but we
>>> shouldn't go into modeling it explicitly.
>>>
>>> -Anish
>>> --
>>>
>>>
>>> <snip/>
>>>
>>
>