The Programmable Data Path: It's not just Extract and Act

#devops #programmable #sdn Data path elements that are programmable imply the ability to execute business and operational logic

Like most terms associated with any technology in the beginning of the hype cycle, programmability is being used and abused to mean a variety of different capabilities. It's important to understand what people mean when they say "programmability" because it ultimately impacts the ways in which you can use it.

Many application-driven solutions claim programmability as a key characteristic and, by extension, a benefit. The benefit, of course, is being able to customize the behavior of the solution to fit just about any possible solution. Zero-day exploit? Check. API versioning change? Check. Application needs the actual IP address of every client? Check. There are too many possibilities to list because the point of programmability is that you can make a programmable "X" do anything.

For the past decade or so, however, the term "programmability" has been used to describe two very different kinds of anything. On the one hand, there's programmability in the classic sense: execution of logic. On the other hand, there's programmability in a more limited sense: extract and act.

The difference may, at first, seem subtle or even pedantic. The ability to extract data, evaluate it, and act on it certainly seems on the surface to be execution of logic. And it is - at least on very rudimentary level. The problem is that "extract and act" systems tend to proscribe what it is you can extract as well a what actions you can take.

For example, a modern switch is programmable when using an "extract and act" definition. A switch can extract data from an IP packet such as source and destination IP and then choose to forward or deny based on policy. Many L4-7 devices, too, can accomplish this feat at higher layers of the stack, enabling "extract and act" capabilities against HTTP headers as well as TCP and IP variables.

But no one has ever referred to a switch as programmable because it can "extract and act". Such capability is a very limited subset of programmability, and is more accurately described as configurable, not programmable. 

Programmability implies a more free-form definition and execution of logic. Logic that enables not only extraction and action, but transformation and collaboration. Programmability enables extensibility; the creation of new services designed to meet a specific operational or business need not currently addressed by available solutions. Programmability doesn't limit you to this HTTP header or that TCP option. Programmability is imagination and innovation and comes without such highly limiting constraints.

SDN architectures today speak in broad terms about programmability but the applicability of that characteristic pertains only to the controller, not the data path. The northbound API, on which many dreams and hopes for the success of SDN are currently laid, gives SDN controllers the right to call itself "programmable". The northbound API enables extensibility, that is the ability of the system to extend its features and functions and capabilities programmatically. Using the northbound API, anyone (ostensibly) can extend how SDN controllers make decisions and, ultimately, how traffic is routed through the network.

But that programmability does not necessarily extend to the data path. The data path, comprising the switches that form the network fabric, still operate under the constraints of an "extract and act" model and it can only extract from data available which, at this time, means TCP and below in the network stack. Extending the SDN controller's capabilities does not change what the switches it controls (and thus the data path) can do. The SDN data path is not truly programmable. Oh, it could be, and the notion of extending a controller with applications via the oft-mentioned northbound API would certainly allow this. But suddenly we've inserted software running on commodity hardware with all the limitations on scale and capacity that implies, into the data path. It's the 25 mile an hour zone on a US highway that runs through a small Midwest town. It can easily become a bottleneck.

That's not going to be acceptable in the long run, because anything that impedes the speed of the data path ultimately impacts the responsiveness of the application and that, as well all know, is unacceptable.

The SDN data path will never truly be programmable unless programmable data path elements are inserted and enabled with the ability execute actually logic; logic that enables modern application architectures to be implemented with relative ease without requiring you to "reduce speed ahead."