Subject: [MBONED] multicast over wifi

From: Mike McBride <[email-masked]>
Date: Wed, 8 Jul 2015 10:38:16 -0700

Hi good people,

Based upon mboned discussions we had recently, on problems with multicast
over .11, Charlie and I whipped up a problem statement draft to begin
discussion. Bill Atwood, and his students, also agreed to contribute to
this draft going forward. Please review and comment on list and in Prague.

https://www.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-00.txt

thanks,
mike

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Jul 2015 12:03:34 -0700

> https://www.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-00.txt

I) I think this document needs to start with a higher layer, business
and standardization facing problem statement, and only then go into
whats written up so far by you, which is a technical analysis.

Multicast on WiFi use-case problem

802.11 has standardized for multicast over WiFi only what can be seen
as a minimum set of functionality that suffers from many technical
problems as outlined in the technical sections. A range of reasons will
likely have contributed to this including a lack of perceived business needs
by the participants in the standardization body and a lack of technical
solutions understood to simple enough to be justified by the perceived
business needs.

Companies outside 802.11 have since then improved Multicast over WiFi
mostly using one technique: converting L2 multicast packets into L2
unicast WiFi frames and therefore allowing all WiFi unicast optimizations
to be applied to them.

This approach shows already that there was a higher business need for
multicast in WiFi than perceived by 802.11, but it also brings up
an important aspect for followup work to this problem statement document:

Most technical solutions to the multicast problems described in this
document can be solved either by converting multicast to unicast
or by improving on the WiFI behavior for multicast frames. Converting to
 unicast will in most cases lead to easier technical solutions, but it
will not be able to support large-fan out scenarios. To appropriately
vet the business need to support a particular solution approach to
a specific multicast problem it is therefo most important to understand
the use-cases fan-out requirements.

In more precise terms: A WiFi deployment will only require "native"
multicast optimizations (as opposed to sollutions relying on unicast
conversion) if the required worst case sustained capacity 
(#stations * per-station-bandwidth) exceeds the capacity that can
be provisioned AND if the the required additional capacity could be
achieved by multicast, eg: by a low number of simultaneously requested
data streams.

So, i think you could write up the above text up to here in a section
give or take better word-smitthing. Now, what i really worry about is
that i think we have not seen well enough written use case statements
that would justify the improvements to native multicast. Most of the times
you want so much content freedom that you do not get to the fan-out
of interest. The only excemption i can see is live streaming in a
stadium : 50,000 people with phones/tablets on less than hmm ? 20 APs,
getting access to eg: 20 othre games running in parallel. 

Seriously: what else is out there where one could not argue that it's
equally if not better solved by unicast conversion ?

II) 

The explanations in the problems section could be improved and better
split up:

> 802.11 is a wireless broadcast medium which works well for unicast.
> With multicast, however, there are no ACKs for multicast packets

a) WiFi retransmissions missing

802.11 as a wireless medium has a highly variable degree of loss, randomn
as well as bursty (eg: when object move around). For unicast, this problem
is dealt with by WiFI L2 retransmission of packets which are transparent
to the WiFi endpoints above the WiFi driver. For multicast no resilience
scheme has been standardized. Therefore, IP multicast applications will
see uncorrected WiFi packet loss which can be as high as 5% on average
and higher in bursts.

b) Multicasting considered inefficient

The bitrate at which packets can be sent between two WiFi stations
depend on the distance and other wireless path parameters. In WiFi
unicast, various means of optimizing the bitrate separate to each receiver
are used, all the way over to MiMO in which interference patterns between
multiple simultaneous but slightly time-shifted copies of the same
bitstream are sent out across multiple antennas to form a beam that
increases the signal strength in the direction of the receiving station.

In WiFi multicast, the bitrate at which multicast is sent is instead
fixed at a configured rate that needs to be low enough for the furthest
away station. There is no standardized mean to dynamically adjust that
bitrate to the lowest bitrate required by the actual active receiving
stations. 

c) Sleeping

Low power wireless clients try to save energy by going to sleep. In
unicast WiFi this is supported..... [ i really have no idea what the
current way to support this is - is it slotted sending so the client
device can wake up periodically ? I think thats it... But is there not
also the ability of client HW to be woken up by unicast packets directed
at them ? ] In any case, i'd like like for the other two subsections
a better explanation why it works for unicast but not multicast.

> The main problems associated with multicast over WiFi are as follows:

III) 

The details sections are repeating a lot of the intro section, so
somwhere there needs to be reduction of replication

Without offering text directly, let me discuss some of the content:

The interference section reads like from an anti-multicast guy 
who tries to badmouth multicast. I think it would be good to
give a more balanced explanation:

Wrt to spectrum usage and non-beamforming/MiMo scenarios, L2 multicast
is of course almost always an improvement: As soon as have two or more
receivers you willhave saved spectrum/interference vs. two
unicast transmissions. And the only downside was that you did send
the multicast potentially with a lower bitrate == more airtime than
what the furst-away active receiver needed. And for non-beamforming/MiMo,
that should be easy to rectify: you just do receiver tracking, and
you dynamically L2 multicast at the bitrate of the weakest receiver.

So in summary spectrum use/interference today is worse by a factor of
N because receivers are on average closer to the AP than its radius,
and its on average better by facor M because you save repeated
unicast transmission. And nobody knows in which deployments M is on
average larger or smaller than N.

Beamforming/MiMo does of course shift the caluclation a lot more into
more unicast transmissions vs. single multicast transmission, and
i would bet nobody has tried to come up with an analytical model to
dynicall determine when multicast is better than repeated unicast with
MiMo.

Cheers
    Toerless