﻿<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- "setl noai nocin nosi inde=" turns off vim autoindentation -->

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->

<rfc category="std"
     docName="draft-mcbride-mboned-wifi-mcast-problem-statement-00.txt"
     ipr="trust200902">

<front>
  <title>Multicast Wifi Problem Statement</title>
  
  <author initials='M' surname='McBride' fullname='Mike McBride'>
    <organization>Huawei</organization>
    <address><postal>
      <street>2330 Central Expressway</street>
      <city>Santa Clara</city> <region></region>
      <code>CA 95055</code>
      <country>USA</country>
    </postal>
    <email>michael.mcbride@huawei.com</email>
    </address>
  </author>
    
  <author initials='C' surname='Perkins' fullname='Charlie Perkins'>
    <organization>Huawei</organization>
    <address><postal>
      <street>2330 Central Expressway</street>
      <city>Santa Clara</city><region></region>
      <code>CA 95055</code>
      <country>USA</country>
    </postal>
    <email>charlie.perkins@huawei.com</email>
    </address>
  </author>

  <date/>

  <area>intarea</area>
  <workgroup>Internet Area WG</workgroup>

  <abstract>
    <t>
      There have been known issues with IP Multicast, in an 802.11 environment,
      which have prevented the deployment of multicast in these wifi
      environments. The mboned working group would like to gather the
      problems of wifi multicast into one problem statement document so
      as to offer the community  guidance on current limitations. 
    </t>
  </abstract>
</front>


<!-- TODO: check against draft-vyncke-6man-mcast-not-efficient-00  -->


<middle>
  <section title="Introduction">
    <t>
      Multicast over wifi has been used to low levels of success, usually
      to a point of being so negative that multicast over wifi is not allowed.
      More applications, such as push to talk in hospitals, video in
      enterprises and lectures in Universities, are streaming over wifi.
      And many end devices are increasingly using wifi for their connectivity.
      To make make multicast over wifi work successfully they often need to
      modify the multicast to instead be sent as unicast in order for it to
      successfully transmit with useable quality. Multicast over wifi
      experiences high packet error rates, no acknowledgements, and low data
      rate. This draft reviews these problems found with multicast over
      wifi.  While this is not a solutions draft, common workarounds to some
      of the problems will be listed, along with the impact of the workarounds.
    </t>
  </section>

<!--                 These keywords are not yet needed in this draft.
  <section title="Specification of Requirements">
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described
      in <xref target="RFC2119"/>.
    </t>
  </section>
  -->

  <section title="Multicast over WiFi Problems">
    <t>
      802.11 is a wireless broadcast medium which works well for unicast. With
      multicast, however, there are no ACKs for multicast packets so there can
      be a high level of packet error rate (PER) due to lack of retransmission
      and because the sender never backs off. It is not uncommon for there to be
      a packet loss rate of 5% which is particularly troublesome for video.
      Additionally, multicast is typically sent on a low date rate which makes
      video particularly troublesome. Wifi loses many more packets then wired
      due to collisions and signal loss. There are also problems because
      clients are unable to stay in sleep mode due to the multicast control
      packets continuing to unnecessarily wake up those clients and
      subsequently reduce energy savings. Video is becoming the dominant
      content for end device applications, with multicast being the
      most natural method for applications to transmit video.  Unfortunately,
      multicast, even though it is a very natural choice for video,
      incurs a large penalty over wifi.
    </t>
    <t>
      One big difference between multicast over wired versus multicast over
      wired is that wired links are a fixed transmission rate. Wifi, on the
      other hand, has a transmission rate which varies over time depending
      upon the clients proximity to the AP. Throughput of video flows, and
      the capacity of the broader wifi network, will change and will impact
      the ability for QoS solutions to effectively reserve bandwidth and
      provide admission control. 
    </t>
    <t>
      The main problems associated with multicast over WiFi are as follows:
	<list style="symbols">
	<t> Low Reliability </t>
	<t> Lower Data Rate </t>
	<t> High interference </t>
	<t> High Power Consumption </t>
<!-- should we also include the requirement for more control signaling?  -->
	</list>
      These points will be elaborated separately in the following subsections.
    </t>

