About networkingnerd

Tom Hollingsworth, CCIE #29213, is a network engineer that works with Cisco, HP, Microsoft, VMware, and various other technologies. Tom has been in the IT industry since 2002, and has been a nerd since he first drew breath.

Twitter, Please Stop Giving Me Things I Don’t Want

new-twitter-logo

Last week, Twitter confirmed that they will start injecting tweets from users you don’t follow into your timeline.  The collective cry from their user base ranged from outrage to a solid “meh”.  It seems that Twitter has stumbled onto the magic formula that Facebook has perfected: create a feature the users don’t care about and force it onto them.  Why?

Twitter Doesn’t Care About Power Users

Twitter has an interesting mix of users.  They reported earlier this year that 44% of their user base has never tweeted.  That’s a lot of accounts that were created for the purpose of reserving a name or following people in read-only mode.  That must concern Twitter.  Because people that don’t tweet can’t be measure for things like advertising.  They won’t push the message of a sponsored tweet.  They won’t add their voice to the din.  But what about those users that tweet regularly?

Power users are those that tweet frequently without a large follower base.  Essentially, everyone that isn’t a celebrity with a million followers or a non-tweeting account.  You know, the real users on Twitter.  The people that make typos in their tweets and actually check to see who follows them.  The ones that don’t have a “social media team” tweeting for them.  Nothing wrong with a team tweeting for a brand, but when they’re tweeting for a person it’s a little disconcerting.

Power users keep getting screwed by Twitter.  The API changes really hurt those that use clients other than the official ones.  Given that Twitter has killed most of it’s “official” clients in favor of pushing people to use the web, it makes you wonder what their strategy might be.  They are entirely beholden to their investors right now.  That means user signups and ad revenue.  And it means focusing on making the message widespread.  Why worry about placating the relatively small user base that uses your product when you can create a method for reaching millions with a unicast sponsored hashtag? Or by injecting tweets from people you don’t follow into your timeline?

The tweet injection thing is like a popup ad.  It serves the purpose of Twitter deciding to show you some tweets from other “users”.  Anyone want to bet those users will quickly start becoming corporate accounts? Perhaps they pay Twitter to ensure their tweets show up in a the timelines of a specific demographic.  It makes total sense when your users are nothing but a stream of revenue

Making Twitter Usable Again

I mentioned some things the other day that I think Twitter needs to do to make their service usable for power users again.  I wanted to expand on them a bit here:

The Unfollow Bug – Twitter has a problem with keeping followers.  For some reason, your account will randomly unfollow a user with no notification.  You usually don’t figure it out until you want to send them a DM or notice that they’ve unfollowed you and mention it.  It’s an irritating bug that’s been going on for years with no hope of resolution.  Twitter needs to sort this one out quickly.  As a side note, if you run a service that monitors people that have unfollowed you, consider adding a digest of users that I have unfollowed this week.  if the list doesn’t match those that I purposely unfollow, at least you know when you’ve been hit by this bug.

Links in Direct Messages – Twitter disabled the ability to send a link in a direct message a few months ago.  Their argument was that it cut down on spam.  The real reason was Twitter’s attempt to turn DMs into a instant message platform.  Twitter experimented with a setting that enabled DMs from users you don’t follow.  They pulled it before it went live due to user feedback.  One of the arguments was that spam accounts could bombard you with URLs that led to phishing attacks and other unsavory things.  Twitter responded by disabling links in DMs even though they removed the feature it was intended to protect.  It’s time for Twitter to give us this feature back.

Token Limits – This “feature” has to go.  Restricting 3rd party clients because they exist destroys the capabilities of your power users. I use a client because it gives me easy access to features I use all the time, like conversation views and muting.  I also don’t like sitting on the garish Twitter website and constantly refreshing to see new tweets.  I’d rather use some other client. Twitter has a love/hate relationship with non-official clients.  Mostly because those clients strip out ads and sponsored tweets.  They don’t let Twitter earn money from them.  Which is why Twitter is stamping them out for “replicating official client features” left and right.  Curiously enough, I’ve never heard about HootSuite being hit with user token limits.  But considering that a lot of Twitter’s favorite celebrities use it (or at least their social media teams do), I’m not shocked they’re on the exempt list.


