What practical concerns led to the use of multicast?

Question

Answers to a question on SF explain the differences between broadcast and multicast. It is not clear yet for me which practical concerns brought in the usage of multicast.

My understanding is that, for both broadcast and multicast, the packet is presented to each host on the wire and

• for broadcast the client processes the packet to check if it there is something relevant for that client inside
• for multicast, the client can choose to process the packet (by having a service subscribe to 224-239 addresses) to check if it there is something relevant for that client inside

Is this correct?

If yes, why not having only broadcast addresses and let the client decide on the usefulness of the received packet?

• is the concern on the processing power? Probably not as all broadcast packets need to be processed anyway (or atl least thereis no way to distinguish in advance on how pertinent a packet is)
• is the concern on routing? This is more understandable: a router can route multicast packets only, assuming that these ones are of interest for devices further on, as opposed to broadcast which is supposed to be local.
• or something else?

Note: moved from SF following suggestions to do so.

Answer 1

is the concern on the processing power?

Yes. A multicast flood of a given size/volume in a given broadcast domain has less (global) impact on the set of hosts being exposed to it than a broadcast storm of the same size.

Probably not as all broadcast packets need to be processed anyway

Yes. A broadcast packet must be processed, up to at least layer 4, to find port numbers or other payload properties that allow to tell if the packet is relevant to the host and its services/processes.

(or at least there is no way to distinguish in advance on how pertinent a packet is)

There isn't for broadcast, but for multicast, there is: Destination addresses.

Upon an incoming multicast packet, a host's network stack can decide early on, based on destination MAC (starting with 01-..) or IP Multicast (224.0.0.0/4) address, if the given packet needs further processing or if it may be discarded. A broadcast packet however must be "passed further up the stack" to look at layer 4 properties until it becomes clear if there is any process on the host interested in it.

Also see OSPF and its use of Multicast

is the concern on routing?

Let's call that "efficient forwarding" instead of routing.

Practically, the difference between broadcast (Dst: 255.255.255.255) and link-local multicast (Dst:224.0.0.0/24, which MUST NOT be routed) isn't all that big, especially all switches will flood multicast traffic for 224.0.0.0/24 as if it were broadcast. Speakers and listeners of 224.0.0.0/24 do not use IGMP, and any switch's attempt to IGMP-snoop 224.0.0.0/24 is therefore futile. However, 224.0.0.0/24 is only for special purposes anyway, and should never be used for applications as such.

it's a different story with "regular" multicast, where hosts tell routers which groups they wish to receive (using IGMP) and where switches can eavesdrop ("snoop") on the IGMP messages and adapt their own internal Layer2 forwarding tables accordingly, so not every 100Mbit/s connected printer (with their weakling CPU) is hit by the 20Mbit/s High Definition video stream of the CEO's speech or the 25Mbit/s stock exchange market data feed.

In short: In a LAN/VLAN/Broadcast domain, bar the use case of low-volume/low-packet rate discovery mechanisms (like done with the 224.0.0.0/24 addresses), you do not want to (locally) forward any of those things as broadcast which are known to work well on multicast or unicast (i.e. audio and video dissemination, or flows of market data). Unsuspecting hosts which have no need for any of these data flows should not be forced to process data they never asked for.