The Silicon Flatirons Conference on Regulating Computing and Code is taking place in Boulder. The annual conference addresses a range of issues at the intersection of technology and policy and provides an excellent look ahead to the tech policy issues on the horizon, particularly in telecommunications.
I was looking forward to yesterday’s panel on “The Triumph of Software and Software-Defined Networks”, which had some good discussion on the ongoing problem surrounding security and privacy of the Internet of Things (IoT); some of the topics raised echoed points made on a Silicon Flatirons panel last year. My colleague and CITP director Ed Felten made some lucid, astute points about the implications of the “infiltration” of software into all of our devices.
Unfortunately, though (despite the moderator’s best efforts!), the panel lacked any discussion of the forthcoming policy issues concerning Software-Defined Networking (SDN); I was concerned with some of the incorrect comments concerning SDN technology. 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.
Some attendees commented that the panel could have discussed how SDN, when coupled with automated decision-making (“AI” in the parlance du jour) presents both new opportunities and challenges for policy. This post attempts to bring some of the issues at the intersection of SDN and policy to light. I address two main questions:
- What are the new technologies around SDN that people working in tech policy might want to know about?;
- What are some interesting problems at the intersection of SDN and tech policy?
The first part of the post summarizes about 15 years of networking research in three paragraphs, in a form that policy and law scholars can hopefully digest; the second part of the post are some thoughts about new and interesting policy and legal questions—both opportunities and challenges—that these new technologies bring to bear.
SDN: What’s New in Technology?
Software-defined networking (SDN) describes a type of network design where a software program runs separately from the underlying hardware routers and switches can control how traffic is forwarded through the network. While in some sense, one might think of this concept as “nothing new” (after all, network operators have been pushing configuration to routers with Perl scripts for decades), SDN brings several new twists to the table:
- The control of a collection of network devices from a single software program, written in a high-level programming language. The notion that many devices can be controlled from a single “controller” creates the ability for coordinated decisions across the network, as opposed to the configuration of each router and switch essentially being configured (and acting) independently. When we first presented this idea for Internet routing in the mid-2000s, this was highly controversial, with some even claiming that this was “failed phone company thinking” (after all, the Internet is “decentralized”; this centralized controller nonsense could only come from the idiots working for the phone company!). Needless to say, the idea is a bit less controversial now. These ideas have taken hold both within the data center, in the wide area, and at interconnection points; technology such as the Software Defined Internet Exchange Point (SDX) makes it possible for networks to exchange traffic only for specific applications (e.g., video streaming), for example, or to route traffic for different application along different paths.
- The emergence of programmable hardware in network devices. Whereas conventional network devices relied on forwarding performed by fixed-function ASICs, the rise of companies such as Barefoot Networks have made it possible for network architects to customize forwarding behavior in the network. This capability is already being used for designing network architectures with new measurement and forwarding capabilities, including the ability to get detailed timing information of individual packets as they traverse each network hop, as well as to scale native multicast to millions of hosts in a data center.
- The rise of automated decision making in network management (“AI Meets Networking”). For years, network operators have applied machine learning to conventional network security and provisioning problems, including the automated detection of spam, botnets, phishing attacks, bullet-proof web hosting, and so forth. Operators can also use machine learning to help answer complex “what if” performance analysis questions, such as what would happen to web page load or search response time if a server was moved from one region to another, or if new network capacity was deployed. Much of this work, however, has involved developing systems that perform detection in an offline fashion (i.e., based on collected traces). Increasingly, with projects like Google Espresso and Facebook Edge Fabric, we’re starting to see systems that close the loop between measurement and control. It likely won’t be long before networks begin making these kinds of decisions based on even more complex inputs and inferences.
SDN: What’s New for Tech Policy?
The new capabilities that SDN offers presents a range of potentially challenging questions at the intersection of technology, policy, and law. I’ve listed a few of these interesting possibilities below:
- 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. Yet, the opportunity to create these types of complex SLAs also presents challenges.When all routing and forwarding decisions become automated, and all interconnects look like Google Espresso, where an algorithm is effectively making decisions about where to forward traffic (perhaps based on a huge list of features ranging from application QoE to estimates of user attention, and incorporated into an inscrutable “deep learning” model), how does one go about making sure the SLA continues to be enforced?What new challenges and opportunities do the new capabilities of programmable measurement bring for SLAs? Some aspects of SLAs are notoriously difficult to enforce today. Not only will complex SLAs become easier to define, the rise of programmable measurement and advancements in network telemetry will also make SLAs easier for customers to validate. There are huge opportunities in the validation of SLAs, and once these become easier to audit, a whole new set of legal and policy questions will arise.
- 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. SDX allows networks to make decisions about interconnection, routing, and prioritization based on specific applications, which creates new traffic management capabilities that raise interesting questions in the context of net neutrality; which of these new capabilities would constitute an exception for “reasonable network management practices”, and which might be viewed as discriminatory? Additionally, the automation of network management may make it increasingly difficult for operators to figure out what is going on (or why?), and some forwarding decisions may be more difficult to understand or explain if they are driven by a complex feature set and fully automated. Figuring out what “transparency” even means in the context of a fully automated network is a rich area for exploration at the intersection of network technology and telecommunications policy. Even things seemingly as simple as “no blocking” get complicated when networks begin automating the mitigation of attack traffic, or when content platforms begin automating takedown requests. Does every single traffic flow that is blocked by a network intrusion detection system need to be disclosed? How can ISPs best disclose the decision-making process for each blocking decision, particularly when either (1) the algorithm or set of features may be difficult to explain or understand; (2) doing so might aid those who aim to circumvent these network defenses?
Virtualization: A Topic in Its Own Right. The panel moderator also asked a few times about policy and legal issues that arise as a result of virtualization. This is a fantastic question that deserves more attention. It’s worth pointing out the distinction between SDN (which separates network “control plane” software from “data plane” routers and devices) from virtualization (which involves creating virtual server and network topologies on a shared underlying physical network). In short, SDN enables virtualization, but the two are distinct technologies. Nonetheless, virtualization presents many interesting issues at the intersection of technology and policy in its own right. For one, the rise of Infrastructure as a Service (IaaS) providers such as Amazon Web Services, as well as other multi-tenant data centers, introduce questions such as how to enforce SLAs when isolation is imperfect, as well as how IaaS providers can be stewards of potentially private data that may be subject to takedown requests, subpoenas, and other actions by law enforcement and other third parties. The forthcoming Supreme Court case, Microsoft vs. United States, concerning law enforcement access to data stored abroad. Does the data actually live overseas, or this this merely a side effect of global, virtualized data centers? As virtualization is a distinct topic from SDN, the policy issues it presents warrant a separate (future) post.
Summary. In summary, SDN is far from old news, and the policy questions that these new technologies bring to bear are deeply complex and deserve a careful eye from experts at the intersection of policy, law, and technology. We should start these conversations now.
