tag:blogger.com,1999:blog-1988432060681510848.post6295574677638952485..comments2024-03-25T23:51:47.067-05:00Comments on Revolution Wi-Fi: Microsoft Lync QoSAndrew von Nagyhttp://www.blogger.com/profile/12658799453646609565noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-1988432060681510848.post-28748717132061248012013-08-02T12:13:51.295-05:002013-08-02T12:13:51.295-05:00Hi Doug,
Deploying Meru APs close to each other d...Hi Doug,<br /><br />Deploying Meru APs close to each other does not ensure maximum system throughput. When APs are on the same channel, EVEN IF COORDINATED, they either: 1) interfere with each other due to CCI, or 2) have to coordinate which AP will transmit. So, either you have collisions or you have a TDMA-like environment. Neither situation enhances system throughput, but deploying more APs in this manner means 1) more AP cost, 2) more Ethernet ports, 3) more PoE power, 4) more Ethernet cables, 5) more controllers with AP and feature licenses, 6) more time to deploy. <br /><br />Other drawbacks of Meru's Virtual Cell (aka: Single Channel Architecture) include 1) lack of scaling, and 2) manditorily controller-based.<br /><br />Meru's SCA doesn't positively or negatively impact the QoS topics within this blog, as best I can tell. All of the same issues would still apply to Meru, just as they do with Cisco, Aerohive, or any other. The one issue to consider, like Andrew mentioned, is whether QoS is done in the AP or in a controller. It's always better at the AP.<br /><br />Thanks!<br />DevinDevinatorhttps://www.blogger.com/profile/02969739263236315747noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-58281248796555152602013-01-08T11:28:39.273-06:002013-01-08T11:28:39.273-06:00Hi Guys,
A bit of a simplistic view as I am not as...Hi Guys,<br />A bit of a simplistic view as I am not as technical as you guys, but this solution has worked very well for me in very high density and application demand environments.<br /><br />I have recently discovered Meru which takes the client roaming decision away from the client by creating a virtual cell, therefore allowing efficient air traffic control of QOS, and because it can be deployed on a single channel you can deploy access points close to each other to ensure maximum throughput, and if required layer other channels up like a cat switch.<br /><br />Like I said it may be too simplistic, but a thought.<br /><br />Doug - Prodec NetworksAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-25029437822579725942012-12-28T12:17:15.198-06:002012-12-28T12:17:15.198-06:00I recommend using DSCP 48 because in Windows the L...I recommend using DSCP 48 because in Windows the Layer 2 QoS is mapped from the Layer 3 DSCP value, and Layer 2 over-the-air link is a shared medium, so it's more important to ensure prioritized delivery from the client over the air than it is over a wired Ethernet link at Layer 2.<br /><br />You will need to couple this with network infrastructure policies on upstream equipment (wireless AP, switch, router, etc.) that inspect the traffic and re-write the correct Layer 3 DSCP value before forwarding the packet deeper into the network. This will be true for both wired and wireless traffic from clients. For example, in a Cisco wireless or wired network you would have to do this with a policy-map on a layer 3 switch or a router. On an Aerohive wireless network you could do this right in the AP with a QoS Classification Map and Marker Map. You just need to re-classify and mark the traffic once it has passed over the air, ideally as close to the AP as possible, which is why I prefer Aerohive QoS implementation because the policy is defined and implemented right in the AP at the edge, without having to traverse layer 2 switches to get to a layer 3 device before the correct QoS is re-applied.<br /><br />Cheers,<br />AndrewAndrew von Nagyhttps://www.blogger.com/profile/12658799453646609565noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-1840844590817645972012-11-13T05:35:15.005-06:002012-11-13T05:35:15.005-06:00Hi Andrew, thanks for taking the time to write thi...Hi Andrew, thanks for taking the time to write this article. I have a question.<br /><br />Firtsly, my environement is MS lync marking voice packets with EF46 and currently being handled handled correctly by our Cisco LAN/WAN for wired clients. For our wifi clients we have Aruba infrastructure. I want to switch on WMM on the controller and for the Cisco lan port to take the EF46 marked voice packet from the client.<br />If we do as you suggest :-<br />'Instead, consider applying a non-standard DSCP marking. Using this approach we use policy-based QoS on Windows platforms to mark voice traffic as DSCP 48 (CS6), which allows it to be mapped to the correct wireless layer 2 CoS value of 6 and be queued correctly for transmission by the client.' as you rightly state this would affect the wired connection so is not really an option as the clients are used for both wired and wirelessly. In which case, are you implying there is no way around this to enable WMM to correctly interpret our EF46 markings in this scenario?<br />Jonjonoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-12799880037250255892011-09-24T11:45:44.717-05:002011-09-24T11:45:44.717-05:00Andrew, thanks for explanation. 100% agree.Andrew, thanks for explanation. 100% agree.Arsennoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-46569516320826832072011-09-22T20:53:14.656-05:002011-09-22T20:53:14.656-05:00Hi Arsen,
Many vendors offer granular QoS policy d...Hi Arsen,<br />Many vendors offer granular QoS policy definition and control. Unfortunately, Cisco does not. Having that level of control does make it easier to integrate wireless and wired policies to ensure end-to-end consistency, and is definitely a good feature to have.<br /><br />However, this does not negate the need for proper over-the-air scheduling and queuing performed by the wireless client itself. Arguably, appropriate traffic handling over the air is the most critical piece since RF is a shared medium. Microsoft Windows and Lync QoS policy settings on the client need to be accurately defined, but the way DSCP to CoS mapping is implemented by Microsoft presents opportunity for mis-configuration if network administrators are not careful to verify behavior. This is especially true since the default behavior does not conform to wireless networking "best practices".<br /><br />Thanks,<br />AndrewAndrew von Nagyhttps://www.blogger.com/profile/12658799453646609565noreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-18052182464356525992011-09-21T06:11:02.160-05:002011-09-21T06:11:02.160-05:00I must have missed something.
I work with Motorola...I must have missed something.<br />I work with Motorola WLAN equipment. On it, you can create ACLs that may include 802.1p/DSCP tags as match conditions and re-mark them as an ACL action. You also can alter the default WMM<->802.1pp<->DSCP mapping table in order to maintain consistent L2/L3 QoS mapping across all of your network. <br />All these look pretty generic to me, and, basically, would solve Lync case (alter WLAN infrastructure QoS mapping table to match LAN infrastructure mapping table, capture and remark Lync packets). <br />Does Cisco not have it or there's some point that I'm missing (like, you're pointing out that network integrators SHOULD keep this issue on the checklist and not just simply trust default settings)?Arsennoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-9258897440758464582011-09-13T13:07:59.844-05:002011-09-13T13:07:59.844-05:00Thanks Andrew, for the recovery! :)Thanks Andrew, for the recovery! :)@ozwifihttp://www.arubanetworks.comnoreply@blogger.comtag:blogger.com,1999:blog-1988432060681510848.post-40366794586370214962011-09-12T15:47:31.343-05:002011-09-12T15:47:31.343-05:00Andrew,
Great article and summary on QoS needs fo...Andrew,<br /><br />Great article and summary on QoS needs for the wired/wireless to handle apps like Microsoft Lync. Quite a bit of marketing lingo but I thought you might be interested in our (Aruba) integration best practices with Microsoft Lync. We aim to overcome some of the challenges you highlighted with signature matching on encrypted Lync sessions to enable application awareness - then apply FW, QoS (marking or re-marking when necessary) policies... delay scanning, enable CAC.. and some more. Let me know what you think. For us the biggest puzzle was to figure out exactly which packets belong to a Lync session running on a laptop... after we figured out how to identify them in a long stream of packets from high density of clients, things got much easier. We are applying that same technique to BlackBerry MVS encrypted sessions, Apple FaceTime traffic, etc. Here is the Lync paper: http://bit.ly/prLSrH <br /><br />(via @ozwifi - Sorry, I accidentally deleted this comment in the moderation queue and couldn't get it back in it's original form. Andrew)Andrew von Nagyhttps://www.blogger.com/profile/12658799453646609565noreply@blogger.com