Subject: [MBONED] Comments on draft-ietf-mboned-ieee802-mcast-problems

From: "Holland, Jake" <[email-masked]>
Date: Mon, 25 Mar 2019 03:53:28 +0000

Hi mboned,

After the hackathon yesterday (in which I worked on AMT service
discovery via DNS-SD for a home network) David Lamparter came
to introduce himself and credibly inform me that the multicast
WiFi problems we see are largely an implementation problem with
the Linux bridge code, rather than an inherent problem with WiFi.

He further let me know that several proprietary implementations
do indeed have an approach that does NOT suffer the same
performance problems with multicast over WiFi.

Also that there was a Linux patch a few years ago attempting to
fix it, which was declined because it made the normal bridge path
slightly slower, but if I understood correctly, he believes it's
fixable, and that it would be a more useful approach than tunneling
unicast.

This seems worth following up on, and it might  dramatically
change the contents of draft-ietf-mboned-ieee802-mcast-problems,
after appropriate consideration.

I wanted to let you all know about this development, and to
introduce David and say thanks for raising this.  I look forward
to some further discussion on this point.

Cheers,
Jake

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Mar 2019 07:58:01 +0100 (CET)

> the Linux bridge code, rather than an inherent problem with WiFi.

I'd like to know more about this. Since even the IEEE has admitted to this 
multicast problem I doubt it's implementation specific like that.

> performance problems with multicast over WiFi.

IEEE has shared that there are mechanisms for multicast retransmission but 
this is not widely implemented in currently shipping gear.

> I wanted to let you all know about this development, and to introduce 
> David and say thanks for raising this.  I look forward to some further 
> discussion on this point.

Thanks, Davdid, please share more details.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 25 Mar 2019 22:02:08 +0000

-----Original Message-----
From: MBONED <[email-masked]> On Behalf Of Mikael Abrahamsson

Me too. Are we talking about successfully implementing WiFi multicasting *without* having to resort to layer 2 retries? Are many of the missed multicast packets in WiFi caused by something other than dropped packets at the radio layer? That would be very interesting indeed.

Otherwise, implementing multicast retries at layer 2 has its own drawbacks. Seems less than a great idea, especially at the high packet rates used in streaming. IMO.

Bert

---

From: David Lamparter <[email-masked]>
Date: Tue, 26 Mar 2019 17:24:36 +0100

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

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 27 Mar 2019 09:44:36 -0700

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:
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Mar 2019 09:18:14 +0100 (CET)

> Last Call with the document soon.

Not directly related to this draft, but after we've now identified state 
of affairs, what's next? When I brought this up originally I asked for 
some kind of "IEEE/Wifi and IETF decide on the work split to fix what part 
of the problem space". Frankly, I can't see that anything happened to 
this?

Does this mean we've decided it's not really a problem we need to solve, 
or what's the outcome? I'm thinking long term strategically... What's the 
future for L2 broadcast/multicast use in IETF?