[CUWiN] IP multicast
jim at netgate.com
Fri Aug 22 19:21:32 CDT 2008
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:
>> in short: no. Mcast suffers from packet loss. No ACKs. Mcast
>> routing not suitable for mesh. Try unicast. Peercast, torrentz,
> 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
> 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:
> Network Coding for Wireless Environments," by Katti, Katabi, Hu,
> and Medard.
> 100% fidelity is not necessary for some types of traffic. For
> 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
> 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
> Project Page: http://cuwireless.ucimc.org
More information about the CU-Wireless