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

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