2 - 5 - david clark interview

7/28/2019 2 - 5 - David Clark Interview

1/32

Hi,there.today we are very, very lucky to betalking with Doctor David Clark a legendin the Internet Architecture space.Doctor Clark led the development of theinternet from about 1981 though 1989.Where he acted as the chief protocolarchitect in the development of, of manyof the internet protocols, he chaired theinternet activities board.and recently he's been very involved invarious clean slate efforts with theNational Science Foundation.And others, to help us think about nextgeneration internet architectures.So, we're going to talk with DoctorClark, today about Software DefinedNetworking, and its role in the future ofinternet architecture.So, thanks for your time, today David.>> Oh, I'm very happy to talk.I think this should be fun.>> So, I'm just going to start with,

the first question.Which is, that, one of the paradigms forsoftware defined networking is actuallythe separation of the data and controlplanes.And that's, that's something we've talkeda lot about in the class so far.and I was wondering, in the originaldesign of, of the internet architecture,did you think about.similar separation between data andcontrol plains?And if not why didn't you think about it

at the time and if so, why didn't youultimately adopt it at the time?>> We actually thought about it a lot,and I think there are a number of reasonswhy we didn't do it.One of them was sort of philosophical,we, we were rebuilding a system whereeverything just barely worked.The routers kept crashing, the end noteskept crashing.Everything kept crashing.And in order to make this work, we needit to be reliable.

And we had a, a principle which we'veclearly compromised over the years.But the principle was, that if mycomputer was up and your computer was up,we should be able to talk to each other.And we shouldn't be dependent on thirdparty boxes on the network over which Ihave no control, which can crash, and yousee that happen today.You see people who are attached to a


2/32

network, and they can't talk to eachother because the DHCP server has failed.And you find people who can't get to ourwebsite because the DNS server hasfailed.And, and I think those are valuableservices and we understand why they'rethere.And what we do is make them reallyreliable.But we thought about building aninternet, well you got have a router, butthe question was well, if the router'sup, do I need anything else that was up?And the idea that, that there's someserver off someplace that's going to tellwhat, the, the router how to, how tomanage routes, just made this uneasy.And there's a, there's a very obviousproblem which, I think, SDN has had theguts to address.But it's, it's how does the network workif the server that's giving you theroutes gets partitioned from the router

that is supposed to have the routes?And, or, what happens if a link goesdown?You sort of have to rebuild the, the, thepath from the server one link at a timeso that it can tell the next router whatto do.And we had this tremendous emphasis inthe beginning on building a network thatwas robust to failure.And we realized we just didn't know howto build algorithms, that could reliablyreconstruct the routing after arbitrary

links had failed.I don't mean the routing between all themachines, I mean the routing from theserver to all the, all the routers sothat it could tell them what to do.And there's something very simple aboutthe idea that the control messages followthe available paths on the data plane.If the data plane is up, then the dataplane is up.The control messages follow the dataplane, and if the data plane is up, thecontrol plane is up.

And we knew how to reason about that.We knew that it was going to limit theset of routes we could build becausethere were only so many things you coulddo in distributed algorithms.And I think we all understood that ifthere was a centralized computation,centralized for some scope.we understood that you could do differentkinds of routing and different kinds of


3/32

control, but at the time, we just didn'tknow how to build those algorithms.And so we went down this path that saidhaving the control messages follow theavailable data plane is something we knowhow to reason about.It minimizes the number of boxes we haveto depend on.And so we went down a path which I thinkcreated a tremendous path dependency.Now I have to say in, in the sort ofearly stages of the design of theinternet.When friends of the telephone companymostly spent their time saying it won'twork, it won't work, it won't work.there was a really interesting piece ofadvice they gave us, which is there's acritical infra, interface that that's aterm of art in the early debates aboutModularity.It was by the way my phone companyfriends that taught me that it'sinterfaces that define industry

structure.We think of interfaces as definingmodular components, but what they pointedout is the modular interfaces at whereindustries can interface.And they said you've left out a criticalinterface, and it's the interfacebetween.What you might call the big iron functionof a router, which is moving lots ofpackets around, and the routecomputation.And they said it's stupid, stupid, stupid

that that's not a clean interface.Because without that interface, then, theguy who sells me the big iron is the guywho's selling me the routing protocol.And there's no reason to think that thesame company can do both things verywell.I want the best of breed in both.But for that, I need a, a cleaninterface.And we said, oh, but is that an interfaceacross the network, or is there just aninterface or is it just a plug on the

side of the box?And 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 lookedlike the Open Flow cut point but, thepeople and the phone company absolutelyunderstood.


4/32

And, of course, at the time, they weretrying to take all the control algorithmsout of the number five ESS.And put them into what was called theintelligent network.So that they could do more complicatedrouting of phone calls.It's the exact same idea, so, so, theidea was clearly understood, it wasdebated.But, at the time we just didn't have,either the algorithm in sense, or the, orthe, or the energy to say we're reallygoing to try to think all this through.So we can build a highly robust,recoverable, reliable system that movesthe route computation out of the routers.We just didn't know how to do it.>> Yeah, now that's, that's reallyinteresting.Actually that jives a lot with some ofthe history that, that I'd read aboutAT&T's network control points and the,their 800 service.

And the, the intelligent routing types ofstuff that you mentioned.It's it's that's, that's prettyinteresting.I guess, so you've, you spent a lot oftime working on the original InternetArchitecture.And, in your retrospective paper, whereyou talk about some of the designprinciples and priorities andnon-priorities.I guess you could say, at the time of theoriginal design.

you sort of list out you know, a bunchof, a bunch of properties that you thinkwere important.And then some that were less important Iguess.In particular you mentioned account,accoutnability, or I think accounting Ithink is the word he uses, kind of likean explicit non priortiy.I'm wondering sort of how well you thinkthe original internet design sort ofachieved.You know, achieved the design priorities

that, that you list out there and whetheror not SDN.Or control data plan separation makes iteasier or possible to achieve some ofthose original design priorities betterthan the original set of technologies andprotocols.>> It's an interesting list to go backand look at.I actually did that recently.


5/32

