Interestingly, this question was asked during a discussion I had at the Open Networking Summit in April with Mike Fratto, an analyst with Current Analysis, and a couple of other people.  And I could not stop thinking about it.  I even asked many people this same question over the last month.  Since the individual responses and the discussions that followed have been so varied, I thought I should post my cumulative thoughts on them.

With Ethernet getting faster and switches increasing in port density, the idea of infinite bandwidth is not that abstract. In fact, as the entire ecosystem of components and engineered systems gets better integrated, the idea of higher non-blocking density with declining price per port continues to follow an almost Moore’s Law model whereby there is a price performance expectation that improves in a predictable way.

So if we are able to count on progressively lower-price-per-bit thinking, why do we need software defined networking (SDN)?  Why is SDN such a hot topic despite this trending?

Most SDN definitions focus on external control planes delivering external programmability to increase business agility. As we have blogged previously, the idea of reducing costs by more easily and reliably moving things around is really the beachhead that SDN must take today to gain mainstream acceptance, whether those things be virtual machines or service provider circuits. The goal is to provision and orchestrate network resources in a real-time manner which solves another type of speed problem, not the speed of the pipe, but the speed with which the network can respond to a request from users, or ideally from the application itself.

So does more bandwidth automatically help with faster network provisioning?

One person argued that more bandwidth means that the idea of Quality of Service (QoS) is less needed since applications would never get congested. SDN advocates, however, would maintain that if an application needs preferential treatment, a path could be provisioned to isolate that application and not require the physical network to be upgraded at all, or at least not a wholesale upgrade.

Another person mentioned that application latency would be lower since there would be no packet drops/loss as every path would now be super-fast. SDN advocates would then argue that again a fast path could be traffic engineered to solve this problem less disruptively than replacing an array of physical switches along that path. However, even if all traffic went by the shortest path, there will still likely be congestion at the egress edge.

Tunneling (overlays) is another approach that was suggested that doesn’t really factor in bandwidth and that could help you manage logical domains more flexibly. And many SDN advocates argue whether the idea of overlays (commonly referred to as Network Virtualization) has anything to do with bandwidth at all. Instead, they believe the issue is of logical domains and managing application flows needed to smoothly traverse subnets.

From this thought-provocative question, it’s not surprising that there are many different opinions around bandwidth utilization. Before you believe that QoS or path latency could be the best approach, consider that while bandwidth helps, adding bandwidth means you are chasing a bottleneck somewhere in your network topology. Now you are going to make changes in the physical network itself. That represents the good ‘ol forklift upgrade that is a fact of life but is not cheap at all. To me, this seems like a cyclic disruption that is too familiar to IT teams.

Let’s not kid ourselves, bandwidth helps. However, faster networks and increased application performance are not necessarily a panacea.

SDN does not solve every problem but it advocates tackling these network problems differently but not necessarily radically. It does provide a new methodology.  A means that is independent of the pipe size. So key in on ‘’software defined’’ instead of hardware defined to avoid wholesale forklift upgrades and after all, we are trying to address network agility.  QoS and latency may be temporary issues due to traffic congestion, and fat pipes help as a wholesale solution, but if you have the capability to adjust the network’s performance in real time, without changing pipe size, you have indeed delivered a new means to avoid a physical limitation.  Put SDN on your shopping list as you migrate to your next speed of Ethernet.  SDN may provide the means to deliver business agility with a less disruptive approach and help you break out of the wholesale forklift upgrade model of the past 20 years.