Re: Comments on draft-ietf-mboned-ieee802-mcast-problems

Hello David and all,

Do you think these problems with 802.11 multicast are sufficiently 
documented in the abovementioned draft?  If not, then maybe we should 
expand on our description.  Perhaps the solution done "properly" in 
commercial systems should be mentioned in the draft?

Any other suggestions you have will be appreciated!  We'd like to go to 
Last Call with the document soon.

Regards,
Charlie P.

On 3/26/2019 9:24 AM, David Lamparter wrote:
> Sigh.  802.11 multicast.
>
> It started out crap, and then more crap was piled on to try and fix the
> problem, and now we have a giant pile of crap.
>
> Sub-problem #1 is the rate selection for multicast packets.  For this,
> Linux software APs, like you find in most homenet/CPE devices, are doing
> a straight-up garbage job.  The spec /suggests/ that you send it at the
> lowest rate supported.  Commercial wifi solutions do it "properly" and
> track the group members, figure the appropriate rate & delivery
> probability for each of them, calculate airtime needed, and then choose
> between unicast conversion or multicast delivery (at a higher rate.)
>
> I've tried tackling this problem a while back here:
> https://github.com/eqvinox/vpls-linux-kernel/commits/mdb-hack
> but as noted in Jake's mail this was modifying the Linux bridge code and
> rejected on the basis that people really want that to be as fast as
> possible.  I've talked to some Linux kernel hackers at netdevconf (which
> immediately preceeded IETF here in Prague) and the current idea is to
> modularize the Linux bridge's MDB code so it can be used in the VXLAN,
> VPLS, as well as 802.11 stacks.  (Each of these has the same problem,
> they want to know additional details about multicast subscriptions.)
>
> (Let's not get started about 802.11 DMS/FMS.  If it those were a part of
> implemented reality, they could help solving the problem, but they
> aren't.)
>
> Either way, none of this is gonna help the installed base, so there's a
> problem, and it's not going away before updated software hits Linux
> software APs, so...
>
> :'(
>
>
> Sub-problem #2 is reliability of multicast on 802.11.  Short of
> implementing 802.11aa Group ACKs, which was designed for dead-on-arrival
> AVB, this is probably not gonna happen.  But for media delivery, the
> "solution" is really just FEC.
>
>
> -David
>
> _______________________________________________
> MBONED mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mboned
>

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned