All things related to multicast

[David Meyer <>]

If ASM is going away, should we give up on MSDP (from the
standards perspective)? I'm struggling with this problem right
now. If we give up, what should we do with (i). what's deployed,
and (ii). the current spec?

As always, opinions and advice greatly appreciated.

Dave

On Mon, May 13, 2002 at 01:22:59PM -0700, John Zwiebel wrote:
>>  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
>>