[CUWiN] IP multicast

David Young dyoung at pobox.com
Fri Aug 22 12:57:40 CDT 2008

On Sat, Aug 09, 2008 at 07:44:38AM +0200, Sven-Ola Tuecke wrote:
> Hey,
> in short: no. Mcast suffers from packet loss. No ACKs. Mcast routing not suitable for mesh. Try unicast. Peercast, torrentz, OLSR/BMF...

There are complicated trade-offs involved in using 802.11
unicast/multicast to deliver unicast/multicast IP traffic.  Here are
assorted thoughts on the problems and the possibilities.

Acks have their uses, but they may be over-rated.  802.11 unicast Acks
and the back-off procedure entail a lot of overhead.  They cost you
opportunities to transmit many, many bits.  The higher the bit rate,
the higher the cost.  The best acknowledgement scheme for multicast in
an 802.11 mesh may reside at a layer between 802.11 and IP.  Maybe you
should not use acknowledgements at all.  More on that later.

Many 802.11 multicast implementations use the very lowest available
bitrate to transmit to multicast destinations.  Sometimes the lowest rate
is the worst possible rate to use, especially for large payload sizes.
The longer that an 802.11 packet is "on air," the more opportunities
for an interfering signal at the receiver to corrupt the packet.
802.11 packet reception is ordinarily an all-or-nothing affair, so long
packets will get clobbered a lot.

If you have a good link metric, it may tell you both the best bitrate or
rates to use to transmit to all of your nearest neighbors on the mesh,
and it may also tell you how many times to transmit multicast packets
in order to be fairly certain that all neighbors receive each packet,
most of the time.

When a mesh router is congested and carrying more than one flow,
sometimes it can effectively deliver two unicast packets with one
multicast transmission, using "network coding".  A thought-provoking
paper on the idea is, "The Importance of Being Opportunistic: Practical
Network Coding for Wireless Environments," by Katti, Katabi, Hu, Rahul,
and Medard.

100% fidelity is not necessary for some types of traffic.  For example,
one may still get some use from an audio/video stream if many bits are
corrupted, while an FTP download in which many bits are corrupted may
be useless.  Perhaps there should be an IP type of service for packets
that may be damaged in transit?

Perhaps ideas in the "digital fountain" literature can be applied to
the 802.11 mesh to improve multicast performance, especially where
peer-to-peer file transfer is involved.


David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933 ext 24

More information about the CU-Wireless mailing list