I've got a program that sends out a IPv6 multicast packet (to ff12::2:0:8afb:382b:c053:85f%en1) every 50ms. I've got it running on a very simple single-computer LAN (Mac mini <-wifi-> Linksys wifi router <-cat5-> DSL modem <-> Internet). In my test there are no computers joined to this multicast group (i.e. nobody is listening to these packets)

My problem is that when this program is running, the Mac's WiFi performance drops by over 50%. Presumably the problem is that all of these multicast packets are eating up a lot of my WiFi bandwidth and causing congestion... but I don't understand why the packets are being transmitted at all. It was my understanding that multicast uses a spanning tree algorithm to ensure that multicast packets are only routed to hosts that are actually interested in receiving them. If that's true, and given that there are no other computers on my LAN joined to this multicast address, shouldn't my Mac realize that and not actually send out any packets unless/until some other host joins the multicast group? Or is the spanning tree culling only implemented at the switch, and not by hosts themselves?


Multicast is a tricky thing. Routers are the ones to arbitrate multicast packets, and smart switches can sometimes ensure that the packets won't get to where they're not supposed to go. However, if there is no router between the multicaster and your client stations (and there isn't if I'm reading that right) then Multicast will behave exactly like Broadcasts on that subnet.


To add to @sysadmin1138's answer (this comment was too long for the comments box)...

It would be good to note that 802.11 adds to the pain here in two ways: intra-BSS relay, and low multicast rates.

On 802.11, wireless-to-wireless frames on the same AP must be retransmitted wirelessly by the AP in case the original sender is not in radio range of the intended recipient. This process is called "intra-BSS relay" and solves what is known as the "hidden node problem" -- where two wireless nodes may both be in range of the AP, but not in range of (hidden from) each other. So every frame that comes from one wireless client of the AP and may need to go to another wireless client of the AP (note: this includes all multicasts and broadcasts) gets transmitted across the same channel twice. First to the AP (this is known as To the Distribution System, or "ToDS") and then again from the AP ("FromDS"), as part of intra-BSS relay.

The "ToDS" leg of the journey is at the highest data rate at which the client can successfully communicate with the AP. So if this is a modern 3x3 N client and AP using 40MHz channels with short guard intervals, this may be 450mbps.

Unfortunately, for the "FromDS" leg of the journey, the frame must be sent at a data rate low enough for all clients of that AP to receive them reliably. That's because multicasts aren't Acked at the 802.11 layer, because it would cause an Ack storm in response to every multicast.

Some APs let you set the multicast rate explicitly. Others let you define your "basic" or "required" rate set, and then the AP chooses the multicast rate out of the basic rates. Still others just let you set your b/g/n (or a/n) compatibility mode, and have a predefined basic rate set and multicast rate based on that. Many APs default to full compatibility mode all the way back to 802.11-1997 DSSS data rates of 1 and 2 mbps (before 802.11b added 5.5 and 11mbps). This means that your multicast rate could be as low as 1mbps.

So in a worst-case scenario, your multicasts could be gobbling up 451 times the channel-airtime as a same-sized wireless-to-wired (or wired-to-wireless) unicast frame would take up.

Note also that in some designs, intra-BSS relay is performed by microcode in the 802.11 NIC of the AP, so on those architectures, these frames don't pass through the AP's host processor before they get relayed. So even if the AP was a "smart" switch that could violate the layering model and do layer-3 IGMP snooping to prune the multicast tree, it wouldn't get a chance to do that before the radio card had already done intra-BSS relay on the frame.

  • +1. Very informative. Thanks for the education. :) – joeqwerty Aug 10 '10 at 3:00
  • +1 Superb answer. – kmarsh Aug 13 '10 at 12:51

Multicast defaults to broadcast behavior when not fully supported by the local router (not switch). As such it tends to propagate out to all known nodes within a LAN segment.

SoHo routers are not well known for supporting MultiCast fully or correctly. Many depend on upstream routers and expect only clients at the LAN level. You can try adjusting your router settings, but if your multicast group has no subscribers, why not turn it off at the source?

  • It's a unidirectional data protocol, so the multicast source doesn't know if there are subscribers or not. (I was counting on the multicast routing layer to handle that issue... I guess I expected too much :P ) – Jeremy Friesner Aug 9 '10 at 18:24
  • ... which is why I suggested turning it off at the source. – kmarsh Aug 10 '10 at 12:43
  • It's a good suggestion, and it would work in my case, but in the field there won't necessarily be someone with the knowledge of why/when/how to turn off the source. – Jeremy Friesner Aug 11 '10 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.