One more question. Have there been any experiments with multicast audio (or even video)? When I think of radios, I think of a single transmission reaching more than one person's ear. Networks over radio apply wired networking feel over wireless, but it is perfect for multicast. Back in the day (mid-1990's) there was something called the MBONE. It was an experimental multicast network connected via tunnels over the Internet (since most routers did not have multicast turned on). They also wrote software for it that multicasted audio, video, and a whiteboard. The multicast session directory listed available programs. Cool stuff, but it was somewhat limited to manually creating tunnels to transport multicast. Since mesh already needs multicast, that barrier would be removed.
Anyways... multicast audio anyone?
Anyways... multicast audio anyone?
I was originally thinking we might see this when we get to IPV6 but After thinking more about the RF characteristics I'm somewhat torn on the concept of multicast, at least in its normal method, directed unicast may actually be more efficient due to some interesting items about RF links vs wired links.
The issue comes down to the 802.11a/b/g/n protocols that are leveraged for the mesh networking.
The rule is that broadcast traffic (multicast is a form of broadcast traffic) must be sent at the slowest common speed so that way all devices can receive it. On a switched wired network where we normally see multicast this is the ethernet port speed and the switch doing the forwarding knows the exact rate for each neighbor and can send it out at that speed. RF however is tricker.
On 900MHz and 2.4Ghz at 20MHz wide the "common" speed would be be 1mbps and on 3.4GHz and 5.8GHz this would be around 6mbps (RF data rate) while a directed unicast signal between two nodes could be as high as 150mbps (802.11n dual chain/MIMO devices assuming current 3.16.1.0b01 or newer build) on all bands at 20MHz, an up to 150x improvement in transmission performance (though I'll admit real world is likely less)
A directed unicast based multicast may actually prove more useful where it can be directed once to each mesh node and then the mesh node could direct it once to each neighbor. Unless you have a LOT of neighbors wanting the exact same data the odds are this could be more efficent
.
It would require some sort of daemon to handle the subscriptions and routings and distributions. I'm not sure if anything for this has been written but it might be more efficient.
Actually, there *is* a daemon. It is a multicast routing protocol daemon. The original one was called 'mrouted' and that is the one I used for the MBONE. Now there is something newer. The routing protocol is called "PIM" or "Protocol Independent Multicast" which only directs traffic to subnets that are "subscribed" or calling for the multicast stream. I haven't read up on this in a while, but I think PIM is the most modern protocol.
Multicast on a LAN is pretty simple, but multicast is also designed to cross routers when requested:
https://en.wikipedia.org/wiki/Protocol_Independent_Multicast
Back in the MBONE days, there would be multiple Session Directory announcements for an event. The Session Directory was very low bitrate since it only announced "channels" or "streams". A single event might have multiple streams. For example, one might be audio only, another audio/video HiRes, another audio/video LoRes. The audio program worked very similar to a two-way radio in that I could "key down" in the program and speak back to the group that was listening on the session.
For example, let's say we have a camera on the mesh. It is just sitting there capturing video and putting it on the Ethernet. Beyond that, the packets don't go anywhere. Then a person decides to take a look at the stream. The routers talk to each other an let upstream know that a client wants the video. Another other client along the link joins the existing stream (if it is the desired bitrate). That way, only a single stream is sent.
I'm not sure it would deal with the bitrate issue I described on quick read it doesn't look like it does unicast streams (nothing shows multiple receivers off the same port in docs I can find on quick glance.) it just appears to chose which interfaces to broadcast out of so we would be limited to the basic 256kbps-1mbps (900Mhz/2.4GHz 5-20MHz channel) or 1.25mbps-6mbps(3.4GHz/5.8GHz 5-20MHz channel) for the full stream at any hop (and that is assuming the entire RF bandwith was dedicated just to the multicast stream and no other traffic went across and that the remote node didn't have to repeat it out its same interface which would immediately half all those numbers) but I have to admit I'm still reading up on it to understand fully.
That is unless I'm misunderstanding it. I'm certainly not up to date on the ins and outs of PIM myself.
Ah, I think I get what you're saying. I will restate it just to make sure. You are saying in a PtMP situation, each client on the AP's radio would loose bandwidth because if one of the clients initiated a stream, the AP would have to receive, then retransmit the stream on the SAME radio, which uses up RF bandwidth. Is that correct? For that, I am not sure, but I think you are right. I know that Ubiquity radios have a checkbox to turn on IGMP snooping so only clients that want the stream, get the stream:
Multicast Enhancement
If clients do not send IGMP (Internet Group Management Protocol) messages, then they are not registered as receivers of your multicast traffic. Using IGMP snooping, the Multicast Enhancement option isolates multicast traffic from unregistered clients and allows the device to send multicast traffic to registered clients using higher data rates. This lessens the risk of traffic overload on PtMP links and increases the reliability of multicast traffic since packets are transmitted again if the first tranmission fails. If clients do not send IGMP messages but should receive multicast traffic, then you may need to disable the Multicast Enhancement option. By default this option is enabled.
My proposal would only be for audio, because it would have the best support across the network and wouldn't require much in the way of bandwidth.
The other issue is AA is RF connected to AB and AC and AD off the same RF port and only AB has subscribed to the stream I believe PIM-SPARSE would say "OK there is router AB on port A that wants it, let me multicast it out to him" where it would go as a broadcast packet which is sent at the SLOWEST RF DATA RATE which would be 1mbps on 2.4GHz at 20MHz wide
If the program (with the same network layout of AA to AB, AC, AD) did:
"OK Router AB on port A wants this -- let me send it to him direct -- I know how to reach him at MCS 16 which is 150mbps I will send it directly to him at full data rate" it would take 1/150 time as long to send the packet.
A second example of this is
"OK Router AB and AC on port A want this, I know how to get to AB at 150MBPS and I know how to get to AC at 75mbps let me send it twice, once to AB and once to AC"
The 75mbps AC path will take twice as long as AB and be in addition to the time AB took. This means its really taking 3x as long on RF time as the example above. That means its 150x/3 = 50x more RF efficient to send two unicast streams (one to AB and one to AC) then it would be to send 1x Multicast (broadcast) stream.
Obviously there is a tipping point where if enough directly RF reachable nodes want the information that the slowest data rate sent once is actually faster (in which case ideally the program would know as such and convert to that mode)
Basically it boils down to on RF:
Broadcast packets will be sent at slowest data rate:
Directed packets (unicast to a specific node mac address) can transmit at up to the fastest possible data rate ( 150mbps ) but this depends on how good the link is. On a really bad link a unicast to a single node could be as slow as a broadcast
Hmmm. I think I'm still missing something. I don't see how a unicast stream at 64kbit/s to a 150mbit/s client and another unicast stream at 64kbit/s to a 75mbp/s client is any different than taking a multicast stream at 64kbit/s and sending it to 150mbit/s client and 75mbit/s clients. I haven't thought about this stuff in a while, so I could be a bit dense right now.
The radio looks like a switch to the router. The radio is using IGMP to see which peers need the packet (subscribed). IGMP works with the multicast routing daemon to join the multicast group. The router just sends the packets at the rate the upstream is getting them. Let's say it is audio at 64kbps. The router just passes the packets from open port (and radio) to the other. It doesn't know about rates and doesn't care, because multicast uses UDP. There is no retransmit. If a packet can't get delivered, it just drops (just like noise on the audio from a traditional radio). Only the client software is selecting the rate of transmit and receive for the stream.
I'm only talking about one or more audio streams of the same bitrate (64kbit/s).
[... edit ...]
Ah! I think I know what you are saying now. I found this link from Mikrotik:
http://wiki.mikrotik.com/wiki/Manual:Multicast_and_wireless
The AP downshifts to the lowest common speed for all STA's for the broadcast packet. Is this what you are talking about? It appears that I kept skipping over the fact that the STA's have different *symbol* rates therefore the packet can't be heard by all clients unless it sends each packet at the correct symbol rate. So now it makes sense. It would only work if the the clients are all locked at the same symbol rate. Correct?
Well, this will be interesting if the mesh ever uses IPv6. I believe that IPv6 requires multicast to function.
So, will there be some sort of optimization for multicast wireless networks with clients of mixed symbol rate? Maybe it already exists.... Ah just found something. It does exist. Multicast packets in 802.11 are sent at a fixed rate. I found a page from Cisco that explains how to set the rate. I suspect there is a similar setting/control in LInux WiFi drivers. The clients that don't meet the connection minimum wouldn't hear the multicast packet. That wouldn't be a terrible thing since it would allow for experimentation of multicast on the mesh without messing up people that have low connection speeds. If I understand things correctly, the packet would get sent only once for all clients, but at a fixed rate for multicast packets. So it appears that it AP does not resend the packet for each rate like you were speculating in the one example.
I found this abstract:
"Abstract—The technical evolution of Wi-Fi networks has made it possible to attain very high speeds for delivering content to users. However multicast transmissions never received the same level of attention as unicast transmissions in the IEEE802.11n standard."
Now that I understand how multicast gets treated in 802.11 (the rate locking) it appears that multicast only really useful to wired networks. Well, unless all the clients on an AP are around the same rate of speed or there are enough clients on the AP to equal out the time it takes to send the packet at that fixed rate.
Soooooooooooooo, bummer. I kinda wanted to see "radio" done on a radio network. Oh well.
[...edit...]
It appears that some people are working on the problem:
HIMAC: High Throughput MAC Layer Multicasting in Wireless Networks
http://web.cse.ohio-state.edu/~prasun/publications/conf/mass06.pdf
So, I guess there is some hope.
I agree that multicast would be extremely useful in our network. Among other things, it's the natural way to implement a roundtable -- something most hams are already familiar with.
But as KG6JEI explained, WiFi has a serious problem with multicast -- at least for user traffic at any appreciable data rate. Radio channel quality can vary widely, and to adapt to this WiFi provides a wide range of physical data rates: not just different channel symbol rates but also different numbers of bits per symbol and different FEC code rates. The list of available modes (and the range of data rates) only increases with each new version of WiFi.
Unicast (point-to-point) WiFi exchanges are acknowledged at the link level so they can adapt rather easily by picking, on a packet-by-packet basis, the fastest modulation/coding scheme supported by both ends and the channel quality. But multicasts are not acknowledged, so there's no easy way for the transmitter to know what data rate to use. The transmitter could use the lowest data rate it had previously used to send unicast traffic to anybody, but there may be newcomers on the channel. And besides, channel quality can continuously vary.
This is enough of a problem in regular WiFi networks that some access points (like mine from Engenius) implement "multicast optimization". The access point keeps a list of associated clients, so when it receives a multicast packet from the Ethernet for transmission over the WIFI interface it unicast a separate copy to each associated station. The usual unicast link mechanism then picks the optimum data rate for each client and ensures, with an ACK, that it got there.
This may seem inefficient, but let's say your access point has only a half dozen associated stations, all of which can receive 54 Mb/s. All six unicasts will still take only about 11% of the time it would have taken to send a single multicast at 1 Mb/s, the lowest 802.11 data rate (not counting channel turnaround and ACK overhead).
The access point can further optimize things by snooping on IGMP (Internet Group Management Protocol) and sending the unicast copies only to clients that indicate membership in the group. (This is already common practice on many access points and Ethernet switches.)
The fact that many access points already implement features like this, plus the fact that they're only really doable in access point mode (aka "managed" or "base station" mode) makes me think that we should seriously reconsider the current use of "ad-hoc" mode in the mesh network. I can think of several other important benefits this may provide, and it's something that should be experimented with.