Tom’s Take

I still find Twitter a very useful tool.  It’s not something that can just be set into automatic and left alone.  It takes curation and attention to make it work for you.  But it also needs help from Twitter’s side.  Instead of focusing on ways to make me see things I don’t care about from people I don’t want to follow, how about making your service work the way I want it to work.  I’m more like to use (and suggest) a service that works.  I barely check Facebook anymore because I’m constantly “fixing” their Top Posts algorithm.  Don’t turn your service into something I spend most of my time fixing.

The Great Tech Reaving

It seems as though the entire tech world is splitting up.  HP announced they are splitting the Personal Systems Group into HP, Inc and the rest of the Enterprise group in HP Enterprise.  Symantec is forming Veritas into a separate company as it focuses on security and leaves the backup and storage pieces to the new group.  IBM completed the sale of their x86 server business to Lenovo.  There are calls for EMC and Cisco to split as well.  It’s like the entire tech world is breaking up right before the prom.

Acquisition Fever

The Great Tech Reaving is a logical conclusion to the acquisition rush that has been going on throughout the industry for the past few years.  Companies have been amassing smaller companies like trading cards.  Some of the acquisitions have been strategic.  Buying a company that focuses on a line of work similar to the one you are working on makes a lot of sense.  For instance, EMC buying XtremIO to help bolster flash storage.

Other acquisitions look a bit strange.  Cisco buying Flip Video.  Yahoo buying Tumblr. There’s always talk around these left field mergers.  Is the CEO looking for synergy? Is there a hidden play that we’re unaware of? Sometimes that kind of thinking pays off.  Other times you end up with Zimbra.  More often than not, the company ends up writing down the assets of the acquired company and taking very little from the purchase.  Maybe not as big as the Autonomy write down, but even getting rid of Flip can make waves.

It makes a person wonder what the point of an acquisition is if it’s just going to wind up being an accounting charge later.  Is it a tax shelter?  A way to use up outstanding cash?  Maybe even a way to buy a particularly good developer and fold them into your organization to keep them out of a competitor’s hands?  The reasons are myriad but it appears that the fever is dying down.  And that might end up hurting innovation in the long term.

This Is Not An Exit Strategy

Think about the startup out there making a hot new technology.  They had their heart set on getting bought by a bigger company in the market.  Now, they just watched that company split off half of their business into a new company.  Cash is hard to find for a new acquisition.  Now the startup has to find a different way to monetize things.  Should we redouble our efforts to market the product? Get new investors? Go public?

I’ve said before that pinning your hopes on getting purchased isn’t the best way to run a business.  It’s like betting all your hopes on getting the winning numbers in the lottery.  It might happen, but the odds are against it.  Perhaps the end result of a market full of split companies will be a reevaluation of the idea of an exit strategy.  Rather than building a business for the sole purpose of being bought entrepreneurs will start building businesses to make products and sell them.  It’s a radical idea, but not so radical as to be unbelievable.  Just ask Hewlett and Packard.  Or Jobs and Wozniak. Or anyone else that didn’t have an exit strategy instead of a business plan.


Tom’s Take

Companies can be too big.  IBM has sold off most of what made it IBM.  Symantec and HP are in the process.  The next domino to fall will be EMC.  Then Cisco.  After that, the landscape will look much different.  But in a good way.  It’s like a stock split.  The same amount of knowledge is out there.  It’s just held differently.  That’s good for the industry because it forces the status quo to change.  New alliances, new partnerships, and new synergies can be found by upsetting the apple cart now and then.

API-jinks

Dastardly-vi

Network programmability is a very hot topic.  Developers are looking to the future when REST APIs and Python replaces the traditional command line interface (CLI).  The ability to write programs to interface with the network and build on functionality is spurring people to integrate networking with DevOps.  But what happens if the foundation of the programmable network, the API, isn’t the rock we all hope it will be?

