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

Hello again David,

Attached, please find the presentation materials that I used last week 
for the [mboned] session.  During the session, we discussed your email 
and especially the possibility of citing the Aruba product, but the 
people in the room seemed not to be in favor of that.

I have a question about the commercial WiFi solution.  Namely - if there 
are slow multicast members in the care of a particular AP, they 
determine the interference characteristics at that AP. It might help to 
use a faster rate for the faster devices, but even so that adds even 
more to the interference since there would be multiple transmissions at 
different rates.

I guess the product somehow takes this into account.  Do you know more 
details?

Also, if you have some text that you'd like to see in the draft please 
send it to me.  The draft should not contain any product announcements 
or advertisements, but some general comments about the way of resolving 
the problems might be appropriate.

Thanks in advance!

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