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