All things related to multicast

[John Zwiebel <>]

 On Monday, May 13, 2002, at 11:59 AM, Lucy E. Lynch wrote:

> Z -
>
> good points, but ASM isn't going away - just ask any of the access
> grid folk - http://www-fp.mcs.anl.gov/fl/accessgrid/default.htm
>
> and I don't know about SDR/VIV/VAT/RAT, but XMIM/MIM will need a little
> tweaking to handle a source address in announcements as I learned during
> the last I2 broadcasts -
Hi Lucy:

Actually, ASM is going away.  The only reason its still around is because
SSM isn't being deployed, and it isn't being deployed because IGMPv3
isn't in the host stack and IGMPv3 isn't in the host stack because SSM isn't
being deployed.  Kind of Circular isn't it.  

Thanks for pointing out the Access Grid info.  There is an interesting
FAQ there from Bill Nickless:
http://venues.accessgrid.org/fom-serve/cache/7.html

He quotes a Cisco web page:
http://www.cisco.com/warp/public/cc/pd/iosw/iore/iomjre121/prodlit/1065_pp.htm 
that says:

Currently, a receiver joins a multicast group but has no ability to specify a source. Multiple sources can exist and all data from them will be received. SSM enables the selection of a particular source for multicast data. This prevents traffic from other sources for the same group from being forwarded to the host. SSM requires well-known sources and is most useful for static applications. 

So, I can't get on Bill's case for this, but -certainly- Cisco should know better --
especially the last sentence which is completely and totally false.  SSM
does not require a well-known source any more than my being able to find
any host in the internet to telnet to.  The method that is used to discover the
source of the multicast data stream you want to listen to is totally, and completely
independent of the ability to listen to that source.

This FAQ presents Bill's impressions as if they are indeed facts.  There
is still a requirement for ASM given my -very-limited- understanding of
how multicast is used in the access-grid where the primary objection is
that:

VV support to keep track of all senders in real time. Client software (vic/rat/&c) extensions to allow VV to feed in the addresses of active sources.


To be sure, I don't know how many senders there are in such a session, but
IMHO, any multicast session with over 100 senders shouldn't be using ASM
either, but rather Bi-dir PIM.  Bi-dir PIM has been installed in Cisco's for a while
now.  The problem is that Bi-dir is -not-  applicable to use over the internet, but
can only be deployed within an enterprise.  Not a lot of attention has been
spend in determining how to deploy Bi-dir across PIM domain boundaries,
because: a) its difficult to imagine thousands or hundreds of sources  all wanting to
use the same tree across the internet;  b) Most internet multicast applications that
I'm aware of use lots of bandwidth and concentrating the BW if hundreds
or thousands of sources on the same shared-tree is going to lead to 
congestion.  So, because of a limited imagination, the need for interdomain
Bi-dir just doesn't seem to exist.

WRT keeping track of sources... ASM doesn't save you a thing when you
are talking interdomain.   It is true that receivers just join to the multicast group
saving some memory in data structures and perhaps some complications in VV.
(I'm totally guessing).  But the last-hop router will by default join to the shortest-path
creating (S,G) trees on every sender.  ie, as far as the network is concerned, 
the steady-state amount of state and the actual distribution of multicast 
packets is exactly the same.  

The difference between ASM and SSM for the network in an access-grid sense
is that ASM requires MSDP (which we have already discussed and which -will-
'go away' someday -- except for some limited deployments which I don't
want to expand on right now) 

-AND- ASM requires setting up of a shared-tree, which the network now
has to see as different from the shortest-path-tree and make -real-time-
decisions on which to pick causing duplication of packets received
and/or loss of packets as the switch from RPT to SPT is made resulting
in a waste of BW and unreliable delivery of data to the receivers.

-AND- ASM requires configuration of an RP (or RPs) within every domain
that wants to participate with the access-grid as well as the networks
that the access-grid data wants to traverse.

-AND- to set up the RPs ASM requires auto-rp and/or bootstrap routers
and/or static configuration of the RP on -every- router in the PIM 
domain.

None of this is required for SSM.  The network builds -only- shortest-path
trees.  There is absolutely nothing that prevents PIM (S,G) joins from 
traversing any portion of the internet (well, of course, PIM has to be 
configured) as there is with an ASM session. 

All the stuff that should never been a part of the PIM protocol to begin
with has been removed and it is up to the application developer and/or
the user to provide that information via whatever means is best suited
to him or the application.  -AND- you can use multiple methods at the
same time without interfering with anyone else's ability to discover the
information.

So, it would appear to me that the comparatively minor changes that
would have to be made to any application to make it SSM aware is by
far, outweighed by the increase in data delivery and reliability of the
applications usage.

Bill did say in his FAQ that the limiting factor was whether or not IGMPv3
was in windows.  I have used it in XP.  It works.  I have only used it
with a test application which was provided to me as a binary, so I
don't know how a 'real' application might be able to take advantage of
it.  But it 'shouldn't'  be hard.  Unless there is some hidden agenda
on Microsoft's part (or perhaps I'm being too paranoid after all, IGMPv3
isn't on MacOSX)

FWIW, the code for getting IGMPv3 onto FreeBSD (and in turn, Darwin
and MacOSX) is available.  As I already said in this thread, 'someone' out
there should be able to make it happen by the end of the week.

SSM is like Fuelcell Cars.  Neither will happen unless we 'just do it'.
The sooner we move to SSM the sooner multicast will be 'real'.
If Access Grid -really- wants to have something that is reliable, they
-must- move to SSM, and the sooner they do it the better.  

No excuses for how "its too hard".  It just isn't.  Any attempt to be
backward compatible with ASM may only prevent you from reaching the goal
access-grid has.  OTOH, if what they have now is "good enough", then
moving to SSM can only make it better.

I apologize for sounding preachy.

z