Subject: [manet] Performance of Multicast in 802.11

From: "Sanda" <[email-masked]>
Date: Mon, 19 Sep 2005 20:29:27 +0800

I am now doing  multicast test in 802.11 environment.
It turns out that its performance is horrible compared to that of unicast counterpart.
The bitrate of the target data stream is barely over 1.5Mbps. 
The unicast version turns out to be fine using udp.
But broadcasting and mulitcasting is very poor.
What is the problem there.

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Abdelhamid NAFAA" <[email-masked]>
Date: Mon, 19 Sep 2005 19:08:51 +0200

Hi Sanda,

The reason for that is certainly the absence of link layer
ACK/retransmission for multicast and broadcast traffic. As a consequence,
there is a much higher unreliability at transport/application level since
many channel-induced errors/losses are not anymore hidden by the 802.11
LLC/MAC layer.

Another issue with multicast communication resides in the inability of the
multicast sender to explicitly deteriorate its rate (11 to 5.5, 2 and 1 Mbps
with 802.11b) to match the fluctuating channel conditions (at receivers),
which make the modulation/coding scheme inefficient in facing high BER and
finish by further exposing the multicast communication to packet losses.

It is therefore extremely required to use some form of application-level
error control techniques to overcome multicast reliability issues in
802.11-based communications.

Rgds,
Hamid.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Sanda
>Sent: lundi 19 septembre 2005 14:29
>To: [email-masked]
>Subject: [manet] Performance of Multicast in 802.11
>

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 19 Sep 2005 11:03:06 -0700

> many channel-induced errors/losses are not anymore hidden by the 802.11

Damned if you do, damned if you don't.  Back when the amateur radio
folks were using AX.25 as their link layer (digipeaters), they might
have several AX.25 links concatenated head to tail.  The link-by-link
ACKs in the X.25 protocol were killing throughput and life got a lot
better if you turned that off and relied on TCP to do the error
detection (which frame relay, in wired networks, institutionalized).  A
good share of the problem tied to the 3-bit ACK counter in X.25 -- the
packets-in-flight problem caused the links to thrash a lot.

So be careful what you ask for!

> finish by further exposing the multicast communication to packet losses.

Multicast has to go at convoy speed -- whatever the least advantaged
user in a multicast group (on that particular segment) can stand.
802.11 lacks the kind of feedback sophistication to figure this out (.16
has all kinds of knobs and dials here).  

<
-- 
b