Hi Joe (et al),
here's an update to my issue and the outcome of my TAC case. When preparing answers for the case, I had to repeatedly replicate the issue and that helped me to notice two additional settings (non-default and not directly mandated by the VoWLAN design guide) that had to be made for the issue to appear:
1) I had the "low latency MAC" feature activated that supposedly helps voice deployments to scale better. When disabling that, the issue would no longer appear.
2) In the WLC Wireless QoS section, I had modified Wired QoS to make use of 802.1p (as mandated by the design guide), but had changed the Tag for Voice from 6 (the default) to 5, based on everything else I knew about the Cisco QoS baseline. It turns out that this was a failure, even though docs on what really happens here are scarce. There is a contrived statement in the VoWLAN guide that essentially boils down to "leave that value at 6, it's good this way and for a reason", but the reasons are complicated. Let's just say here that 802.11e has another mapping of voice and video classes to user_priority tags than has the Cisco baseline on the LAN side, and the WLC does a lot of magic to make this chasm transparent, but setting the wired side QoS 802.1p tag value to 5 (which *is* the value used on this side, so it seemed completely natural to choose) will partially break that. It should *NOT* break it in the way I observed (simply losing voice QoS would be the expected breakage that nevertheless would be disastrous), but to make the long story short, setting this value back to the default of 6 made the issue disappear, too.
So I could work around the issue by simply fixing a misconfiguration that seemed to trigger that problem on less-tested code paths, and I could work around it by simply disabling the low latency MAC, which seemed a good idea anyway after some testing. These were completely orthogonal to the issue disappearing in WLC software 6.0 that just got released, so it's solved the real way, too.
Now what does all that mean for your problem which looks exactly the same but on autonomous APs? I'd say you should have a close look on what the APs call "STREAM", which is exactly the low latency MAC (aggressive queue length limitation) and 802.11e tag mapping stuff on the autonomous AP side. You have a lot more configuration options here compared to the WLC, for instance you can really configure the queue lengths for low latency by giving a number, it's not just magically and mostly undocumentedly pulled down to 4. But keep in mind that just choosing "Optimized Voice" from the general QoS page (Radio X Access Categories tab) will automatically activate low latency MAC settings in the STREAM page without the admin necessarily noticing that (I had it active on an autonomous AP of mine, without ever noticing the STREAM page before).
So I'd say you could have some testing around these exact settings, disabling the low latency MAC behaviour, and could well get rid of the issue even with current IOS and WMM/802.11e generally enabled. What we both have seen IMHO lingers somewhere there in the queue limiting code overshooting and killing essentially every frame that was trying to leave the interface, somehow concluding it was too late to make sense at the receiver.
HTH & Thanks,
Andre.
