Welcome back. We're talking about the future of SDN and in particular, I'll be discussing what I view as some important open problems and challenges as we move forward in this area. A caveat with this particular lecture is that there are far too many open problems to discuss in such a short lecture. So we'll recap highlights from some of the course interviews. I want to talk about specific problems that I think are interesting in this area. I should also note that many of the problems I'll discuss in this lesson, are problems that I'm working on in my own research lab. So if a particular problem strikes your fancy, I strongly encourage you to drop me a note and we can explore working together on one of these exciting problems. There's several important open problems areas in SDN. One is in the development of the northbound API and applications that use it. One important application domain that sits on top of the northboud API is wide-area networking and interdomain routing. Another is programming and debugging. The area of control presents many exciting challenges, such as how to design a fault tolerant SDN, how to use SDN to enforce security properties, or quality of service. How to use big data to help improve network management, and how we can continue to push on concepts of verification to make verifiable reliable SDN's. Another important challenge that we've seen that comes up in the data plane is how we move programmable hardware beyond simple match action primitives. In the context of new applications and services, we studied the use of SDN in various contexts and for various applications, but it's important to note that SDN is just a tool. It does not specify what the killer application actually is. So, in some sense we're still looking for many of the compelling applications that ISP's and operators want, that could not be solved without SDN. One potential such area is wide-area networking. We've seen that interdomain routing is quite brittle, because mechanisms are indirect, policies are only based on destination prefix, and it's only possible to influence the behavior of the direct neighboring AS. We explored one way of introducing disruptive change at an Internet Exchange Point in the form of SDX. But the SDX opens up a whole new set of possibilities, in terms of the types of protocols that autonomous systems could use to communicate with one another and the types of business models that they might set up to exchange traffic with one another and more generally the set of applications that might be deployed at such an internet exchange point. In my research lab we're exploring how to use the SDX to improve the security properties of inter-domain routing and also how to provide better incentives for ISP's to peer with one another in developing regions, where peering has historically been quite sparse. Programming and debugging is another area where there are many open problems. Programming applications for SDNs is getting easier with some of the new high-level languages that we explored, but it is still arguably very difficult. Coupling and composing heterogeneous control programs is not always possible and debugging remains a huge challenge. In the future these high level programming languages could provide support for heterogeneous components and control, as well as better support for debugging. Another area that presents many open interesting problems is fault tolerance. When data plan elements fail, an SDN controller needs to compute alternate paths to ensure that traffic can continue to be exchanged across the network. We need a general fast recovery mechanism but there's still no notion of IP fast re-route for SDN and current fault tolerance approaches are typically quite application specific. Developing fast general purpose recovery mechanisms for SDN remains an important challenge. Another really green field area for SDN is security. The current internet architecture has no accountability built in and for that matter, in general security in the internet infrastructure today is quite weak. In particular, security properties are extremely difficult to verify and enforce and data leaks are incredibly common. In the future, it will be very interesting to explore whether SDN can control traffic flows according to some formal security policy. The recent advances in verification could help us make important strides in this area. For example, we could use a concept like header space analysis to reason about or enforce how traffic should or should not be able to flow between different parts of the network. Yet another area that presents many exciting opportunities is quality of service. The network-wide visibility and control that SDN provides. They provide new mechanisms to give applications the quality of service that they need to give users a good experience. The need for such quality of service is particularly acute given the rise in video streaming, but more generally, it will be interesting to explore how applications and the network can interact to provide better quality of service for all the flows that traverse the network. In particular, applications might provide hints to a network controller about the requirements and the network could offer visibility to applications that can help the applications make better decisions. For example, a video streaming application might make different decisions about trans-coding, or bit-rate adaptation, with better knowledge about the resources that are available in the network, and vice versa. An application might inform the network about its needs, to help the network provision resources or paths that the application needs to provide a good end to end experience for the user. We've seen how SDN makes certain types of network management tasks easier but no existing technology takes advantage of the huge amounts of data about the network, such as regular traffic patterns, prediction and so forth. An interesting opportunity might be combining mechanisms to mine configuration, traffic demands, and so forth and combining that with SDN control, to enable much more intelligent network management. Likely involving better prediction and automation. We explored some very important work on pieces of the verification puzzle, including technologies that allow the verification of both the control-plane and the data-plane, but many important problems remain. In particular, we considered the verification of the control-plane and the data-plane separately, but there's still no way to verify that a control-plane program won't induce a particular, undesirable or incorrect data-plane behavior. Figuring out how to couple control-plane verification like kinetic with data-plane like header space analysis could yield very important breakthroughs in verification. Another big question mark is composition. For example, we've looked at how to compose state based SDN policies and each one of those state based policies can be verified, but verifying a composition of those policies remains an important open question. Finally, figuring out how to apply verification techniques to enforce or verify security properties in a network remains an important opportunity. Finally in consideration of hardware and programmable data planes, we've seen that SDN can be more than just match/action. In fact, a better way of thinking about SDN is logically centralized control of multiple network devices, and all other resources across the network. We've seen several extensions to simple match/action paradigms, but we still need to unify and control frame work to help us compile high level policies into custom hardware and better orchestrate the network, compute, and storage resources across the network. In summary, there are many open problems in SDN in many areas including further development of the northbound API, hardening the control plane, and making the data plane more flexible. This course is just a starting point and you're now equipped to solve some of these next. This course has helped develop a foundation for you to help think about and solve the next set of problems related to SDN and I strongly encourage you to join me in working on this exciting area. As I mentioned, if any particular problem area in this lesson strikes your interest, I strongly encourage you to get in touch and figure out whether or not we can work together on one of these important and exciting problems. Thank you very much for taking the course. I hope that you've enjoyed it and I look forward to seeing you again in the future. I also encourage you to check back when the course is offered again in the future, as I'm continually updating the course materials to make sure that it's relevant to the latest set of problems in SDN.
