Subject: Re: [MBONED] I-D Action: draft-ietf-mboned-ieee802-mcast-problems-05.txt

From: "Holland, Jake" <[email-masked]>
Date: Sat, 11 May 2019 00:52:27 +0000

AFAIK it depends a lot on which particular router.

Some of them are based on OpenWRT or LEDE (not always obviously), and
from the patchworks message on the initial upstream submission, it looks
like those have had default enabled support for mc2uc on AP interfaces
since the builds from at least about early 2016 or so:
https://patchwork.kernel.org/patch/9494055/

I don't have a platform handy this week to check how well that seems to
hold up on the ones I can check easily, but if I remember I'll try to
take a look and send an update next time I get a chance.

Of course, this is different from "most customer routers", so I'm not
contradicting Mikael here, just mentioning a point that might be relevant
to the question.  And I agree that a very common case is likely to be high
loss with a high use of airtime, at least for the routers where you can get
them to transmit the packets at all (in my anecdotal experience, it seems
common to block the traffic by default except when it's sourced inside the
nat).

-Jake

On 2019-04-29, 13:22, "Jeffrey (Zhaohui) Zhang" <zzhang=[email-masked]> wrote:

    I was hoping to hear that, even w/o the unicast conversion, since the router does not have to use a low speed to reach many receivers (of different signaling levels), it would not be problem.
    
    Guess I was too naïve 😊
    
    Thanks.
    
    Jeffrey

    Juniper Internal
    
    > -----Original Message-----
    > From: Mikael Abrahamsson <[email-masked]>
    > Sent: Monday, April 29, 2019 4:17 PM
    > To: Jeffrey (Zhaohui) Zhang <[email-masked]>
    > Cc: [email-masked]; [email-masked]
    > Subject: Re: [MBONED] I-D Action: draft-ietf-mboned-ieee802-mcast-
    > problems-05.txt
    > 
    > On Mon, 29 Apr 2019, Jeffrey (Zhaohui) Zhang wrote:
    > 
    > > I am also curious, in a home environment, if only one receiver joins a
    > > particular multicast flow (e.g. one viewer for a multicast TV channel),
    > > how much trouble would a typical consumer router run into if we turn on
    > > multicast?
    > 
    > >From my understanding most customer routers do not have the
    > multicast->wifi-unicast conversion mechanism, so it'd start to transmit
    > the multicast stream at low speeds without any retransmit mechanism,
    > giving that receiver lots of packet loss for this multicast plus chewing
    > up most of the airtime.
    > 
    > So that's a bad idea...
    > 
    > --
    > Mikael Abrahamsson    email: [email-masked]
    _______________________________________________
    MBONED mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mboned

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 11 May 2019 08:11:08 +0200 (CEST)

> https://patchwork.kernel.org/patch/9494055/

I have an OpenWrt 18.06.2 device at home I can test with. How can I check 
on a MacOS or Linux machine whether the packet I received was sent as 
unicast or multicast wifi packet?

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 13 May 2019 14:06:58 +0000

As I understand it, if it has been unicast-mapped, the Ethernet MAC address
will be your NIC's MAC address, instead of starting with 01-00-5E and
finishing with the last 23 bits of the group address.  (Or 33-33- and
finishing with the last 32 bits of the group, for IPv6.)

I think these are where the normative behavior for normal multicast is
described, and the m2u behavior just uses the unicast ethernet MAC instead:
https://tools.ietf.org/html/rfc1112#section-6.4
https://tools.ietf.org/html/rfc2464#section-7

Thanks for taking a look!

-Jake

On 2019-05-10, 23:11, "Mikael Abrahamsson" <[email-masked]> wrote:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 13 May 2019 17:03:27 +0200 (CEST)

> Thanks for taking a look!

On my mac, tcpdump:ing while connected to my OpenWRT 18.06.2 running 
WRT1200AC wifi:

16:49:19.412965 c2:56:27:73:35:13 > 33:33:00:00:00:01, ethertype IPv6 
(0x86dd), length 230: (flowlabel 0x67b7e, hlim 255, next-header ICMPv6 
(58) payload length: 176) fe80::c056:27ff:fe73:3513 > ff02::1: [icmp6 sum 
ok] ICMP6, router advertisement, length 176

So that looks like a regular multicast wifi packet to me? Or does this not 
apply to RAs and ff02::1 packets?

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 13 May 2019 17:02:01 +0000

Ah, sorry, I guess I didn't explain that well.

I think ff02::1 is probably not covered.  As I understand it, the
m2u translation relies on IGMP/MLD snooping, so it will only apply
to group addresses where a receiver has actively sent a membership
report recently.

Many of the local control packets with multicast destinations
typically won't have a join issued by all the receivers, since
they're often part of the bootstrap, including e.g. the membership
queries and reports for IGMP and MLD.  (Also, I wouldn't be
surprised if some of them are special cases, because they'll
sometimes have different handling paths.)

A better test might be possible using something like VLC between 2
nodes in the LAN, with at least the receiver connected wirelessly.
I'm pretty sure VLC will issue a join.  Other possibilities also
might work, not sure what's easiest for you?

Best,
Jake

On 2019-05-13, 08:03, "Mikael Abrahamsson" <[email-masked]> wrote: