Re: multicast-transition

[Marshall Eubanks <tme@21rst-century.com>]

Hi Ross;

SSMinterest is not really the appropriate place to discuss this IMHO, as
it is not really an SSM issue. MboneD or even IDMR might be better.

Ross Finlayson wrote:
> 
> In considering a multicast tunneling solution, we need to be clear about
> exactly what environment(s) we are aiming for.  As Tony noted, the
> immediate focus should be on mechanisms for supporting non-native-multicast
> *receivers*.  (It might also be useful to concentrate first on *SSM*
> receivers, although I hope ISM can be supported as well.)

Why ? What's the difference here ? In both ISM and SSM you have a receiver
receiving multicast traffic (maybe by unicast) and mirroring this
traffic out to other
receivers. Why should this system care what address block the traffic
uses ?

Or are you just saying that the first goal should be to support
receivers, not
senders ? That's OK, of course.

Whether it's a IGMP v2 or v3 join, the real problem is source discovery,
which is
going to involve some out of band mechanism, so I do not see that SSM
really buys you
much in this case...

> 
> Considering receivers, there seem to be four possibilities, based on two
> independent Boolean variables:
> - "OldOS" or "NewOS": Whether or not the receiver's OS supports (or can be
> upgraded to support) IGMPv3, and/or a IP-level multicast tunneling protocol.
> - "OldFHR" or "NewFHR": Whether or not the receiver's first-hop router
> supports (or can be upgraded to support) IGMPv3 and PIM, or failing that, a
> multicast tunneling protocol.
> 
> So, the four cases to consider are:
> 1/ OldOS,OldFHR
> 2/ OldOS,NewFHR
> 3/ NewOS,OldFHR
> 4/ NewOS,NewFHR
> 
> (Case 4 [NewOS,NewFHR] is the ideal case in which both the OS and FHR are
> doing 'the right thing', so no tunneling is needed.)
> 
> Of the remaining 3 cases, the most frequently occurring (and thus the most
> important cases to consider) are probably [OldOS,OldFHR], [NewOS,OldFHR],
> and [OldOS,NewFHR], in that order.  (Note that for most end users, their
> first-hop router is a legacy DSL router or dialup portmaster.)  In any
> event, it seems clear that any useful tunneling solution can't ignore the
> [OldOS,OldFHR] case.
> 
> For the two "OldOS" cases, we already have a well-defined (and implemented
> and deployed) tunneling protocol: UMTP
> <http://www.ietf.org/internet-drafts/draft-finlayson-umtp-04.txt>.  There's
> no reason why smart upstream routers couldn't be made smart enough to
> intercept UMTP "join"/"leave" requests, and act as a tunneling endpoint.
> 
> For the [NewOS,OldFHR] case, we can (& probably should) do something
> smarter - perhaps some sort of IGMPv3-over-IP tunneling, tied in with the
> OS's IGMPv3 implementation somehow...  From what I can tell, this is the
> case that Tony has been looking at.
> 
> Orthogonal to this is the question of how to *find* tunnel endpoints.  The
> simplest solution would be to have this happen automatically, under the
> assumption that tunnel endpoints will be implemented in (or at least, are
> colocated with) multicast routers.  (Again, we might want to focus solely
> on SSM as a simplifying assumption here.)
> 
>          Ross.


The trouble I have with any sort of router based version of this is that
the people
who cannot get multicast largely cannot get it because their routers are
not configured for
it, and these routers are beyond their control. So a router based
version really solves
nothing, it just replaces one problem with another. At the ISP level, I
think that the
solution should be, _enable multicasting_, not, enable a work-around.

I would argue that this problem has been solved already, and more than
once, just
not in the real time case, and at the application level. Think about
Gnutella, or
even Napster. What are these really but source discovery protocols ? And
this problem is
at heart a source discovery problem. Now, these are not appropriate / efficient
solutions for this problem at hand, but they do show that a protocol for 
application layer multicasting as a standalone piece of software could
find wide
utility.

Also, I regard the MDU/MTU market as the prime target of multicasting at
present. Most
of these people are on Ethernets. A very useful protocol, and a good
first step, would
be one to allow a receiver on a MDU/MTU LAN to  mirror a received tunnel
to others
on the same LAN using layer 2 Ethernet multicast. 


                                   Regards
                                   Marshall Eubanks


   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : tme@on-the-i.com     http://www.on-the-i.com