The IP over ATM Mailing List Archive by date

[jed@llnl.gov (James E. [Jed] Donnelley)]

I started this "Multicasting with ATM - a concern" thread
because I was worried about getting too far down the path with
the IP over ATM approach discussed in "Support for Multicast
over UNI3.1 based ATM Networks" - draft-ieft-ipatm-07.txt
without a clear understanding that it would suffice for
the sort of multicast applications that are running now
(after a fashion) over the Internet MBone.

I received many very thoughtful and to me useful replies - mostly
on the ip-atm@matmos.hpl.hp.com list.

I feel there is a clear conclusion from these replies.  Based on
this assumption I would like to end that discussion and
ask what I hope is a more focused and limited "meta" question.

My conclusion from the discussion on this thread is that
ATM will not effectively support multipoint to multipoint
"circuits."  It won't even effectively support bi-directional
point to multipoint "circuits."  I hope my terminology is
clear here.  The basic problem is the multiplexing of
a single circuit data structure while still separating the
multiple transmitters at the destination - e.g. with VCIs
within a VPI or whatever.

I don't want to fan any embers that may be smoldering
on that issue, but rather ask a higher level question.
Basically the question is "does it matter?"  Namely, are
there applications for which the capabilities that ATM
does deliver are not adequate?

We have numerous examples of multicast applications
available on the MBone.  These currently work with
the IP multicast group mechanism.  Do they need to?
Would something simpler do?

When I think about multicast applications I tend to
fall into thinking about something like a distance
learning application or a radio or television talk show.
Namely, there is one usual "multicaster", but possible
sporadic "back" channels that may be distributed to
the multicast group.

It seems to me that ATM's support for a unidirectional
multicast circuit suffices for what is needed for such
applications.  Namely, a multicaster can set up such a
multicast circuit.  Any "back" channels can be set up
from the back transmitters as unicast circuits directly
to the multicaster.  The multicaster can then mix these
back channels into the multicast.  Not quite like
current IP multicast group semantics, but is the difference
important for applications?

All that is needed with this approach is efficient
(i.e. scalable, etc.) support for unidirectional
point to multipoint multicast.
_____________________________

My meta question is: are there applications for
which such an approach will not suffice?  I.e.
are there applications where a true multipoint
to multipoint capability is needed?

Since both these lists are mostly focused on lower
level issues (are there such lists for higher level
issues or are such things only supposed to be discussed
face to face?), I ask that any responses be sent
only privately to me.  I would think that potential
examples can be discussed off-line and only brought
to the list if any seem solid.

Since I don't want to come back to the lists unnecessarily,
I would like to explore the consequences of the possibility
that there are NO such applications.  In this case it seems
to me that perhaps we have a problem with the semantics
of IP multicast groups.  Namely they may be more rich than
needed and specifically too rich for a reasonable ATM
implementation.

While I accept Dan Grossman's comment:

>Bringing us back full circle to where the ip-atm WG is already at - mpt-mpt
>IP communication using overlaid pt-mpt VCs.

in the limited sense in which I think he meant it - namely this
is where we are in trying to adapt IP multicast to ATM.
However, I am unhappy with this conclusion in terms of
what it means for multicast applications over ATM.
This approach of overlaying pt-mpt VCs to achieve IP
multicast will not (IMO) scale.  It will not scale and so it
effectively WILL NOT WORK.  Who are we kidding with
this approach?

It seems to me that we might be in a situation where
we have adopted an overly rich set of semantics for
IP multicast because it was available.  IF (!) there are
no applications that truly require mpt to mpt
multicast semantics, might we not be better off
defining a new and narrower set of multicast semantics
that can effectively used to build applications for IP and
"native" ATM and IP over ATM?

I still feel my original concern, but thanks to the many
thoughtful comments on the lists I think my concern is
somewhat more focused.  The problem I see is that we
are continuing to "blindly" develop multicast applications
for the rich IP multicast semantics when a narrower
set of semantics would (?) suffice AND would work
effectively with ATM if/when it becomes more widely
available.

Please be kind to the lists and direct all but the most
generally relevant comments directly to me (jed@llnl.gov)
until they can be filtered some.  Naturally I will respond
as best I can to requests to take such high level discussions
elsewhere - suggestions on where elsewhere might be
are solicited.


--Jed   http://www-atp.llnl.gov/atp/jed-signature.html