W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2001

[AMG]: Some thoughts on Multicast.

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 22 Mar 2001 16:01:57 -0000
Message-ID: <5E13A1874524D411A876006008CD059F192323@0-mail-1.hpl.hp.com>
To: "Henrik Frystyk Nielsen (E-mail)" <frystyk@microsoft.com>, "Jean-Jacques Moreau (E-mail)" <moreau@crf.canon.fr>, "John Ibbotson (E-mail)" <john_ibbotson@uk.ibm.com>, "Krishna Sankar (E-mail)" <ksankar@cisco.com>, "Lynne Thompson (E-mail)" <Lynne.Thompson@unisys.com>, "Marc Hadley (E-mail)" <marc.hadley@uk.sun.com>, "Mark A. Jones (E-mail)" <jones@research.att.com>, "Martin Gudgin (E-mail)" <marting@develop.com>, "Nick Smilonich (E-mail)" <nick.smilonich@unisys.com>, "Oisin Hurley (E-mail)" <ohurley@iona.com>, "Scott Isaacson (E-mail)" <SISAACSON@novell.com>, "Yves Lafon (E-mail)" <ylafon@w3.org>
Cc: "David Fallside (E-mail)" <fallside@us.ibm.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
On last nights AMG telcon I took an action to discuss seed some discussion
of multicast addressing issues in relation to one-way messaging and
request-response messaging patterns. Here are a few thoughts intended to
promote further discussion.

Regards

Stuart
--

XMLP/SOAP and Multicast
------------------------

I am familiar with two styles of multi-cast routing.

1)	Where there is a notion of membership of a multicast group where
enumaration of all multicast group members is not possible (ie. the
originator of a message is unable to determine how many recipients will
receive the message and who/what/where those recipients are). IP multicast
works in this fashion. Nodes become members of a multicast group by
listening on a multicast address (and port - I'm a bit hazy on the details).
IP multicast addresses are recognisable as the occupy a defined sub-range of
the IPv4 address space. Also, the act of listen on a multicast address
general cause a multicast IP node to advertise it's interest in a multicast
group (unless it observes interest from others on the same real subnet - in
which case it supresses it report since a regular report from just one such
node is enough). The multicast routing infrastructure picks up this report
and works to ensure that packets sent to that particular IP multicast
address reach that particular real subnet and are MAC layer multicast (if
it's a LAN) to all those nodes listening for packets destined to that
particular multicast group. For the most part this is in a sense real
multicast, making maximum use of underlying LAN multicast capabilities and a
branching message distibution topology.

	I am only aware of UDP based usages of IP multicast. I'm not aware
of a Multicast TCP and have some difficulty in concieving what that might be
designed to achieve - particularly in the context of an open group
membership.

	I make this latter point only to note that HTTP is dependent on TCP
and so I would not expect direct multicast support from HTTP. I'd possibly
even go so far as to suggest that SOAP 1.1 over HTTP doesn't do multicast -
but I'm prepared to be informed otherwise.

2)	Where the sender (or its agent) has an explicit knowledge of the
membership of a multicast group and dispatches messages to the group through
repeated unicast to an enumberable set of group members - this distribution
could happen directly at the sending node or at some (yes) intermediary
whose role is message distribution to the members of a multicast group.

	It is certainly plausible that HTTP could be used to distribute
SOAP/XMLP messages in this way.

The area of multicast messaging and particularly reliable multicast
messaging remains a live and active topic of research.

So how does this relate to SOAP/XMLP?

SOAP/XMLP one-way (UNITDATA)
----------------------------
It would seem plausible that we could send a one-way SOAP/XMLP message to a
multicast destination. In prinicple at least the sending application need
have no knowledge of whether it is addressing a unicast or multicast
destination. It need not be necessary for us to devise some conventions or
style to decorate URIs in away that enable us to distinguish a unicast URI
from a multicast URI. In the case of SOAP/XMLP over HTTP, something some
'magic' (currently unspecified) would need to happen under-the-hood either
at the sending node or an an intermediary would have to maintain the notion
of a set of destination URIs are an expansion of the destination URI (and
could themselves denote further multicast groups).

It is not clear (to me at least) that SOAP when bound to HTTP currently
truely supports one-way messaging - it is not clear to me whether the HTTP
POST response is allowed to return an empty/null message. Setting that
aside, SOAP/XMLP over HTTP (over TCP) can achieve a multicast effect which
relies on repeated unicast to an enumerable set of actual destinations.

SOAP/XMLP request/response (DATA)
---------------------------------
Multicast request/response is trickier. Firstly, in the model presented in
the AM document a request/response operation can fail ie. a response can be
silently absent. It is also the expectation in the abstract model that a
request in the DATA operation gives rise to at-most one response. This could
be seen as a specialisation of request/multiple-response where the first
response is also the last response, but even in the general multi-response
case (which is not discussed in the AM) the expectation would be that the
multiple responses all came from the same source and that the last response
is in someway distinguished so that the lifetime of the operation can
normally be bounded.

So I think the question to consider wrt to multicast request/response is
what would we expect to happen with a multicast request and unicast
responses. In this case a single request give rise to multiple responses in
a similar way to the request/multiple-response case. However, each response
is made by a different responding application and in the single-response per
responder case each is a last response and in general initiator will not
know how many response messages to expect.

So how might a multicast request/response be modeled. Firstly, there is
implied correlation (whether due to the underlying protocol and biding or
due to the inclusion of a message id/corelation id/request id in a message
header). Responses would either directly correlate with a request (because
of repeated uni-cast) or correlate with the request by carrying a message
id/corelation id/request id that matches the one in the request. At the
responding end of the operation things are identical to the unicast case. It
the initiating end, response message loss is allowed and the operation could
be terminated against a timer (late responses being lost).

From an AM point-of-view this has made very little change to the DATA
operation (other than allowing for multiple DATA.confirms) this could also
easily be harmonised with an operational model that encompases
request/multi-response.

Summary
-------
If there is a hard part to this, its exploiting real multicast
infrastructure and that's regardless of the one-way and request/response
discussion - the mapping of destination URIs to multicast groups and the
fact that HTTP is not itself a multicast protocol - we would have to rely on
repeated unicast to reach multiple destinations. 

This of course is only for simple situations where reliable multicast [1] is
not required and/or where we have few if any concerns over the relative
ordering of arrival of messages at multicast destinations. Ken Birman's work
on ISIS [2,3] in the '80s included work on 'atomic multicast' protocols
where all messages are delivered to all nodes in the group in the same order
- it also considers a number of weaker ordering constraints, but I am not
familiar enough with the work to elaborate. The papers at [2] are a good
place to start if you have deep interests in multicast application
protocols.

[1] http://www.ietf.org/html.charters/rmt-charter.html
[2] http://www.cs.cornell.edu/Info/Projects/ISIS/ISISpapers.html
[3] http://www.cs.cornell.edu/Info/Projects/ISIS/
Received on Thursday, 22 March 2001 12:54:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:59 GMT