There's a, there's a revision I just did.I haven't published it any place yet, butthere's a revision I did of, of thatpaper from 1988.Where I went back and said well, if I wasgoing to say this in 2013.What would I say a sort of 25 yearretrospective on that paper.I think that of course you have toremember that paper itself was aretrospective.It was written in 1988, to try to capturethe thinking that had shaped what we weredoing in the late 70s and early 80s.So the paper itself was, at that time wasa retrospective.And to a certain extent, the priority orthe ordering of the points in that paper,reflect what had actually happened.So, you know, we, we sort of talk aboutthe points in that paper.The, the things that at the top of thepaper, which I thi, the top of the list.Which I think we did pretty well,

internet communication should continuedespite loss of networks or gateways.I think we did a pretty good job ofresilience.I think we didn't do a good job ofunderstanding how to build routingprotocols that converge rapidlyespecially at the global scope.So if you look at BGP today it ties farlonger than we would like to convergebecause we didn't know how to limit theproblems of route propagation.But certainly, the dynamic protocols work

pretty well.And in fact, I think it's some of the,the human oriented management that peopleput in.Where they say, well yeah, there's a wrapbut i don't want to use it for businessreasons that have actually, somewhatimpaired the, the resilience.We don't, we do a reasonable job, Ithink, of supporting multiple types ofservice.But this is, this is an area where, Ithink, the community has a little bit of

blinders on.what we meant, what I meant bycommunications services in this paperwas, was things like real time flows,right?Or at least I think that's what I meant.>> [LAUGH].>.You'll have to go back and look at thenotes and see what I actually meant.


6/32

But the point is thatWe designed some quality service stuff inthe 1990's, it did not get deployed inthe public internet.It's been deployed in corporate nets andit worked pretty well.It's used, it's widely used in corporatenets.And the reason it was not deployed hasnothing to do with the technicalproblems.It has to do with the fact we didn'tengineer the economics so that theproviders understood by deploying thiswould cause them any increase in revenue.But there are certain things we can't doon the Internet today.There are things related to really highlyreliable real-time applications.The, the one we always talk about, whichis perhaps a little bit of a, a sort ofa, a stretch, but it's, it's the one wealways put on the table, thistelesurgery.

>> Uh-huh.>> And the point is, well, you need,you need some controlled latency becauseyou're trying to see what's going onthere.But it's also really, really, reallyimportant that the network not go down.And, and I have a recurring conversationwith the, with the real-time community.And what the real time community says isyou don't have good tools in the internetto control latency, so we'll need a newnetwork.

And I say we do have good tools in theinternet to control latency.And if you'd like to build a test bed inwhich you try those tools out, I'mwilling to bet you that you'd find thelatencies are controlled just fine.The fact that it's not on the internetdoesn't meat it's not on the protocolsuites.And what we finally discovered aftertalking for about a half hour, is thatwhat they really want is a network thatnever goes down.

In other words, they want to make surethat even though the middle of thecountry vanishes into a cloud of smoke,that the application can still run.And I said, what you need for that hasnothing to do with control of latency.It has to do with finding disjoint routesand mapping flows on to disjoint routes.And we don't do that very well on theinternet.


7/32

There's talk about TCP taking multiplepaths but but this takes us into a spacewhere I'd be interested in your reactionabout SDN.And I think that one of the reasons wecan't reason about really robust serviceson the Internet is that we have overvirtualized the paths.And what I mean by that is the routersthink that they're computing routes ontop of links.But those links are usually virtuallylinks.In the old days they were built out ofMPLS.Although, people who do SDN today mightnot do MPLS anymore.But those sit on top of Landis that siton fibers, that sit on bundles, that sitin tunnels, right?And when the Baltimore fire, in, in thefire in the Baltimore tunnel occurred.It didn't just burn up a MPLS flow itburned up a whole bundle of fibers and

all kinds of things.>> Right.>> People thought disjoined turned outto have a common failure mode.And so if you're sitting at the IP layer,or you're sitting at the MPLS layer, andyou say, I'm trying to set up two flowsthat are physically disjoint.We don't know how to figure that outtoday, because we've over virtualized theinfrastructure so you can't ask thatquestion.There's no way you can say, do these

flows go through the same fiber bundle.And that is a problem that people whoreally, really, really, really, careabout.Highly reliable networks have to solve byhand if you look at something like airtraffic control.>> Absolutely.>> So I would think there's sort of aquestion back to you which is, I've neverreally understood about how softwaredefined networks can cross layers.And whether it help with the question.

For example, if I were to say to thecontroller, give me two paths that aredisjoint.and then, of course, we have to runprotocol on top of them, and figure outhow to do that.But, but, but I've never quite understoodwhether SDN makes it easier to do that.>> Yeah, that's a really good question.I mean, I think,


8/32

I'm not sure that it, it really does makethat easier.when thinking about, the example you,you, mentioned about the Baltimore tunnelfire.I was reminded of, there was a PHD thesisfrom, from someone by the name of SeanGorman.Almost like 10 or 12 years ago, where hebasically mapped out all the fiber pathsin the U.S.And he did actually, he did actually, I,he did actually point out the, exactlywhat you mentioned.Which is, if you want to find thecritical points in the internet in theU.S.Don't go to the exchanges Go to, youknow, some trench along a highway inOklahoma.Because everything between the East Coastand the West Coast is actually going, youknow, going through, you know, a fewtrenches.

For example, and all the fibers, like yousaid, are sort of bundled, there.And I sort of feel like, you know, SDNmight be able to get you.You know, it, it does in some sense blurthe boundary between the IP layer and,and, and layer two.But in order to answer that questionabout, sort of true independence, youalmost need to know like what fibers areyour circuits being mapped to underneath.And I'm, I'm, I know that ISPs spent alot of time trying to keep their

databases up to date trying to figure outthose types of things out.And, it's not clear to me whether or notSDN has an answer to that.although I haven't spent a lot of timethinking about SDN at that layer.There area a few companies.>> Right.>> In the space of, like, turning upLambdas and using SDN to turn up Lamdas.And maybe, maybe the people operating atslightly lower layers might have a betteranswer though.