Shiny API People

APIs enable the world we live in today.  Whether you’re writing for POSIX or JSON or even the Microsoft Windows API, you’re interacting with software to accomplish a goal.  The ability to use these standard interfaces makes software predictable and repeatable.  Think of an API as interchangeable parts for software.  By giving developers a way to extract information or interact the same way every time, we can write applications that just work.

APIs are hard work though.  Writing and documenting those functions takes time and effort.  The API guidelines from Microsoft and Apple can be hundreds or even thousands of pages long depending on which parts you are looking at.  They can cover exciting features like media services or mundane options like buttons and toolbars.  But each of these APIs has to be maintained or chaos will rule the day.

APIs are ever changing things.  New functions are added.  Old functions are deprecated.  Applications that used to work with the old version need to be updated to use new calls and methods.  That’s just the way things are done.  But what happens if the API changes aren’t above board?  What happens when API suddenly becomes “antagonistic programming interface”?

Losing My Religion

The most obvious example of a company pulling a fast one with API changes comes from Twitter.  When they moved from version 1.0 to version 1.1 of their API, they made some procedural changes on the backend that enraged their partners.  They limited the number of user tokens that third party clients could have.  They changed the guidelines for the way that things were to be presented or requested.  And they were the final arbiters of the appeals process for getting more access.  If they thought that an application’s functionality was duplicating their client functionality, they summarily dismissed any requests for more user tokens.

Twitter has taken this to a new level lately.  They’ve introduced new functionality, like pictures in direct messages and cards, that may never be supported in the API.  They are manipulating the market to allow their own first party apps to have the most functionality.  They are locking out developers left and right and driving users to their own products at the expense of developers they previously worked arm-in-arm with.  If Twitter doesn’t outright buy your client and bury it, they just wait until you’ve hit your token limit and let you suffocate from your own popularity.

How does this translate to the world of network programmability?  Well, we are taking for granted that networking vendors that are exposing APIs to developers are doing it for all the right reasons.  Extending network flexibility is a very critical thing.  So is reducing complexity and spurring automation.  But what happens when a vendor starts deprecating functions and forcing developers to go back to the drawing board?

Networking can move at a snail’s pace then fire right up to Ludicrous Speed.  The OpenFlow release cycle is a great example of software outpacing the rest of technology.  What happens when API development hits the same pace?  Even the most agile development team can’t keep pace with a 3-6 month cycle when old API calls are deprecated left and right.  They would just throw their hands up and stop working on apps until things settled down.

And what if the impetus is more sinister?  What if a vendor decides to say, “We’re changing the API calls around.  If you want some help rewriting your apps to function with the new ones, you can always buy our services.” Or if they decide to implement your functionality in their base system?  What happens when a networking app gets Sherlocked?


Tom’s Take

APIs are a good and noble thing.  We need them or else things don’t work correctly.  But those same APIs can cause problems if they aren’t documented correctly or if the vendor starts doing silly things with them.  What we need is a guarantee from vendors that their APIs are going to be around for a while so we can develop apps to help their networking gear work properly.  Microsoft wouldn’t be where it is today without robust support for APIs that has been consistent for years.  Networking needs to follow the same path.  The fewer hijinks with your APIs, the better your community will be.

Rome Wasn’t Software Defined In A Day

Everywhere you turn, people are talking about software defined networking.  The influence can be felt in every facet of the industry.  Major players are trying to come to grips with the shift in power.  Small vendors are ramping up around ideas and looking to the future.  Professionals are simultaneously excited for change and fearful of upsetting the status quo.  But will all of these things happen overnight?

Not Built In A Day, But Laying Bricks Every Hour

The truth of SDN is that it’s going to take some time for all the pieces to fall into place.  Take a look at the recent Apple Pay launch.  Inside of a week, it has risen to become a very significant part of the mobile payment industry, even if the installed base of users is exclusive to iPhone [6,6+] owners.  But did this revolution happen in the span of a couple of days?