<!-- To read: debian.cse.msu.edu/CSE/pub/crg/PAPERS/mswim-03.pdf -->
<!--          also seems to have worthwhile citations -->
  <section title="Low Reliability">
    <t>
      Because of the lack of acknowledgement for packets from Access Point to
      the receivers, it is not possible for the Access Point to know whether
      or not a retransmission is needed.  Even in the wired Internet, 
      this characteristic commonly causes undesirably high error rates,
      contributing to the relatively slow uptake of multicast applications
      even though the protocols have been available for decades.  The
      situation for wireless links is much worse, and is quite sensitive
      to the presence of background traffic.
    </t>
  </section>	<!--  END SUBSECTION "Low Reliability"  -->

  <section title="Low Data Rate">
    <t>
      For wireless stations associated with an Access Points, the necessary
      power for good reception can vary from station to station.  For unicast,
      the goal is to minimize power requirements while maximizing the data
      rate to the destination.  For multicast, the goal is simply to maximize
      the number of receivers that will correctly receive the multicast packet.
      For this purpose, generally the Access Point has to use a much lower
      data rate at a power level high enough for even the farthest station to
      receive the packet.  Consequently, the data rate of a video stream, for
      instance, would be constrained by the environmental considerations of
      the least reliable receiver associated with the Access Point.
    </t>
  </section>	<!--  END SUBSECTION "Low Data Rate"  -->


  <section title="High Interference">
    <t>
      As mentioned in the previous subsection, multicast transmission to the
      stations associated to an Access Point typically proceeds at a much
      higher power level than is required for unicat to many of the receivers.
      High power levels directly contribute to stronger interference.  The
      interference due to multicast may extend to effects inhibiting packet
      reception at more distant stations that might even be associated with
      other Access Points.  Moreover, the use of lower data rates implies that
      the physical medium will be occupied for a longer time to transmit a
      packet than would be required at high data rates.  Thus, the level
      of interference due to multicast will be not only higher, but longer
      in duration.
    </t>

    <t>
      Depending on the choice of 802.11 technology, and the configured choice
      for the base data rate for multicast transmission from the Access Point,
      the amount of additional interference can range from a factor of ten,
      to a factor thousands for 802.11ac.
    </t>
  </section>	<!--  END SUBSECTION "High Interference"  -->

  <section title="High Power Consumption">
    <t>
      802.11 multicast is somewhat incompatible with radio sleep schedules.
      One of the characteristics of multicast transmission is that every
      station has to be configured to wake up to receive the multicast,
      even though the received packet may ultimately be discarded.  This
      process has a relatively large impact on the power consumption by the
      multicast receiver station.
    </t>
  </section>	<!--  END SUBSECTION "High Power Consumption"  -->



  </section>	<!--  END SECTION "Multicast over WiFi Problems"  -->

  <section title="Common remedies to multicast over wifi problems">
  
    <t>
      One common solution to the multicast over wifi problem is to convert the
      multicast traffic into unicast. This is often referred to as multicast
      to unicast (MC2UC). Converting the packets to unicast is beneficial
      because unicast packets are acknowledged and retransmitted as needed
      to prevent as much loss. The Access Points (AP) is also able to provide
      rate limiting as needed. The drawback with this approach is that the
      benefit of using multicast is defeated.
    </t>
    
    <t>
      Using 802.11n helps provide a more reliable and higher level of
      signal-to-noise ratio in a wifi environment over which multicast
      packets can be sent. This can provide higher throughput and reliability.
    </t>
  </section>
    

  <section title="IANA Considerations">
    <t>
      None
    </t>
  </section>

  <section title="Security Considerations">
    <t>
      None
    </t>
  </section>

  <section title="Acknowledgments">
    <t>
   	The following people have contributed information helpful for the
   	development of this Internet Draft:
	<list style="symbols">
	<t> Dave Taht </t>        <!--  Dave T[umlaut a]ht causes trouble  -->
	<t> Donald Eastlake </t>
	<t> Marc Mosko </t>
	</list>
    </t>
  </section>
</middle>

<back>
  <references title='Normative References'>
  <?rfc include="reference.RFC.2119" ?>
  </references>
<!--
  <references title="Informative References">
  http://netlab.cs.ucla.edu/publication/download/374/getPDF.pdf3.pdf
  "MAC RELIABLE BROADCAST IN AD HOC NETWORKS"
  </references>
	-->
</back>

</rfc>
