Stanford Seminar - Software-Defined Networking at the Crossroads

I I made John promise that he wouldn't salt me in his introduction and and I think he failed except he called me a theoretical physicist so I think by by his standards did that he succeeded so thank you for that introduction and it's great to be here I wanted to start off my talk by acknowledging my co-conspirators in this effort first and foremost is Martine casado who's a graduate from here in 2007 should be familiar to all of you I believe he's a consulting professor actually here and he is really the inventor of Software Defined Networking he remained the intellectual leader in that field some six or seven years later and everything I'll be saying today is really largely due to him then there's another character you're familiar with who when he's not starring in James Bond videos actually has been leading the Software Defined Networking effort as well and then there's somebody you probably don't know very well which is tamuka ponen who has played a major role in architecting Software Defined Networking and in his spare time is best internet architect in the world period by a large margin so I wanted to spend a little time talking about my co-conspirators rather than just putting up their names on the first slide because when I was at Xerox PARC about 20 years ago they did survey asking how do you choose what problems you work on and most people said you know intellectual depth or practical relevance or you know potential commercial applications and I said I choose who I work with and then I choose what I work on and because for me the idea of co-creating with people that I like and respect is the highest pleasure in research and so for the work in Software Defined Networking I've had the best of both worlds both intellectually interesting work and working with people that I have the utmost affection and awe of now of course in Software Defined Networking lots of other people have done very important work there's a huge group at Stanford that's done it the open networking lab that that was formed by guru and that's led by gurus that have formed out of the Berkeley and Stanford groups then there are people at many other universities and many other commercial endeavors whose butt working on this and their ideas obviously will be reflected in my talk but I want to you know most of it flows from these co-conspirators I want to start my talk with a couple of clarifications first I want to acknowledge that coming to Stanford to give a talk about software-defined networking is a huge exercise and bringing coal to Newcastle and at first I turned down the invitation because I thought this is stupid and then I realized that NIC and guru probably have never given a departmental wide talk and software-defined networking at Stanford and I've never given a department-wide talking on Sdn at Berkeley but guru has and so maybe the right aphorism here is that nobody can be a prophet in their homeland and so you have to go to some other university to be able to articulate your vision of what Software Defined Networking is second is this talk has no technical depth zero that you're not going to find any interesting algorithms there's not going to be any new results if we used to not be able to do this and now we can do that and that's because Sdn really is not a technological development in the classical sense Sdn is nothing more than a way of arranging functionality arranging network functionality now you might think that that's an insult but the internet architecture is nothing more than how you arrange network functionality and that turned out pretty well so the point is there is nothing clever about the internet architecture there's no place where you can look and say wow they solved a really hard technical problem there it's all about wisdom about getting the right solution not being clever so this is going to be an architectural talk an unabashedly architectural talk but academia academia in architecture don't always mix oh well there's a user interface expert who played a long role at Apple I believe he's at Northwestern now who says academics don't get paid I mean get paid for being clever not for being right so in this talk though I am NOT going to try and prove to you that I am clever because I'm not I'm going to try and argue that we're right because we are ok so the talk will have three main components I'm going to give a basic introduction to Sdn I know a lot of you already know a lot about it but if you don't understand the basics the rest of the talk is a waste of time this is a departmental wide talk so I want to make sure we're all on the same page and my twist on Sdn is probably a little different than what you're used to then I'm going to talk a little bit about what we thought when Sdn was invented what were the the ideas we had in our mind and then what we think now and after five years and then I'm going to explore the opportunities and implications of these changes in thinking and what it means for the future of networking so I'll start with talking about the basic introduction to Sdn and there I want us to talk about its roots because its roots are deep and broad it didn't just come out of one isolated piece of work there have been people who are doing early efforts to try and separate the control plate from the data plane I'll explain what those are later but epsilon people at Cambridge long time ago there were commercial efforts to manage wireless networks certainly aruba later Meraki have been using centralized methods that look a lot like SDM there were effort internal efforts to tame data center networks at Google and Amazon and elsewhere that looked a lot like Sdn and certainly where I got involved with the Stanford group was in these academic projects to revamp network management but there were other projects at CMU the 4t project ADT research the RCP project there are all these people who are working not exactly in Sdn but in closely related areas Sdn most people think that it originated when the NOx network operating system in the OpenFlow specification came out in 2008 and that's sort of when it officially started but what I wanted to make clear is it came out of a much longer intellectual history of people working on related things and when you have this broader intellectual movement of people focusing on similar questions it's driven by some need and so the question is what was the thing that was driving all of us to think about these problems and they are first of all that networks are hard manage sort of initially put this in past temps on the slides the networks were hard to manage but they're still hard to manage so networks are very hard to manage it takes sort of an order of magnitude more assisted men help to administer a single switch that it does to administer a single computational node so that they're compared to other things we have in computer science networks are hard to manage they're very hard to evolve that is if you want to introduce function new functionality into the network it's much harder in networks than it is and other software systems were used to and network design is not driven by formal principles and the easy way to look at that if you look at an operating systems course or a distributed systems course or a database course they're oriented around some fundamental principles of synchronization and mutual exclusion and so forth that you build off of that helps people organize the way they think about the field the way we and that means it of all of us who teach networking it's basically a big bag of protocols we have no principles we just teach them a various set of protocols so those are symptoms of why we started looking but what's the root cause why do we have these problems in networking and the way to think about that is to go and ask well how do we build the systems that work well what do we do what makes it work there and what we do there is we bake break the problem into tractable pieces and this is most pithily expressed by Barbara Liskov and her Turing Award lecture where she said modularity based on abstraction is the way things get done that is that's the one trick we have if you want to build a system that scales and works use modularity based on abstraction so if you're looking for root causes the answer is simple which is if you can't manage if you can't evolve and you can't understand the system then chances are you don't have the abstractions right so if that's true that what abstractions do we need for networks now to answer that we'd have to realize that networks have two different planes or two different problem very different problems being solved in networks one is what we call the data plane which is a packet arrives at a switch or a router and I will use switch and router completely interchangeably has a packet header the switch a router looks at the packet header it looks at some forwarding state that's sitting there and figured out what do I do with that packet do I drop it do I send it out port 17 do I send it out port 27 what do I do with that packet that's the data plane this happens on nanosecond timescales and it's completely local then there's the control plane the control plane is how that forwarding State got there if you get there through distributed algorithms if you get there through manual configuration it's not slower timescales it's tens of milliseconds two days if it's manual configuration and it's inherently non-local that is the information has to come from the outside world a router by itself can't figure out where it should send a packet so these are two very different problems one is local and very fast one is non-local and not very fast they're very different problems they probably have different abstractions or the data plane we have a very well-known set of abstractions that's layering that if you go and write a network application you don't write a piece of spaghetti code that goes all the way from the application down to low level networking code you write your application on reliable transport you write reliable transfer it on best-effort global packet delivery you write that on best-effort local packet delivery and you write that on local physical transfer of bits now this layering is why the internet was so successful because you broke the problem into tractable pieces when you wanted to solve a networking problem you didn't have to solve everything at once and it enabled innovation at every layer independently that is if you had some new let's say optical technology that you wanted to use in the network you just put it in that's a new way to do local transfer of bits everything else in the stack and remain exactly the same you didn't have to rewrite the entire networking stack you just do a local change and everything works and this has allowed the internet to survive many orders of magnitude change in the speed and the scale and diversity of uses you know six or seven orders of magnitude that's a pretty amazing feat to have the same architecture still work with almost no change so that's the data plane and and we got those abstractions right we not including me but but we as the community got those abstractions right what about the control plane well today the control plane has no abstractions there are a wide variety of mechanisms trying to do a wide variety of things you want to do routing that is getting packets from here to there you want to do various kinds of isolation to make sure the packets from here don't get to here and you want to do various kinds of traffic engineering trying to spread the load out across the network so you don't have overloaded links for each one of those tasks we have a set of mechanisms and the problem is that there's no modularity if you want to write a new out router the algorithm you start from scratch there aren't these well-known building blocks that you can start with you start from scratch and because you are always starting from scratch you actually have limited functionality that is rotting algorithms aren't very good our isolation mechanisms aren't very good and our traffic engineering mechanisms are actually pitiful so this is a classic case of the masses because we built mechanism without abstraction so if you want to know why was Sdn developed it was because we were struggling with a control plane that was built without any abstraction and it was a embarrassing mess so what should we so if that's the diagnosis what's the cure what are the abstractions we should be using so finding good abstractions is all about finding what pieces of functionality you want to reuse okay so let's think about what you would be doing when you want to design a control plane you know to accomplish some task what are the components that you would need to do first you need to figure out what the network looks like if you're going to do something like routing I need to know what the network looks like before I can decide how I can possibly route so step one I figure out what the network looks like then I figure out how to route on that network or if I'm doing isolation I figure out how to not route to make sure that packet don't get from here to there and then once I figured that out I figure out how do I tell the switches what to do meaning how do I install the forwarding State in them so they do the right thing okay so I start by figuring out what the network looks like I then figure out how to accomplish my goal and then I've tell the switches to do what I want now which one's of those are reusable which ones are these are reusable so clearly figuring out what the network looks like you're going to use that for a wide variety of control tasks so that's reusable figuring out how to do that task on a particular network topology that's very specific to the task that's not reusable but then telling the switches once you've figured out what to do that's reusable so those are the two things we're going to reuse you now in exactly 14 minutes know everything you need to know about Sdn that is SDA it is the use of those to control plain abstractions that's all it is so I told you there was no cleverness so you have the global network view that provides information about the network the way that's typically implemented is with something we call a network operating system that's just software running on servers that happen to be placed in the network the forwarding model is the standard way of telling a switch how to forward if you've heard of open flow that's what the role open flow plays it's basically just the way you can tell us which if the packet header looks like this then take this action just a just a standard way of telling it that simple statement so given those abstractions then Sdn is nothing more than layers for the control plane just like we had layers for the data plane that's layers for the control plane we start with a bunch of switches connected by some wires we then build the network operating system remember this is just software running on servers but these servers talk to all the switches they do so using this forwarding model open flow like they use the information they get from the switches to build this global network view that is they know the topology and then you build a control program on top of that topology and that control program can be routing it can be access control it can be whatever you want and I call this layers because you have a very clean separation of concerns the control program has no other job than to express the operators goals like if they want to do connectivity or if they want to do isolation that's what the control program is concerned with its implemented on top of this global network view the control program doesn't care where that view came from it doesn't care how you found it out it just said you give me the view I'll figure out what I'm supposed to do and I'll compute this forwarding state that every switch should have the network operating system sits there and it says I will talk to the switches and I will compute the global network view all gather that information and that when the control plane I mean the control program tells me I will convey the configurations down to the switches I don't understand what the control program is trying to do I don't need to I'll just tell the switches and the switches just follow orders from the network operating system the very clean separation of concerns and so now you can have independent innovation at every layer you can build better routers and switches and as long as they support this interface they're fine you can build better network operating systems as long as they take orders from the control program they're fine and you can change what your control program does and the other layers can remain intact so while this is very simple it is a major change in the paradigm that is the control mechanism now is no longer a distributed algorithm like we think of routing algorithms it merely uses the network operating system API it is nothing more than a graph algorithm giving me a graph I will figure out what I should do if you want the shortest path I use Dijkstra if you want K disjoint paths you go write some complicated graph algorithm that computes K disjoint graphs but it's local it is nothing to do with distribution so that makes it much easier to manage evolve and understand those were the three symptoms we identified earlier that networks were bad at and once you go to this paradigm they now become much easier it also ends up with a very clean separation of control and data plates that is the data plane is now completely handled in the switch but the control plane is now running on these servers in the network so they're completely separated whereas today when you buy a box it has the control plane the data plane all jumbled together in a proprietary closed box this separation allows you to use commodity Hardware and third-party software it also allows you to do much better testing of the network because there's this clean separation you can test the control plane independent of the underlying hardware there's been a lot of work at Stanford and at Berklee trying to take advantage of this and try and elevate network testing and troubleshooting to a first-class citizen the way it is in the chip industry and other places where they do this testing very well so this separation makes networking look a lot more like the rest of the industry but everything I've said so far is based on what we thought five years ago so now I want to step back and say given that it's been five years we got a lot of it right but we had a couple of areas where we were just flat wrong so the rest of the talk I want to explore what those areas were why they're important and what the implications are for the future of networking but I want to be clear that if you think about Sdn is just sort of observing modularity and networking that part we got right and all of the additional insights that we have now are about finding new and more advanced kinds of modularity that is our search for modularity was right we've just discovered additional modularity whatever you build a system it sometimes takes you a while to get the modularity right and it's taken us five years and we're probably still not right so let me list a couple of things we used to think we used to think that the control program would compute the configurations that is the forwarding state for all the network switches we thought that switches were relatively homogeneous and roll and function we thought the network was comprised entirely of Hardware switches of course it was what other kind of switches are there and we thought the native network data plane with fairly simple that's been the dogma about the Internet is that it has a very simple data plate so what we now think is that those are all wrong okay so what I want to do is go through each one of these and explained individually where we're wrong and why you should care that we were wrong let's go to misconception number one the control program configures all of the switches that is that it's job is to go and compute what the forwarding state should be in all the switches so what is the role of a control program control programs are how operators express their network requirements and policies that is should everybody be connected should these people not be able to talk to these people that's what the control program is supposed to Express the control program should not be in charge of implementing those requirements for a simple reason which is one of the goals of modularity is to push complexity into the reusable portions of the system and keep the things that you have to write on a per application basis very simple and you want control programs which are written on sort of a per site or per application basis you want to keep those as simple as possible and push the complexity into the reusable code so you don't want your control program responsible for implementing so let me illustrate that with an example so here we have a network we have host a a and host B and then here a bunch of switches connected by links and the operators goal is to prevent eighth packets from reaching B let's say this is a visitor's laptop in the lobby of your corporation and this is a back-end database that holds all of your company secrets and you would like to make sure the packets remai don't get to be that's a natural requirement so if you did it with a standard Sdn method what you would say is the control program would then instantiate forwarding entries that says if you see a packet from a going to be drop it and you would have to enter those forwarding entries at enough places in the network so that it was impossible for a packet ever to get from A to B and the problem is that then the control program must respond to through ology and routing changes let's say I put in a new link from here to here the control program would have to know oh there's a path available I better put in another forwarding entry that blocks the delivery of packets now it becomes hard to write a correct control program because it's got to monitor all changes in topology and routing not impossible but it's hard it's way too hard that much harder than it should be so that's where what we call network virtualization comes in what we do is we introduce a new abstraction and a new Sdn layer the abstraction is a virtual topology that is this is purely logical we use switches that you can configure so it's a logical switch that you can put flow into and that's how the operator can express the requirements and policies and then there's a layer that we call the network hypervisor that translates those requirements into the physical switch so you can think of it as sort of a compiler for virtual topologies that says if these are your policies I will then compile them into configurations of low-level Hardware low-level physical switches so if you go back to this example this is the global network for you the virtual topology that the operator would use to say here's my network it's just one big switch and I know I have a host de somewhere and I have a host B somewhere and all I want to tell you is if you see a packet from A to B drop it at that point the control program is done it is told the network all of the semantics that are specific to its application it's now network hypervisors job to insert these flow entries and if the network topology change it's the hypervisors job to follow those topology changes and make sure you have the flow entries so now we've made it much easier to write the control program a lot harder to write the compiler but compilers are always hard to write that's okay so we take this picture and what we do is we insert a new layer this network hypervisor and the virtual topology you write your control programs on the virtual topology and that's apology will differ depending on what job you you have and then the network hypervisor translates that or compiles that virtual topology into what your physical network looks like based on the global view and then your network operating system carries that down to the actual physical switches so virtualization is the killer app for Sdn consider a multi-tenant datacenter Rackspace Amazon so you have lots of customers who want to move their network to the cloud and black space and Amazon want to allow their customers to specify their policies of what VMs are allowed to talk to what other VMs in their virtual network so they allow them to specify a virtual topology Vic has their policies and requirements and then the data centers network hypervisor takes all of these and I mean thousands of them and compiles them down to low-level configuration so that everybody's individual policies are met this is something that you could not do with today's technology or before Sdn sure you could do it with a few having thousands and having them change dynamically you couldn't do it and so this is what people are paying money for this is the killer app now there are long-term implications of network virtualization one is that in the long run virtualization may be more important than Sdn itself Sdn may be very useful it certainly is now for implementing virtualization but in the long run it may be virtualization that's actually the thing that adds value that is that's what people are actually willing to pay for because it makes it easier for them to manage the network in Sdn is a means to an end rather than an end enough itself meaning five years from now somebody may invent some other technology that supports network virtualization that's better or worse than Sdn but what will be important I think in the long run is that we have some kind of network virtualization we can also extend this to much more general abstractions the idea of virtual topologies just beings analogical networks that do forwarding that happens to be the use people are making of it right now but you can extend this to include much higher level functionalities like authentication and so forth and actually allow these virtual topologies to express sort of application level semantics of who's allowed to talk to who and allow the network hypervisor to then enforce those the network level that would make it much easier to build these large-scale applications so that's something that may happen in the longer term and that network virtualization completely decouples the control program which expresses the operators goals from the physical network and what that means is that the operators now abstractly Express the requirements and the network hypervisor has complete freedom and how it implements those desires and that's going to be important let's go to a misconception number two switch is a relatively homogeneous and rollin function and all I mean by that is if this is a network then when you implement your functionality just so that you know you sort of putting these flow entries and they're spread throughout the network and you don't treat switches any differently than than any other a priori so let's explore that when you think about what happens when you have a host sending a packet through a network there are three different logical interfaces first of all the host is telling the network something which is I want this packet delivered to this destination and maybe something about quality of service that's the host talking to the network then as the packet goes through and hits each router the packet is telling something to the router it's saying this is who I am you should look at me and figure out what are your forwarding state you want to use to forward okay so the packet is trying to identify itself to the router and meanwhile while all these packets are running around the operator network operators try to control the network so the operators trying to tell the network something about traffic engineering or isolation that's a network level concern an operator level concern so these are relatively independent interfaces okay so how are they implemented in today's networks so for current networks the packet header itself is used for both the host talking to the network and a packet talking to a router or switch that is when a packet arrives at any switch the switch says first what was the host trying to do ie what destination was this going to and then it says and now I need to use that information to look up in my forwarding State to figure out how to forward the packet so it's doing both of those interfaces with the same header but current networks have no general operator network interface that is the way the operator controls the network is a completely kludgy and not worthy of the name interface Sdn gives you this complete programmatic beautifully clean way of the operator controlling the network but it does nothing to separate the host network in the packet router interface and as you still use the packet header and you look at it at every router or switch along the way now MPLS is a technology the the non networking people don't you know probably don't know the only thing you need to know about it a it's used widely in in large networks and it makes a distinction between the edge and the core of the networks the edge uses the header as the host network interface that is when the packet first hits the first hop switch the edge router looks at and says what was the host trying to do it then slaps on something we call a label think of a label just as a bag of bits it's only meaningful within the network it means nothing to the host so it inserts an MPLS label and then the core the interior of the network doesn't look at the packet header at all it just looks at that label and says somebody already interpreted what this host was trying to do they put this label on it from now on I just look at the label and that's enough for me to know how to forward this packet so what we should have done five years ago is recognized that MPLS was right and we should have incorporated into Sdn meaning we should have edge routers look at the full packet header insert a label into the packet and the course switches which I will sometimes call a fabric um or just based on that label they don't look at the rest of the packet header that's already been looked at at the edge this now creates a very clean network modularity the host network interface is handled completely by the edge the packet router interface is handled by the label in the core and Sdn handles the operator Network interface so once again we find more modularity by separating this out we have very clean separation of concerns and we do each job once we do it right rather than having it all bunched together now let me consider two controversial claims about this edge core split one is that the core can focus just on packet delivery and as operators have a bunch of requirements and the claim here is that all of them but connectivity that is just m2m packet delivery can be implemented at the edge and as if I want to block access control if I want to do isolation I can do all of that at the edge the core must obviously deliver packets and I will include in terms of packet delivery also multicast and quality of service but other than that the edge can do everything else now every time I give this talk to a networking audience somebody gets this an oh here's this use that you can't do at the edge and then it'll give me some crazy scheme that of course you can't do at the edge so I've modified it that the edge can do everything else that people are willing to pay for okay and that I still stand by so this is the Sdn equivalent of the end and print of the end-to-end principle and networking said you take functionality out of the network and you put whatever possible you put it in the Antos and this is just saying you keep the core of the network simple you take all the functionality you can out of the network core and you put it all of the complexity to the edge very similar reasoning and I think it will be as important at Sdn networks as the NBN principle was for the internet so you end up with a network that looks like this which is you have these core switches you have these edge switches and the core nodes only provide end-to-end connectivity so if I have a packet here its job the job of these nodes are just to get the packet from here to there and that's it okay they don't do anything else and the edge no do all of the other functionality so the long-term implications of this are first of all we've now told the core you have one job just get the packets edge to edge don't do anything else you don't need to understand anything else and once you've simplified them to that point they can do a much better job so one of the things that people complain about in today's networks it takes a very long time to recover from failures that if a link goes down it can take hundreds of milliseconds to recover from that failure once the core is not doing anything else there are recent research result from from several groups that argue that you can have the core which respond to failures on packet delivery times nanoseconds not hundreds of milliseconds this is actually what you are doing is you are changing the modularity again and pushing connectivity into the data plane that is you actually put something in the forwarding a6 it's actually a very simple thing that if a packet comes into the wrong direction I remove a destination from my forwarding table that's it that's all I need and I can build a sort of a forwarding fabric that will never end up not delivering a packet meaning that when you fail links it will find a path if it the network is physically connected it will find a path at packet delivery times so we can do a much better job by changing the modularity once again you also could imagine once you have this edge course split why not push the edge all the way to the host you know it will require some trusted hardware and software on the host you know sort of all on the the host network interface card but we've got the technology for that so this isn't trivial this will require you know a lot of interesting distributed systems and security issues but one could imagine actually building networks where they never saw anything but labels all the labeling was done off in the Haute end host themselves ok so let's talk about misconception number three the network is comprised entirely of Hardware switches so on this one we just got blindsided we just I mean duh we of course switches our Hardware switches well you know what what well turns out that software switches are quite common every hypervisor has a software switch right you have a VM here VM here they want to talk to each other they are connected by a software switch a V switch that lives in the hypervisor so you might say oh yeah ok fine that's a special case it's not a special case there are more software ports than Hardware ports right now if you consider these switches having software ports to all of its VMs in 2012 the number of software ports crossed the number of hardware ports I'm sure I'm violating some copyright agreement by showing the slide but I stole this from somewhere now so I can forgive us for not knowing about this in 2007 if you extrapolate these curves then hardware clearly dominated but not now not now software ports dominate so this idea that the network is made out of hardware switches just not true it's not true and not only that but software switches are getting much faster now I just need to clarify when I say software forwarding obviously all forwarding is done eventually in hardware so if you're using an x86 a general-purpose processor that doesn't know you're doing software forwarding I call that software forwarding if you're using a special-purpose ASIC that was designed with networking protocols in mind that's hardware forwarding so that's the the language I'm using and so a data point that if you use sort of recent Intel technology you take a single core it can do 23 and a half million packets per second of IP view for forwarding we did this with mid sized packets that's 16 and a half gigabits per second for single core if you extrapolate of what that would be for average sized packets that's a single core doing 200 gigs now clearly a single core camp do 200 gigs it doesn't have anywhere close to that i/o but the point is copy patiently the amount of work you need to do to do software forwarding is not very hard at all so the claim number two I promised you two controversial claims the claim number two is the edge can use software that is when you have this edge core network all of the edge switches our software switches of course switches are still hardware but the edge switches are software so you can clearly do this in virtualized data centers because that's what's happening already they use the V switch and the hypervisor if you look at a large ISP verizon and AT&T Deutsche Telekom and you look at the total amount of bandwidth that they send inter domain that crosses their borders and you ask how much would I have to spend to buy enough cores to do that forwarding one hundred and fifty thousand dollars that's not even the price of mid-range router so the amount of forwarding you need to do software forwarding is trivial and so when you look at other examples of enterprise networks and so forth I don't see any setting where it would be infeasible to do software forwarding at the edge it may not be as cheap as you can do it today in most cases it certainly won't be as cheap as you can do it today but you certainly can do it so let me talk a little bit about software versus hardware because I'm not claiming the software forwarding is as fast or cost-effective as Hardware forwarding you know people who know better than I tell me there's two orders of magnitude difference and it's probably growing I'm fine with that my point is that the edge forwarding requirements can be met with software and that we would be better off with the increased flexibility of software at the edge we don't need to use it in the core because we don't need any flexibility in the core of the cords just doing label based forwarding hardware is great for that but at the edge we should use software so we're not limited by what current Asics can do so the law I I hope you will forgive me I'm not going to tell you about a long-term opportunity this present this is one of my sort of academic obsessions so if you don't like to think about internet architecture you can turn your brain off for 30 seconds and I'll come back to it but what this could do if you put the software at the edge is you could allow architectural evolution in diversity what I mean by that is you build let's say 18 T or Deutsche Telekom they build their domain with software at the edge hardware internally only the software at the edge knows that you're running an intra main protocol meaning those you're running IP everything else internally is protocol agnostic think of it as you know layer 2 Ethernet or protocol agnostic they don't care whether you're writing v4 v6 so now if you want to change architectures like going from ipv4 to ipv6 that's just changing your Sdn control program says rather than looking at this bits in your packet header and doing that match look at these bits in your packet header and do that match that's it that's the ipv4 to ipv6 transition right there it's that simple and then if you want to do something radical you may have heard about these information-centric networking that say you know network shouldn't be designed around the socket interface about sending packets it should be this pub/sub interface about getting content and that's a radical change we need to change the entire network that's just changing your Sdn control program quite seriously that's all it takes now you do need to make some modifications on the end host but in terms of the network infrastructure it is an update to your Sdn control program now you might be saying butBut how can you change the architecture the thing we've all been taught in networking class is that the internet works because we have this narrow waist that everybody agrees upon and then of course everybody agrees that you you need a narrow waist and that quite simply is we don't need a narrow waist I can explain why the narrow waist comes because we've conflated Ethernet with domains but that's a longer lecture but domains can run many architectures in parallel and to support these architectures in parallel and do it on the host it's conceptually radical but the technical changes you need to make are embarrassingly simple so this is easily within our technical range it's just a question of convincing people it's worthwhile to do okay so end of rant that so let's go on to misconception number four and something that somebody other than me cares about and here there's the network dating data plane is fairly simple and Here I am stealing content from Silvia rotten Asami a colleague of mine at Berkeley and there's a saying about artists that good artists borrow and great artists steal so in this regard in this regard only I claim greatness so the myth of the Internet's data plane is that the Internet only provides best effort delivery and that that's enough to satisfy users the reality is that these things called middleboxes or network appliances are used to augment the data plane and they do all sorts of stuff ok so you have firewalls you have LAN optimizers you have proxies you have gateways you have VPNs you have load balancers and you have intrusion detection and that's only a partial list so you have lots of things on the data plane that are doing things it's not simple the other thing that's very shocking is that sylvia's group found that when you go do measurements and you look at small networks medium networks large networks and very large networks and you count the number of middle boxes and you compare it to the number of routers and the number of switches and they're comparable middle boxes you shouldn't think of your network at all it's all switches and routers and there are a few middle boxes over here that I can treat the special case no there are as many middle boxes as there are routers so there are 4 important facts to remember one is most packets are touched by several middle boxes ah sorry thank you for asking that a middle box is so I have this beautiful pristine textbook network switches and routers packet gets routed between switches and the routers and they go the only time anybody understands a packet is when it's sent from this house and when it's received at that house that's the Internet and then I'm gonna big bad middleboxes gonna be stuck in the middle of the day to plant a packet comes in and this box and we call it a middle box it's stuck in the middle will then look at the packet and make some decision about that packet like I don't like the content of this back and I'm going to drop it or I'm going to look at this packet and see if somebody's attacking me or I'm going to be a firewall and I'm going to control connections and that's why it is data planing that it is stuck right in the middle it has no official role in the flow going on but it's making decisions about package so thank you for asking that so that's what a middle box is so now let me get back to those four facts most packets go through several of them they're typically deployed at the edge of the network they typically not always but they typically use x86 packet processing and the things they do the packet are much more complicated than what you would do if you were just simply forwarding the packet okay so if you accept these four facts there's one absolutely inescapable conclusion which is that Sdn should implement middle box functionality at the edge in software replacing all these separate boxes that we have currently do it you know we put in these separate boxes being middle boxes but we ought to be doing it at the edge in software right because it's already being done at the edge in software just not by Sdn so Sdn just should bring it under its domain and when you do that you have now cemented the case for edge software forwarding because software forwarding was necessary for middle boxes it's already being used for middle boxes doing I mean software processing doing the extra forwarding is a tiny additional if you have enough cores to do your middle box functionality you essentially have enough cores to do your software forwarding on top of it yeah you mean by the edge and is there only one edge it ends means anytime a packet from a host and end host enters the network that first top is an edge boundaries between domains nice piece are not edges ah I should say there are two ended right there's when it leaves a host or when entering from another trust trust domain and so that would be two domains who are connected that don't trust each other then you have to consider that an edge because any label that would have been inserted by that domain I will I don't either trust or don't know the meaning of it and it traverses many edges getting from one place to another yes so if we buy this that we're going to do software forwarding at the edge this represents a radical shift from hardware to software the hardware network goes back to being dumb pipes but they were in the beginning when we actually didn't have any metal boxes and actually the network just forwarded packets and everything interesting happens in software at the edge under the control of Sdn this is the truly disruptive nature of Sdn there was a yes our current understanding of middle boxes work do we know if they're processing every packet that flows through them are only processing a sample of the packets flowing through them it really depends on the middle box because if it's the case that they're only processing a sample of them then by using software it forward every packet and necessarily process every packet wouldn't you be introducing a lot more network latency you wouldn't be introducing more network latency oh yes you would have been ignored by the middle boxes packing meanie ah so if what you're saying is that I'm going to do something very slow on some packets but what you would say is I need to have enough core capacity so that I can for that line right yeah and if I can't do it with one core I take two cores and if I can do with two I take seven and so if I'm forwarding it line right then you don't increase the latency yeah what what what's the commercial impact of this observation this seems to me to be very disruptive to current network hardware not attack let's get to that idea okay because III think that that's a subject for a prolonged discussion so well I want to step back because we've now gotten to this place where we would focus on software for anything you might say you know you said you were coming here to talk about Sdn and now you're talking about software forwarding how do we get from here to there so let me recapitulate Sdn established this nice control plane modularity switches network operating system control programs they all have their own jobs and that virtualization came in and decoupled the control program from the physical network so what this did is the control program just expressed its goals on a virtual topology that gave the Sdn platform full control over how it implemented those desires and then we said now that the Sdn platform has full freedom it's going to say let me put the functionality at the edge and just do forwarding in the core you removed all but all functionality but connectivity from the core and then the last step we said in G by the way at the edge we can use software there we can forward fast enough to do software there and that last step pulls all the functionality out of any ASIC there is no longer any complicated functionality in the Asics the Asics are just doing label forwarding and all the complicated functionality is now at the edge in software so that's why Sdn played such a role because it is able to control where the functionality is implemented and manage the network in that way that you can put it in the one place where you can replace hardware forwarding with software 40 now you might say why do I care so much about software I mean was i beaten up by an ASIC when I was a child and and you know and the point is software for ting is a stable forwarding platform that does not limit functionality you know so I want to match over the first 500 bytes I can do that if I want to match over the first 30 bytes I can do that it doesn't matter I'm not told of well this ASIC only supports matches up to X bytes and if you want to do more than that we just can't do it now obviously if I want to match over more bytes that go slower but we're used to that in software that if you ask something to do more it goes slower but it doesn't fall off a cliff and it's a platform to get faster over time new functionalities deployed merely through software upgrades and hardware upgrades are largely transparent I just I put new hardware and it goes faster yeah daddy's talking I think it's faster first time so we can be only appropriate person to say I'm sorry what I'd never slips off me that you got faster over time without metal hardware underneath and we know Moore's laws reach the end so that's going to happen so I forget slower over time unbeliev in many core powers constrain what I would say that first of all if you look at the recent forwarding rates x86 forwarding rates have increased dramatically over the last couple of years so whatever they're doing they're figuring out just like virtualization has gotten better I don't care about Moore's law but people are figuring out what instructions we need to do forwarding faster and that's clearly you don't see any curve that looks like that's flattened off maybe it will in a few years but we also can spread you know forwarding packets is highly parallelizable using multi-core for that is very easy because we just we typically are not joining the forwarding one packet tuna lycée actually I thought you man it was going to reduce latency but using multiple cores is not going to slay oh I'm sorry I understand that you care a lot about latency by that is at the cording rate of a single packet that the latency that you know if I can go at 200 gigs computationally then whether when the capacity the total you know that latency in the switch is not the main thing that I'm worried about in terms of latency so I care about increasing aggregate bandwidth I care about can I have a thousand port thousand by ten ports which that's what I care about the actual latency on an individual line is low enough that I don't think that's that's the issue forwarding even software you gave a number that was throughput but you didn't get actual latency number no I don't have that number also I'm curious a for example this is assuming that you're doing a packet closer to go across the US and take hundreds of milliseconds so you don't mind wasting a few tens of my per seconds on each and doing the software business yeah so I I don't have that number I don't have that number so the nice thing about this platform provides both stability and innovation there's a much more stable customer experience then certainly if you try and do a network upgrade and there's more innovation and competition both in the hardware and the software platforms and this is much like the x86 computational platform over the past decades so this is why I say given the title of my talk that Sdn and networking in general is at the crossroad that the question is will networking in Sdn be defined by the limitations of Asics that is there are certain things you can and can't do or will it embrace the generality of software for DES so I'm not claiming the move to software will be trivial or fast it requires new thinking you know how exactly do you want to structure your software what are the kinds of matches you can do in software that weren't practical and hardware new products like how do I get a high port density software switch those aren't really available today and you need new players people who roll in the marketplaces to fill those niches right now they're not there but this move is inevitable and it's already underway that is if you look at what's going on in middleboxes you're already paying that latency if that's your concern all we're saying now is you want to take advantage of the fact that this is already going on to generalize your functionality it's certainly going on in a virtualized data centers and this transition and this is getting to the point that was raised before will change the nature of the networking industry it's faster innovation more competition and better customer experience and with that thank you yeah distributed denial-of-service attacks rely on this boy right in the future so what I would say is that any mechanism you would want to deploy that you could deploy more easily by doing it in software at the edge then you could do now by saying okay little box I put it in a tub point so that I can do whatever countermeasures so it doesn't magically solve it but it gives you a much easier deployment path for those kinds of solution I mean you're talking about interim solution this doesn't inter debate yes yeah I've been reading that a lot of people are trying to apply a scheme to layer four problems like load balancing you know some hard ones that hardware has done pretty well at like SSL termination that's kind of expensive um you know and I know I do think these changes are going to occur but what is your take in much closer to this on all that so no I think there are some things that are going to be slower faster than others but I think eventually it's all going to be eaten by generalize you know I think that there is a lot more to be learned about how you can accelerate various tasks I mean the one thing that Intel is really good at is if you give it workloads it will go into exhaustively look at gee what instruction would speed this up we're at the very early stages of looking at the entire x86 could do to make these things faster really quick question on that is are people in the industry right now using commodity hardware like just standard rackmount pcs to implement these network operating systems the other problem is is that that's just uh that's not on the data plate the question is where are they implementing the data and some middle boxes are essentially stock servers that just have a few cards stuck all I once was on an airplane sitting next to somebody obviously a Salesman because the only people who talked to me on their planes I put on this sort of very antisocial demeanor you can tell somebody start talking to me I know it's a salesman and this person you know I found out work for a company that sold security middleboxes and so I said you know what use special-purpose process you know to you and any SEC yeah you know and then sort of after about a half-hour he said well you know actually our old bonds use the special purpose processor our new bonds you six but we can't admit that to any of our customers because our whole marketing campaign was based on special purpose hardware but but but but that they too had sort of decided that the flexibility was such that writing the technology what are your thoughts about the color and space constraints when the edge is not a virtual data center but the edge is a central office as a Metro edge or a point of presence and so on red power and space the compass have become scarce resources that made software at your as your edge well how do you think if you get realized or when will it get realized because those constraints making it difficult for people to deploy a software as an agent it's not a host but surely a network coming in as an edge as it so I think that's going to be one of those cases where on the one power consumption and on the other hand we have better flexibility and different markets will make the transition at very different times that is that when people recognize that once I move to an x86 platform I actually have to upgrade my equipment much less often certainly upgrade my software much less often that it's a better you know sort of total cost of ownership that's going to differ based on different scenarios and and I don't claim to have any special insight about that so you talk about hardware a6 and software x86 processors but there's a continuum in there there are these network processors do you see any role for these sorts of things or you think it will just be you know x86 everywhere um I don't I don't want to make a definitive statement on that I think that the people I talk to about middleboxes seem to think that network processors are getting a smaller share of the market than they used to but you know I I don't wanna make a definitive statement but it seems like they've had a very hard time finding the sweet spot that's where we program it the flexibility is much better than but the speed is much better than x86 is I think that gap this is is narrowing the implementation of these mostly linux on x86 with a real-time minimal or is it some other they mean how you afford it yeah right so so I mean the you know it tell has this DP DK forwarding thing that is typically what we took our measurements on they just want it so you know x86 the real regular standard I think it's a regular stable so with if no one's become much more programmable essentially inflexible what kind of effect does that have on participants like what do persistent mins become in that world is Amazon just start hiring way more C programmers it's like right I mean I think there would be sort of two separate they're the sort of edge to edge network delivery where the network has a very simple task and there will be network administrators to sort of make sure that happens and then there will be people who will be sort of more about the sort of the the S the ends of auxiliary functionality that will be hopefully programs yeah and I guess like that I'm like where's miss do it do you uh and vision these things being changed like to maybe watch your writing code sort of on live networks or is it or would it still be more of a model more like you have some vendor like Cisco's everything just writing new boxes at a more rapid pace because they're easier to deploy so um I imagine there will be coming that write software that they will go directly to users and say this will solve your problem so aside from the table our high speeds or the large data centers I don't imagine many end customers will be writing their own control programs but there will be companies that do and how I'm living in happens to be one of those bought the house that I haven't be living so the control program is that is there a single control program is this a large distributed program which shares information with other instances of the same program what what is it so it's very complicated right so so that actually when you're writing a control program is a distributed system system running over a cluster not widely distributed over the entire network so it's not really just a single box you know you need to shard the problem and spread it over several servers but you get to control that rather than being the victim of the topology of the network going by some core edge model what I mean that there will be minimal ventilation opportunity in the core area because maybe again we use of MPLS we may be the Guru mineral opportunity to do innovation yeah good zone so actually know um that that something like having networks that respond to link failures immediately that's something we don't do now they're terrible about that and I think that's certainly within technological reach so I think that it would be not in terms of broad-based functionality but it would in terms of you know metrics of how fast you recover from failures and you know how fast can you support multicast joins and things like that okay so you use MPLS you know it's already ours today yeah but but but but it doesn't recover very well from calories so you know you need to build in that that stuff yeah so a really interesting talk really provocative because I never box trucks in here question like it is Ranger me because everything so differently but a lot of questions I mean first but I one thing about my idea of Sdn is kind of different the idea that testing is simply making switches programmable and enabling api's into the protocols and I remember somebody I don't remember who it was gave us really interesting talk about like the end of protocols in the future network but that was kind of good and I wonder and so this leads me to question your idea of a hypervisor running on top of the operating system because usually a hypervisor just creates sort of recreates a hardware interface or sort of duplicates it and and you know virtualizes it and so the question I question for you is why do you think that the role programs will want to use the same interface talking to your hypervisor as they would use talking to hardware because it would seem to make a lot more sense to me to have an API that doesn't necessarily mean the hardware interface at all ah so you're absolutely right except right now if I'm running a network and I want to move it to the cloud I think in terms of switches and configurations right now if the cloud said we've got this great interface you know you have to learn into language and it's got this other policy thing but you can do whatever you want I'd say no thanks if you say you can take the configuration you're using in your network and move it to the cloud I'll do it but you're absolutely right I would hope ten years from now if we're still using that interface I would be very disappointed but right now it's this is what people understand how to think about networks and um you know the early days of Nasir I will you know when we went out and talked to people we would say you can do all this great stuff and their answers in terms of Ackles and these low-level mechanisms they could not articulate a policy it was and so giving them an interface that they understand is the first step but I absolutely grew that was what I was trying to say about more general abstractions I would hope that the virtualization layer supported much more general abstractions in the future that didn't force people into thinking about it the way networks work right now just virtualize the hardware they actually provide convenient higher level abstractions like you know files rather than a virtual disk or processes rather than you know virtual addresses but and sometimes are virtualized but often you get these are higher level abstractions which are much more convenient we're going complete agreement we're going to play truth what abacus dean and the new smaller network start-ups have to say about this Oh Andy Bekele Stevie oh yeah so what is the risk to think about this I would not want for Wednesday's next era you know I think the right way to think about this is this is disruptive it will create new opportunities and it will render some old paths less relevant I mean building sort of very fast fabrics is a really important thing and doing that well is incredibly important so I don't want to diminish that at all so there's going to be a role for Hardware here and just it's sort of the allocation of functionality maybe a little bit different or you know I would be advocating deformed it's not like home bass was in the market go away so colleagues affect the core routers are going to be specialized Hardware they're going to be just another instance of a sort of standard server that you buy off-the-shelf although I assume core hardware we have 40 boxes that's because of the multiplicity of network for that I was just so curious if I understood you correctly can you realize a CCN like model or architecture using the controller what are the modification because the controller can tell the edge software what to do so that the controller can say you know when when you look at the packet look at the using some kind of name based networking architecture look at the name of the content go check your cache if it's there the action you take is to respond with the object if not you forward it the way in the end would you know it's just saying that that I you know that something that the software can do let me take one more so in the core do you still feel that Sdn and a controller should manage those even if they have like diminish functionality or it's simpler because a good chunk of Sdn is about manageability and they're not going to manage themselves Lissa's yeah yeah no so I would imagine the core still managed by his DS absolutely absolutely okay so I said what would holla to confuse we middle boxes coming bringing all the functionality at the edge so the flow table these brings this very natural decoupling between the fast data plane and then the longer timescale control plane but the moment you bring the little box is there where you have per packet processing this seems to be a bit mixed up again and so do you do you think of any abstractions on the middle box that could go down to per packet processing that could be similarly abstracted to an SDN controller I'm not sure so he do I think they're abstractions that are middle boxes could export to a control so the controller could understand what they were trying to do so what I'm saying is Sdn we have the flow table and these gives these decoupling of a very fast data plane in a very much slower Pinero plane the moment you bring middle boxes and per packet processing into this picture right which seats in the data plane it's not clear to me how the separation of control plane and other thing happens right but I thought that the part of your question I would object to is we didn't bring little boxes into this picture they are part of getting here and we're just we're just dealing it so that they would be part of what we manage but but wasn't my idea to bring them there that ok so thank you very much you

Channel: stanfordonline

Views: 106,986

Rating: 4.8992043 out of 5

Keywords: stanford, stanford university, stanfordonline, scott shenker, seminar, ee380, computer systems

Id: WabdXYzCAOU

Length: 71min 7sec (4267 seconds)

Published: Tue Jun 04 2013