But, but it's, I'm not aware of, of youknow, any, anything that, you know, anyexisting solution to that.When we asked the ST [INAUDIBLE].>> Right, I.>>>> There's, there's a long conversationwe could have there, and we probablyshouldn't dwell on it now.But I think there's an interesting


9/32

challenge to the optical people, sayingcould you give us some interfaces thatThat actually allow you to query thefibers.I mean, let's use some, some part of theoptical space that's crappy.Could you somehow query the fiber so thatyou can ask there're two lambdas.Are they in the same fiber?Because again, we, we certainly I thinkin the engineering space in the Internet.We, we've always emphasized the dataplane 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 tosomething else you want to talk about.We certainly did a good job ofaccommodating a variety of networks,that's one of the reasons the internetexperience is so variable.That we said it ought to be able to runover anything.I think that was a good choice, but it

means the applications have to be veryadaptable.The fourth thing in the list was, theinternet must permit distributedmanagement of its resources.And I think this is something we shouldtalk about, because I wasn't here arguingfor a routing protocol that runs on therouters.What I was really saying is there aregoing to be different parts of theinternet that are run by differentinstitutions.

And you know, AT&T has to be able tomanage their part, and MIT has to be ableto manage it's part, and Georgia Tech hasto manage your part.There isn't some global centralized thingthat's sitting above all of theseautonomous systems.That wouldn't work, it wouldn't scale.So I think that, there's an interestingquestion to come back to, which is whatdoes SDN mean in the, in themulti-provider space.Cost effective?

I don't know let's not, you know, weoptimize the links but there's so manyexpenses.I think we've learned that the size ofpacket headers is not the issue we'redealing with.A host attachment with a low level ofeffort.I don't know, we could debate that.I don't think it's too related to SDN.


10/32

The, the last one in the list, and what Isaid about this list is.It's not that we rejected him, it's justthat this was sort of a priority.I said the resources used in the internetarchitecture must be accountable, Iwanted, that had nothing to do withwhether we've built an accountableinternet.Which in Washington, today means that weand associate human being with thereaction.So we can throw them in jail if theyscrew up.>> Right.>> This was essentially saying I useresources, I should be able to buildthem.And we didn't put any accounting tools onthe Internet.And in fact we can have an hour longconversation.I'll just bookmark it here, but, there'sabsolutely no way in the internet, when I

have a flow of packets, going from me toyou.To tell whether the value associated withthat primarily accrues to me or to you.In the internet, we have, I'm sorry, thetelephone system we have this idea that,the sender paid for a call unless thereceiver agreed to pay for it.Which is an 800 number and if thereceiver agreed to pay for it.Then the sender could call withoutincurring an expense.So the two parties could sort of, in, in

the crude way, negotiate about which endof them had more value.We've never had anything like that in theinternet.And, and I think that's one of thereasons we don't have QOS on theinternet.It's one of the reasons why the accessproviders, today they're whining about.The fact that they have to carry all ofthis content for Netflix as nobody'spaying them to do it.Winge, winge, winge, and so there's a

huge space here, that we're onlybeginning to sort out.And what's happening today is we'resorting it out using the technical toolsand the internet today which are prettyfeeble.Which means we're primarily sorting itout in terms of business negotiation andlawsuits and things like that.And that's a really interesting area and


11/32

I'm not sure what has to, it has to dowith it.>> Yeah, I, I actually, that's, that'sa really timely, it's definitely a reallytimely observation.Particularly in light of what's going onwith these, quote, next generationpeering wars with, you know, Netflix.And some of the access network providers.And, yeah I don't know if SDN hasanything to say about you know whether ornot.you know, whether or not we can come upwith new business models or or anythingof that nature.that might help us solve these types ofthings.But I, I guess one thing that you've donesome work on is, is these tussel spaces.and I wonder actually if by decouplingsome of the policy from mechanism, forexample.Like the fact that you could maybe definea policy in such a way that it's

independent from how it's ultimately, youknow implemented on the switches below.Maybe there's something there where, incontrast to today where we are prettymuch stuck with BGP's, knobs and localpreference.And things are kind of, you knowoperators or ISP's in some sense havetheir hands tied.Potentially with more flexibility couldsome of these tussles be resolved outsideof the context of the protocols.>> Well, I think there's two levels of

tussle.one of the things I've always liked aboutthe idea of, of Open Flow or sort ofcentralized route computation.Is that you could actually imaginesimultaneous route computations runningthat have different attributes, anddifferent packets.I don't know what it would be driven off,you know, a QOS flag or something likethat, could pick one route over another.So you could actually have multiplesimultaneous mounting graphs imposed on

the same connectivity graph.I, I don't know how important it is, butit's always struck me as a really cleveridea.But, when it comes to the tussles betweenISP's, I actually don't know what SDN cando for you.Now this is fundamentally a distributedcomputation, that is to say, I have mypolicies and you have your policies, it's


12/32

not a centralized thing.It's possible you could imagine a worldin which somehow our, our routecomputation boxes talk to each other.So there's sort of an inter-providerprotocol there.I don't know how well developed thatthought is in, in SDN space.But clearly that's going to have to be aglobal standard.Because all of the IPS's in the world.>> Yeah.>> Would have to standardize on howthey talk to each other so you have tobuild a routing policy language.And I think that's a really interestingchallenge but I, well anyway, I thinkthat.Let me just say that it's a reallyinteresting challenge and I think thatBGP today is, is definitely constrainingwhat the ISBs can say to each other.They'd like to say more complicatedthings than they can, as, as you clearly

understand.>> Absolutely.>> The thing I don't know, the thing Idon't know is, how much flexibilityinside my own ISB?The flexibility that, that you can getfrom running something like SDN today,helps me.In implementing, what it would mean totranslate the, the, interprovider policyinsertions into stable packet flows, so.I think it's a really interestingresearch challenge, but I actually just

don't know how much SDN could help.>> Yeah, that's, that's a really, it'sa really fascinating question, I think.there's been some work I think, you know,Jen Rexford's group has done some work onpolicy language type stuff for SDN.Where they talk about like what do you dowhen there are like two conflictingpolicies.Like what happens when the load balancepolicy conflicts with the Security policyand so forth.But I think something that's been totally

