[CUWiN] IP multicast

[Jim Thompson]

On Aug 22, 2008, at 7:57 AM, David Young <dyoung at pobox.com> wrote:

> 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.

You need to understand the layer 1 issues.

> They cost you
> opportunities to transmit many, many bits.

Yes, but see above. Also note that 802.11 attepts to preserve LAN  
semantics, and meshes aren't LANs.

Therefore 802.11 radios are round peg/square hole, but they're cheap,  
so people do try to use them.  With mixed results.

> 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.

Or even a MAC different than 802.11 altigether.

> 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.

Such that all STAs can decode the transmission.

>  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.

True, but the higher bit rates have higher SNR requirements.

>
> 802.11 packet reception is ordinarily an all-or-nothing affair, so  
> long
> packets will get clobbered a lot.

If the iterferer signal level is high enough to cause insufficient  
SINR at the receiver for the modulation used.

>
> 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?

Damaged packets are (almost) always droped in IP protocols.  You seem  
to not want a new TOS as much as a new layer 4 protocol.

>
>
> 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.


You may wish to look at some of the flooded broadcast mesh routing  
protocols.

Jim
>
> Dave
>
> -- 
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933 ext 24
> _______________________________________________
> CU-Wireless mailing list
> CU-Wireless at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless
> Project Page: http://cuwireless.ucimc.org