Challenges still exist
With the above set of benefits one thing is sure for us: we have no regrets about taking the OpenFlow SDN path for this very large and crucial internal WAN. What's more, the development, testing and operations experience has reinforced our belief that SDN is the future for networking. All the same, there have been some challenges, and it is up to the SDN community to share this sort of learning.
For a start, managing this network is different. Operations staff are no longer just looking at network devices, they are looking at a system made of devices, controllers and applications, and this requires new thinking. This highlighted the need for new tools that would consolidate this diversity of data and present it in a useful, graphic way to help the operations staff visualise and work with systems, rather than just devices. SDN does furnish the base structure to create such tools, but we still need to develop them.
The basic issues of any traditional network - latency, hardware programming speed, queuing and packet I/O performance - still need to be addressed in an SDN system, but it should by now be clear that we had greater flexibility to work around these classic problems in a more innovative manner.
One example was a problem with our specific Open VSwitch implementation that arose early on as a consequence of having both protocol packet I/O and flow updates running over a single TCP stream. Our OpenFlow agent serialised the processing of all the OpenFlow commands, so you got large sets of flow updates with hundreds of route changes and these were holding back the time sensitive protocol I/O packets. Time-sensitive protocols then began to expire, creating further flow updates and blocking even more data. The solution was pretty simple - we just added some advanced queue prioritisation - but it shows that you do need to be aware of basic networking issues when developing SDN solutions and vendors should bear this in mind.
SDN and the future of networking
OpenFlow in particular, and SDN in general, are still in the early stages of development, but I can say with confidence that, even at this stage, OpenFlow has proved its value to us in optimising traffic efficiency on an extremely large real-world WAN.
The benefits we got from implementing a pioneering OpenFlow solution can be summarized in terms of:
• Unified network-centric approach
• Leveraging high performance servers for more sophisticated traffic control
• Faster, more consistent failover
• Quicker development and easier testing to accelerate deployment
• Low impact system upgrades
• Flexibility, no longer constrained by individual hardware device limitations
Although we have only been describing benefits on Google's internal facing WAN, I can now truly claim that these are beginning to impact the Cloud services we provide - in terms of faster response, better search, greater reliability and so on.
The world needs faster, better and more reliable Internet, and it will continue to evolve. SDN and OpenFlow have an important contribution to make towards realizing these needs. For my part I will conclude with two main items on my wish list.
First, we need more carrier class OpenFlow enabled devices, please. Google has gone a long way as a pioneer developing its own solutions, but we want a marketplace where we can shop for future developments.
Secondly, as a member of the ONF board I am obviously a keen supporter of standards to ensure interoperability and build market confidence in SDN. However, in my personal opinion, we should focus on standardising at the ground level - getting a rock solid OpenFlow protocol - but above that we must preserve freedom to innovate.
The greatest gift of software-defined networking is that it liberates rigid structures to become flexible, programmable and organically evolvable systems. Let's build that on a firm foundation, but let's also maintain a fertile, open environment for the exciting future of networking.
By eliminating high entry costs for big data analysis, you can convert more raw data into valuable business insight.
A discussion of the "risk perception gap", its implications and how it can be closed