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 it genuinely solves your 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.
>> 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.
Stephen, I believed you nailed this argument! Great post. Thanks!
Omer
Thanks Omer!
Hi Stephen,
Nice post Looks for me “HPs view of SDN”, Potential used case for SDN would be lower cost to keep operating networking devices.
Intelligent networks provide best out of them during uncertainty caused by (Active path failover, Fast convergence during link failures, line card failures and hundreds of used cases),for this to happen every networking device needs to be intelligent and program themself during uncertainty, todays networking devices do this at every node and they keep evolving.
SDNs changes networking concept by centralising network information and programing all nodes via controller and this results effectively lower cost of devices said by SDN gurus. Does SDN based used cases can handle uncertainty as traditional devices do?
Hi Ravi – yes it is a bit 🙂 [this kind of write up!]
Let’s debate 🙂 I don’t see “lower cost” as a use case. Sure it’s a good and worthy business objective, but is it a use case? network path failure is a good example of a use case.
Good question whether and how SDN solves such issues. If we separate out some of the variants of SDN …..
(1) As I understand, OpenFlow v1.0 did not have controller resilience built in to the spec (I could be wrong here on the details but I do recollect at least one pretty major resiliency feature was not there in the 1.0 spec). Of course this is being addressed as versions come out however OpenFlow still IMHO has to be proven in large scale enterprise and SP networks under the variety of use cases that customers require (for example I’d argue that the well published Google use cases [search as main use case] don’t need to address the wide variety of challenges we see in many networks today).
(2) Cisco ONE Platform Kit API. This is an API to existing network equipment and features – so you have all your existing resiliency feature, proven, if you follow this route!
(3) Virtual Overlays – again time will tell if these networks have all the resiliency features required. I will write a blog soon on some of the troubleshooting challenges in these networks – this will show you that some virtual networks have resiliency challenges today!
Thanks again for the question, good questions, happy to debate (and apologies for delay in replying, due to the holiday period)