Re: Sunday traffic curiosity

[Owen DeLong <owen () delong com>]

> On Mar 22, 2020, at 13:41 , Alexandre Petrescu <alexandre.petrescu () gmail com> wrote:
>
>
> Le 22/03/2020 à 21:31, Nick Hilliard a écrit :
> > Grant Taylor via NANOG wrote on 22/03/2020 19:17:
> > > What was wrong with Internet scale multicast?  Why did it get abandoned?
> >
> > there wasn't any problem with inter-domain multicast that couldn't be resolved by handing over to level 3 
> > engineering and the vendor's support escalation team.
> >
> > But then again, there weren't many problems with inter-domain multicast that could be resolved without handing over 
> > to level 3 engineering and the vendor's support escalation team.
> >
> > Nick
>
> For my part I speculate multicast did not take off at any level (inter domain, intra domain) because pipes grew 
> larger (more bandwidth) faster than uses ever needed.  Even now, I dont hear problems of bandwidth from some end 
> users, like friends using netflix.  I do hear in media that there _might_ be an issue of capacity, but I did not hear 
> that from end users.
>
> On another hand, link-local multicast does seem to work ok, at least with IPv6.  The problem it solves there is not 
> related to the width of the pipe, but more to resistance against 'storms' that were witnessed during ARP storms.  I 
> could guess that Ethernet pipes are now so large they could accomodate many forms of ARP storms, but for one reason 
> or another IPv6 ND has multicast and no broadcast.  It might even be a problem in the name, in that it is named 'IPv6 
> multicast ND' but underlying is often implemented with pure broadcast and local filters.

In most cases, though “local” filters, they are filters at the hardware interface level and don’t bother the OS, so… 
WIN!

Also, in most cases, the solicited node address will likely be representative of an extremely small number of nodes on 
the network (very likely 1) so the number of CPUs that have to look at each NS packet is greatly reduced… WIN!

Reducing the network traffic to just the ports that need to receive it is a pretty small win, but reducing the CPUs 
that have to look at it and determine “Nope, not for me.” is a relatively larger win. If the host properly implements 
IGMP
joins and the switch does correct IGMP snooping, we get both. If not, we still get the CPU win.

> If the capacity is reached and if end users need more, then there are two alternative solutions: grow capacity 
> unicast (e.g. 1Tb/s Ethernet) or multicast; it's useless to do both.  If we cant do 1 Tb/s Ethernet ('apocalypse'  
> was called by some?) then we'll do multicast.

My inter domain multicast comment was largely tongue in cheek and was never intended as a serious proposal.

There are a plethora of issues with inter domain multicast including, but not limited to the fact that it’s a great way 
to invite smurf-style attacks (after all, smurfing is what mcast groups are intended to do).

Owen