unexplored is what happens when thisISP's policy conflicts with that ISP'spolicy?And how do you, you know, how do youresolve that type of conflict?I, I've seen nothing of the sort to dateat least but I think it's a really,really interesting question, certainlyBGP.I don't think ever is going to have the


13/32

answer there.Given the extremely crude knobs that wehave there, but poten, it seems likethere's some potential to work on there.>> Somebody showed me a picture frominside AT&T's networks it was what thepacket layers, or the packet headersactually look like.And there were 18 headers, there were, Ithink, three IPs, two FBLS', a [UNKNOWN]and, this is what the lettering reallylooks like.And if you ask, why do they do this?It's because different people withdifferent scopes of responsibilityresolving different problems.You know, traffic spreading or you know,I don't know what.And, and basically they do it through aseries of encapsulations.And that's just stupid, I mean certainlywe're going back to, the internet shouldbe cost effective.If you have a packet with an ACK in it,

it's got 18 headers on it.If somehow you could take that and solveit by doing policy composition in the SDNcontroller as opposed to headercomposition in the packets.You'd be a lot better off.But what you have here is differentpeople with different responsibilitiestrying to do their job.And we haven't modularized those controlmechanisms and Internet rights so that.So that they know how to do it.They end up of course, because these are

headers being nested.Which actually may not be what you needat all.But policy composition is a criticalproblem for large ISP's today.And if you can stop doing it by puttingincapsulating headers in and start doingit by doing policy comp composition in abox.I think we would be just gloriouslybetter off.>> Yeah, I know that's, that's a reallygood exaltation I think to the, to the

research community for sure>> Well, we polished the data plan, andwe have ignored the management plan andthe control plan from the very beginning,and I have, I have yelled about this.The trouble is, and again I don't knowwhat SDN has to do with this.But there have been research groups thathave said, well, okay, we're going tofocus on management.


14/32

And, it has not been a, a sustainableexercise.And I think the reason is, there may notbe a coherent thing called management.The best papers on management do not havemanagement in the title.>> Right, right.>> There were a thousand, or somethinglike this, and, and I think to say I amgoing to study management may, may.May actually be a malformed utterancebecause there isn't a coherent thingcalled management that you can study.On the other hand, when you talk aboutcomposition of policy, you're forcingyourself to think about.the things that do interact with eachother.But we persist in publishing papers andsitcom in which get the data plane towork a little better.And I, I personally sort of pushed backon this, but, you know.>> It seems, it seems to me like I

mean, a slight tangent, but it seems tome that like one of the reasons may bethat.That we focus on that as it's pretty easyto measure the data plan.I mean, we know how to measure packetforwarding rates and packet loss ratesand so forth.But measuring how good a control plane isseems a little bit fuzzier, I might say.I don't know, would you agree with that,or do you have any thoughts about it?>> Well, of course, you've, you've

manifested a particular point of view.And I'm not trying to give you a hardhere, hard time here.But you manifested a particular point ofview which is our's is a performancediscipline.And therefore, the evidence that you'vedone something better's been measuringsome parameter and the curve goes up.>> Correct.>> And, and I don't even know whetherwe know what the measures of quality are,never mind how to measure them.

I don't even know whether we know whatthe metrics are for a good managementsystem.Because a lotta the problems we'redealing with today, problems of tussleand aligning business interests andsecurity.They're not amenable to a qualifiablemetric, which means, of course, ahorrible problem for our field.


15/32

As somebody cynically said about sitcom,you get your paper in if the curve goesup.And so.>> Right.>> How do you, how do you, how do youthink about some of these things wheresome of the consequences may beintrinsically qualitative?So, I think you raise the right question,but it's actually worse than [LAUGH],it's actually worse than you said.>> [LAUGH] Yeah, I don't know.I mean, I guess it's, it's sort of alonger discussion about how we you know.How, how we sort of change the thinkingof the community or, or value structures.But you know, maybe, maybe that's anotherhour.[LAUGH].>> I think it is, and so I know you'vebeen like really involved in, in theNational Science Foundation's find andfuture Internet efforts.

And it, there've, there've been a lot ofpapers and articles published about thisso-called clean slate Internet design.in fact, this discussion's Been going onalmost for a decade now.So I was, I was, wondering if you couldjust talk about your role and some ofNSF's, future architecture efforts.And, whether or not you think SDN has youknow, has it played a role in those, andif not, y'know, why, why hasn't it, soon?[INAUDIBLE].

>> Actually, the answer, you know wecan talk about that but the answerrelates to what we were just saying.yeah, the project's been going on formaybe, I don't know, eight years or sonow.It started off with some exploratorystuff the challenge to the community wasvery easy to articulate.What do you think the internet 15 yearsfrom now should look like?The challenege was dont, dont say how arewe going to make the internet a little

better today, how are we going to do anincremental improvment.That's fine, I like that research, butthere ought to be some subset of peoplethat are saying, okay.But what are we, what's the 15 year goal?What do we want it to look like outthere?And if you could describe a vision to methat was really compelling.


16/32

Then, you know, incrementally, we cansort of try to get there.The research that NSF has funded hasproceeded through several years of smalltraditional sort of single, singular PIcollaborative grants.And then it proceeded to, four largerewards for people who are trying to comeup with, coherent alternatives.And in fact, there's currently a, asolicitation that just, just closed tofund those projects for another coupleyears.So, so this is a fairly ambitiousactivity.But I would say, and I've been pushingagainst this.That in fact all of these architecturesfocused on alternative visions of thedata plane.And when you ask most of them how do youdo routing, they say routing is somethingthat you have to be able to replace.Just the way we've replaced the, the

integrate way protocol several times.You know we started out with Rip and youknow, we've, we've replaced it severaltimes.The, the way you do routing inside yournetwork, never mind BGP, most of themgotten to BGP.But the way you to routing can't be partof the architecture because it has to bereplaceable.We know we've had to replace it in thepast.And therefore, for the moment that's not

what we're focusing on because ourarchitecture will make it equallyreplaceable.And so, we're not going to do that.So we just assume that some other groupof people over there, that are going todo routing.And I think a lot of these people wouldsay, something like SDN would absolutelydo our routing.That's not true for all of them.>> Yeah.But something like SDN could absolutely

