The cat coughs: kack, kack.

You call this a haiku on

Bandwidth policies?

 

Here at Microsoft we love acronyms. Take Windows Management Instrumentation, for example. Say "Windows Management Instrumentation" around Microsoft, and hardly anyone will know what you're talking about. Say "WMI," however and – well, if you do that you still won't find many people who know what you're talking about.

 

That's because we Microsofties not only love acronyms but we love to pronounce acronyms as if they were real words. No one at Microsoft says W-M-I, spelling out each letter; everyone says "wimmie" instead. Quality of Service (QoS)? What the -- oh, you must mean "kwoss." Help files, those files that have the .CHM file extension? Hmmm, any chance you're referring to "chum" files? When Microsoft employees first went to school they didn't learn their ABCs. Instead, they learned their "ab-sees."

 

Well, most of us anyway.

 

Of course, Microsoft being Microsoft, there are also times when we don't love acronyms. For example, people all over the world refer to Office Communications Server 2007 R2 as "OCS." Not at Microsoft, though: here we refer to Office Communications Server 2007 R2 as, well, Office Communications Server 2007 R2. Why don't we use an acronym when referring to Office Communications Server 2007 R2? To paraphrase Alfred Lord Tennyson, "Ours is not to reason."

 

Trivia note. In addition to acronyms, here are a few other phrases you're likely to hear around Microsoft:

 

·         We need to find out who has skin in the game

·         Stakeholders

·         Rhythm of the business

·         At the end of the day

·         Grow the business

·         Low-hanging fruit

·         Send me a Sched-Plus and we'll get together

 

The latter, by the way, is a reference to Microsoft Schedule Plus, a scheduling program that hasn’t been around since 1997. Gone, but definitely  not forgotten.

 

Call Admission Control, the new bandwidth management feature introduced in Microsoft Lync Server 2010, left us in a quandary, however. There's an obvious acronym for Call Admission Control, an acronym that's used throughout the telecommunications industry: CAC. However, and as one editor put it, CAC "… sounds like a cat coughing up a hairball." (Always an issue when you pronounce acronyms instead of spelling them out.) After some internal debate, it was decided that we could use CAC instead of always having to spell out "Call Admission Control." In turn, those of us at the Lync Server PowerShell blog immediately began trying to write a haiku that featured both bandwidth management and a cat coughing up a hairball.

 

Note. We wanted to get there first, before any other haiku writer could come up with a similar haiku.

 

We won't try to explain how Call Admission Control works in Lync Server 2010, at least not today. For one thing, that's too big a job to tackle in a haiku. (We're looking into the possibility of using iambic pentameter as a way to explain bandwidth management.) For another, Rui Maximo, Subbu Chandrasekaran, and Thomas Binder have already written an article that provides a good introduction to Call Admission Control. Instead, we'll simply say that Call Admission Control enables you to place constraints on the amount of bandwidth that can be taken up by audio/video calls. Equally important, you can place different constraints on different network segments. For example, do you have a good, reliable, high-speed connection between Redmond and Boston? Excellent; then you can allocate a large amount of bandwidth for audio/video traffic over that connection. But is the connection between Redmond and Phoenix somewhat less than optimal? No problem; just limit the amount of bandwidth that can be used for calls between Redmond and Phoenix. You can place a limit on the bandwidth allocated for a single call, and/or you can place a limit on the total bandwidth allocated for all concurrent calls.

 

Clarification. In other words, you could say that any one call has a limit of 200 kilobytes per second (kbps); anything higher than that and the call doesn't go through. In addition, you might configure things so that you can have as many simultaneous calls going on as you want, provided that the cumulative bandwidth used by those calls stay below 5000 kbps. At 200 kbps per call, that means you could have 25 simultaneous calls traversing this network segment. CAC (which you'll probably always pronounce as "kack" from now on, won't you?) helps you prevent users from placing calls that could seriously degrade network connections.

 

Bandwidth constraints are managed by using bandwidth policies. In turn, these policies can be configured by creating a policy profile and then adding a network bandwidth policy to that profile. (These polices are created by using the New-CsNetworkBWPolicy cmdlet.) Here's an example of New-CsNetworkBWPolicy; in this case, we have a command that creates a new network bandwidth policy ($ap) and then adds that policy to an existing policy profile (LowBWProfile):

 

$ap = New-CsNetworkBWPolicy -BWLimit 2000 -BWSessionLimit 300 -BWPolicyModality audio

Set-CsNetworkBandwidthPolicyProfile -Identity LowBWProfile -BWPolicy @{add=$ap}

 

For more information, take a peek at the Lync Server PowerShell help for New-CsNetworkBWPolicy:

 

Get-Help New-CsNetworkBWPolicy –full | More

 

Oh, and be sure to take a look at the article Lync 2010 Bandwidth Management (CAC) by Jens Trier Rasmussen.

 

That's all we have for today. TTFN!