The other week I attended the "Software Defined Networking 2013" conference in London.  This is a UK-based event for the discussion of SDN, OpenFlow and Network Virtualisation Solutions from a strategic perspective.  There were quite a few interesting perspective s I picked up at this conference.  In particular, the conference for me reinforced the potential of SDN -but if you apply it to the wrong problem, you may not get the return you hope for!

Top of mind for me, then, coming out of this conference was a demo of "What SDN Can Do For You" from one of our competitors.  At best, the phrase "using a sledge hammer to crack a nut" comes to mind.

The demo came from our friends in Palo Alto, who once (boldly but incorrectly!) predicted  that "Cisco UCS would be dead a year after launch". They gave a SDN-focused demo that, when I "peeled back the onion", didn't demonstrate a compelling SDN use case.  Rather, it convinced me that if you have this particular problem as illustrated in their demo, you don't need SDN: you need a new vendor!

Our competitor's demo video used Microsoft Lync to demonstrate the effect of a congested network.  It showed 2 views of desktop sharing with Microsoft Lync.  With the "normal" (non-SDN) network, we saw the presenter changing a slide, and (by virtue of the video of their demo), we simultaneously saw the view experienced by the remote viewer.  It took 5 seconds, maybe more, for the received content to be correctly presented to the remote viewer on his/her PC.  You have to agree -this is a very poor end user experience.

Then they showed the effect of inserting SDN devices and an appropriate SDN app into this scenario. Lo and behold, the act of desktop sharing was instantaneous -the kind of end user experience you would expect. The SDN app, working with an OpenFlow controller, had performed some kind of traffic classification or bandwidth allocation to ensure that the Microsoft Lync desktop sharing feature performed in real time.

First, a comment before I critique this scenario: I'm going to focus on what the presenter was discussing -how SDN can "fix" your Microsoft Lync desktop sharing problems.  Clearly there are other potential benefits that I won't mention (which to be fair our competitor didn't mention either during  the demo) . In particular, if you have the correct type of SDN app and assuming your controller supports network wide QoS configuration, this app could (potentially) reconfigure QoS at the entire network level, as opposed to the often manual process of configuring QoS on a port by port basis, which you may need to do in your environment today, assuming you aren't using a good NMS and/or router config update tool which would provide a similar level of productivity to the SDN approach.  So forgive me while I ignore these potential productivity benefits for now.

At first glance, when you see the impact of this SDN demo, you may be tempted to think "Wow, when can I get SDN into my network?!" However, as I watched this demo, I was thinking, "Why don't I see such lousy network performance effects when I am working?"

Of course in Cisco, we use Cisco networking and Cisco Webex.  I have to say this here: as part of a distributed global team, Cisco's collaboration product suite has changed my life -from living life on a Boeing 777 to living life on Cisco Webex and TelePresence!  (And my travel has reduced from 100,000+ miles per year to ~ 300 miles this year!)  And when I work from home, even over my poor home broadband (I subscribe to a 20 Mbit/s DSL service but reality at home is I get ~ 3Mbit/s download speed, and around 400Kbit/sec upload), I can easily run Cisco Webex, my Cisco IP phone, 2 laptops, my iPhone and even the amazing Cisco Jabber for TelePresence. All at once, and I have good performance on all devices (thanks in part to the wonderful Cisco Virtual Office solution).   And when I use Webex desktop sharing, there is practically never -yes never -any delay in displaying desktops and presentations over Webex.  So you can understand why I was puzzled by our competitor's SDN demo.

So I had a chat with my good colleague and fellow "RAB" cyclist James MacDonald in my local office, one of our Collaboration experts.   It seems that Microsoft Lync is a bit of a bandwidth hog.  In fact Lync we understand requires ~15 times as much bandwidth per desktop sharing session as a corresponding Cisco Webex session.  Cisco uses a protocol called "Binary Flow Control Protocol", or BFCP, defined specifically for video transport -which appeared as RFC 4582 in 2006, whereas Lync uses a more proprietary mechanism.

Now, let's go back to the conference demo ... clearly SDN is being used here to re-prioritize the bandwidth usage (e.g. though QoS and traffic classification) in this "demo network" so that Microsoft Lync gets the bandwidth it requires. So to my question:  Is this a good thing?   Is this a good use case for SDN?  Or is it a "band aid" for a poorly designed application and a poorly designed network?

What about the implications if this was executed on a large scale?  Well, this SDN approach may result in significant reallocation of network bandwidth towards desktop sharing, leaving less bandwidth for (as an example) the customer-facing web server farm or high definition video conferencing.  Is this a good thing?  Will this SDN application impact higher priority users of the network adversely?  Is this SDN use case effectively using a sledge hammer to crack a nut?!

So ... getting to the point ... In this example, is it SDN you need?  Or should you be looking for a new networking and web conferencing partner?! SDN has great potential, however if you apply it to the wrong problem, it may end up costing you more and/or you won't get the returns you hope for.

Cisco, unlike some of our competitors, has invested heavily in R&D over our history.  We have invested broadly in both traditional networking and SDN.  We invest both in the technologies (Cisco onePK API, OpenFlow, NfV, network virtualization, and ACI) as well as in design and deployment best practice methodologies, as delivered by Cisco Services.  With our "No Technology Religion" mantra, we will advise you on a particular technology option only when itgenuinely solvesyour networking challenges and business goals.   We are equally happy helping you design SDN-based or hybrid networks as we are helping you with traditional networks -our approach is whatever is best for you, our customer.  And if you engage Cisco Services to help you with your SDN investigations, rest assured we will not advise you to use a sledge hammer to crack a nut!

PS:  If you would like to read more about high value use cases of SDN, I recommend you read the recently published and well-received book "SDN: Software Defined networking", by Tom Nadeau and Ken Gray.  Tom -a former employee of both Cisco and Juniper -is a good friend.  Ken was part of the Cisco CRS-1 design team. I can't think of anyone better to write a vendor-independent view of current SDN status and evolution.