Apple Pay works because Apple spent months, if not years, designing the best way to provide transactions from a phone.  It leverages TouchID for security, a concept introduced last year.  It uses Near Field Communication (NFC) readers, which have been in place for a couple of years.  I even talked about NFC three years ago.  That means the technology to support Apple Pay has been in place for a while.

That kind of support structure is needed to make SDN work the way we want it to.  There’s no magic wand that will convert your infrastructure to SDN overnight.  There is no SDNecronomicon to reference for solving scaling issues or interoperability concerns.  What’s required is the hard work of taking the ideas and processes around SDN and implementing them today.

SDN feels like a radical shift to traditional networking because it’s a foreign concept.  If you had told the first generation iPhone users their device would be a application computer with the capability to pay for purchases wirelessly they would have laughed at you and told you it was a fantasy.  That sufficiently advanced technology was beyond their understanding at the time.

SDN is no different.  The steps being taken today to solve traditional networking problems will feel antiquated in four to five years.  But that foundation must be laid in order to make SDN work in the future.  SDN won’t transform the industry overnight, but we have to keep making advances and pushing forward to make the important gains no matter how small they are.

Not Built In A Day, But It Burned In One

The fear of SDN leads to the dark side of standards adoption.  Arguments. In-fighting. Posturing. Interests making decisions not because they are right for customers but because they protect market share.  If SDN fails in the long term, it will be because of these dark elements and not a technological constraint.

Nothing is immune to politics.  Linux has been more or less standardized for years.  Yet tech advances are still hotly debated.  Go mention systemd to your local Linux hacker and prepare for the onslaught of discussion.  Linux has had much less pressure from these kinds of discussions by virtue of the core kernel being very stable and maintained by a small team.  SDN is very different.

The competing ideas around SDN drive innovation, but also threaten it.  The industry will eventually standardize on OpenDaylight for their controller, much like the server industry standardized on Linux for appliances.  But will that same consensus lead to stagnation? Will innovation simply happen as vendors attempt to modify ODL just enough to make their offering look superior?  Before you say that it’s impossible go and find a reference TRILL implementation.

SDN will succeed because the momentum behind it won’t allow it to fail.  But much like Rome, we need to build SDN with the proper architecture.  Simply laying bricks haphazardly won’t fix our problems.  If the infrastructure is bad enough, we may even need our own Nero to “fix” things again.  Momentum without direction is a useless force.  We need to ensure that SDN is headed in the right direction where it benefits customers and users first.  Profit margins are secondary to that.


Tom’s Take

An idea can transform an industry.  A simple thought about making things better can drag the community out of stagnation and into a Renaissance.  That we are witness to an industry shift is undeniable at this point, especially given that so many things are becoming “software defined”.  However, we must face the truth that this little hobby project won’t produce results overnight.  Hard work and planning will win the day.  Rome went from being a village among hills to the largest power in the Western world.  But that didn’t happen overnight.  The long game of SDN needs to be played one move at a time.  And the building of the SDN empire will take more than a single day.

The Atomic Weight of Policy

Helium-atom

The OpenDaylight project put out a new element this week with their Helium release.  The second release is usually the most important, as it shows that you have a real project on your hands and not just a bunch of people coding in the back room to no avail.  Not that something like that was going to happen to ODL.  The group of people involved in the project have the force of will to change the networking world.

Helium is already having an effect on the market.  Brocade announced their Vyatta Controller last week, which is based on Helium code.  Here’s a handy video as well.  The other thing that Helium has brought forth is the ongoing debate about network policy.  And I think that little gem is going to have more weight in the long run than anything else.

The Best Policy

Helium contains group-based policies for making groups of network objects talk to each other.  It’s a crucial step to bring ODL from an engineering hobby project to a full-fledged product that can be installed by someone that isn’t a code wizard.  That’s because most of the rest of the world, including IT people, don’t speak in specific terms with devices.  They have an idea of what needs to be done and they rely on the devices to implement that idea.

