Hello John,
To answer your question, I don't think your summary is correct. Indeed,
early versions of 802.11 were capable of multicast (at least since the
late 1990's). They are not unicasting unreliably to each station to
achieve multicast. They are blasting out the data to all the stations
at the time when the stations are awaiting multicast -- which means that
they have to wake up so that they can await it.
Basically, all versions of 802.11 have this problem with multicast. The
penalty ranges from one to three orders of magnitude.
I can get similar information for other wireless media if you will tell
me which ones you think are important. Some wireless media don't
support multicast at all and then they really do have to do serial
unicast -- which on the other media is nowhere near as reliable as it
has come to be for 802.11.
Regards,
Charlie P.
On 6/30/2015 6:09 AM, John Dowdell wrote:
Charlie
I've no problem with asking around for information. Always good to do a sanity check. I'd do the same if I was feeling that way.
I'm no expert in 802.11, but on reading the below it sounds to me like the early editions of 802.11 protocols were never really capable of true multicasting, and are effectively unicasting unreliably to each station to achieve a multicast. Further, even if an 802.11ac AP does it better (which I'm not technically competent to pass comment on), any station that only supports the early editions, or has fallen back to using an early edition will compromise the whole system.
Have I understood that correctly?
John
On 30/06/15 05:25, Charlie Perkins wrote:
Hello folks,
When I get lonely in a technical discussion, I confer with friends for a sanity check.
Dave Taht has done more mesh deployments around the world than all of us put together, by orders of magnitude.
Here are some relevant excerpts from recent mail, in which I laid out my case to him by forwarding my argument as I made it on this list.
I have asked the opinions of other experts as well.
On 6/27/2015 11:50 AM, Dave Taht wrote:
On Sat, Jun 27, 2015 at 11:19 AM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Dave,hundreds, in the case of N. thousands, in the case of 802.11ac. It is
Here it is. Please tell me if I am wrong on any of these points!
========= forwarded from internal mail list =============
....
This email is about multicast at layer 2.
One good reference is draft-vyncke-6man-mcast-not-efficient-00
Not all of the points in that draft apply for the abovementioned issue, but:
In order to reach all nodes, and considering that multicast and
broadcast frames are not protected by ARQ (retries), the AP is
constrained to transmit all multicast or broadcast frames at the
lowest rate possible, which in practice is often translated to rates
as low as 1 Mbps or 6 Mbps, even when the unicast rate can reach a
hundred of Mbps and above. It results that sending a single
multicast frame can consume as much bandwidth as dozens of unicast
frames.
The direct consequence is that multicast can produce *dozens*
of times more interference than unicast.
awful.
Note. Thousands.
As an aside, there is very serious discussion about deprecatingIn a lot of ways 802.11b is depricated. Most APs basically are
802.11b for very similar reasons.
configured to accept g or higher.
Continuing....Somewhere in here, someone should note that powersave is conventionally
As the IP multicast frame is actually broadcasted over the wireless
network, this also means that all wireless receivers must process
this frame even if it will be dropped quickly by the host kernel
because the host is not part of the IP multicast group. This goes
beyond a waste of CPU and affect mobile device batteries... because
in order to save the battery, it is common for mobile device to go
into sleep mode when inactive to be awaken by the radio receiver
(which is always on) in order to process wireless frame received
either to the unicast MAC address or to any multicast MAC address or
to the broadcast MAC address. Even if the device can go quickly back
to sleep mode after discarding the IP packet, it drains the battery.
enabled these days. Multicast broadcasts take place on a 250ms interval,
which everybody wakes up for, which (while more efficient) kind of mucks
with many assumptions in ipv6 and so on.
I underestimated the effect of power drain by quite a bit. Each STA has to wake up every 250ms.
Moreover, using multicast with 802.11 may well be counterproductive,Multicast is used as a link failure detection method by many meshy
because unicast is reliable and bidirectional, and multicast is neither.
So, by substituting a multicast instead of a unicast, we may well see
a *decrease* in reception of the RREP at its intended receiver.
protocols precisely because it does NOT do reliable retransmits.
If you want *unreliability*, use multicast.
Unfortunately APs have got SO good, that lowest level multicast
IS heard over a wide area.
In other words, *much* more interference.
And: Definately having some portion of the link layer that is unreliable is
kind of core to many other protocols actually sort of working better. People
have taken reliability to unheard of extremes in wifi, breaking a core
contract between the layers - and injecting delays far, far, far in
excess of what the upper layer protocol is already designed to compensate for.
In other words, layer 2 unicast is far, far more reliable than can be designed in upper layers.
Dave actually complains that it's "too reliable" in other parts of the email which I omitted.
If you want to follow more about what Dave Taht is up to, google "bufferbloat" and "codel".
He is undeniably an expert in this area of routing dynamics.
Does anyone here think the situation is better for *other* layer-2 technologies? If so,
please say so. I have a great deal of information about 802.15, LTE, etc.
Regards,
Charlie P.
