The Ruckus Room

Treating Multicast Video Right, Cisco Sees the Light.

Cisco's first big (Wi-Fi) blessing was beamforming. Now the behemoth is 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 long-haired 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 UDP unicast traffic (that is acknowledged). 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 no one 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 complex RF signaling (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 publish 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 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.

Zapping Wi-Fi Performance

Even with the best wireless gear, characterizing Wi-Fi performance is a pain in the buttocks and difficult at best.

Reflections, refractions, signal fading and attenuation all wreak havoc on throughput causing performance to vary freakishly.

Because wireless performance is inherently statistical, accurate performance testing must account for this random component.

Here's a good Black Paper on "Characterizing Wireless Performance" written by one of our super geeks (apologies in advance).download it here.

Ultimately, real-world wireless testing is essential, but this testing must be performed in a way that exposes the underlying performance statistics, looking beyond average throughput.

Sampling is the key to recovering the statistical performance and must be conducted across all relevant dimensions. Time-based sampling of the wireless channel, sampling at a large number of locations and sampling across the full range of channels are the keys to providing valid comparisons and predictions.

Introducing Zap: Now Free!

Zap is a wireless performance testing tool that Ruckus engineers developed precisely for this purpose. While Chariot and NetPerf are good tools for determining average (50%) throughput, they are expensive and don't do the best job in sampling to the 99.5 percentile.

Zap works by sending controlled bursts of packets and measuring both packet loss and inter-arrival times. The primary results reported are number of packets lost, total packets received and detailed throughput statistics. Because Zap provides a measure of both throughput and consistency over time and distance, it has particular importance to streaming video, voice and other latency-sensitive applications. Conversely, knowing only average throughput levels will not help predict the performance of a wireless network. By measuring the maximum throughput of batches of packets, Zap is able to determine the minimum throughput that can be expected at a given percentile

We initially developed Zap to as a way to figure out worst case performance for multicast IPTV streaming. Service providers just don't care about average throughput, they care about what they can guarantee - what they can charge for. For Ruckus, Zap has been invaluable making our Wi-Fi products perform better.  With it, we've been able to effectively guarantee how they will perform 99% of the time in a given area (just don't hold us to it).

Zap lets any company better understand the statistical throughput distribution of a wireless system to more accurately characterize Wi-Fi performance. With Zap, admins can easily test sustained throughput of an existing system and predict the real-life performance of a planned system before deployment.

By enabling an accurate determination of the true, sustained and worst-case performance that a wireless network can deliver 99.5 percent of the time, companies can become more confident in knowing that their wireless network will adequately support the more stringent application requirements that exist and the quality of service that users have come to expect.

Now in our infinite wisdom, we are releasing Zap to the world. We've released the raw code to open source and have posted compiled versions for the PC (Download Zap_install_20100413) and the Mac (download Zap_mac_20100111) to anyone who wants to use it. 

NOTE: The ZapD file is a daemon that runs on the server, the other Zap file runs on the client.