do our routing.And maybe somebody else in the next roomwill figure out how.So, routing has not actually been adistinctive part of any of these pro,proposals with one exception.And the one exception is name datanetworking.And I don't think we should spend a lotof time talk, talking about name data


17/32

networking here.But just, you know, very briefly, theidea is.That when you send off a packet to find apiece of information.The destination address in the packet isnot the destination or machine where youthink the piece of information is.It's the name of the information, it'sthe name of a packet.And by some magic means, the packet feelsits way through the network until itencounters the piece of information, andthe piece of information comes back.That absolutely transforms and sort ofresets to zero.How you think about routing?>> Mm-hm.>> And of course, routing is the magicsauce that makes NDN work or not, butthat's not a conversation about SDN.So we probably going to table that onefor another conversation.It's fascinating.

>> You know that's interesting.I mean it seems like from what you'resaying about, about many of the projects,though.That since they sort of put routing asidein some sense or expect someone else tosolve it, and you know, SDN might be agood way to solve it.That in some sense one might think of SDNas complimentary to many of thoseefforts, or, you know, potentially evena, a keystone.Because, because so many of the, the

projects ultimately depend on thatworking properly and, but don't, don'tmake their own efforts to ,to address it.>> I think that's right.And again, there's a different answer forevery one of the projects.If you look at, the Nebula Project, wherethe, the fore-reading plane is based onicing.Icing is a source-routing scheme, a veryrich, expressive source-routing schemewhere the header contains these proofsthat you're allowed to follow the path.

And as you go down the path, there's thiscomputation so that you can look at thepacket and you can see compu.Using crypto goo, crypto magic, that thepacket actually followed that path.It's a source-routing scheme.So I don't, I don't know what it means tosay you run an SDN underneath a, asource-routing scheme.But in fact, they're not trying to


18/32

forward packets using icing, they're notforwarding router by router.They're following, they're routing domainby domain, so it's really source routingat the domain level.And it seems to me that inside thedomains, they absolutely need a interiorgateway protocol, or an SDN, just as muchas anybody else does.But, I've never again thought about whatit would mean about stn underneath icing.You know, that, that's sort of like, okayfine.That's a interesting hybrid.You can go talk to the Icing folks aboutthat, but.>> Yeah, yeah.I know you, you mentioned, I mean, youknow, a lot of the talks you've given on,on future internet.You've talked a lot about security andthe in, this sort of importance ofconsidering security in, in futureinternet architectures.

And certainly some of the talks that I'vegiven on various SDN types ofarchitectures is one of the things thatcomes up invariably is.Is this more of less secure than, thanthe exisitng internet architechture?Because couldn't someone attack thiscontroller or whatnot?And I was wondering if, if you had anythoughts about just, sort of the mostimportant security problems just ingeneral 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, doesthat type of architecture make theinternet more or less secure.Or are there aspects of the control dataplan separation that provide someopportunities for improving security?>> So, I'm going to give you a longanswer, and.>> Yeah.I actually feel that, I have a particularpoint of view about SDN, here.

And I haven't been able to find anybodywho buys it.So I'm going to, I'm going to air anoriginal idea here with you.And I'm curious to see what you think, Iam relatively uninterested in thequestion of, oh my God, they could attackthe controller.I believe that when you have a securityproblem that is essentially solvable by


19/32

technical innovation, we can solve it.>> Right.>> You know, we're we're having a fightto get secure BGP, we're having a fightabout secure DNS.But, in some sense there's no, well I ststarted to say there's no tussle.Of course there's horrible tussle aroundthose.But, but in some sense.They, they exist at a technical level,where the technical solution could bedone.So, so, I think there's the fundamentalproblem that SDN has, which is, okay.If the network is highly unstable, andlinks are going on up, up and down.How do you make sure that the controllercan reconstruct the network, step bystep, knowing that it has a data path.To the next thing that it has to control.And how do you build the data plane backso that your control messages can flow.Fundamental problem, but yes, you, I'm

sure you could replicate the servers.You can have, you know, you can have allkinds of things that computer scientistsknow how to do there.That doesn't really worry me.I think the real security problems wehave in the internet are not thevulnerability of the network itself.It's the question of what role thenetwork plays, or the network can play insecuring the higher level activitieswhich, as architects.We don't consider the internet, we

consider the applications.But if you look at all the espionagethat's going on today.This is not occurring because themachines have been penetrated, it'sbecause we're stealing.>> Right.user credentials, using phishing attacks.And so the answer's, so what can we do toprevent that?So, so let me try a, an idea on you here.a lot of the issues in this base have todo with theft of identity credentials.

And once I've penetrated a computer andinstalled Malware on it, then I'm you andso, you know, every time I log in I'mempowering you to do the things you wantto do.So log in doesn't really help a lot.Bu, imagine that we went to anarchitecture where to do certaindangerous activities.Such as sending data outside your


20/32

corporate perimeter, two machines had toconcur.That human beings had to make all thiswork it's unworkable.But imagine you design [CROSSTALK].>> A signature on it's chapter orsomething like that [LAUGH].>> Something like that, that's right.The applications have to be designed sothat this happens as part of the normalapplication data flow.But imagine that there's this other boxoff to the side, it's sort of amother-may-I kind of thing.You have to go to this other box and say,I'm about to send data out.And that box could say, well I want to doan independent validation of thecredentials of the guy at the other end.The guy who's receiving the data.Because we're sending the stuff out.So who's getting it?And imagine that that box is simpleenough.

It's not running the operating systems oftoday.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 Isaid, can you build that machine so thatit's sort of robust enough?And they said, oh, it's a simple singlefunction.I mean, they throw out virtual memory,right?But once you start throwing out enough

stuff, they say yeah, we can completelyaudit that machine.Can't run chain, chains that code it on,it's a stable machine.That is not penetrable.And that machine has to concur.So, so now you're saying, well I want tosend data out of the network, I have toget that other machine over there toconcur.What we're really talking about is thatthere's certain data flows that shouldn'tbe permitted unless the security

architecture says they are permitted.And that's exactly the kind of policy theSDN can express at the data level.So SDN could actually, you can't sendpackets to the firewall unless that guyvoer there says it's okay to send packetsto the firewall.And the application has to be designed sothat you've, in the normal flow.Which is to say in the absence of a


