Indeed, an 802.11 AP should be able to do this without breaking 802.11. However, there are probably wider cases where unicast fanout is worth doing.
BTW, it's a common misconception that 802.11 transmit rates have something to do with range; actually, they're only very weakly correlated with range, because other selection effects dominate first. Still, that's not particularly relevant to the present discussion. What is relevant is that multicast selects very low rates and is not aggregatable, which wastes transmitter shots; an AP can easily have 100x more unicast throughput than multicast. On Tue, Apr 2, 2013 at 5:35 PM, Carsten Bormann <[email protected]> wrote: > On Apr 2, 2013, at 03:48, Toerless Eckert <[email protected]> wrote: > > > Why should an AP not be able to convert multicast->unicast. > > Oh sure. I haven't checked 802.11 if its four-address structure actually > might make this work without any change at the adaptation layer or above. > Hacking the destination address visible at the MAC layer API may be a bit > heavy, but might still work (what do we know about the implementation > status of RFC 6508 or its IPv4 equivalent?). Hey, this might even be > supported by snooping a bit in the 6CIO option that indicates RFC 6508 is > implemented... > > So please go ahead and build product :-) > > Mark's problem of course is that he would like to make this work with > commodity consumer APs. > > > All it would ahve > > to do is IGMPv3 snooping to know the clients connected to it. And it > does know the > > per-client bitrate, aka: how far or how close a client is. > > Yes, the AP (or controller) knows all that is needed to do this well. > > > I guess the one things that not possible is to send the smae multicast > group/channel > > in both multicast and unicast from the same AP because that would > potentially create > > persistent duplicates. > > Once you send multicast, you already have wasted the resources. > However, a multi-unicast could serve as a fill-in for the losses (e.g., > for a station more remote from the AP). > Is getting lots of duplicates going to cause a problem? > > Grüße, Carsten > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
