Cisco’s first big (Wi-Fi) blessing was beamforming. Now the behemoth is now touting multicast conversion for streaming video over 802.11. Finally!

It’s been a lonely five years for us out there in the networked world trying to convince people that multicasting video over Wi-Fi is an annoying problem. But Cisco only told half the story (the half that we’ve patented….here’s the patent).

The other half (once the multicast issue is addressed) is how to deal with the actual RF transmissions as packets fly through the air (more on that later). Cisco’s so-called VideoStream technology is designed to make video work better over Wi-Fi. That’s pretty cool. VideoStream was developed to solve the problem of how to better transport multicast video over an 802.11 network. So why is this a problem in the first place?

When using Wi-Fi, multicast IP packets are treated as best effort traffic. This means that multicast packets are given the lowest level of priority. And because multicast is a UDP protocol, there is no client acknowledgment, so frame loss is high. Basically, you never know if the packets even reached their destination. And to ensure that clients receive multicast traffic, the network typically uses a lower data rate to transmit them. So it takes longer to send packets. This results in highly inefficient use of time.  All of these problems are big killers for streaming video transmissions.

We figured this out about 5 years ago when our sweaty, hungry, long-hair engineers tried to stream IP video from a computer to a TV in another room. As soon as we added other traffic to the network (or shut a door between the rooms…yet another problem), everything stopped. The solution was to convert multicast traffic into “directed multicast” or unicast traffic. When traffic enters our AP, if it is identified as multicast, it is converted to TCP unicast traffic. This allows us to both prioritize it, assign it a higher physical data rate and receive acknowledgments from the client.  But how do we know who to send this “converted” traffic to?

To fix THIS problem we implemented a way to listen to the client to see if the client wanted to join a particular multicast group.  Basically it’s like when you push the channel button on your TV remote. It sends a message to the set top box asking it for another stream. The technoid term in the IP world is IGMP snooping. If we see one of these “IGMP join” requests, we then know that a given client want to receive a particular video stream – so we convert the multicast traffic and direct the packet to the requesting station.  We quickly figured this was something that noone else had done so we went running to the USPTO.

Unfortunately multicast-to-unicast conversion alone isn’t a panacea for good, consistent, and reliable video performance in the real world. You have to also address the real world over-the-air issues that make the RF channel unreliable – issues like interference, multipath and noise. So we went to work again and started building fancy antennas that could deal with all this RF crap (we also have some patents on that. Here’s one).

We started working on “smart” (multi-array) antennas and beamforming software that could figure out the best (fastest) directions to send traffic to a given client. When combined with our multicast handling, the results were (are) picture perfect.

Cisco did published some test results of their not-so-breakthrough technology. But given the impact of the RF channel on video performance, it was a strange choice to cable the clients to the AP. In this technique, (simulated) clients are all sent out over a single RF cable, which is connected to the AP. Cabling implies there is no over-the-air (OTA) characterization of performance, which basically means that your real-world video performance is likely to be quite different (worse).

It turns out there are some very simple ways to test real-world video performance because the human mind is highly attuned to visual things. Remove the expensive, cabled equipment in the test, and replace with real clients connected to real APs. Just for fun, make the distances real-world, and for grins, let’s throw in some walls, and other assorted obstructions.

A simple test will tell you everything. Run some IP multicast streams video streams to the laptops and find some 5 year olds to sit in front of the screens. They will tell you all you need to know about how best to handle multicast IP video over Wi-Fi.  And you’ll never hear the end of it.