All things related to multicast

[John Lyons <>]

On Mon, May 22, 2006 at 11:12:16AM -0700, Joel Jaeggli wrote:
> >  This strikes me as a very dangerous statement, I can think of very few 
> >  situations where flooding multicast is acceptable but many many more 
> >  where it is completely unacceptable. 
> 
> Since I bear some responsibility for starting this, let me just weigh in
> again.
> 
> You don't need this as much as you think you do.

 That's an unfair assumption to make, in any case where I've deployed
 multicast I've needed it - Triple play ISP delivering 65 IPTV channels,
 Commercial ISP delivering BBC multicast to DSL subscribers, organic 
 research and education networks using video conferencing. 

> If you do need it that badly it's because a trunked bunch of vlans on
> core switches to avoid buying more l3 ports is a poor way to build a
> network. If you melt your switch core before the edges that would indeed
> be a bad thing.

One size does not fit all. There are many reasons why one may require
snooping. 

ISP's who are doing triple play over DSL definitely require some form of 
snooping in DSLAMs otherwise their subscribers are going to receive all 
their neighbors channels over their limited DSL connection. (I appreciate 
this isn't snooping in the traditional ethernet switch sense of the word). 
Organically grown networks with many with 1000's of switches who don't 
turn on snooping can end up with very non-deterministic network behaviour, 
which at best is a nuisance and at worse can melt your networks and limit 
access to services.

> Modern (eg in the last 10 years) ethernet chipsets have a decent enough
> multicast filter down in the cam to drop quite a few Mb of multicast
> without noticing. So that leaves 1/2 duplex network segments (who cares)
> really big broadcast domains (better subnetting), wireless edge networks
> (which switch packets in software and can be configured to drop them
> just as easily as forward them them), and legacy devices. 

 I think you've trivialised the matter here. How about a situation where
 I've 50+ channels all being watched at any one time on a L2 network,
 are you happy for each interface to flood 200-300Mb/s of traffic out
 every port. Or even just a couple of HD 25Mb/s streams ? I've seen many
 networks without snooping melt on far less multicast traffic.
 
 Sure they could make the L2 networks smaller but rebuilding/redesigning
 is a non-trivial exercise for a lot of people.
 
> >  This is not a "potential problem", Lack of snooping is a complete show
> >  stopper when it comes to rolling out multicast in the vast majority of
> >  networks (particularly outside of NRENs and connected institutions).
> 
> Again, some people have used this various versions of this excuse to
> retard their campus deployments for almost a decade. The hardware will
> never be ready with the foo magic feature that is required this time to
> make it all work. Moreover no-one replaces all their hardware at once
> which means by the time you get to the point were you got all the
> features you need everywhere you need them, your needs, or protocol
> development, or vendor featureitis will have moved on to something else,
> which will the pose a different impediment to deployment.

 This is a fair point, but like it or not, it has been a huge reason for 
 many networks not to deploy multicast. 
 
> We deployed multicast across campus more than a decade ago and by in
> large our customers neither noticed or cared, yeah some of their apps
> magically worked (IPTV, Ghost etc), but the network didn't catch fire
> and burn down, and I don't expect that an eventual deployment of v6
> multicast support will cause it to either even if all the l2 pieces
> aren't in place...
> 
> >  John
> 
> I concluded a long time ago that Steve Deering's original premise, which
> was to regain the functionality (flooding) lost when Ethernets became
> routed, was probably a flawed one (That I spent 11 years of my life
> working on it is another); But it's the people and the economics that
> have been persistent barriers to deployment not the technology, however
> flawed it may be.

 I agree, in part, any protocol requires a "killer app" in order to get 
 widespread deployment and until relatively recently that killer app hasn't
 really existed for multicast. IPTV has become that killer app in the last 
 few years particularly in the triple play market.
 
 But, it's both a combination of a lack of a killer app (IPTV has been useful 
 for a number of years but until recently most subscribers haven't had the 
 last mile bandwidth to be able to use it) and limits of the technology
 / vendors implementations which have erected barriers to multicast 
deployment. 
 
 Like it or not, lack of stable code, security concerns, lack of a scaleable 
 address allocation system, requirement for lot's of state, difficult 
debugging, 
 and lack of a scaleable inter-domain infrastructure have all played a 
 significant part in the stunt in growth of multicast deployment. 

 John