21/32

security penetration, that authorizationwill have been obtained before you eventried.So you don't know there's anything wrong,but if some guy comes into your computerand breaks in he can't do it.Because that other computer over therehasn't been penetrated and it won'tconcur.So I think SDN as a control of what flowsare acceptable would be a reallyinteresting tool to deal with higherlevel security if the applications weredesigned in such a way.That the security policies, and or sorry,the implementation of the steps necessaryto comply with the security policies,were embedded into the normal workflow ofthe application.>> Yeah, I think this is really afascinating point.I mean, we've, we've done a little bit ofwork on for example, if you've got aninsecure web application.

How do you make sure the data doesn'tleak through cross-site scriptingcross-site request forgery.And can you use mechanisms in the networklayer to kind of prevent those types ofleaks.>> Right.>> And I think there's something reallyinteresting in the architecture youpresent, right, because if we think aboutweb apps right?And how they are developed and deployedand so forth I think it's, you know,

it's, it, it seems safe to say that theseare fairly tough to secure.[LAUGH] and>> Yes.>> you know, it's, it's not just thenature of, of the runtime environment,it's also a matter of the you know,development cycles, and auditing, and,and everything.And yet, we've got these sort of brittleweb apps.With really, really important data[LAUGH] sitting behind them

And what if we had a network that couldessentially prevent those leaks fromoccur, prevent the application fromleaking.Even in the case when a compromise hadoccurred, and I think that seems like areally ripe area for the type ofapplication or architecture that youmentioned.Because like you said, we know, I mean we


22/32

can maybe understand a little bit betterabout what types of data or what types offlows should be allowed.From point a to point b, that to me atleast seems a lot easier to reason aboutthan does this web application have aparticular 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, theinter-machine version of sandboxing forsomething like that.I'm not sure the analogy tells us a lot,but the point is that at the applicationlevel you know what sort of data flowsare likely tone need.Of course you don't want to kill off the,the authorized but exceptional patterns,so you have to think how to make thatwork.That's the same is true with sandboxing,sometimes I actually want to getsomething out of the sandbox and how willI do it.

And I think the answer in that case, asin the example I gave you, as well.Maybe what you need is, you invoke whatin the old days, in the security world,used to be called a trusted process.Which is uncorrupted, uncorruptedprocess.And you can go to it and say, this iswhat I'm trying to do.It involves declassification.Taking something out of the sandbox,>> Right.>> Verify for me that, that's okay.

But I think, I think that's a good way tothink we, we clearly have to rethink howwe think about security and I, I do thinkSDN a building block in that space.>> Yeah that's, that's a really, reallygreat insight.I wanted to actually just ask anotherquestion about, about, sort of, history.since, since you've certainly beeninvolved in.I mean, you sort of witnessed variouschanges and proposed changes to internetarchitecture over the years.

In my reading of history, I was reallystruck in reading some of the history ofactive networks.In particular, the motivation behindactive networks and, sort of its goals inenabling the deployment of new serviceson the network and such.And as I read some of the motivation forit, I thought, wow, this is reallysimiliar to some of the motivation that's


23/32

cited for, SDN and, and Open Flow.I was really curious as to your thoughtsand perspective given that SDN'sobtaining so much attention fromindustry.you know, why, why is it?Do you think that it's a question oftiming?Do you think that it's a question of thetechnology that's enabling it?Do you think it's a question of like Whatproblems people chose to focus on atparticular times,>> I, Active Nets means more than onething.If you were talk to Dave Tennenhouse orDave Weatherall.You might get a slightly differentanswer.Then you talk to Larry Peterson.You know, Larry Peterson's comment isthat.A lot of what he learned working onactive nets about how to put, multiple

independent third party pieces of codeinto a machine is what led to Planet Lab.And Planet Lab is a fantastic success butI don't know whether if you ask some ofthe other active nets advocates.They would say that what they've beentrying to build was, was This planet lab.Some people interpreted activeness verynarrowly which is that we're actuallytrying to put third party algorithms ontorouters.And we were actually trying to send thealgorithms out in the packets.

And I think that narrow interpretationsimply was solving a problem that wasextremely hard to problem and didn'texist.When people didn't need to program the,the forwarding plane.The forwarding plane works pretty welland I don't know what it means to sendalgorithms out that are in some sensecompeting for the forwarding asset.In other words, I send out an algorithm,here's my packet's priority.I mean, what does that mean?

It doesn't make any sense.>> [LAUGH].>> That has to be arbitrated.So, so I, I think that interpreted overlynarrowly, and I'm not trying to be, I'mnot trying to sort of caricature PlanetLab.I, I mean Active Nets here, I thinkinterpreted overly narrowly it wassolving a problem that in fact was, was


24/32

not a well, well-formed problem.If you, If you though about it, it'strying to put an algorithm in packet thatmodified the forwarding plane.If you said I want services in the net,and I'm thinking about now theapplication level.And I'd just like some services out therelike cashing or something like that, wellclearly we've moved the internet in thedirection of highly distributedapplications.All of the work on CDNs, and CDNs arenot just content replicators at thispoint, they are platforms for applicationdistribution.but we are, are by the way, the, thecellular people are now moving the, whatthey call the cloud.Thats the new word, right?They are now moving fragments of thecloud onto the base station antennapoles, right?You're getting boxes that mount on the

antenna poles that have got, a platformin them from any third party code.>> Right.>> Application level code.So, so, the question is, what happened tothe brand name Active Nets, and In whichdirections did it go?Because, because, if you look likesomething like Planet Lab.I think, we not only got a amazinglypowerful research vehicle there.But it actually did teach us a lot aboutcloud.

And so I suspect a lot of people wouldthink I was insane if I said that, thatvirtual machine cloud management is sortof one of the, outcomes of acting nuts.But I think if you, if you talk to Larryhe'd say well, what I learned was all ofthe issues about running potentiallycompetitive code.On a, on a common platform usingvirtualization tools and how to keep themseperate and what it means when you runout of resources in all these issues.but I think SDN is solving a problem