Think about a firewall.  When is the last time you wrote a firewall rule by hand? Unless you are a CLI masochist, you use the GUI to craft a policy that says something like “prevent DNS queries from any device that isn’t a DNS server (referenced by this DNS Server object list)”.  We create those kinds of policies because we can’t account for every new server appearing on the network that wants to make a DNS query.  We block the ones that don’t need to be doing it, and we modify the DNS Server object list to add new servers when needed.

Yet, in networking we’re still playing with access lists and VLAN databases.  We must manually propagate this information throughout the network when updates occur.  Because no one relies on VTP to add and prune information in the network.  The tools we’ve been using to do this work are archaic and failure-prone at best.

Staying Neutral

The inclusion of policy components of Helium will go a long way to paving the road for more of the same in future releases.  Of course, there is already talk about Cisco’s OpFlex and how it didn’t make the cut for Helium despite being one of the most dense pieces of code proposed for ODL.  It’s good that Cisco and ODL both realized that putting out code that wasn’t ready was only going to hurt in the long run.  When you’ve had seven or eight major releases, you can lay an egg with a poorly implemented feature and it won’t be the end of the world.  But if you put out a stinker in the second release, you may not make it to the third.

But this isn’t about OpFlex.  Or Congress. Or any other policy language that might be proposed for ODL in the future.  It’s about making sure that ODL is a policy-driven controller infrastructure.  Markus Nispel of Extreme talked about SDN at Wireless Field Day 7.  In that presentation, he said that he thinks the industry will standardize on ODL as the northbound interface in the network.  For those not familiar, the northbound interface is the one that is user-facing.  We interact with the northbound controller interface while the southbound controller interface programs the devices.

ODL is making sure the southbound interface is OpenFlow.  What they need to do now is ensure the northbound interface can speak policy to the users configuring it.  We’ve all heard the rhetoric of “network engineers need to learn coding” or “non-programmers will be out of a job soon”.  But the harsher reality is that while network programmers are going to be very busy people on the backend, the day-to-day operations of the network will be handled by different teams.  Those teams don’t speak IOS, Junos, or OpenFlow.  They think in policy-based thoughts.

Ops teams don’t want to know how something is going to work when implemented.  They don’t want to spend hours troubleshooting why a VLAN didn’t populate only to find they typoed the number.  They want to plug information into a policy and let the controller do the rest.  That’s what Helium has started and what ODL represents.  An interface into the network for mortal Ops teams.  A way to make that work for everyone, whether it be an OpFlex interface into Cisco APIC programming ACI or a Congress interface to an NSX layer.  If you are a the standard controller, you need to talk to everyone no matter their language.

Tom’s Take

ODL is going to be the controller in SDN.  There is too much behind it to let it fail.  Vendors are going to adopt it as their base standard for SDN.  They may add bells and whistles but it will still be ODL underneath.  That means that ODL needs to set the standard for network interaction.  And that means policy.  Network engineers complain about fragility in networking and how it’s hard to do and in the very same breath say they don’t want the CLI to go away.  What they need to say is that policy gives everyone the flexibility to create robust, fault-tolerant configurations with a minimum of effort while still allowing for other interface options, like CLI and API.  If you are the standard, you can’t play favorites.  Policy is going to be the future of networking interfaces.  If you don’t believe that, you’ll find yourself quickly crushed under the weight of reality.

SDN Use Case: Content Filtering

K-12 schools face unique challenges with their IT infrastructure.  Their user base needs access to a large amount of information while at the same time facing restrictions.  While it does sound like some corporate network policies, the restrictions in the education environment are legal in nature.  Schools must find new ways to provide the assurance of restricting content without destroying their network in the process.  Which lead me to ask: Can SDN Help?

Online Protection

The government E-Rate program gives schools money each year under Priority 1 funding for Internet access.  Indeed, the whole point of the E-Rate program is to get schools connected to the Internet.  But we all know the Internet comes with a bevy of distractions. Many of those distractions are graphic in nature and must be eliminated in a school.  Because it’s the law.

The Children’s Internet Protection Act (CIPA) mandates that schools and libraries receiving E-Rate funding for high speed broadband Internet connections must filter those connections to remove questionable content.  Otherwise they risk losing funding for all E-Rate services.  That makes content filters very popular devices in schools, even if they aren’t funded by E-Rate (which they aren’t).

