Re: Use of SAP in a PIM SSM Network

[Hugh LaMaster <lamaster@nren.nasa.gov>]

On Wed, 15 Nov 2000, Leonard Giuliano wrote:


> SSM presents an interesing tradeoff where some functionality is reduced to
> meet a much more common model as well as radically simplifying network
> deployment.  Being only able to join a single source is inherantly
> incompatible with something like SAP, but few commercial content providers
> would disagree that sdr doesn't represent the commercially viable future
> of multicast.  SSM hinges upon the mass appeal of one-to-many apps like
> WMP, Real player and IP/TV, while eliminating the biggest hinderance to
> deployment: a PIM-SM/MSDP RP-based infrastructure is too complex.
                                                       ^^^^^^^^^^^

I agree that SSM is much more appealing to commercial providers
at this time, and covers 80% of the users and applications out there,
so, that's great.  If it motivates content providers, enterprises,
and consumer ISP's, wonderful.  But, it doesn't necessarily cover 
100% of the users and applications.

Also, a couple of message have mentioned the difficulties os PIM-SM,
RP's, etc., but, I honestly think it is *easy* compared to many things 
out there- it just doesn't have many people's bottom lines associated 
with it today.  (Compare PIM to, for example, what ISPs do regarding
traffic engineering (in general), or what enterprises do with frame-relay,
and ISDN, and tons of other messy stuff.  PIM is easy by contrast.)

The biggest problem we have today with MSDP is the same thing that
we have always had with multicast -- people generally don't monitor
things until the minute they need them, so, something may be broken
for a while before someone notices it.  When lots of people are
accessing lots of multicast content, network operators will start
hearing complaints when things break, just like they do now with
web access.


> Maybe SSM is just a stepping stone to the full functionality that
> shared-tree infrastructures provide.  But it will be a whole lot better
> than what we have now, where multicast is virtually nowhere to be found.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Multicast is widely available on WANs.  By far the largest problem
is getting it into the enterprise LAN and out to the consumer.  
If SSM is the catalyst that gets content providers and consumers 
demanding multicast, that's great, but, you're still going to have 
to deal with all the legacy enterprise, dialup, tier-2/3 deployment 
issues that you had before.  [Hmm.  I'm plagiarizing...;-)  ]
The hope is, that, with new content providers embracing SSM,
the demand will be there, and hence, the motivation to work on
the deployment issues.


=======

The other issue is the future:  SSM will work fine for accessing
broadcast-type content-- there aren't going to be *that* many
content providers out there, and, consumers will expect to find
that content at the providers web site.  Additional router state
will be small.

SSM doesn't address the problem of a scalable multicast source 
directory (neither does the SAP-via-MSDP method either, really - 
MSDP won't scale to really large numbers of sources either).

SSM also doesn't address the problem of large numbers of "small"
groups.  I think we still need a pure shared-tree implementation
to handle the (1000's of low-bandwidth sources)X(1000's of groups)
problem.


--
 Hugh LaMaster, M/S 233-21,    Email: lamaster@nas.nasa.gov
 NASA Ames Research Center     Or:    lamaster@nren.nasa.gov
 Moffett Field, CA 94035-1000  Or:    lamaster@kinkajou.arc.nasa.gov
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.