Subject: Re: [Int-area] [pim] Fwd: [ieee-ietf-coord] draft on Multicast Considerations over IEEE 802 Wireless Media

From: Linus Lüssing <[email-masked]>
Date: Sun, 9 Apr 2017 12:37:16 +0200

> From: Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
> Date: March 31, 2017 at 8:33:01 AM CDT
> To: [email-masked]<mailto:[email-masked]>, Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
> Subject: [ieee-ietf-coord] draft on Multicast Considerations over IEEE 802 Wireless Media
> 
> Hello all,
> 
> This is the draft that I mentioned during the meeting. Please take a look and provide inputs either here or in the IntArea WG list ([email-masked]<mailto:[email-masked]>):
> 
> https://tools.ietf.org/html/draft-perkins-intarea-multicast-ieee802-02

Hi everyone,

Thanks for raising awareness of the potential pitfalls concerning
multicast on 802.11! Had to find out about them the hard way back
then, so I am really looking forward to this RFC :).

My comment/wish is just about multicast group awareness: In
"3.2.3. - MLD issues" I would have expected some notes regarding
the issue of IGMP/MLD report suppression and how this makes it
difficult to track per STA group membership state.

I would have then expected a section regarding "Multicast Group
Awareness / Multicast Snooping" in "4 - Multicast protocol
optimizations", explaining how it can improve performance, but
what would need to be done to mitigate those report suppression
issues: If applying some multicast group awareness then how
RFC4541 would need to be translated from bridges to APs
(i.e. by interpreting each STA as an individual "switch port"
- and emphasizing again where to and where not to forward IGMP/MLD
reports).

An older version of OpenWRT missed RFC4541 for its group-aware
multicast-to-unicast implementation some years ago entirely,
resulting in ugly packetloss back then...

Regards, Linus

---

From: Linus Lüssing <[email-masked]>
Date: Sun, 9 Apr 2017 13:15:00 +0200

> resulting in ugly packetloss back then...

By the way, the according (fixed/working :) ) patch got accepted
upstream in the Linux kernel just recently. There had been quite some
discussions on the according mailinglists, because the according
patch was basically hijacking the Linux bridge code (the "software
switch" implementation in Linux which conveniently already
provided IGMP/MLD snooping). Also, there was a submission at the
same time for a non-group-aware multicas-to-unicast patch which was
done entirelly in the Linux wireless stack though.

So there were some thoughts and discussions on moving smartness more
into the Linux wireless stack.

Regarding the IETF-IEEE coordination I would be curious to
know how much smartness to implement into a generic wireless stack
makes sense.

For instance, does it make sense to implement some group-aware, QoS-aware,
clever algorithm in a wireless stack to convert a multicast packet to a
mix of multicast and unicast frames to be transmitted at various, selected
802.11 bitrates? Or will wifi chips be able to provide a superior,
more convenient solution in the future?

Regards, Linus