Content filters also cause network design issues.  In the old days, we had to put the content filter servers on a hub along with the outbound Internet router in order to insure they could see all the traffic and block the bad bits.  That became increasing difficult as network switch speeds increased.  Forcing hundreds of megabits through a 10Mbit hub was counterproductive.  Moving to switchport mirroring did alleviate the speed issues, but still caused network design problems.  Now, content filters can run on firewalls and bastion host devices or are enabled via proxy settings in the cloud.  But we all know that running too many services on a firewall causes performance issues.  Or leads to buying a larger firewall than needed.

Another issue that has crept up as of late is the use of Virtual Private Networking (VPN) as a way to defeat the content filter.  Setting up an SSL VPN to an outside, non-filtered device is pretty easy for a knowledgeable person.  And if that fails, there are plenty of services out there dedicated to defeating content filtering.  While the aim of these service is noble, such as bypassing the Great Firewall of China or the mandated Internet filtering in the UK, they can also be used to bypass the CIPA-mandated filtering in schools as well.  It’s a high-tech game of cat-and-mouse.  Blocking access to one VPN only for three more to pop up to replace it.

Software Defined Protection

So how can SDN help?  Service chaining allows traffic to be directed to a given device or virtual appliance before being passed on through the network.  This great presentation from Networking Field Day 7 presenter Tail-f Networks shows how service chaining can force traffic through security devices like IDS/IPS and through content filters as well.  There is no need to add hubs or mirrored switch ports in your network.  There is also no need to configure traffic to transit the same outbound router or firewall, thereby creating a single point of failure.  Thanks to the magic of SDN, the packets go to the filter automatically.  That’s because they don’t really have a choice.

It also works well for providers wanting to offer filtering as a service to schools.  This allows a provider to configure the edge network to force traffic to a large central content filter cluster and ensure delivery.  It also allows the service provider network to operate without impact to non-filtered customers.  That’s very useful even in ISPs dedicated to education institutions, as the filter provisions for K-12 schools don’t apply to higher education facilities, like colleges and universities.  Service chaining would allow the college to stay free and clear while the high schools are cleansed of inappropriate content.

The VPN issue is a thorny one for sure.  How do you classify traffic that is trying to hide from you?  Even services like Netflix are having trouble blocking VPN usage and they stand to lose millions if they can’t.  How can SDN help in this situation? We could build policies to drop traffic headed for known VPN endpoints.  That should take care of the services that make it easy to configure and serve as a proxy point.  But what about those tech-savvy kids that setup SSL VPNs back home?

Luckily, SDN can help there as well.  Many unified threat management appliances offer the ability to intercept SSL conversations.  This is an outgrowth of sites like Facebook defaulting to SSL to increase security.  SSL intercept essentially acts as a man-in-the-middle attack.  The firewall decrypts the SSL conversation, scans the packets, and re-encrypts it using a different certificate.  When the packets come back in, the process is reversed.  This SSL intercept capability would allow those SSL VPN packets to be dropped when detected.  The SDN component ensures that HTTPS traffic is always redirected to a device that and do SSL intercept, rather than taking a path through the network that might lead to a different exit point.

Tom’s Take

Content filtering isn’t fun.  I’ve always said that I don’t envy the jobs of people that have to wade through the unsavory parts of the Internet to categorize bits as appropriate or not.  It’s also a pain for network engineers that need to keep redesigning the networking and introducing points of failure to meet federal guidelines for decency.  SDN holds the promise of making that easier.  In the above Tail-f example, the slide deck shows a UI that allows simple blocking of common protocols like Skype.  This could be extended to schools where student computers and wireless networks are identified and bad programs are disallowed while web traffic is pushed to a filter and scrubbed before heading out to the Wild Wild Web.  SDN can’t solve every problem we might have, but if it can make the mundane and time consuming problems easier, it might just give people the breathing room they need to work on the bigger issues.

Why is Lync The Killer SDN Application?

lync-logo

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.