Which is incredibly timely, I thinkoperators using large nets today.As I said earlier, if you look at thispicture from AT&T which just blew meaway.They are absolutely exceeding the braincapacity of even very smart people tosolve the problem of all of the differentmanagement problems.They have traffic engineering, load


25/32

balancing, all this kind of stuff.And we somehow have to pull that into aplace where we can solve in a centralizedway these problems of policy composition.It doesn't mean we know how to runalgorithms that do policy composition, atleast we have a vehicle for doing it.>> So, so, I think that SDN is in facta framework that is solving a problemthat is staring commercial providers inthe face.And I would that was true of Active Nuts.>> Yeah, that's a really good point.I mean, it kind of reminds me of youknow, of the, of the research that, thatwe were doing like, you know, ten yearsago.Even, even in the context of BGP, forexample, where we were saying.You know, it's really hard to reasonabout you know, what this protocol isdoing, in terms of like where's thetraffic going.How do you do load balance?

And how do you make sure that you don'thave forwarding loops or ocilation insystems like that?And now it's just like one protocol,right?And as you're talking about the examplethat you mentioned from AT&T where we'vegot.Oodles and oodles of packet headers andencapsulation and different protocolsinteracting.Yeah, your point is super well taken.Um,so, yeah, I guess I mean, that's, that

pretty much is, I guess we are at kind ofa good wrapping up point.I guess, one final thing that, that mightbe fun to just wrap up with is, is kindof looking forward type of question.I mean, I guess you know, con, consider,consider people who are, who may betaking this course or may be, may be youknow, undergrads that, that, that youtalk to.Or maybe other, other engineers who are,they say they want to work on networkarchitecture.

so I guess, first question is, you know,in your view what is networkarchitecture?Like how would you, how would you defineit.It seems to me there are a lot ofdifferent definitions for it.But, I guess just the question to wrap upwith would be, what types of internetarchitecture problems.


26/32

Or what types of problems in the big Iinternet, maybe, are, are things thatyou'd like to see people work on?And do you think SDM plays a role inthose problems or not?>> Well, let me, let me answer thatpart in pieces.We do throw this word architecture arounda lot without.Without exactly defining it clearlyarchitecture is both a discipline, apractice.I mean if you talk about architecturedesigned buildings its a design processbut it also produces a a you know result.You could talk about Gothic architectureand And it sort of becomes a, arecognized style.The, the, John Rafalski as I said, washelping me try to articulate what thismeans in the context of the futureInternet stuff.And he said, you know, architecture isthat aspect of your system design which,

characterizes the, the basic designprinciples that you hope are going tohold for decades.It's that framework, it's that set ofconstraints and accepted limitationswhich stabilize the, the basic skeletonso you can change all the other stuff.So, the idea that an architecture letsyou replace the routing is actually avery strong statement.Which is to say it, it is key assumptionsyou made that make that happen.And so you can say, well, for example,

what does the Internet architecture haveto do about routing.because it says nothing about rallying.Well it actually's got warm little teenytiny toehold in there.Which is it's got what today we know as ahot panel that's called GTL.Which means that there's something aboutthe data plane that tells you when youhave a loop.Now I don't know whether that's the rightbuilding block for rallying algorithms,but It is a building block we put into

the architecture.Because we thought looking into thefuture we had no idea it would help withstabilizing a wider range of dynamicrouting algorithms.And you can look at a couple other placesin the internet where there's a teenytiny hook.Which is our guess sort of in the mid1970s as to something that would enable a


27/32

range of, of algorithms to be put inplace and taken out, and put in, and soforth over time.>> I'd love to see your your write upon teeny, tiny hooks.I bet it, it's sort of like Easter eggsor something would be, would be prettycool.>> Well, it's you know.I, I, I can actually send you if you wantto show it to your class, I can send itto you.But the point is that architecture insome respects is best when it's minimal.The fewer things you have to agree on,and the system still works [LAUGH], thebetter off you are.Because what it means is you've left moreflexibility for diversity in solvingproblems differently in different partsof the net.And you still achieved inter-operability.And, and in some sense, the whole pointof the Internet was inter-operability and

nothing else.That is to say, I want my net to becompletely different from your net, but Iwould like to be able to inter-operate.And in fact, the one thing that we arehung up on today is the the syntax of thepacket header.You now we can't convert from IPB4 toIPB6 because its too well we willeventually.But its really high and if you look atsome of the work for example that ScottShaker and the students have done

Architectural Minimality.One of the things they said is that Infact we shouldn't be agreeing on thepacket header as a part of thearchitecture.Because if we just add state to thenetwork, and that of course itself is astrong architectural statement, you canrewrite the header in the middle.We have to agree on a global routing.>> Right.>> And we have to agree on how do youagree on how do you control DOS attacks

and so forth.But if you look at the future internetproject that's coming out of SCMU, theybasically have a very complicated packetheader.In fact, it has multiple kinds ofaddresses inside it.They're not even in series, it's a DAG,and what they're saying is, we'll try thefirst address.


28/32

If you don't know how to process it,you'll fall back to the second one.So, what they're saying is we should makeevolution of the address structure.A fundamental part of the architecture,that gets rid of the one constraint thatwe have in the internet today, which isthe size of the, of that, the addressfield in the header.In that respect, architecture is anexercise in Minimality, which is an art.And I don't actually know how to tell astudent who's interested in this.To go work on it because I think it'simportant to understand it.It's important to understand thedistinction between what we imbed in thearchitecture and what we leave as aresult.For the people who are trying to reducethe architecture to a running system.But, but I, I think that we don't need10,000 architects.What we need is people who understand

this distinction and can see how it isthat you very carefully pick the thingsthat are in the architecture.John Goyle has called them theconstraints that de-constrain.And it's the same idea that we know whenyou freeze an interface, you picksomething that said it's going to be hardto change that.So you can change everything else aroundit.And, and so the art is finding.>> I think I know what that is.

>> 30 or 40 years.And we didn't get it, we were, we were Iwould say, without knowing what we weredoing we were remarkably successful atthe end of it.But it's clear we didn't get it exactlyright, andAnd it's clear again that we didn't, wedidn't at all think about putting in onesentence the word architecture and theword management and control.We absolutely do not know how to putthose in a sentence.

