Introduction
Updated 6/15/2009: Clarified Source tagging requirements.
In Part 1, I provided some background on WMM and showed the client and AP controls that enable it. And in Part 2, I actually managed to show an example of WMM properly prioritizing media traffic. In this final Part 3, I’ll show additional test results and to wrap things up, explain why WMM doesn’t currently provide any improvement for media streaming.
Vista and qWave
On the road to finding the combination of router, clients and settings that worked, I kissed a lot of frogs. And once I had a "known good" IxChariot script, I tried some other variations.
I first tried just reversing the traffic flows of the test pairs to test whether WMM worked running uplink. The plot in Figure 1 first fooled me into thinking that uplink WMM wasn’t working, because the "background" trace didn’t fall below the "Video" trace when it started.
Figure 1: Uplink not working?
But upon closer inspection, the "Video" stream is getting its required 10 Mbps of bandwidth and the "background" stream does drop its speed a bit. It turned out that I was just fooled by the higher bandwidth available running uplink. Once I raised the BK stream rate to 20 Mbps and the VI stream to 15 Mbps, I got a clearer indication that WMM was working fine, as shown in Figure 2.
Figure 2: Uplink WMM clearly working
I next tried using the Intel WiFi Link 5100 AGN client in the notebook running Vista SP1. Vista supports an "improved" QoS scheme called qWave (Quality Windows Audio-Video Experience). Neither the Wi-Fi Alliance WMM white paper nor the test plan mention qWave. But my Ixia contact said that it should support WMM without having to perform the registry change needed on XP.
So I switched in the Vista SP1 notebook as an endpoint for the VI ("video") priority stream. And it worked just fine as shown in Figure 3 and also running uplink (not shown).
Figure 3: qWave in Vista SP1 works fine
Switching APs
So with these successes under my belt, I tried some different APs. I first tried an old Linksys WRT54G, updated with firmware that supports WMM. But no matter which clients or OSes I tried, I didn’t get good results.
Figure 4 shows an example of what I saw, running a BK stream to an XP SP2 and VI stream to the Vista SP1 system. This same script ran fine with a D-Link DIR-655 as the AP, even though I was using a qWave QoS template with the XP SP2 system. But even when I switched to using DSCP coding on the BK stream, I still got similar results.
Figure 4: WRT54G WMM failure
Although the BK stream drops back when the higher-priority VI stream starts, it doesn’t drop far enough to give the VI stream the 12 Mbps it needs. I also tried the WRT54G using two XP clients using DSCP QoS templates and got similar results.
Finally, I switched in a Linksys WRT160NL that just came in for review and paired it with another notebook running XP SP2, but with a wireless adapter using an Atheros AR5001X+ chipset. Figure 5 shows that the background stream once again dropped back, but the VI priority stream doesn’t have enough bandwidth to satisfy the 10 Mbps stream rate that I set.
Figure 5: Linksys WRT160NL and Atheros adapter
I tried a few other combinations of stream rates and adapters and wasn’t able to achieve the proper prioritization obtained with the DIR-655.
Real World
My final step was to try to show WMM providing improved video streaming robustness using simultaneous video and data streams. If WMM operates properly and the wireless connection has sufficient bandwidth to meet the needs of the video stream, WMM should ensure that bandwidth is taken from the lower-priority data stream so that the video stream always gets enough bandwidth to provide a trouble-free viewing experience.
I first checked the Wi-Fi Alliance’s Certification database and searched for media servers with WMM certification. Even though this would only show media servers with built-in wireless, it would at least be a start. But the search results showed only media players.
Since media servers are built into virtually all NASes, I then asked Buffalo, Cisco, NETGEAR, QNAP and Synology if the media servers built into their NASes provided media streams with WMM-compliant priority tagging. Unfortunately, makers of media servers seem to be blissfully ignorant of WMM’s third requirement—the source application supports WMM. I didn’t hear back from QNAP, but Buffalo, Cisco, NETGEAR and Synology all told me that their NASes did not support WMM compliant priority tagging, or any other priority tagging, for that matter.
The responses I received seemed to indicate that NAS manufacturers don’t understand the connection between WMM and media servers in general. Since WMM is a wireless technology and NASes are primarily wired products, NAS makers seemed unaware of the need to provide priority tagging in their media streams so that WMM could properly prioritize them.
Updated 6/15/2009
The Wi-Fi Alliance provided a clarification regarding source application priority tagging. A WFA Alliance technical contact said:
"source applications do not need to know about *WMM* tagging…they can do layer 3 DSCP tagging or layer 2 tagging.
So for example, a NAS that was connected by Ethernet could use DSCP tagging that [would be] converted to WMM tagging when it hits a WMM enabled AP.
I then discovered a reference to DLNA version 1.5 supporting WMM. Since some NAS manufacturers say their NASes are DLNA compliant, I started checking this lead. But this also turned out to be a dead end. Once again, since WMM is a wireless technology, only wireless products that are DLNA 1.5 compliant would implement it.
I did find, however, that Cisco’s Linksys Media Hub and WD’s New "White Bar" MyBook World are DLNA 1.5 certified. But the certification certs (Linksys, WD) show only media format interoperability and no indication of WMM. This probably makes sense, since Cisco told me that although DSCP marking on media packets is part of DLNA-1.5 QoS, this is an optional requirement.
Software Media Servers
So how about software media servers? Well, perhaps the most promising route would be via Windows Media Center (the version built into Vista) streaming to Media Center Extenders like the Linksys DMA2200, Xbox360 or other devices. With Vista providing both the media source and player and both ends implementing qWave, surely this would be an promising configuration.
I didn’t have any Windows Media Extenders to try. But I fired up a copy of Vista Home Premium SP1 and the Windows Media Center that it includes, on an Ethernet-connected test system. I transferred some test video files to the Vista machine, then had Windows Media Center add the files to its library. I next associated the Vista SP1 notebook that I had used in my IxChariot testing with the D-Link DIR-655, which had WMM enabled.
Once I had everything connected, I opened Windows Media Player 11 on the Vista notebook and used its Library browser to find and play a 720p WMV demo file from the Windows Media Center system. After it played for awhile, I started a large file download on the notebook.
The video played pretty well for the most part, but had some stuttering in spots while I was running the file download. But I wasn’t sure whether WMM was working and there just wasn’t enough bandwidth to go around, or whether WMM just wasn’t being used.
So, to find out, I fired up Wireshark and ran a packet capture on the server machine while the video played on the wireless notebook. Wireshark revealed that the Media Center / Player pair used TCP for the file play and not a streaming protocol like UDP or RTP. The packet capture also confirmed that the DSCP tag was set to 0, which is the "default" coding of "best effort" (lowest-priority).
To ensure that I wasn’t interpreting Wireshark incorrectly, I ran a capture on one of my IxChariot tests that used BK and VI DSCP priorities. Figure 6 shows a packet from the notebook running the VI priority stream properly tagged with DSCP = 5. The same capture showed the BK priority stream tagged with DSCP = 1 (not shown). So qWave or not, Vista, Windows Media Center and Windows Media Player didn’t appear to implement any form of media priority tagging.
Figure 6: Wireshark showing DSCP Service Class 5 (VI) tagging
My last shot was to download TwonkyMediaManager and to try to see if it would provide a priority-tagged media stream. Maybe I had something wrong in my setup, but it didn’t seem to be able to play even unmolested VOB files ripped from a DVD. It also didn’t seem to even want to index a Quicktime 720p.mov file. So I quickly abandoned that experiment.
Closing Thoughts
There is no doubt that the Wi-Fi Alliance has been successful in getting wireless product manufacturers to support WMM in the majority of today’s Wi-Fi products. And WMM seems to provide a benefit for wireless VoIP (or Skype) phones that properly handle incoming and outgoing voice streams with WMM-compliant tagging and processing.
But my experiments show that WMM provides no benefit for improving video (or audio) streaming robustness by shifting available bandwidth from low-priority data traffic to higher-priority media streams. The only way that this will change is if media servers—both standalone and NAS-embedded—implement WMM-compliant priority tagging, something that, at least until this article, they weren’t even aware that they needed to do. And it also appears that some Wi-Fi product manufacturers, like Cisco, may have some work to do on their WMM implementations so that they properly allocate bandwidth among prioritized streams.