Cyclomatic Complexity of OpenFlow-Based SDN May Drive Market Innovation

#openflow #sdn Programmability and reliability rarely go hand in hand, especially when complexity and size increase, which creates opportunity for vendors to differentiate with a vetted ecosystem

I’m reading (a lot) on SDN these days. That means reading on OpenFlow, as the two are often tied together at the hip. In an ONF white paper on the topic, there were two “substantial” benefits with respect to an OpenFlow-based SDN that caught my eye as they appear to be in direct conflict with one another.

1. Programmability by operators, enterprises, independent software vendors, and users (not just equipment manufacturers) using common programming environments, which gives all parties new opportunities to drive revenue and differentiation.

2. Increased network reliability and security as a result of centralized and automated management of network devices, uniform policy enforcement, and fewer configuration errors.

I am not sure it’s possible to claim both increased network reliability and security as well as programmability as being complementary benefits. Intuitively, network operators know that “messing with” routing and switching stability through programmability is a no-no. Several network vendors have discovered this in the past when programmable core network infrastructure was introduced. The notion of programmability for management purposes is acceptable, the notion of programmability for modification of function is not.

Most network operators cannot articulate their unease with such notions. This is generally because there is a gap between developers and network operators’ core foci. Those developers who’ve decided to plunge into graduate school can – or should be able – to articulate exactly from where this unease comes, and why. It is the reason why points 1 and 2 conflict, and why I continue to agree with pundits who predict SDN will become the method of management for dynamic data centers but will not become the method of implementing new functions in core routing and switching a la via OpenFlow.

Code Complexity and Error Rates

Most folks understand higher complexity incurs higher risk. This is not only an intuitive understanding that transcends code outwards all the way to the data center architecture but it also been proven through studies.

According to Steve McConnell in “Code Complete” (a staple of many developers), a study at IBM found “the most error-prone routines were those that were larger than 500 lines of code.” McConnell also notes a study by Lind and Vairavan that “code needed to be changed least when routines averaged 100 to 150 lines of code.” But it is not just the number of lines of code that contribute to the error rate within source code. Cyclomatic complexity increases the potential for errors; that is, the more conditional paths possible in logic the higher the cyclomatic complexity.

The cyclomatic complexity of a section of source code is the count of the number of linearly independent paths through the source code. For instance, if the source code contained no decision points such as IF statements or FOR loops, the complexity would be 1, since there is only a single path through the code. If the code had a single IF statement containing a single condition there would be two paths through the code, one path where the IF statement is evaluated as TRUE and one path where the IF statement is evaluated as FALSE.

-- Wikipedia, Cyclomatic complexity

An example of this is seen in the OpenFlow wiki tutorial, illustrating some (very basic) pseudocode:

Sample Pseudocode

Your learning switch should learn the port of hosts from packets it receive. This is summarized by the following sequence, run when a packet is received: