One of the panels at the Silicon Flatirons big conference on Regulating Computing and Code dealt with Software-Defined Networks and software in general. SDNs are an important development that allows us to overcome some of the handicaps of traditional Internet architecture. When you try to adapt a research network from the 1970s to the general-purpose network of the 21st century, there are going to be problems.

Unfortunately, the panelists didn’t treat the subject with the respect it deserves. One panelist (at 12:56) quoted a luminary to the effect that “networks have been software-defined [since the 1970s].” This is misleading because there’s a difference between SDNs and networks that simply happen to include some software.

SDN is Network Virtualization

Virtual machines are software that enables one physical computer to run multiple operating systems. If you can run Microsoft Windows in a window on your Apple MacBook while running OS X in the other windows, you have a virtual machine. The capability to run two OSes at the same time means you can run a wider variety of software and enjoy a number of other benefits.

You don’t have a virtual machine on your computer simply because you have software on it. This is a very specialized kind of software that can actually be painful to install.

Similarly, the Internet is not an SDN simply because TCP, IP, and device drivers are software constructs. You have an SDN because your networking provider offers you the opportunity to appear to the Internet as several different machines attached to several different networks at the same time. You would want to do this if your organization runs a number of different applications at the same time and wants to provide each with a network service tailored to the application’s needs.

SDN is a Transitional Step

The third panelist, Matt Larsen of Vistabeam, got the discussion partly on track with a mention of RINA, John Day’s alternative network architecture that corrects some of the TCP/IP shortcomings (at 17:13). We’ve discussed RINA with Day here, and while it’s a promising long-term direction for the Internet, we need to take some transitional steps to get to it from where we are today.

Princeton professor Nick Feamster corrected panelist misstatements in a blog post on CircleID:

Oddly, two panelists stated that Software Defined Networking has offered “nothing new”. Here’s one paper that explains some of the new concepts that came from SDN (including the origins of those ideas), and another that talks about what’s to come as machine learning and automated decision-making begin to drive more aspects of network management. Vint Cerf corrected some of this discussion, pointing out one example of a fundamentally new capability: the rise of programmable hardware. One of same panelists also said that SDN hasn’t seen any deployments in the wide-area Internet or at interconnection, a statement that has many counter-examples, including projects such as SDX (and the related multi-million dollar NSF program), Google’s Espresso and B4, and Facebook’s Edge Fabric to name just a few of the public examples.

So SDN is a new technology, it has important implications for policy, and it’s a real thing that’s happening today.

Technical Advances

As Feamster explains, SDN consists of at least three new capabilities:

1. Comprehensive end-to-end control of routing;
2. Programmable hardware; and
3. Automated decision making in network management.

The largest of these is end-to-end routing control, including fine-grained interconnection management. TCP/IP consists of two layers, obviously, both of which must cooperate to transmit information from the sender to the receiver. But each layer is not equally powerful.

TCP knows what’s happening on the sending and receiving ends, but not much about what’s happening in the middle. IP knows that’s going on in each link in the chain from sender to receiver, but it doesn’t aggregate its knowledge from end-to-end. TCP has to control the rate at which information transits the network, but it has to duplicate and aggregate the knowledge IP has at each node to do this.

So TCP/IP is relatively inefficient, error-prone, and incapable of guaranteeing quality. This is a problem as applications become more diverse, speeds and traffic volumes increase, and critical systems migrate to the public Internet.

Policy Issues

As Feamster explains, SDN has at least two major policy implications:

Service Level Agreements. A common contractual instrument for Internet Service Providers (ISPs) is the Service Level Agreement (SLA). SLAs typically involve guarantees about network performance: packet loss will never exceed a certain amount, latency will always be less than a certain amount, and so forth. SDN presents both new opportunities and challenges for Service Level Agreements. On the opportunity side, SDN creates the ability for operators to define much more complex traffic forwarding behavior — sending traffic along different paths according to destination, application, or even the conditions of individual links along and end-to-end path at a particular time…

SLAs are a feature of commercial Internet service plans, and are a foreign concept to consumers. In the fullness of time, we may discover that SLAs – perhaps in a simplified form – become important for consumers as well. SDNs provide a way for ISPs to offer this capability to consumers. Feamster adds an issue of definite consumer concern to the mix as well:

Network Neutrality. Although the Federal Communication Commission (FCC)’s release of the Restoring Internet Freedom order earlier this year effectively rescinds many of the “bright line rules” that we have come to associate with net neutrality (i.e., no blocking, no throttling, no paid prioritization), the order actually leaves in place many transparency requirements for ISPs, requiring ISPs to disclose any practices relevant to blocking, throttling, prioritization, congestion management, application-specific behavior, and security. As with SLA definition and enforcement, network neutrality — and particularly the transparency rule — may become more interesting as SDN makes it possible for network operators to automate network decision-making, as well as for consumers to audit some of the disclosures (or lack thereof) from ISPs.

It’s fortunate that the FCC embarked on a deregulatory path while keeping disclosure requirements; both facets of ISP regulation will become more important as SDNs continue to develop. I imagine future conferences will dig deeper on these questions.

Next time I’ll highlight a panel that brought new insights to the fore.