All things related to multicast

["Lucy E. Lynch" <>]

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 -

mim -v 206.196.182.101 233.64.133.200 7010 -a 206.196.18 233.64.133.201 7012
failed but
mim -v 233.64.133.200 7010 -a 233.64.133.201 7012
worked.

Lucy E. Lynch                           Academic User Services
Computing Center                        University of Oregon

                (541) 346-1774/Cell: 912-7998

On Mon, 13 May 2002, John Zwiebel wrote:

> Let me take a moment to bug everyone with some -obvious- points.
>
> 1) MSDP is and always has been a kludge.
> 2) MSDP is -never- going to work well -- especially when you think
>       that its going to carry a SDR/SAP packet, thinking of having
>       MSDP carry -any- multicast packet was a dumb idea and
>       continuing to go down that very broken path just continues
>       to prove how dumb we can all be.
> 3) Windows XP includes IGMPv3.
> 4) FreeBSD has patches available that allows a very stable IGMPv3
>       to be incorporated into 4.0 through 4.4 (I haven't tried 4.5 yet, I
>       just tinker with building kernels and readily confess that I have
>       no idea how I'm ever successful).
> 5) Darwin is based on FreeBSD.
> 6) Darwin can run on 386 machines (I wouldn't be surprised to see
>       Darwin and FreeBSD merge at some point, but neither would I
>       be surprised to see them go their separage ways).
> 7) Darwin is the kernel used in MacOSX.  (having looked at the 'xnu'
>       project which is what Apple calls the Darwin kernel -- hey it took
>       me -days- to figure this out -- and looking at the Darwin header 
> files,
>       not the source code, which may mean I'm wrong; it should take me
>       about a week of concentrated effort to get IGMPv3 into Darwin --
>       meaning that most of you on this list should be able to do it
>       in about an hour.)
> 8) "EVERYONE" knows that IGMPv3 is all that is needed to make SSM
>       deployable.
> 9) "EVERYONE" knows that an SSM deployment can work for the
>       -entire- multicast group range -- not just for 232/8.
> 10) "EVERYONE" knows that once SSM is deployed that MSDP will have
>       absolutely no reason to carry an encapsulated packet and that,
>       in fact, there will be little reason to even deploy MSDP except for
>       folks who insist on running obsolete operating systems that don't
>       support multicast well anyway because it depends on IGMPv2,
>       which in turn requires MSDP to work, which is -never-ever- going
>       to work as well as it needs to.
>
> Why is it that one of you smart guys out there doesn't take wilbert's
> patch and get it into a stable FreeBSD release?  Why is it that
> all SAP sessions don't include the source in the announcement?
> Why is it that we are still trying to push a many-to-many model that
> has proven over 10 years to be extremely difficult to make reliable and
> which has 'proven' to 'content providers' that multicast is never going
> to
> go anywhere?
>
> There is absolutely no excuse for continuing to waste our time going
> down this MSDP path.  It would seem to me that the biggest reason
> SSM isn't deployed is because hosts don't have IGMPv3 so applications
> can't be written to take advantage of it.
>
> But the OS vendors don't include IGMPv3 because the app guys
> haven't figured out that SSM is the future.
>
> Please, someone, anyone who has a little more experience than I do
> with kernel development, get IGMPv3 into a FreeBSD stable release,
> where (if I read the opendarwin.org pages and developer.apple.com pages
> correctly) it will 'automagically' migrate into MacOSX and then we can
> stop this insane (if not totally asinine) discussion on why MSDP doesn't
> work.  If the man-years wasted on MSDP had been devoted to getting
> SSM deployed, we would have all had time for month-long vacations
> in Italy -- or where ever you want to go.
>
> I'm working on getting IGMPv3 into Darwin because:
>    -- I like Macs
>    -- it means I can get SSM apps into MacOSX
>    -- no one else seems to be and even though I have extremely limited
>       experience with kernel development, and manage to accomplish
>       things purely by accident rather than design, I do know that I can
>       be successful.
>    -- it means I might be able to stop this MSDP insanity.
>
> Now, I've stated this opinion on several different forums and have
> generally
> received a positive response for stating it.  However, I've totally
> failed to
> get anyone to move things forward.  Its frustrating to know that once
> I've
> build my IGMPv3 capable MacOSX that its all going to come to nothing
> because I'll be pated on the head and told "isn't that nice, but that
> isn't the
> way the 'real word' works".
>
> Well, -you guys- are the 'real world' and -you guys- have as much, if not
> more, of a reason to get SSM deployed.  Everything is in place, its just
> a question of doing it.
>
> FWIW, I believe that Microsoft has IGMPv3 in XP purely as a defensive
> measure.  They have little reason to write applications that take
> advantage
> of it because of the same reasons that most content providers don't use
> multicast  "They" can't control who sees the content -- nor can they
> charge you for the 'extra reliability' of the unicast stream.  Plus there
> is a lot of "CDN" FUD floating around -- enough so that when I've
> confronted
> those folks in a Public forum about multicast they have tried to dismiss
> me.
> There's -NO-MONEY- in multicast for these guys.  So, they have
> a vested interest in keeping the MSDP debate up and running.  As
> long as this "community" can be diverted with the argument that SSM
> is going to happen "in the future, but not now", they can keep taking in
> the bucks.
>
> (OK, I'll let my anti-Bush feeling show by _directly_ comparing this to
> his FUD on the -need- to drill for oil to 'protect' American interests
> rather
> than spend money to research fuel cells which will happen "some time"
> in the "future".  How stupid are we?)
>
> So the ISPs don't want to deploy multicast because its such a mess, and
> as long as it depends on MSDP, its going to continue to be a mess.
>
> Wake up America.  You guys are smart.  Out of all the  guys on this list,
> there must be at least half of you that could get IGMPv3 into a stable
> FreeBSD kernel in about three hours.  And another half (some of which
> are the same folks -- leaving 1/4 for those like me who can't really "do"
> anything) who could modifiy their multicast application to take advantage
> of an SAP source field so that SSM could work.
>
> Heck, IGMPv3 has been in Cisco IOS for over a year, maybe going on two.
> (I plead Altzhimer's, really, there are a lot of people smarter than I
> am.)
>
> But just in case it isn't obvious, to get SSM working you need:
>    -- IGMPv3 on the host
>    -- applications to know how to send an IGMPv3 report for the source
> and group
>    -- a way of putting the source into the SAP announcement, or providing
> the
>       source/group via some other method.
>    -- IGMPv3 on the -last-hop- router (and -ONLY- the last hop)
>    -- PIM, _ANY_ PIM, deployed on the network.  As far as SSM is
> concerned,
>       PIM is totally agnostic.  The use of the 232/8 group range for SSM is
>       a political choice.  A content provider that wanted to reach say
> 224.1.1.1,
>       need only send out a SAP message that includes the source field.
>       Applications that are aware of what that field means, can use it to
>       make an IGMPv3 call.  Applications that don't know what it means,
>       make an IGMPv2 call.  The "stupid" (ie non-SSM) app can still depend
>       MSDP to get the content.  The "smart" (ie SSM) app avoids having to
>       depend on the MSDP/shared-tree kludge and immediately joins the
>       shortest path.
>
> There -is- a difference in the way PIM behaves with SSM and ASM (ie
> standard
> PIM) but from a user perspective and from an ISP perspective it is
> -totally-
> immaterial.  There are only advantages, no disadvantages.
>
> So, please, let us stop this silly effort to make MSDP work and do
> stuff it should never have been asked to do in the first place.
> Certainly,
> delivering SDR announcements is one of these.  Certainly it is obvious
> to EVERONE that SDR was a good first step -- 10 years ago!!!
>
> If this isn't obvious, then someone, please, please please, enlighten
> me.  IMHO, the thing that is "too hard" is getting folks to let go of
> processes and procedures that obviously don't work because they
> think they have to be backward compatible.  That requirement has us
> no better off with the deployment of a useful multicast than we were
> five years ago.  If you want to waste another five years, feel free to
> continue down this same stupid path.
>
> If you want multicast to be useful, think SSM and do -nothing- that
> doesn't move SSM forward.
>
> Everything is in place -now- for it to work.  Its just a question of
> getting
> everyone to use those tools rather than depending on the broken
> paradigm of the past.  If "we" concentrated on SSM, by the end of the
> year Marshall
> could have lots of viewers for his content because it wouldn't have to
> depend on the unreliable MSDP.
>
> Whether or not he'll make any money that way, I don't know.  But then, no
> one is making money with multicast now so what difference does it make?
>
> z
>
> On Monday, May 13, 2002, at 09:17 AM, Marshall Eubanks wrote:
>
> > On Mon, 13 May 2002 07:55:21 -0700 (PDT)
> >  "Lucy E. Lynch" 
> > <>
> >  wrote:
> >> Bill -
> >>
> >
> > Hello;
> >
> >    MSDP had a limit of ~ 1500 bytes (1492, I think), that was extended
> > to
> >
> > "The maximum size SA message that can be sent is 9192 octets. The 9192
> >    octet size does not include the TCP, IP, layer-2 headers."
> >
> > in version 12 of the MSDP draft.
> > The idea was to fit in ethernets, and then into
> > SONET. There is no provision for fragmentation. Since SAP is largely
> > carried
> > encapsulated in MSDP, this sets an effective limit on the size of SAP
> > packets.
> >
> >> Additional testing on our end (thanks to Jon Miyake) shows that
> >> any large announcement will break both SDR & XMIM (info field,
> >
> > Was this > 1492 bytes ? > 9192 bytes ? At least 1492 should be
> > supported.
> >
> > Marshall
> >
> >> subject field etc.) and it appears that this is related to
> >> the strong suggestion in the RFC:
> >>
> >> RFC 2974             Session Announcement Protocol          October
> >> 2000
> >>
> >>    RECOMMENDED that SAP packets are smaller than 1kByte in length,
> >>    although if it is known that announcements will use a network with a
> >>    smaller MTU than this, then that SHOULD be used as the maximum
> >>    recommended packet size
> >>
> >> Not sure if IP/TV & VBrick have the same limitations built in.
> >>
> >> Lucy E. Lynch                              Academic User Services
> >> Computing Center                   University of Oregon
> >> 
> >>            (541) 346-1774/Cell: 912-7998
> >>
> >> On Mon, 13 May 2002, Bill Owens wrote:
> >>
> >>> At 11:07 -0700 5/10/02, Lucy E. Lynch wrote:
> >>>> James -
> >>>>
> >>>> I'm using both SDR v2.8 and xmim
> >>>> (see:http://videolab.uoregon.edu/mim/)
> >>>> to try and gather sap announcements on a linux box (redhat 7.1) -
> >>>> XMIM will collect announcements for a while and then seg faults -
> >>>> while sdr manages to collect announcements and stay up - but if I
> >>>> exit and then re-start it dumps core.
> >>>
> >>> I have seen the same symptoms here, with SDR 2.8. I am also running
> >>> the sdr-monitor TCL script, I'm not sure if that makes any difference.
> >>>
> >>> BTW, the University at Buffalo did not have multicast connectivity
> >>> until very recently, April 25 to be exact. Prior to that date Jim was
> >>> presumably running this session unicast, or with a point-to-point
> >>> tunnel that didn't touch the MBONE.
> >>>
> >>> Bill.
> >>>
> >>
> >
>