>> Right.>> You look at all of the futureinternet architecture projects, we have ameeting every six months.And we say okay, what are we going totalk about in the next meeting?We've done security, we've done economicviability.Every time I say we're going to do ameeting on management, they all run away.


29/32

>> So that you'll.[CROSSTALK].>> That remains one of the, one of thegreatest unsolved challenges in, in yourview, you think?>> I, I think it is, I think it is.And I think it would be a a major shiftfor our field to, to really emphasizefundamental thinking about management.And I think SDN is a, is a fundamentalshift in how we think about control andmanagement.And we talked about distinction betweenthose two, but it doesn't matter.it's a, it's a fundamental shift in theway we think about things that are notthe data plane.>> And, and I think we should do morethan that.>> Yeah, that's really interesting.I mean, as, as you know like I've hadquite a passion for management for, forquite a long time.And you know, it's, it's certainly as you

know, one of those, those things that'sreally hard to think about in that, inthat.You know, within the confines of, of thecurrent architecture.and you end up sort of like doing bandaidtype things and slapping things onbecause you're working around theconstraints of the existing protocols.And I remember, you know, when we wereworking on BGP configuration checking.And and Harry said, you know, don't youknow, don't design a new language,

because like, no one's going to adopt it,you know.You know, it's, you know, it's too hardto change, you know, the existingconfiguration languages.And then people are going to, you know,people are going to have to agree onthat, and it's never going to happen.And, and I think that was absolutely trueat the time.So you were kind of like stuck with, youknow, okay here's this thing, you know,that we can't really change.

And people are operating at a really lowlevel.So let's just kind of, like, put somebaling wire around it and, and, you know,run some checking scripts.And it seems now that one of the thingsthat SDN might make possible is we, asyou said, we can sort of separate policyand mechanism.We can think about things in a central


30/32

place.Things like security and other aspects ofmanagement as well.and it may be possible to do things thatwe just like really had to punt on.>> So I do encourage, and the, and youasked about students.I do encourage people to, to think aboutdifferent mechanisms.I understand Harry's reservation, but, sohere's my counter argument In thebeginning, we had this huge debate aboutIPv6.And you can go back and read the historyand the things Steve Deering said, it wasvery conservative, and some other peoplewere a little more flamboyant.And, and my argument was you're going tohave to get people to convert.And in order to make them convert, therehas to be enough of an incentive in therethat they see the payoff for them.And so IPv6 should embody improvementsthat apply to all parts of the community.

And Steve said we should take thesmallest possible incremental step.Because it will scare people if they haveto take a big step and so we should makea step that's not scary.>> Now what happened in fact is thatmost of the innovations that weredescribed As being possible only with theconversion to IPv6.Which I would remind you, includes thingslike IPsec.>> Right.>> Where magically retro-fitted into

IPv4 once people figured out they wereimportant.Leaving IPv6 with very little to offer usexcept enlarged address spaces.So sometimes there are two possibleoutcomes of taking, being daring enoughto take a big step.And one of it is it becomes enticingenough that people will actually gothere.And the other is in fact even though in anominal sense you fail in fact yousucceed, because all your ideas leak into

the current internet.And so, that's why I believe in futureinternet.It's not because we're going to have aflag day.It's because by asking people to envisionan alternative future, all of a suddenpeople look at the current internet andsay, oh, I could actually do that.And that would be really powerful.


31/32

And maybe it won't be quite as clean andblah, blah, blah, and all that kind ofstuff.But I think that's the way to breakyourself out, so to me Clean Slate wasnot about the fact that we're going tohave a flag day.Clean State was about freeing your mindfrom constraints so you could imagine theimagine the alternatives Yeah, I couldn'tagree more with that.I mean I always sort of thought aboutclean slate thinking versus clean slatearchitecture.I mean it's really, it's reallyheartening to hear you say that,>> Absolutely, exactly.>> I's I guess.Yeah, and it's, it's, I think it's reallyinteresting too for, you know, whentalking to operators and things like.You know, even still today when we askthem like.We've got SDN that we'd like to deploy in

an exchange, right?And inter, internet exchange like, whatwould you do with that and, or, or we'vegot want to deploy in this context andlike.What kind of problems do you facing andand still the you know the thinking is inin in that area is very much.So like well, I'd like to be able to dothis with my local preference, alright.I'd like to be able to do that with my ASpath pretending or prefix splitting and Ithink people aren't site thinking.

You know, at, at the, you know, they'renot doing the clean slate thinking yet inoperations.But maybe we'll get there at some pointand maybe [CROSSTALK].>> You have to help them, you have tohelp them think that way.>> Right.>> And you can't go to them and sayhere's SDN, you know, that's just a pieceof mechanism.>> Right.>> You have to go to them and say, you

have some problems here.and I've worked with you long enoughYou know, Jen's a good collaborator herebecause she's, she's, she's, she's,worked the night shift in the knock youknow, and, and.>> Right.>> And we need people who can do that,who can then abstract, and say.This is what I think you'd, you might not


32/32

have put it this way, but this is whatyou're trying to do.And then you say, oh okay I understandwhat you're saying.And then you can say, here's my solution,you know, and you have to turn the SDNinto the solution as opposed to being apiece of the mechanism.An ISP once said to me, don't talk to meabout technology, talk to me aboutservices.And I didn't get it and I finally figuredit out.Technology is something we have to payfor service is something that they canbill for, right?>> Yeah, that, that definitely makessense.So really, it's, it's about gettingoperators to speak in the language aboutwhat their problems and pains are.And not what the problems of the currentmechanisms are.>> So then we [UNKNOWN] That's right.

Exactly.>> Think about the [UNKNOWN] And, andthat's part of our job.We are, we should be good abstractors.>> Okay.>> Right.>> And, and, and that's part of, that'spart of our skill set.>> Yep.Well great I, I think that, that prettywraps things up.I, I really thank you very much for yourtime.

It's really been a great discussion, andI hope the, the people who are watchingthis enjoy it as well.So, thanks very much.It was really, a great privilege to, tohave you.>> Well and you're very welcome, it wasa lot of fun.>> Thanks.

2 - 5 - david clark interview

Documents