Sunday traffic curiosity

Owen DeLong owen at delong.com
Mon Mar 23 03:40:06 UTC 2020



> On Mar 22, 2020, at 13:41 , Alexandre Petrescu <alexandre.petrescu at 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




More information about the NANOG mailing list