Hi there. Today we are very, very lucky to be talking with Dr. David Clark a legend in the Internet architectural space. Dr. Clark led the development of the Internet from about 1981 through 1989 where he acted as the chief protocol architect in the development of, of many of the Internet protocols. He chaired the Internet Activities Board. And recently he's been very involved in various clean-slate efforts with the National Science Foundation and others who help us think about next-generation Internet architecture. So, we're going to talk with Dr. Clark today about software-defined networking and its role in the future of Internet architecture. So, thanks for your time today David. >> Oh, I'm very happy to talk. I think this should be fun. Stu just going to start with the first question, which is that one of the paradigms for software-defined networking is actually the separation of the data and control planes. And that's, that's something we've talked a lot about in the class, so far. And I was wondering, in the original design of, of the Internet architecture, did you think about similar separation between data and control planes? And i, if not, why didn't you think about it at the time? And if so, why didn't you ultimately adopt it at the time? >> We actually thought about it a lot. And I think there are a number of reasons why we didn't do it. One of them was sort of philosophical. We, we were building a system where everything just barely worked. The routers kept crashing, the end nodes kept crashing, everything kept crashing. And in order to make this work, we needed to be reliable. And we had a, a principle which we've clearly compromised over the years. But the principle was that if my computer was up and your computer was up we should be able to talk to each other. And we shouldn't be dependent on third party boxes in the network over which I have no control, which can crash. And you see that happen today. You see people who are attached to a network, and they can't talk to each other because the DHCP server has failed. And you find people who can't get to a website because the DNS server has failed. And I think those are valuable services, and we understand why they're there. And what we do is make them really reliable. But we thought about building an Internet, well you've gotta have a router. But the question was well, if the router's up, do I need anything else that was up? And the idea that, that there's some server off some place that's going to tell what, the router how to, how to manage routes just made us uneasy. And there's a, there's a very obvious problem which I think STN has had the guts to address. But it's, it's how does the network work if the server that's giving you the routes gets partitioned from the router that is supposed to have the routes? And, or what happens if a link goes down? You sort of have to rebuild the, the, the path from the server one link at a time so that it can tell the next router what to do. And we had this tremendous emphasis, in the beginning, of building a network that was robust to failure. And we realized we just didn't know how to build algorithms that could reliably reconstruct the routing after arbitrary links had failed. I don't mean the routing between all the machines. I mean the routing from the server to all the, all the routers so that it could tell them what to do. And there's something very simple about the idea that the control messages follow the available patterns on the data plane. If the data plane is up, then the data plane is up. The control messages follow the data plane. Then if the data plane is up, the control plane is up. And we knew how to reason about that. We knew that it was going to limit the set of routes we could build, because there are only so many things you can do in distributed algorithms. And I think we all understood that if there was a centralized computation, centralized for some scope we understood that you could do different kinds of routing with different kinds of control. But, at the time, we just didn't know how to build those algorithms. And so, we went down this path that said having the control messages follow the available data plane is something we know how to reason about. It minimizes the number of boxes we have to depend on. And so, we went down a path which, I think, created a tremendous path dependency. Now I have to say, in, in the sort of early stages of the design of the Internet, when our friends, the telephone company, mostly spent their time saying it won't work, it won't work, it won't work there was a really interesting piece of advice they gave us which is there's a critical infra interface. That, that's a term of art in the early debates about modularity. It was, by the way, my phone company friends who taught me that it's interfaces that define industry structure. We think of interfaces as defining modular components, but what they pointed out is the modular interfaces are where industries can interface. And they said you've left out a critical interface, and it's the interface between what you might call the big iron function of a router, which is moving lots of packets around, and the route computation. And they said it's stupid, stupid, stupid that that's not a clean interface, because, without that interface, then the guy who sells me the big iron is the guy who's selling me the routing protocol. And there's no reason to think that the same company can do both things very well. I want best of breed in both, but for that I need a, a clean interface. And we said oh, but is that an interface across the network, or is it just an interface, or is it a plug on the side of the box? We didn't know how to think about it, so we ignored them. >> [LAUGH]. >> And so, there is no cut point there, and, in retrospect, I wish we'd put it in. I don't know whether it would have looked like the OpenFlow cut point, but the people in the phone company absolutely understood. And, of course, at the time they were trying to take all the control algorithms out of the number five VSS and put them into what was called the intelligent networks so that they could do more complicated routing of phone calls. It's exact same idea. So, so, the idea was clearly understood. It was debated. But, at the time, we just didn't have either the algorithmic sense or the, or the, or the energy to say we're really going to try to think all this through so we can build a highly robust, recoverable, reliable system that moves the route computation out of the routers. We just didn't know how to do it. Yeah. Now, that's, that's really interesting. Actually that jives a lot with some of the history that, that I've read about AT&T's network control point and their, their 800 service and the, the intelligent routing types of stuff that you mentioned. So, that's, that's, that's that's pretty interesting. I guess so you've, you've spent a lot of time working on the original Internet architecture and in your retrospective paper where you talk about some of the design principles, and, and priorities and, and non-priorities, I guess you could say, at the time of the original design. You sort of list out you know, a bunch of, a bunch of properties that you think were important. and, and then some that, they were less important, I guess. In particular, you mentioned account, accountability or accounting, I think is the word he uses. Kind of almost like an explicit non-priority. I'm wondering sort of how well you think the original Internet design sort of achieved, you know, achieved the designed priorities that, that you list out there. And whether or not SDN or control data plane separation makes it easier or possible to achieve some of those original design priorities better than the original set of technologies and protocols? [BLANK_AUDIO]. >> It's an interesting list to go back and look at. I actually did that recently. There's a, there's a revision I just did. I haven't published it any place yet, but there's a revision I did of, of that paper from 1988 where I went back and said, well if I was going to say this in 2013, what would I say. You know, sort of a 25-year retrospective on that paper. I think that, of course, you have to remember that paper itself was a retrospective. It was written in 1988 to try to capture the thinking that had shaped what we were doing in the late 70s and early 80s. So, the paper itself was, at the time, was a retrospective. And to a certain extent, the priority, or the ordering, of the points in that paper reflected what had actually happened. So, you know, we, we sort of talk about the points in that paper. The, the things things that at the top of the paper, which I, the top of the list, which I think we did pretty well. Internet communications should continue despite loss of networks or gateways. I think we did a pretty good job of resilience. I think we didn't do a good job of understanding how to build routing protocols that converge rapidly, especially at the global scope. So, if you look at BGP today, it takes far longer than we would like to, to converge, because we didn't know how to limit the problems of, of route propagation. But, certainly, the dynamic protocols work pretty well. And, in fact, I think it's some of the, the, the human-oriented management that people put in where they say, well, yeah, there's a route, but I don't want to use it for business reasons that have actually somewhat impaired the user resilience. We don't, we do a reasonable job, I think, of supporting multiple types of service, but this is, this is an area where, I think, the community has a little bit of blinders on. What we meant, what I meant by communication services in this paper was, was things like real time flows, right? Or, at least, I think that's what I meant. I have to go back and look at the notes and see what I actually meant. But the point is that we designed some quality of service stuff in the 1990s. It did not get deployed in the public Internet. It's been deployed in corporate nets, and it worked pretty well. It's used, it's widely used in corporate nets. And the reason it was not deployed has nothing to do with the technical problems. It has to do with the fact we didn't engineer the economics so that the providers understood why deploying this would cause them any increase in revenue. But there are certain things we can't do on the Internet today. There are things related to really highly reliable, real time applications. The, the one we always talk about, which is perhaps a little bit of a, a sort of a, a stretch, but nonetheless it's, it's the one we always put on the table as telesurgery. >> Uh-huh. >> And the point is well, you need, you need some controlled latency because you're trying to see what's going on there. But it's also really, really, really important that the network not go down, and, and I have a recurring conversation with the, with the real time community. And what the real time community says is you don't have good tools in the Internet to control latency. So, we need a new network. And I say we do have good tools in the Internet to control latency. And if you'd like to build a test bed in which you try those tools out, I'm willing to bet you that you'd find the latencies are controlled just fine. The fact that it's not on the Internet doesn't mean it's not in the protocol suites. And what we finally discovered, after talking for about a half hour, is that what they really want is a network that never goes down. In other words, they want to make sure that even though the middle of the country vanishes into a cloud of smoke, that the application can still run. And I said what you need for that has nothing to do with control of latency. It has to do with finding disjoint routes and mapping flows onto disjoint routes. And we don't do that very well on the Internet. There's talk about TCP taking multiple paths, but, but this takes us into a, a space where I'd be interested in your reaction about SDN. I think that one of the reasons we can't reason about really robust services on the Internet is that we have over virtualized to the paths. And what I mean by that is the routers think that they're computing routes on top of links. But those links are usually virtual links. In the old days they were built out of MPLS, although people who do SDN today may not do MPLS anymore. But those sit on top of lambdas that sit on fibers that sit in bundles that sit in tunnels, right? And when the Baltimore fire, in the, in, in the fire in the Baltimore Tunnel, it occurred, it didn't just burn up a MPLS flow, it burned up a whole bundle of fibers. And all kinds of things. >> Right. >> That people thought disjoint turned out to have a common failure mode. And so, if you're sitting at the IP layer, or you're sitting at the MPLS layer, and you say I'm trying to set up two flows that are physically disjoint, we don't know how to figure that out today because we've over virtualized the infrastructure, so you can't ask that question. There's no way you can say. >> Right. >> Do these flows go through the same fiber bundle? And that is a problem that people who really, really, really, really care about highly reliable networks have to solve by hand, if you look at something like air traffic control. >> Absolutely. >> So, I mean, I think there's sort of a question back to you which is I've never really understood about how software-defined network can cross layers and whether it helps with the question. For example, if I were to say to the controller give me two paths that are disjoint. And then, of course, we have to run a protocol on top of the material and how to do that. But, but, but I've never quite understood whether SDN makes it easier to do that. Yeah, that's a really good question. I mean, I think I'm not sure that it, it really does make that easier. When thinking about the example you, you mention about the Baltimore tunnel fire I was reminded of, there was a Ph.D.thesis from from someone by the name of Sean Gorman almost like 10 or 12 years ago where he basically mapped out all the fiber paths in the U.S.. And he did actually, I, he did actually point out the, exactly what you mentioned, which is that, you know, if you want to find the critical points in the Internet in the U.S., don't go to the exchanges. Go to, you know, some trench along a highway in Oklahoma, because everything between the east coast and the west coast is actually going, you know, going through, you know, a few trenches, for example. And all the fibers, like you said, are sort of bundled there. And I sort of feel like, you know, SDN might be able to get you, you know, it, it does, in some sense, blur the boundary between the IP layer and, and, and layer two. But, in order to answer that question about sort of true independence, you almost need to know like what fibers are your circuits being mapped to underneath. And I'm, I'm, I know that ISPs spend a lot of time trying to keep their databases up-to-date, trying to figure those types of things out, and. It's not clear to me whether or not SDN has an answer to that. Although I haven't spent a lot of time thinking about SDN at that layer. There are a few companies that are in the space of like turning up lambdas and using SDN's to turn up lambdas. And maybe, maybe the people operating at slightly lower layers might have a better answer there. But, but it's, I'm not aware of, of you know, any, anything that, you know, any existing solution to that in the SDL space. >> Right. I >> There's a, there's a long conversation we could have there, and we probably shouldn't dwell on it now. But I think there's an interesting challenge to the optical people. Saying, could you give us some interfaces that, that actually allow you to query the fibers. I mean, lets use some part of the optical space that's crappy could you somehow query the fiber. So that you can ask their two lambdas are they in the same fiber because again we, we certainly in the engineering space on the internet. We have always emphasized the data playing at the expense of management tools. Anyway, let me just play with this list here for a little bit. And then we should probably go on to something else you want to talk about. We certainly did a good job of accommodating a variety of networks. That's one of the reasons the Internet experience is so variable, we said it ought to be able to run over anything. I think that was a good choice, but it means the applications have to be very adaptable. The fourth thing on the list was, the internet must permit distributed management of its resources. And I think this is something we should talk about, because I wasn't here arguing for a routing protocol that runs on the routers. What I was really saying is, there are going to be different parts of the internet that are run by different institutions. And you know AT&T has to be able to manage their part. And MIT has to be able to manage its part. And Georgia Tech has to manage your part. There isn't some global, centralized thing that's sitting above all of these autonomous systems. That wouldn't work. It wouldn't scale. So I think it would be, there's an interesting question to come back to, which is what does SDN mean in the multi-provider space? Cost effective, I don't know. Let's not, you know, we optimize the links, but there's so many other expenses in the system. I think we've learned that the size of packet here is not the issue we're dealing with. A host attachment with a low level of effort. I don't know, we could debate that. I don't think it's too related to SDN. The last one in the list, and what I said about this list, is it's not that we rejected them, it's just this was sort of a priority. I said the resources used in the Internet architecture had to be accountable. That had nothing to do with whether we've built an accountable Internet. Which in Washington today, means that we can associate a human being with a reaction. So we can throw them in jail if they screw up. >> Right. >> This was essentially saying, if I use resources, I should be able to bill them. And we didn't put any accounting tools in the internet. And, and in fact, there's a, we could have an hour long conversation, I'll just bookmark it here. But there's absolutely no way in the Internet when I have a flow of packets going from me to you. To tell whether the value associated with that primarily accrues to me or to you. In the Internet, I'm sorry, in the telephone system we have this idea that, the sender paid for a call unless the receiver agreed to pay for it. Which is an 800 number. And if the receiver agreed to pay for it,. Then the center could call without incurring any expenses. So the two parties could sort of in, in a crude way negotiate about which end of them had more value. But we never had anything like that in the internet. And, and I think that's one fo the reasons we don't have QoS on the internet. It's one of the reasons why the access providers today are whining about the fact that they have to carry all of this content from Netflix. because nobody's paying them to do it. Wink, wink, wink. And so there's a huge space here that we're only beginning to sort out. And what's happening today is we're sorting it out using the technical tools and the internet today which are pretty feeble. Which means we're primarily sorting it out in terms of business and negotiations and lawsuits and things like that. And that's a really interesting area and I'm not sure what SDN has to do with it. >> Yeah, I, I, actually that's, that's a really timely, it's definitely a really timely observation. Particularly in light of what's going on with these quote next generation peering wars. With you know, Netflix and some of the access network providers. And yeah I don't know if SDN has anything to say you know, whether or not you know, whether or not we can come up with new business models or anything of that nature. That might help us solve these types of things. But I guess one thing that you've done some work on is these tussle spaces. And I wonder, actually, if, by decoupling some of the policy from mechanism. For example, like, the fact that you could, maybe, define a policy. In such a way that it's independent from how it's ultimately, you know, implemented on the switches below. I mean, maybe, maybe there's something there where, in contrast today. Where, we're pretty much stuck with, you know, BGPs, knobs and local preference. And things are kind of you know, operators or ISPs in some sense have their hands tied,. Potentially maybe with more flexibility could some of these tussles be resolved outside of the context of the protocols? >> Well, I think there's two levels of tussle. One of the things I've always like about the idea of, of OpenFlow or sort of centralized route computation,. Is that you could actually imagine simultaneous route computations running that have different attributes and different packets. I don't know what it would be driven off, you know, a QoS flag or something like that could pick one route over another. So you could actually have multiple, simultaneous routing graphs. Impulse on the same counter activity graph. And I was trying to, I don't know how important it is but it struck me as a really clever idea. But when it comes to the, tussles between ISP's, I actually don't know what SDN can do for you. Now this is fundamentally a distributed computation. That is to say, I have my policies, you have your policies, it's not a centralized thing. It's possible you could imagine a world in which, somehow, our, our route computation boxes talk to each other. So there's sort of an inter-provider protocol there. I don't know how well developed that thought is in SDN space. But clearly, that's going to have to be a global standard. Because all of the ISPs in the world are going to have to standardize on how they talk to each other. So you'd have to build a, a routing policy language. And I think that's a really interesting challenge. But I. Well anyway I think, I think that let me just say that, it's a really interesting challenge. I think BGP today is definitely constraining what the ISP's can say to each other. They'd like to say more complicated things then they can as you clearly understand. The thing I don't know, the thing I don't know is how much flexibility inside my own ISP. The flexibility that you can get from running something like SDN today. Helps me in implementing what it would mean to translate the, the, the intra-provider policy assertions into stable packet flows. So I think it's a really interesting research challenge, but I actually just don't know how much SDN could help. Yeah, that's, that's a really, it's a really fascinating question, I think. There's been some work, I think, you know, Jen Rexford's group has done some work on policy language-type stuff for SDN. Where they talk about like, what do you do when there are like two conflicting policies? Like what happens when the load balance policy conflicts with the security policy and so forth. But I think something that's been totally unexplored is what happens when this ISP's policy conflicts with that ISPs policy. And how do you know how do you resolve that type of conflict? I've seen nothing of the sort to date at least. But I, I think it's like a really, really interesting question. Certainly, BGP, I don't think is ever going to have the answer there. Given the. >> Right. >> Extremely crude knobs that, that, that we have there. But potent, it seems like there's some potential to, to work on there. >> Somebody showed me a picture from inside AT and T's networks. It was what the packet layers, or the packet headers actually look like. And there were 18 headers. There were I think three IP's, two MPLS's a UVP, and this is what the layering really looks like. And if you ask, why do they do this? It's because different people with different scopes of responsibility were solving different problems. You know, traffic spread or I don't know what. And, and basically they do it through a series of encapsulations. And that's just stupid. I mean certainly we're going back to a unit should be cost effective. If you have a packet with a packet and it's got 18 headers on it. If somehow you could take that and solve it by doing policy composition and the SDN controllers as opposed to header composition in the packets. You'd be a lot better off. But what you have here is different people with different responsibilities trying to do their job. And we have a modularized the control mechanism rights so that. So they know how to do it. They end up of course because these are headers being nested, which actually may not be what you need at all. But policy composition is a critical problem for large ISP's today. And if you can, stop doing it by putting encapsulating headers in. >> [LAUGH] >> And start doing it by putting policy compositions in a box. I think we would be just gloriously better off. >> Yeah, I know. That's a really good good exhortation, I think, to the, to the research community, for sure. >> Well, we polish the data plane. And we have ignored the management plane and the control plane from the very beginning. And I've yelled about this. The trouble is,. And again, I don't know what SDN has to do do with this. But there have been research groups that have said, well okay, we're going to focus on management. And, it has not been a, a sustainable exercise. And I think the reason is, there may not be a coherent thing called management. The best papers on management do not have management in the title. Right, right. >> There about [INAUDIBLE] or something like this. And, and I think the Stanford Study Management may, may, may actually be a malformed utterance. Because there isn't a coherent thing called management that you can study. On the other hand when you talk about composition of policy. You're forcing yourself to think about the things that do it or act with each other. But when we persist in publishing papers in SIGCOMM in which we get the data plane to work a little better. And I, I personally sort of push back on this. But, you know. >> It seems, it seems to me like I mean, a slight tangent. But it seems to me that, like, one of the reasons, maybe, that we focus on that, that is it, it's pretty easy to measure the data plane. I mean we know how to measure packet forwarding rates and packet loss rates and so forth. But measuring how good a control plane is, seems a little bit fuzzier, I guess you might say. I don't know, would you agree with that or do you have any thoughts about? >> Well, [CROSSTALK]. You've, you've manifested a particular point of view. I'm not trying to give you a hard here, hard time here. But you've manifested a particular point of view which is ours is a performance discipline. And therefore, the evidence that you've done something better is by measuring some parameter and the curve goes up. >> Correct. >> And I don't even know whether we know. What the measures of quality are nevermind how to measure them. I don't even know what the metrics are for a good management system. Because a lot of the problems we are dealing with today, problems of tussle and aligning business interest and security. There not amenable to a quantifiable metric. Which is of course a horrible problem for our field. As somebody cynically said about about SICCOMM you get your paper in if the curve goes up. And so, >> Right. >> How do you, how do you, how do you think about some of these things, where some of the consequences may be intrinsically qualitative. So I think you raised the right question, but it's actually worse than, it's actually worse than you said. [LAUGH]. >> Yeah, I don't know I mean I guess it's, it's sort of longer discussion about how we sort. You know, how, how we sort of change the thinking of the community or, or value structures but yeah. Maybe, maybe that's another hour. [LAUGH] >> I think it is, and. >> And, so, I know you've been, like, really involved in, in the National Science Foundation's, find and future internet efforts. And there, there have been a lot of, papers and articles published about, this so called clean slate internet design. In fact, this discussion's been going on almost for a decade now. So I was, I was wondering if you could talk about your role in some of NSF's future internet architecture efforts. And whether or not you think that SDM has played a role in those and if not why hasn't it? Played a bigger role. >> Actually the answer, Yeah we can talk about that. But the answer relates to what we were just saying. The other project's been going for maybe, I don't know, eight years or so now. It started off with some exploratory stuff. The challenge to the community was very easy to articulate. What do you think the Internet of 15 years from now should look like? The challenge was, don't say how you're going to make the Internet a little better today, how are we going to do it, incremental improvement. That's fine, I like that research. But there ought to be some subset of people that say okay, but what are we, what's the 15 year goal? What do we want it to look like out there. And if you could describe a vision to me that was really compelling, then you know, incrementally we could sort of try to get there. The research that NSF has funded has proceeded through several years of small sort of single PI collaborative grants. And then, it proceeded to four large rewards for people who were trying to come up with coherent alternatives. And in fact, there's currently a solicitation that just, just close to find those projects for another couple of years. So, so it's a fairly ambitious activity, but I would say and I've been pushing against this. That in fact, all of these architectures focused on alternative visions of the data plane. >> Mm-hm. >> And when you ask most of the how do they do routing, they say, routing is something that you have to be able to replace. Just the way we've replaced the, the interior gateway protocol several times, you know? We started out with. Rip and, you know, we've replaced it several times. The, the way you do routing inside your network, nevermind BGP, most of us haven't gotten to BGP. But the way you do routing can't be part of the architecture because it has to be replaceable. We know we've had to replace it in the past. And therefore, for the moment, that's not what we're focusing on because our architecture will make it equally replaceable. And so, we're not going to do that. So, we just assume that there's some other group of people over there that are going to do routing. And I think a lot of these people would say something like SDN could absolutely do our routing, that's not true for all of them. But something like SDN could absolutely do our routing. And maybe somebody else in the next room will figure that out. So routing has not actually been a distinctive part of any of these pro, proposals, with one exception. And the one exception is named data networking. And I don't think we should spend a lot of time talk, talking about named data networking here. But just, you know, very briefly, the idea is that when you send off a packet to find a piece of information. The destination address in the packet is not the destination machine where you think the piece the information is. It's the name of the information it's the name of a packet. And by some magic means the packet feels it's way through the network until you encounter the piece of information. The piece of information comes back. That absolutely transforms and sort of resets to 0. How you think about routing. >> Mm-hm. >> And of course, routing was the magic sauce that makes NDN work or not. But that's not a conversation about SDN, so we probably will table that one for another conversation. It's fascinating. >> That's interesting, I mean it seems like from what you're saying about many of the projects though that since they sort of punt routing aside in some sense. And expect someone else to solve it and, you know, SDN might be a good way to solve it. In some sense, one might think of SDN as, as complementary to many of those efforts or potentially even a, a keystone. Because so many of the, the project ultimately depend on that working properly, but don't make their efforts to address it? I think that is right and again there is a different answer for every one of the projects. >> If you look at the Nebula Project, where the forwarding plane is based on icing. Icing is a source routing scheme. A very rich, expressive source routing scheme where the header contains these proofs that you're allowed to follow the path. And as you go down the path, there's this computation so that you can look at the packet. And you can see compu, using crypto guru, crypto magic, that the packet actually followed that path. It's a source routing scheme. So I, I don't know what it means to say you run SDN underneath a source routing scheme. But, in fact, they're not trying to forward packets using icing. You're not forwarding router by router, they're following the routing domain by domain. So it's really source routing at the domain level. And it seems to me that inside the domains, they absolutely need a interior gateway protocol. Or a, an SDN just as much as everybody else does. But I've never again thought about what it would mean to run SDN under these icing. Well that, that's sort of like fine that's an interesting habit. You could be talking to the icing folks about that but. >> Yeah, yup. I know you, you mentioned, I mean in a lot of the talks you've given on, on future internet. You've talked about security and this sort of importance of considering security in future internet architectures. And certainly some of the talks I've given on, on various SDN types of architectures. One of the things that comes up invariably is, is this more or less secure than, than the existing internet architecture? Because yeah, couldn't someone attack this controller, or, or whatnot? I was wondering if, if you had any thoughts about just, sort of the most important security problems. Just in general that we should be thinking about. And whether or not you think SDN has anything to say about it. You know, does it make, do, do, does SDN make the Internet. Does that type of architecture make the Internet more or less secure? Or are there aspects of the control data plane separation that provide some opportunities for improving security? >> So I'm going to give you a long answer, and I actually feel that, I have a particular point of view with SDN here. And I haven't been able to find anybody who buys it. So, I'm going to, I'm going to air an original idea here with you and I'm curious to see what you think. I am relatively uninterested in the question of oh my god, they could attack the controller. I believe that when you have a security problem that is essentially solvable by technical innovation. We can solve it. >> Right. >> You know we're having a fight to get secure BGP. We're having to fight about security DNS. But in some sense there's no, well I, I started to say there's no tussle. Of course, there's horrible tussle around those but, but in some sense. They, they exist at a technical level where the technical solution could be done. So, so I think there's the fundamental problem that SDN has. Which is, okay, if the network is highly unstable and links are going all, up, up and down. How do you make sure that the controller can reconstruct the network, step by step. Knowing that it has a data path to the next thing it has to control. How do you build, the data plane back so that you control less [UNKNOWN]? Fundamental problem. But yes, I'm sure you can replicate the servers. You can have, you know, you can have all kinds of things that computer scientists know how to do there. That doesn't really worry me. I think the real security problems we have in the Internet are not the vulnerability of the network itself. It's the question of what role the network plays or the network can play in securing the higher level activities. Which, as architects, we don't consider the Internet, we consider the applications. But if you look at all the espionage that's going on today, this is not occurring because the machines have been penetrated. It's because we're stealing user credentials using phishing attacks. And so, the answer is, well, what can we do to prevent that? So, so let me try a, an idea on you here. A lot of the issues in this case have to do theft of identity credentials. And once I've penetrated computer and installed malware on it, then I'm you. And, and so you know any time I log in I'm empowering you to do the things you want to do so log in doesn't really help a lot. But imagine that we went to an architecture where to do certain dangerous activities, such as sending data outside your corporate perimeter. Two machines had to concur. Now, human beings have to make all this work. It's unworkable. But imagine if you designed a- >> It's almost like a dual signature on a check or something like that. >> Something like that. That's right. The applications have to be designed so that this happens as part of the normal application data flow. But imagine that there's this other box, off to the side. It's sort of a mother, may I kind of thing. You have to go through this other box, and say, I'm about to send data out. And that box could say, well I want to do an independent validation of the credentials of the guy at the other end. The guy who's receiving the data. Because we're sending this to house, and he's getting it. And imagine that that box is simple enough. It's not running the operating systems of the day. You can't load code onto it at run time. It doesn't run macros. It's just pretty secure. I was talking to some folks at NSA, and I said, can you build that machine so that it's sort of robust enough? And they said, oh. It's a simple single function. I mean, they throw out virtual memory, right? But, once you start throwing out enough stuff, they say yeah, we can completely audit that machine. We can't run- change the code on it. It's a stable machine. That is not penetrable. And that machine has to concur. So, so now you're saying, well I want to send data out of the network, I have to get that other machine over there to concur. What we're really talking about is that there's certain data flows. That shouldn't be permitted unless the security architecture says that they are permitted. And that's exactly the kind of policy that SDN can express at the data level. So SDN could actually, you can't send packets to the firewall unless that guy over there says it's okay to send packets to the firewall. And the application has to be designed so you, in the normal flow, which is to say in the absence of a security penetration. That authorization will have been attained before you even try, so you don't know there's anything wrong. But if some guy comes in to your computer and breaks in, he can't do it, because that other computer hasn't been penetrated, and it won't concur. So I think SDN as a control of what flows are acceptable, would be a really interesting tool to deal with higher level security. If the applications were designed in such a way that the security policies. And, or, sorry, the implementation, the steps necessary to comply with the security policies, were embedded into the normal workflow of the application. >> Yeah, I think this is really a fascinating point. I mean, we've, we've done a little bit of work on for example, if you've got an insecure web application,. How do you make sure the data doesn't leak through cross scripting or cross site request forgery. And can you use mechanisms in the network layer to, to, to kind of prevent those types of leaks. And I think there's something really interesting in that architecture that you present right. Because we think about web apps right and, and you know how they are developed and deployed and so forth. And I think it's you know, it's it seems safe to say that these are fairly tough to secure. And you know, it's not just the nature of, of the, the run time environment. It's also matter of the you know development cycles and auditing and everything. And yet, we've got these sort of brittle whim apps. With really, really important data sitting behind them. And what if we had a network that could essentially prevent those leaks from occur, from, prevent the application from leaking. Even in the case when a compromise had occurred. And, and I, I think that seems like a really ripe area for the type of application or architecture that you mentioned. Because like you said, we know. I mean, we can maybe understand a little bit better about what types of data or what types of flows should be allowed from point A to point B. That to me at least, seems a lot easier to reason about than. Does this web application have a particular vulnerability that's going to allow data to leak. >> Yes, I completely agree with you. It's sort of like, it's sort of like, the inter-machine version of sandboxing or something like that. I'm not sure the analogy tells us a lot, but the point is at the application level you know what sort of data flows are likely needed. Of course you don't want to kill off the, the authorized, but exceptional patterns. You have to think how to make that work. That's the same but true with sand boxing. Sometimes I want to get something out of the sandbox and how would I do it? And I think the answer in that case, as in the example I gave you. Was well, maybe what you need is you invoke what in the old days, in the security world, used to be called the trusted process. Which is uncorrupt, uncorrupted process, and you can go to it and say, this is what I am trying to do. It involves declassification, taking something out of the sandbox. Verify to me that that's okay. I think, I think that's a good way to think. We, we clearly have to rethink how we think about security. And I, I do think SDN's a building block in that space. >> Yeah that's, that's a really, really great insight. I wanted to actually just ask another question about, about sort of history. Since since you've certainly been involved in, I mean you sort of witnessed various changes. And proposed changes to internet architecture over the years in my reading of history. I was really struck in reading some of the, history of active networks in particular the motivation behind active networks. In, sort of it's goals and enabling the deployment of new service on the network and such. And as I read some of the motivation for it. I thought wow this is really similar to some of the motivation that cited for SDN and, and OpenFlow. And I was really curious as to your thoughts and perspectives. Given that SDN's obtaining so much attention from industry you know, why, why is it? Do you think it's a question of timing? Do you think it's a question of the technology that's enabling it? Do you think it's a question of like, what problems people chose to focus on at particular times? >> I, active nets means more than one thing. If you were to talk to Dave Tennenhouse, or Dave Wetherall, you might get a slightly different answer. Then you talk to Larry Peterson. You know, Larry Peterson's comment is that a lot of what he learned working on active nets. About how to put multiple independent third party pieces of code into a machine is what led to PlanetLab. And PlanetLab is a fantastic success. But I don't know whether if you ask some of the other active net activists they would say that what they were trying to build was, was, was PlanetLab. Some people interpreted the active nets very narrowly which is that were actually trying to put third party algorithms onto routers. And we're actually trying to send the algorithms out in the packets. I think that narrow interpretation simply resolving the problem that was extremely hard to problem and didn't exist. And people didn't need to program the forwarding plane. The forwarding plane works pretty well. And I don't know what it means to send algorithms out that are in some sense competing for the forwarding asset. In other words, I, I send out an algorithm. It gives my packets priority. I mean what does that mean? It doesn't make any sense. [LAUGH] >> That has to be arbitrated. So, I think that interpreted overly narrowly, and I'm not trying to be, I'm not trying to sort of caricature PlanetLab. I mean, the act is necessary, I think, interpreted overly narrowly, it was solving a problem that in fact was not a well-formed problem. If you, if you thought about it as trying to put an algorithm in a packet to modify the forwarding plane. If you set out what services in the net, and I'm thinking about, now, the application level. And I just like some services out there, like caching or something like that. Well, clearly, we've moved the Internet in the direction of highly distributed applications, all of the work on CDNs,. And CDNs are not just content replicators at this point, they are platforms for application distribution. But we are, and by the way the, the cellular people are now moving the what they call the cloud. That's the new word, right? They're now moving fragments of the cloud onto the base station antenna poles. Right, they're, you're getting boxes that mount on the antenna poles that have got a platform in them for any third party code, application or code. So, so the question is, what happened to the brand name Active Net, and. In which directions did it go? Because if you look at something like planet lab I think we not only got a amazing powerful research vehicle there but it actually did teach us a lot about cloud. And so I suspect a lot of people would think I was insane if I said that virtual machine cloud management is sort of one of the outcomes of active nets. But I think if you, if you talk to Larry, he'd say, well what I learned was, all of the issues about running potentially competitive code on a common platform using virtualization tools, and how to keep them separate, and what it means when you run out of resources, and all these issues. But I think SDN is solving a problem which is incredibly timely. I think operators, using large nets today, as I said earlier, if you look at this picture from AT&T which is moving away, they are absolutely exceeding the brain capacity of even very smart people to solve the problem of all of the different management problems. They have traffic engineering, load balancing, all this kind of stuff. And we somehow have to pull that into a place where we can solve it. A centralized way these problems of policy composition. Doesn't mean we know how to run algorithms that do policy compo, composition, at least we have a vehicle for doing it. So, so I think that SDN is in fact a framework that is solving a problem that is staring commercial providers in the face, and I don't think that was true of Active Nets. >> Yeah that's, that's a really good point, I mean it kind of reminds me of you know, of the, of the research that, that we were doing like, you know, ten years ago even in the context of BGP for example where we we're saying you know it's really hard to reason about, you know what this protocol is doing in terms of like where's the traffic going, and how do you do load balance? And how do you make sure that you don't have forwarding loops or oscillations or things like that? And that was just like one protocol, right? And as you're talking about the example that you mentioned from AT&T where you've got you know, oodles and oodles of, of packet headers and encapsulation, different protocols interacting. And yeah, your point is, is super well taken. So yeah, I guess I mean that's the, pretty much is, I guess we're at kind of a good wrapping up point. I guess. One final thing that it might be fun to just wrap up with is, is kind of looking forward, type of question. I mean, I guess, you know consider, consider people who are maybe taking this course or maybe, maybe you know undergrads that you talked to or maybe other, other engineers who are, they say they want to work on network architecture. so, I guess first question is, you know, in your view, what, what is network architecture? Like how would you, how would you define it? And it seems to me there are a lot of different definitions for it. But I guess just the you know, question to wrap up with would be What types of internet architecture problems or what types of problems in the big I internet, maybe, are, are things that you'd like to see people work on? And do you think SDN plays a role in those problems or not? >> Well let me, let me answer that part in pieces. We do throw this word architecture around a lot without, without exactly defining it. Clearly architecture is both A discipline, a practice. I mean if you talk about architects who design buildings it's, it's a design process but it also produces a, a, a result you know you could talk about Gothic architecture and, and it sort of becomes a recognized style. And the, the John McCluskey as I said was helping me try to articulate what this means in the context of the future internet stuff and he said you know architecture is that aspect of your system design which. Characterizes the, the basic design principles that you hope are going to hold for decades. It's that framework, it's that set of constraints and accepted, limitations which stabilize the basic skeleton so you can change all the other stuff. So,. The idea that an architecture lets you replace the routing is actually a very strong statement. Which is to say, it, it is key assumptions you made that make that happen. And so, you could say, well, for example, what does the internet architecture have to do about routing? because it says nothing about routing. Well, it actually has got one little teeny tiny toehold in there. Which is it's got, what today we know as a hop [UNKNOWN]. Although it's called TTL. Which means that there's something about the data plane that tells you when you have a loop. Now, I don't know whether that's the right building block for, routing algorithms, but, it is a building block we put into the architecture, because we thought, looking into the future we had no idea, it would help with stabilizing a wider range of dynamic routing algorithms. And you can look at a couple other places in the internet where there's a teeny tiny hook, which is our guess, sort of in the mid 1970s, as to something that would enable a range of, of algorithms to be put in place and taken out, and put in and so forth. >> I would love to see your, your writeup on teeny-tiny hooks. I bet it's sort of like Easter eggs or something, it would be, it would be pretty cool. >> Well, it's, you know, I, I, I can actually send it if you want to show it to your class, I can send it to you. But the point is that architecture in some respects is best when it is minimal. The fewer things you have to agree on and the system still works. [LAUGH] The better off you are because what it means is that you've left more flexibility in solving problems differently in different parts of the net. And still achieve their operability. And in some sense the whole point of the internet was interoperability and nothing else. That is to say I want my net to be completely different from your net and I would like to be able to interoperate. And in fact the one thing that we are hung up on today. Is the, the syntax of the packet header. You know, we can't convert from IPv4 to IPv6 'cause it's too, well we will eventually but it's really hard. And, if you look at some of the work for example that Scott Shenker and his students have done on architectural minimality, one of things they said is that in fact, we shouldn't be agreeing on the packet headers as part of the architecture, because, if we just had stayed in the network, and that, of course, itself is a strong architectural statement, you can rewrite the header in the middle. We have to agree on global routing and we have to agree on. >> Right. >> How you control, DOS attacks and so forth, but. If you look at the future Internet project that's coming out of CMU, they basically have a very complicated packet header. In fact, it has multiple kinds of addresses inside it that are not even in series, it's a DAG. And what they're saying is, we'll try to first address, if you don't know how to process it, you fall back to the second one. So what they're saying is, we should make evolution of the address. Structure a fundamental part of the architecture. And that gets rid of the one constraint that we have in the Internet today, which is the size of the, of the address field in the header. In that respect, architecture is an exercise in minimality, which is an art. And I don't actually know how to tell a student who's interested in this. To go work on it, because I think it's important to understand it, it's important to understand the distinction between what we embed in the architecture and what we leave as a result for the people who are trying to reduce the architecture to a running system. But, but I, I think that we don't need 10,00 architects, what we need is people who understand this distinction and can see how it is that you very carefully pick the things that are in the architecture. John Doyle has called them the constraints that de-constrain, and it's the same idea that we know. When you freeze an interface. You've picked something and said it's going to be hard to change that, so you can change everything else around it. And, and so the art is finding - >> Figuring out what that is. >> Is, for 30 or 40 years. We didn't, we were I would say, with out knowing what we were doing, we were remarkably successful on the internet. But it's clear we didn't get it exactly right. And and it's clear again that we didn't at all think about putting in one sentence the word architecture and the word management in control. We absolutely do not know how to put those in a sentence. >> Right. >> We look at all of the future internet architecture projects, we have a meetings ever six months and we say okay, what are we going to talk about in the next meeting. We've done security, we've done economic variability. Every time I say we're going to do a meeting on management they all run away. So [CROSSTALK]. >> That remains one of the greatest unsolved challenges in, in your view, you think? >> I think it is, I think it is. And I think it would be a major shift for our field. To, to really emphasize fundamental thinking about management. And I think SDM is a, is a fundamental shift in how we think about control and management. We can talk about a distinction between those two, but it doesn't matter. It's a, it's a, it's a fundamental shift in the way we think about things that are not the data plane. And i think we should do more of that. >> Yea that's really interesting I mean. As you know i had quite a passion for management for, for quite a long time. You know. It's certainly as you know, one of those things that are really hard to think about. In, in, within the current confines of the current architecture. And you end up sort of like doing band aid type things, and slapping things on. Because your working around the constraints of the existing protocols. And I remember you know, when we were working on P2P configuration checking. And and Horry said, you know, don't. You know, don't design a new language. because like, no one's going to adopt it, you know, you know, it's, it's you know, it's too hard to change, you know, the existing configuration languages. And then, people are going to, you know, people are going to have to agree on that, and it's never going to happen. And, and I think that was absolutely true at the time. So we were kind of like stuck with, you know, okay, here's this thing and, you know, that we can't really change. And people are operating at a really low level. So let's just kind of like put some baling wire around it and, and, you know, run some checking scripts and it seems now that one of the things that SDN might make possible is we, as you said we can sort of separate policy and mechanism. We can think about things in a central place. Things like security and other aspects of management as well. It may be possible to do things that we just like, really had to punt on. >> So I do encourage, and you asked about students, I do encourage people to, to think about different mechanisms. I understand Hari's reservation, but, so here's my counter argument. In the beginning, we had this huge debate about IPV6. And you can go back and read the history and the things Steve Deering said. It was very conservative, and some other people are a little more flamboyant. And, and my argument was you're going to have to get people to convert. And in order to make them convert, there has to be enough of an incentive in there that they see the payoff for them. And so IPV6 should embody improvements that apply to all parts of the community. And Steve said we should take the smallest possible incremental step, because it, it'll scare people if they have to take a big step. And so we should make them a step that's not scary. Now what happened, in fact, was that most of the innovations that were described. As being possible only with the conversion to IPV6 which I would remind you includes thing like IP sect. >> Right. >> Where magically retrofitted into IPV4 once people figured out they were important leaving IPV6 was very little offers except in large to dress spaces, so sometimes. There, there are two possible outcomes of taking, being daring enough to take a big step. And one of them is it becomes enticing enough that people will actually go there. And the other is that, in fact, even though in a nominal sense you failed, in fact you succeeded. Because all your ideas leak into the current internet. And so that's why I believe in future internet. It's not cause we're going to have a flag day, it's because by asking people to envision an alternative future, all of a sudden people look at the current internet and say, "oh I could actually do that." And that would be really powerful, and maybe it won't be quite as clean and maybe blah, blah, blah, and all that kind of stuff, but. I think that's the way to, to break yourself out. So, to me, clean slate was not about the fact that we were going to have a flag day, clean state was about freeing your mind from constraint so you could imagine the, imagine the alternatives. Yeah, I couldn't agree more with that. I mean, I always sort of thought about clean slate thinking versus clean slate architecture. I mean, it's really, it's really heartening to hear you say that. >> Absolutely. >> Yeah, and it's, it's, I think it's really interesting too for when talking to operators and things, like, you know, even still today, when we ask them like. We've got STN that we'd like to deploy in an exchange right like internet exchange, what would you do with that and or or we've got we want to deploy it in this context and what kind of problems are you facing and and still you know the thinking in in that areas very much so like well I'd like to be able to do this with my local preference or I'd like to be able to do that with my AS path prepending or prefix splitting. I don't think are quite thinking at the, they are not doing the clean slate thinking yet in operations but maybe we will get there in some point.>>You have to help them think that way and you can't go to them and say here is SDM, you know that is just a mechanism, you have to go to them and say. You have some problems here, and I've worked with you long enough, You know, Jen's a good collaborator here, because she's, she's, she's, she's worked the night shift and the NOC, you know? >> Right. >> And you need people who can do that, who can then abstract and say. This is what I think you'd; you might not of put it this way, but this is what you're trying to, to add and then you say, oh, okay I understand what you're saying. And then you can say, here's my solution. You know, and you have to turn this into the solution. As opposed to being a piece of mechanism. An ISP once said to me, don't talk to me about technology, talk to me about services. And I didn't get it. And I finally figured it out. Technology is something they have to pay for, service is something that they can bill for. Right? >> No, that, that definitely makes sense. So, really, it's, it's about getting operators to speak in the language about what their problems and pains are, and not what the problems with their current mechanisms are. >> That's right. >> So then we can, we can think about the right. >> And that's part of our job, we are, we should be good abstractors. Okay. >> Right, >> And that's part of, that's part of our skill set. >> Yep. Well great I think that, that pretty much wraps things up I, I really thank you very much for your time. It's really been a great discussion and I hope the people who are watching us enjoy it as well. So. Thanks very much it was really a great privilege to have you. >> You're very welcome it was a lot of fun. >> Cool. Thanks.
