[aodvv2-discuss] Possibly irrelevant material, given "Simple Flowchart for deciding RREP-Unicast_or_Multicast"

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Sat, 04 Jul 2015 07:32:31 -0700


Hello again folks,

First, let me clearly state that I do not intend any of my emails to cause any possible delay to achieving Last Call.

As I mentioned earlier, I have been checking with various friends about the multicast issue. So far my concerns have been validated by 100% of them.

One of them is chair of an IETF multicast group, and by strange fortune he was already working on a relevant draft. I told him of my interest, and he asked me to co-author.

The (obviously incomplete) current result is attached. By Monday, it will include the material I sent to you last week, for submission to [intarea].

Please note, this material is *only* relevant given certain choices of the Simple Flowchart.

Regards,
Charlie P.




Internet Area WG M. McBride
Internet-Draft C. Perkins
Intended status: Standards Track Huawei
Expires: January 3, 2016 July 2, 2015


Multicast Wifi Problem Statement
draft-mcbride-mboned-wifi-mcast-problem-statement-00.txt

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 3, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of




McBride & Perkins Expires January 3, 2016 [Page 1]

Internet-Draft Multicast Wifi Problem Statement July 2015


the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 2
3. multicast over wifi problems . . . . . . . . . . . . . . . . 2
4. Common remedies to multicast over wifi problems . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . 3
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3
8. Normative References . . . . . . . . . . . . . . . . . . . . 3
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4

1. Introduction

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, low data rate, among others. This draft reviews
these problems found with multicast over wifi and, without intending
this to be a solutions draft, will list common workarounds to the
problem.

2. Specification of Requirements

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 [RFC2119].

3. multicast over wifi problems

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 no
retransmission and due to the sender not backing 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 the problems of clients



McBride & Perkins Expires January 3, 2016 [Page 2]

Internet-Draft Multicast Wifi Problem Statement July 2015


unable to stay in sleep mode due to the multicast control packets
continuing to unnecessarily wake up those clients and subsequently
reduce energy savings. With video becoming the dominate application
for end devices to consume and with multicast being the most
efficient method to transmit video, video over wifi applications sent
using multicast take a big hit over wifi.

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.

4. Common remedies to multicast over wifi problems

One common solution to the mutlicast 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.

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.

5. IANA Considerations

None

6. Security Considerations

None

7. Acknowledgments

Coming soon

8. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.





McBride & Perkins Expires January 3, 2016 [Page 3]

Internet-Draft Multicast Wifi Problem Statement July 2015


Authors' Addresses

Mike McBride
Huawei
2330 Central Expressway
Santa Clara CA 95055
USA

Email: michael.mcbride@xxxxxxxxxx


Charlie Perkins
Huawei
2330 Central Expressway
Santa Clara CA 95055
USA

Email: charlie.perkins@xxxxxxxxxx

































McBride & Perkins Expires January 3, 2016 [Page 4]

Other related posts:

  • » [aodvv2-discuss] Possibly irrelevant material, given "Simple Flowchart for deciding RREP-Unicast_or_Multicast" - Charlie Perkins