Some thoughts on Lync and Bandwidth consumption

You've bought or installed Lync 2010 and introduced this to your environment. Was it all a good process? Did you prepare your network? Or are you now experiencing all kinds of problems, because no one prepared you for impact on network utilization Lync 2010 can have? Not sure, then maybe this post is for you.

I am not going to bore you with facts like how much bandwidth each you actually use, there are plenty of other posts and good technical documents for the facts. If you are looking for facts, you might want to start by looking here:

http://technet.microsoft.com/en-us/library/gg398842.aspx
I’ll rather talk about you understanding the consequences of the facts.

This is a discussion I’ve had with many customers. It doesn’t matter whether it’s my sales organization who hasn't done their homework, a competitor’s sales organization or just a customer who didn’t think things through; It’s always the same story: The end users complain about bad quality and unreliable services. They “all” come to the same conclusion: Microsoft is not the right product for us, or this is a bad product…

Well, here’s a thought; What if there is nothing wrong with the product, but someone misinterpreted the facts, or did not think about the all the scenarios and their consequences. Maybe they simply did not know the WAN/LAN layout and capabilities of the entire company before enabling Lync all over, and quite possibly remove the old PABX entirely.

Sounds familiar? Sure it does. Let me draw you a “reality” map:

In a perfect world, we have a lot of bandwidth all over the place. But in my world; That’s not always the case. The cost of high-speed links between all sites, often to remote locations, has been too high to justify. As the traditional PABX or PSTN used to be directly connected to the site, we never gave it a thought. But with Lync, and centralized SIP trunks, we’re potentially adding a lot of bandwidth just for pstn calls. And what will happen if some of the users in the remote sites decided to create/join a conference with audio, Video and desktop sharing, then what?

I’ll take a typical example of a topology I might (or might not) have come upon in my past: The typical Norwegian company isn’t too big. We might say the SMB marked range from 300 – 2500 users. Comparing these figures with Microsoft’s scalability chart, we might think a single Standard Edition Lync server would do the trick. I am not saying it doesn’t, I’m just saying you need to consider your network topology too. And here is why:

My imaginary company might have 500 users at HQ. But to stay in touch with the marked “everywhere” in Norway, they have regional offices in several cities around Norway. These offices might have something between 10-50 users at each site. Some of the locations might be well connected with 10MB WAN or higher; other sites might not have the same luxury. They might have limited connectivity (2MB or less?). Previous infrastructure deployments have taken the lack of bandwidth into account, and have deployed local file/print servers and domain controllers. So why shouldn’t we do the same with Lync?

Let’s take a quick peak at some facts according to the Lync TechNet Library (http://technet.microsoft.com/en-us/library/gg413004.aspx):
- An RTAudio Wideband connection will typically use 57.0 Kbps for a call
- A VGA Video stream will typically use 600 Kbps (VGA is the highest quality available for conferences)
In a conferencing scenario:
- Endpoints send audio streams only when the users speak.
- All participants receive audio streams (separate streams, not multicast).
- If video is used, only two-three endpoints send a video stream at a time (the active speaker and the previous active speaker. A roundtable can be added, if it exists).
- If video is used, all participants receive video streams (separate streams, not multicast).

Why are these facts important? Well, let’s look at one of our “smaller sites” with only 10 users and the 2MB WAN connection. Let’s look at how things might go “wrong” in this scenario.

User A and User B are discussing a project in a chat window. They decide they need to take a closer look at a document, and start an application sharing session. As they have seen the “coolness” of Lync, they add some Video to the mix. After all, it makes the experience so much better. No problem you might say. The traffic is peer-to-peer and contained within the site.
Then, after a while they decide to bring in User C from the same location. (The lack of a conference room might be a reason why they’re not meeting in person). Now then, what will happen to the traffic? Well, the conference is all of a sudden removed from the peer-to-peer mode and they all get connected to the conference server.

The consequence? There will always be one sender of each media type, and two receivers of the media streams. In simple math; 657Kbps upstream and 2x600Kbps + 2x57 Kbps downstream. Whoops! Did we just ask to utilize 1,3 MB of the total of 2MB WAN capability (And I haven’t taken the BW required for sharing stuff into account here)?

Yes we did! If we just add 1 more person, we’re suddenly very close to the BW maximum capability. Now let’s not forget we’re not alone on this WAN link. There might be Replication, file transfers, Outlook/Exchange traffic, web browsing/streaming and who knows what other applications consumes of the bandwidth.

No problem one might think, Lync has an automatic adjustment of bandwidth usage, based on what is available to us. Does it always work the way we expect it to, and at what cost? The quality might drop quicker than you expect. And when users compare it to the “old” system, the poor audio quality alone will be sufficient for the users to complain about it. They’re forgetting about all the good stuff in a whim.

I know my example is bit extreme, but you could have similar scenarios without knowing. I know it from experience; There are a lot of companies out there without a sufficient overview and understanding of the implications of introducing a fully-fledged unified communications installation.

Are you wondering if you did the right thing by installing/buying Lync? Of course you did. Stop wondering, and get to work. There are a few things you should, and could do prior to the Lync Deployment (or even adjust during the deployment, if you’re already on it). I won’t get into great detail on any of the topics, but rather let you know where you might spend some time investigating.

1. Know your network topology, and the utilization of the existing infrastructure. Discover where you need to invest in additional BW, or where you might take other actions. Don’t let a restriction of BW catch you by surprise, and get the better of you.
2. Can you implement CAC? Some say CAC looks like a lot of work. It’s not hard at all, and is totally worth the time and skill. Control how much BW Lync has available for sessions or in total between sites. I’ll give you a quick rundown in an upcoming post.
3. Use QoS in your network infrastructure. QoS could be used to guarantee BW, but it could also be used to restrict BW (So Lync, or any other type of traffic do not “steal” capacity from other critical apps). QoS is best used in conjunction with CAC (make the numbers match, and it will all be a “dream”)
4. Control what users can do with a well-defined policy. Not all users need to be able to do a multipart meeting/conferencing.
5. Don’t forget there are policies for regular uses and policies for meetings in addition to CAC.
6. Teach/Instruct/inform you users on how to use the features. And make them understand why thing might happen in remote locations.
7. Deploy a different topology. Some sites might be large enough to justify a dedicated pool. Just bear in mind it’s always the initiators pool we use. If users have different pools dedicated, they only use their own pool when initiating a conference, but they will connect to the imitator’s pool when joining a conference.
8. There are a lot of 3rd party solutions for smaller branches. It might be worth your time to take a look those products.

I hope I haven’t scared you from deploying Lync Server, I just wanted you to realize it’s not all “plug and play”. Do your homework, and you’re less likely to run into the dreaded “Poor quality” trap.