The key to showing the promise of SDN is to find a real-world application to showcase capabilities. I recently wrote about using SDN to slice education networks. But this is just one idea. When it comes to real promise, you have to shelve the approach and trot out a name. People have to know that SDN will help them fix something on their network or optimize an troublesome program. And it appears that application is Microsoft Lync.
MIssing Lync
Microsoft Lync (neè Microsoft Office Communicator) is a software application designed to facilitate communications. It includes voice calling capability, instant messaging, and collaboration tools. The voice part is particularly appealing to small businesses. With a Microsoft Office 365 for Business subscription, you gain access to Lync. That means introducing a voice soft client to your users. And if it’s available, people are going to use it.
As a former voice engineer, I can tell you that soft clients are a bit of a pain to configure. They have their own way of doing things. Especially when Quality of Service (QoS) is involved. In the past, tagging soft client voice packets with Cisco Jabber required setting cluster-wide parameters for all clients. It was all-or-nothing. There were also plans to use things like Cisco MediaNet to tag Jabber packets, but this appears to be an old method. It was much easier to use physical phones and set their QoS value and leave the soft phones relegated to curiosities.
Lync doesn’t use a physical phone. It’s all software based. And as usage has grown, the need to categorize all that traffic for optimal network transmission has become important. But configuring QoS for Lync is problematic at best. Microsoft guidelines say to configure the Lync servers with QoS policies. Some enterprising users have found ways to configure clients with Group Policy settings based on port numbers. But it’s all still messy.
A Lync To The Future
That’s where SDN comes into play. Dynamic QoS policies can be pushed into switches on the fly to recognize Lync traffic coming from hosts and adjust the network to suit high traffic volumes. Video calls can be separated from audio calls and given different handling based on a variety of dynamically detected settings. We can even guarantee end-to-end QoS and see that guarantee through the visibility that protocols like OpenFlow enable in a software defined network.
SDN QoS is very critical to the performance of soft clients. Separating the user traffic from the critical communication traffic requires higher-order thinking and not group policy hacking. Ensuring delivery end-to-end is only possible with SDN because of overall visibility. Cisco has tried that with MediaNet and Cisco Prime, but it’s totally opt-in. If there’s a device that Prime doesn’t know about inline, it will be a black hole. SDN gives visibility into the entire network.
The Weakest Lync
That’s not to say that Lync doesn’t have it’s issues. Cisco Jabber was an application built by a company with a strong networking background. It reports information to the underlying infrastructure that allows QoS policies to work correctly. The QoS marking method isn’t perfect, but at least it’s available.
Lync packets don’t respect the network. Lync always assumes there will be adequate bandwidth. Why else would it not allow for QoS tagging? It’s also apparent when you realize that some vendors are marking packets with non-standard CoS/DSCP markings. Lync will happily take override priority on the network. Why doesn’t Lync listen to the traffic conditions around it? Why does it exist in a vacuum?
Lync is an application written by application people. It’s agnostic of networks. It doesn’t know if it’s running on a high-speed LAN or across a slow WAN connection. It can be ignorant of the network because that part just gets figured out. It’s a classic example of a top-down program. That’s why SDN holds such promise for Lync. Because the app itself is unaware of the networks, SDN allows it to keep chugging along in bliss while the controllers and forwarding tables do all the heavy lifting. And that’s why the tie between Lync and SDN is so strong. Because SDN makes Lync work better without the need to actually do anything about Lync, or your server infrastructure in general.
Tom’s Take
Lync is the poster child for bad applications that can be fixed with SDN. And when I say poster child, I mean it. Extreme Networks, Aruba Networks, and Meru are all talking about using SDN in concert with Lync. Some are using OpenFlow, others are using proprietary methods. The end result is making a smarter network to handle an application living in a silo. Cisco Jabber is easy to program for QoS because it was made by networking folks. Lync is a pain because it lives in the same world as Office and SQL Server. It’s only when networks become contentious that we have to find novel ways of solving problems. Lync is the use case for SDN for small and medium enterprises focused primarily on wireless connectivity. Because making Lync behave in that environment is indistinguishable from magic, at least without SDN.
If you want to see some interesting conversations about Lync and SDN, especially with OpenFlow, tune into SDN Connect Live on September 18th. Meru Networks and Tech Field Day will have a roundtable discussion about Lync, featuring Lync experts and SDN practitioners.
The Networking Nerd 
Pingback: Why is Lync The Killer SDN Application?
Nice Article !
Assuming you’re running an enterprise network where a GPO structure exists and client machines are corporately owned, I would argue that applying QoS to Lync is easy. Creating the QoS GPO is a straight forward task that your GPO implementer should be able to handle. Microsoft has provided documentation for this which can easily be found online. The telecom just needs to provide the appropriate Lync (voice, video, desktop sharing, file transfers) port ranges and DSCP values to the implementer. If you are not in an environment where you have this type of control, then I agree that SDN is absolutely necessary for prioritization of Lync traffic.
One instance where SDN for Lync works particularly well is on Aruba wi-fi. Since the Aruba controllers detect the various types of Lync traffic, they can write/re-write DSCP markings on the Lync packets whether it is voice, video, desktop sharing, or file transfers. This is helpful in BYOD situations where you can’t apply QoS policies to the machine so the Lync traffic will not have any QoS, or you’re in a situation where you have to re-write Lync DSCP markings. A good SDN use case for the latter is when Windows 7 is configured with a Lync QoS policy to mark voice traffic with DSCP 46. Over the air, Windows translates DSCP 46 to AC VI, rather than AC VO, so proper airtime values (TX duration & AIFS) are not used when the frame is transmitted to the AP. To correct this, you must change the Lync QoS policy to mark Lync voice traffic with DSCP 47 or higher; Aruba recommends DSCP 56. Now, you have proper QoS over the air from the machine to the AP, but your Lync traffic is no longer tagged EF. Once the AP receives the frame it encapsulates the packet (DSCP 56 still intact) in GRE, sets a DSCP value of 46 on the packet to controller, and off it goes. The controller receives the packet, decapsulates and unencrypts it, recognizes the payload as Lync traffic, changes the DSCP marking from 56 to 46, and the packet is then sent on its way through the wired network with proper QoS. This is the magic of Lync SDN at work.
#FULL DISCLOSURE – I WORK FOR HP NETWORKING. All comments and opinions are my own. :
Hey Tom,
Warning – Shameless Product Plug below.
First, let me say it’s great to see someone talking about SDN in a context beyond Network Virtualization, Overlays and OpenStack. There’s a much bigger set of problems out there that SDN can be used to help address and the more we can do as an industry to evangelize the possibilities that SDN can only be great for all of us.
Speaking on behalf of myself, I think you’re right. Lync is a great example of a killer application which is ripe for SDN driven network performance improvement. As a recovering voice engineer myself, I understand exactly what you mean about about the challenges of provisioning QoS in a modern data network. Having the application actually request service from the network, and having the network being able to respond appropriately almost seems like magic.
It’s nice to see that other vendors are starting to follow the path that HP started blazing back in 2013. ( http://techfieldday.com/video/continuing-the-hp-networking-roundtable-with-tech-field-day-at-onug/ ).
HP actually released the Lync Network Optimizer product early this 2014, so this is not something that customer have to wait for.
For anyone interested:
http://h17007.www1.hp.com/us/en/networking/products/network-management/Network_Optimizer_SDN_Application_Series/index.aspx
Interesting times for sure!
See you in New York!
@netmanchris
I think we all agree that marking should be done by Lync itself, based on Lync-specific policies (e.g. calling the fire dept. gives you more priority than calling home).
Thus, the fact that you (an expert I recognize) see Lync as the killer application makes me think that there is no killer application at all. The use case you describe is an ugly workaround to an important feature missing from an application.
I don’t need more complicated, multilevel, multivendor workarounds.
Bergonz
Hi Michelle,
The problem with having the application do the marking is that applications in general can’t be trusted. Not sure if you remember the browser wars, but there was a time when Internet Explorer ( maybe IE 5.5? ) actually marked itself with a IPP of 5 to try and take advantage of configurations of the network to squeeze just a little bit more performance than Netscape. Fact is that as a network team, tools like Deep Packet Inspection, NBAR,, etc… are all designed because the applications generally don’t mark their traffic and often can’t be trusted when they do.
I agree 100% that Lync is the place where the policy should be defined. Do you want to give emergency calls? priority? No problem. Do you want to give the CEO’s corp. video stream priority over all the other video calls happening? We can do that.
The point I think is that the lync 2.0 API actually gives us a fairly robust signalling mechanism for Lync and the network to talk to each other which allows us, the network team to give the ability to one specific application that we understand and trust the ability to define it’s QoS markings across the network.
The signalling layer between the apps and the network is what’s been missing. Although we’ve become very good over the years at guessing what the apps want, wouldn’t it just be nicer to allow them to ask nicely?
We can still always say “no”.
@netmanchris
Sorry for the double post. Just had another thought. 🙂
Think of this in terms of a typical Cisco voice deployment. You configure the edge of the network to extend the trust boundary to include the phones, This means that you will allow the client ( IP phone ) to mark and trust that their markings are inline with business policy ( give X type of application traffic some specific treatment on the network ).
Think about this in the context of Lync which is usually running as a soft client on a PC. How do we extend the trust boundary to include just the Lync traffic coming from that particular PC? Because of the nature of the trust mechanisms we have at our disposal today, it’s kinda all or nothing.
If we trust the lync app, we then trust eveything else coming from that device opening up the network to potential abuse by individuals who want to get a free ride on the DSCP EF speed train.
By allowing the network and the lync server to talk directly to each other, the lync server can tell the network exactly what hosts are about to talk and what level of QoS coloring/marking should be applied.
The difference betwen this method and traditional DPI methods is that we’re not guessing anymore. We KNOW that this ip/udp/rtp traffic is actually a voice stream and we KNOW that it belongs to THOLLINGSWORTH active directory account so we need to give it preference.
I think this is going to become the model for a lot more app-network integrations in the very short-term future.
@netmanchris
Pingback: Why is Lync The Killer SDN Application? | The Networking Nerd | JC's Blog-O-Gibberish