All things related to multicast

[David Farmer <>]

A few more thoughts,

<> Wireless, wifi or cellular is becoming a dominant access media for 
most everyday users and uses, Multicast is not generally wireless 
friendly and is especially not wifi friendly in most cases.  This is 
probably just a special case of Guys IEEE 802 comment below.  But, the 
RF domain that all wireless depend on is especially variable and 
variable on a per user basis.  While counter intuitive unicast is 
frequently overall more efficient than multicast in many such 
environments. Unicast can more easily adapt to the per user variability 
that wireless presents and has failure modes that are more user friendly 
or at least better understood by the users.

<>  Multicast is especially challenging in large-scale campus or 
enterprise wifi deployment, even something seemingly as simple as link 
local only mDNS service discovery can be especially challenging in large 
scale wifi environments, see the Educasue petition 
http://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group 
and the possible new IETF working group MDNSEXT 
https://www.ietf.org/mailman/listinfo/mdnsext and 
http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-00 for details.

Moving from Wireless;

<> Large amounts of Multicast create large amounts of state in the 
routers, classic ASM creates a more state than new alternatives like 
embedded RP or SSM, but even these alternatives can't really scale to 
unrestricted Internet wide inter-domain multicast.  Especially without 
crushing Internet backbone routers with multicast state.

I'm probably not ready to completely give up on multicast, there are 
still some interesting problems it can be used to solve, but honestly we 
will probably be moving away from enabling it by default at our network 
edges, making it a special case service or limited scope service.

On 12/17/12 18:25 , Guy Almes wrote:
> Joe et al.,
>    A very interesting thread.
>    A few thoughts:
> <> it's hard to imagine an application that you cannot do with unicast
> but that you can do with multicast, modulo (of course) the efficiency of
> the one-to-many that a well-engineered multicast setup might have.
> <> for the applications (e.g., VIC/VAT) that multicast was classically
> associated with, those audio/video streams are simply not
> very-high-bandwidth by today's standards.  You can do skype among
> several participants and it does not strain the plumbing.
> <> classic ASM multicast is *complicated*.  I recall attending an
> Internet2 multicast workshop that Joe hosted at Univ Oregon.  I knew
> most all of the elements of it already and knew that it was not
> super-hard to support at the *backbone* level, but sitting in on the
> training, and especially the slides and slides on troubleshooting, I
> began to think "oops, this is imposing a really huge aggregate burden on
> our campus IP engineers".
> <> much (but by no means all) of that complexity was due to the ASM
> model, which raises the issue of "source discovery".  Source discovery
> gotchas accounted (if memory serves) for about half of the slides in the
> troubleshooting section of the workshop
> <> to a degree, the more recent SSM single-source model, which
> immediately gets rid of source discovery, but at the price of separate
> 64-bit channels for each source looks much simpler
> <> another sign of trouble is the complicated interplays of Ethernet
> switch support that do the needed snooping.  This brought into play
> complicated interplays between IETF multicast protocols and IEEE 802
> stuff, resulting in years for switch vendors to adapt to changes in IP
> multicast.
>
> <> in a sense, application-level multicast in the form of
> infrastructures such as akamai and many related examples can provide the
> efficiencies that IP multicast could also have provided, but without
> requiring the support of IP multicast throughout the network (especially
> at the already overburdened campus layer)
>
>        -- Guy
>
>
> On 12/17/12 12:37 PM, Joe St Sauver wrote:
> > Bill commented:
> >
> > #Sadly, running a  test is the only way to know, since nobody has
> > #ever made use of IPv6 multicast for anything other than a demo.
> >
> > Ditto: I don't think I've ever seen "real" IPv6 multicast content.
> >
> > #It seems clear that the larger networking world has bypassed native
> > multicast
> > #in favor of various kinds of streaming and application-layer
> > multicast (or
> > #multicast-like) transmission. There appear to be many reasons why this
> > #happened, not least the inability of the standards community to find
> > a stable
> > #and scalable answer for wide-area any-source multicast.
> >
> > 1) I'd argue it's (almost) all about content.
> >
> > By way of example, some time ago I looked for songs I liked on Youtube,
> > obviously a non-IP multicast content source. Now admittedly I have
> > what my
> > kids refer to as "dinosaur rock" tastes (the radio stations are more
> > sensitive to aging egos, and normally refer to my market niche as
> > "classic
> > rock" listeners), but it was ALL there. Any band or song I looked for, I
> > could find.
> >
> > Or consider Netflix or Hulu: not total coverage, but a LOT more
> > content than
> > IP multicast could ever offer.
> >
> > Hypothetically: eyeballs and eardrums follow content availability,
> > particularly since content quality now includes at least some HD-quality
> > content (at least in the case of the examples mentioned above).
> >
> > 2) Secondly, assume you're a user with a PC running some flavor of
> > Windows
> > or a Mac user, or someone on a iPad or Android device. What are the
> > recommended (free, robust, featureful) clients for those platforms
> > these days, eh?
> >
> > > From a user's POV, Youtube just works, ditto Netflix and Hulu, and
> > > there's
> > none of the "join-in-progress" issues that always detered IP multicast.
> >
> > 3) What does IP multicast availability look like in home broadband
> > networks
> > these days? Can I get IP multicast support from Comcast, Centurylink,
> > Time Warner, and all the other "usual suspects" servicing home markets?
> >
> > Last time I checked... no. Those guys typically have alternative plans
> > for customers who want to watch videeo, and the discussion normally
> > begins
> > with "And would you like HBO and Cinemax with your cable TV package?"
> >
> > #I won't even go so far as to suggest that we 'early adopters' turn off
> > #interdomain IPv6 multicast, although nobody would notice. But if
> > anyone is
> > #actively using interdomain IPv4 multicast, they really should get to
> > work
> > #moving their application over to IP v6 before the tiny number of
> > networks who
> > #support it decide that it's just another source of complication, bugs
> > and
> > #potential security holes, and dump it.
> >
> > I think if you want IP multicast to survive, you need a strategy for
> > addressing the paucity of content, client issues, and home broadband
> > availability. Currently I don't think any of those three areas are
> > looking particularly strong, unfortunately.
> >
> > Regards,
> >
> > Joe
> >
> > Disclaimer: all opinions strictly my own


--
================================================
David Farmer               Email: 

Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================