ACM ByteCast - Radia Perlman - Episode 3

Episode Date: July 7, 2020

In this episode of ACM ByteCast, Jessica Bell is joined by Radia Perlman, ACM Fellow and renowned computer scientist, who has made fundamental contributions to Internet routing and bridging, including work on network resilience. Currently a Fellow at Dell EMC, Perlman is famous for writing the spanning tree protocol (STP), which powers the Ethernet. She reflects on her early days at MIT and later Digital Equipment Corporation, where she worked on DECnet, one of the first peer-to-peer network architectures, and how that inspired her doctoral thesis on routing in the face of malicious network failures. Perlman then relates how she wrote the algorithm behind STP “over a long weekend.” They also discuss the importance of teaching critical thinking in STEM education, healthy corporate culture, and the reciprocal value of mentorship.

This is ACM ByteCast, a podcast series from the Association for Computing Machinery, the world's largest educational and scientific computing society. We talk to researchers, practitioners, and innovators who are all at the intersection of computing research and practice. They share their experiences, the lessons they've learned, and their own visions for the future of computing. I'm your host, Jessica Bell. Today, I have the great pleasure of talking to Radia Perlman, a computer scientist and researcher who made great strides in the field of networking. You might have heard of STP or spanning tree protocol. Radia wrote the algorithm which powers this technology. Welcome, Radia. Hello, Jessica. Pleased to be here.

I'm so happy to have you too. I'd like to start with just a little introduction of yourself and tell us a bit about who you are. Well, I work at Dell Technologies. I design network and security things. Great. So somebody who came into the Computing Society fairly recently, I've read a lot about your career and it seems like you weren't necessarily destined to be a computer scientist. I've even seen some interviews where you self-describe as hating computers. I'd love to know a little bit more about how you not only got into this career, but ended up developing some of the pioneering technology that we all use today. Could you walk me through how you got into tech and how you got over, quote, hating computers?

Yeah. Well, I'm not sure I've ever gotten over hating computers. But yeah, I was always good at science and math. I also was good at like creative writing and stuff. But I was obsessed about getting straight A's. And math and science, all you had to do was understand this stuff and you'd get a good grade. Whereas the other stuff with the subjective grading made me nervous. I was completely open about what kind of career I would have. I wanted it to be reasonably interesting. There's the stereotype of an engineer that as a young kid, they put together spare parts and made a computer or built a ham radio or whatever that is. I never took anything apart. I literally went to college without knowing how to change a light bulb.

When my light bulb, you know, it was something that I would tell my father, my light bulb burned out. And a few days later, it would be fixed. And I wasn't even curious what he had done. I assumed it was dangerous or something. Then in college at MIT, my light bulb burned out. And I was wandering around the dorm asking people, are you majoring in electrical engineering? And finally, yes, why? And I said, my light bulb burned out. What do I do? So I was always very good at logic problems, but never was on things. So, you know, that's sort of an important lesson that it's very important to have a team that looks at problems from different dimensions. I sort of think about the conceptual heart of it.

That's sort of another aspect that I have a terrible memory. So if you ask me to remember one more thing, I'm going to have to forget something important like my name. Other people managed to get through school by remembering what the teacher wanted them to say on a test. And I couldn't do that. I had to deeply understand it and be able to derive it from the two things I could remember. At any rate, I was good at, you know, any sort of science or math thing. Actually, I wasn't even happy about sort of being the best student. I always had a fantasy that some boy would do better than me at some math or science thing. And my plan was to fall in love with him and marry him.

Well, not till college, really. And then also, I've realized that smartness has so many different dimensions, some of which are mutually exclusive. So you can't really compare two people. In high school, a teacher noticed that there was a programming class at a local university. So she could sign a few of us up, drive us over there, wait for the class to be over, completely volunteer on her part. I mean, teachers are just awesome. Wow. I walk into this class after always before knowing, oh, it's a class. I know how to do classes. I'll do fine. And everyone was talking about how they had built a ham radio when they were seven. And I had no idea what that was. And then they were asking questions with fancy words like input. I had no idea what that was. And then they were asking questions

with fancy words like input. I had no idea what that was. But my mind sort of closed off and I got nothing out of that class because I sort of thought I was so far behind. But later on, I mean, my grade didn't matter in that class, so it was fine. But then I sort of knew that if you asked me what I wanted to do as a career, I would say, well, anything as long as it doesn't involve computers. Then for, I mean, I was taking a physics class in college And the TA said, would you like to be my programmer? I have a project and I need a programmer. And I said, I don't know how to program. And he said, yes, I know. That's why I'm asking you because I have no money to pay you. And if you knew how to program, you'd expect to get paid. So, you know, I had a friend at the time who knew how to program and I figured that was a safe way to learn. So indeed, I did learn how to program. So yeah, I can do that. But still, when my daughter was so proud of me when she was in high school, hopefully she still is, but she was telling her friends, my mommy's a famous computer scientist. She knows all about computers. And her friends would call me up and say, I'm trying to install a printer and I'm getting

this error message. Have to tell her that really there's nothing that I know how to do that any of her friends would be interested in. So at any rate, then I went to college. I was in math. And like you would expect, I went to grad school right after undergraduate. At the time, the MIT math department was extremely unhelpful. You had to find your own advisor.

And I was shy and insecure. And I would try knocking on a few professors' doors and say, after I'd finished all of my classwork and tests and all that, the only thing left was a thesis. But everyone whose door I knocked on saying I needed an advisor, they would say, well, I'm a big, important, busy person, which was very discouraging. So I did that for very long before an old friend said, are you enjoying grad school? And I said, no, I have no idea how to get started on a thesis. And he said, oh, come join our group, which was at a little company called BBN.

And it was designing network protocols for the packet radio net, which I discovered I love because the concept of having all these little things all doing their own their own stuff independently based on local information and how it fits together like a giant symphony is just beautiful oh and then for totally bizarre, I wound up in the ideal job at that point in history, which was at Digital Equipment Corporation, being in charge of designing what's called Layer 3 of networking, which is the thing where it enables you to plug a network together like Tinker Toys, any topology you want, and then the little connectors, let's call them switches, amongst themselves and figure out how to create the tables that they use in order to know which direction to send messages based on the destination address. I realized that computing has such different implications. And we have this very small idea about who is a computer scientist and what programming is. So I find stories like yours really interesting about how you're more into the logic or the big picture or how the networks and the switches come together. I had the same experience as you. I took some computer science class, never had built a gaming computer and thought, oh, wow, I could never do this. And now I'm a

software engineer. I think we have a little problem of PR in our field a little bit. But I'd like to continue a little bit on the idea of these networks that you're starting to talk about and move into talking about some of the things we've chatted in our intro chats about network resilience and how you transition from working in the networks, being in academia to somewhere where you are now, where you're thinking about the real world implications of how resilient a network is. What does that mean for a network to be resilient? And how do you think your background in developing STP has helped you think about networks from a higher level? Could you speak a little bit more about that? Yeah, let me talk about it more historically. When I first was in charge of doing Layer 3 for DECnet, I looked at the only existing

equivalent network, which was for the ARPANET. And so I was looking at that algorithm and I realized, oh, wow, it's not stable. Just a few bad messages and the network would be down forever. Now, we're used to that with our PCs. It gets into bad states and you shrug your shoulders and you reboot it. But you can't reboot the Internet, especially the way that you diagnose what's going on. And the way you fix it is by sending network management messages across the network. So my first paper was about, hey, it's not good for a network to be so fragile that a few corrupted

messages makes the network be down forever. And this is how to fix the algorithm so that it would be self-stabilizing, meaning that to get rid of the machine that is generating bad messages, the network will recover by itself, whereas the ARPANET algorithm would not do that. And indeed, actually, it did wind up having that problem. There were a few corrupted messages and the network was down forever. And the only way that they managed to fix it was that they were extremely lucky. The same people who designed the algorithm and wrote the code were the ones fixing the network. So we're able to do a core dump, realize what the problem was, and basically have to come up with a patched version of code that specifically ignored the kind of messages that were corrupted. And then they could one by one get rid of the bad messages that were floating around.

But you couldn't do that in the Internet today. So it's rare that it be self-stabilizing. Another dimension was that original networks were for researchers to share data. And so it was fine for the people managing the network to, you know, that was their entire job. And they designed the algorithms, they wrote the code, they understood it all. But these days, and shortly after that point in history, real people have to keep the network working.

So it has to be easy to manage and intuitive to manage. And if you have to set parameters, it has to be very resilient to misconfiguration. So that was kind of another dimension that I added. When I designed things, I was designing it for somebody like me, meaning you don't want to even think about it. You just want to plug it together and it will work. Somebody once complained to me, once told me that they had customers that were complaining about one of the products I had designed. And they said they find it so boring because all you do is you plug it in

and you don't have to do anything with it. Another thing that once someone told me was they were doing a survey of customers on how much they liked DeckNet. And most of them answered, what's DeckNet? Which actually was a great compliment. Right, right. If they don't even know they're using it. So another dimension of resilience was in that original paper, the last sentence I had said was, this is how to design a network. So once whoever is injecting bad messages gets disconnected from the network, the network will return. But there's no way to make a network continue working while bad things

are happening. And for weird reasons, 10 years after I dropped out, I went back to grad school and my manager at digital, who was one of the smartest people I've ever worked with, suggested as a thesis topic that I either prove that statement that I made in the original paper, that it was impossible to make a network work, or that I design a network that will work even if some of the components are malicious and are purposely generating as bad messages as possible. So that indeed was my thesis. I've never done anything terribly complicated.

Everyone thought it was going to be a hard problem and an important problem. So they told me certainly that would be good enough for a thesis, even if you can only do a very small subset, like allow two computers that are direct neighbors of each other to be able to communicate, even if someone way far away is malicious. But it turned out to be very simple. And then I was nervous that the solution was so clear and simple that they wouldn't give me a thesis for it. So I asked somebody, is there any minimum length to a thesis? And he told me, well, it either has to be long or good. So there's a lot of dimensions of resilience that I care about.

So one is usability, that a lot of times things don't work because the users did the wrong thing. And I claim you should never blame the users. You should design your things so that there's nothing the user self-stabilizing, but then there's the working despite having some components being malicious. At the internet, it's just too large to assume that everybody has good in their heart. Right. And especially nowadays with our networks going beyond what we ever thought at the beginning. I mean, these networks are now spanning every single part of our world and handling data that we never thought. It's not academic anymore, right? It's everything, credit card information, public identifiable information, all this kind of stuff. Early papers on network security said what you have to worry about is theft of data, unauthorized access to data, unauthorized modification of data. And oh, yeah, there's denial of service, but we don't have to worry about that because no one would bother because

you don't gain anything from doing that. Right, right. Of course, that's- Which is fun to hear now. Right, it's proven to be absolutely false. You actually can make a lot of money from denial of service. Right. Right. What do you think drew you towards

thinking about network resilience of all the things you could have done with computer science or your early career, what kept drawing you to this idea of networks and their overall resilience? I think it was just where I landed. If a different friend had approached me when I was in grad school and said, are you happy in grad school? Oh, really? You're not happy now? Why don't you come join our group? And it was chemical engineering. I suspect I would be just as happy in chemical engineering. Right, right. So how has this idea then shaped

once you got into this? And once you started realizing, oh, I actually, you know, this is simple to me, I have these really clear, simple ideas, which I mean, I fight against this all the time. I'm always like, I want more simple code, not more complex code. But that's a whole nother conversation. How do you think that this has now gone on to shape some of your, your farther work and the work that you're doing now? Have you always stayed within this vein or did you end up going along different sort of branches of a tree, if you will? Oh, I still wind up when I design something that after I design it, people will look at it and say, oh yeah, that's very simple. Anyone can do that. And I sort of know from experience that even if I do something incredibly simple, that if somebody else had designed it, it would most likely be an extremely complicated thing that wouldn't work in all cases. Whenever they discover a new case that it doesn't work in, they add an extra little piece to it to try to handle that case. It's, I think, partly because I get rid of all of the details that are irrelevant to get to the heart of the problem being solved. Or if it's a big problem, I will partition it into smaller problems and then solve each one simply.

Yeah. Who was that designer that said good design is when you take everything away and when you can't take anything else away, you've got a good design. Oh, man, what is his name? He's a German guy. He's very famous. Anyways, it sounds like that. It sounds a lot like that.

It might have been Einstein that said keep things as simple as possible, but no simpler. Yes, exactly. Exactly. So it's... What we talked about has to do with the spanning tree algorithm. It's sort of ironic that that is what I'm mostly famous for. But it has a nice rings, spanning tree algorithm, whereas resilience and scalability and manageability of network protocols is really kind of too long of a phrase. It's not very catchy.

But the spanning tree algorithm was a hack that I thought was a bad idea. What happened was that in a network, in order to send a message, you have to put it in an envelope that says you want it to go to. But then people came out with the Ethernet with fanfare, and everyone was so excited about this new way of doing networking that they were doing that instead of putting in the kind of envelope that enables it to get forwarded across a large network. Ethernet was really just a single wire that everyone on the wire could hear everybody else. So there was none of this forwarding necessary. They were doing that. I was saying, no, no, no, you still need layer three. And they would say, oh, Radia, you're just upset because no one needs your stuff anymore. I said, but you may want to talk from one Ethernet to another. And they said, oh, our customers would never want to do that.

Of course not. So years later, when, hey, our customers did want to talk outside the scope of a single building, my manager said, hey, Radia, we need to design a magic box that will sit between two Ethernets and forward packets from one to the other. Of course, what my stuff did, but the stuff I did required the end nodes being aware of it and using that and doing other things. So the constraint was design something that does not require changing the existing end nodes and does not change the Ethernet header in any way. There's no spare fields and there's a hard size limit, so you can't add anything there. And so that's kind of where I came up

with the spanning tree algorithm, which took exactly one week. Now, to not only invent it, it's a really simple thing, but to write the specification. My manager asked me to do this on a Friday and then disappeared for a week. He was on vacation. And this was before you could send email or call anyone on cell phones. Right. So at the end of Tuesday, I had the complete spec written and the implementers got it working very quickly from that spec without asking me a single question. So the remainder of the week was used on writing the poem that goes along with the algorithm. And it was abstract of the paper in which I published it. Now, I still

thought that the right answer was fixing the endnotes to put layer three in. But it was fine to do this thing because it might take like six months to do that. But it's interesting that even though now everyone has put Layer 3 back into network stacks, everyone is still using Spanning Tree. And as a matter of fact, Ethernet, the original invention doesn't exist anymore. When you talk about Ethernet, it has nothing to do with the mechanism for sharing bandwidth on a single wire, which was the original invention. It's all just point to point links, just two nodes on a link and forwarding using the spanning chain. Wow. I mean, it's remarkable to think about these things that someone like me learned of as

just, you know, the foundation of the internet and to hear that you made it over a long weekend is just mind blowing to me. Well, it isn't like every week I come up with something that changes that's true that's true it seems like sometimes the the most impactful pieces of technology that we build are not the big super complicated ones it's the it's the small simple connecting two things or filling this this gap that we think is kind of silly or frivolous. And then all of a sudden, this changes everything in the whole field. And I feel like the more I learn about computer science history,

the more I find most problems are quite simple. It just takes the knowledge of, oh, well, we should hook these two things up, or we should fill this gap here. Yeah, complicated things will never really work. I was once at a meeting where somebody was talking about something that was just so bizarrely complicated, and it was sort of silent and kind of depressed about this thing. And somebody said very cheerfully, well, with enough thrust, anything can fly. That's true, I guess. It's just how long will it fly before it crashes to the ground? Exactly. Yeah.

So I'd like to sort of use this idea to transition a little bit to something we've talked about as well, which is computer science curriculum and the industry and sort of how we're potentially missing out on certain things because of perhaps it's a PR thing, perhaps people stay away because they think, oh, I'm not tinkering with, you know, a ham radio, or these days, I'm not building my own video game in high school, that people sort of shy away from the field or the idea that perhaps our field is too focused on certain things. I know you have a lot of thoughts around these, so I'd like to hear a little bit about, yeah, what do you think is missing from our curriculum or perhaps our industry as a whole? Well, something that I'm passionate about is critical thinking. So surprisingly, not everything you read on the internet is true, but it's not just everything you read on the

internet. It's even textbooks wrong. And, you know, your professor or whatever. Well, the early education that I had, everything was true, false, multiple choice, right, wrong. Kind of a very bad way to teach thinking, because in general, problems are not like that. So getting people to look at something and say, well, in what ways can you imagine this being correct? How can you argue for this? How can you argue against it? And make them on both sides, have them read papers that were published in reasonable venues that turn out not to be correct. So they should just be questioning things as opposed to thinking that a teacher's job is to fill your head with facts and then test that you are remembering the same facts that were fed to you. And how do you think that might express within our field? Is that, because I think computer scientists might have an image of themselves that, oh, well, we are very

critical thinking, right? We have to think through these big critical ideas. And yet, perhaps that isn't necessarily the case. How do you think a wider view of critical thinking could be introduced into our field, either through education or through things like bringing in people who necessarily wouldn't come to the field or haven't been trained in a certain way? What are your thoughts around that subject? Yes. So a lot of people that I've talked to that say they're going to go into French literature, I say, well, why not STEM?

And they say, well, I wouldn't be good at that or something. And they don't really, one of the reasons I'm so valuable is that I have found an ecological niche where I'm very different than the other people. And I look at problems kind of a different way. So that's useful. The problem is you need to have a corporate culture that lets people thrive. And that's like another whole passion that I've had. And I've been observing how organizations work and don't work, just like I look at computer

networks and think of how to make them or whatever. So one rule is that it has to be safe to ask questions. But an example of a corporate culture where it was exactly the opposite was that I was in a group where the culture was dominated by some very aggressive, obnoxious people. I have yet to see anyone that acts that way, by the way, that's actually good technically. But at any rate, the culture in this group, if you were to ask a question, one of those people would say, if you don't know that already, you don't belong in this group. Which, how do you go from there? So if somebody asks me a question that everyone knows, like what's a public key? I won't say, how can you not know that? I'll say, oh my goodness, it is the coolest thing. And I can't believe that I have the honor to be the first person to

introduce you to it. But another dimension to that is if you're a senior person, sometimes you think, wow, I'm supposed to know everything. And if you believe you know everything, you're incredibly dangerous and you should retire. But if you're a really senior person, you should be a role model and you should be the first person to ask naive questions. I don't know what that is. To show that you're perfectly comfortable admitting that you don't know everything and that it's fine to ask questions. If you could bring people in who have not been living in your little specialty for their entire lives, sometimes they'll ask questions that make you rethink your basic assumptions.

And basic assumptions are wrong. Right. Exactly. So it's very, very useful to bring people who are intellectually curious. Don't. So how do you manage to explain the conceptual heart of what you're doing without jargon? Right. And merely that exercise of explaining it at a conceptual level is useful to the person explaining it. But then answering questions from people who you've intrigued and they say, well, couldn't it

have been done this other way? Right. It's just a great opportunity, creativity and innovation. Definitely. I feel like that has been so true during my career. I'm, I have a degree in international relations and politics, right? So I don't come from software at all. And it's always been the people who sit down with me and explain things to me that I have found to be the most curious and effective programmers, because they're not afraid when I asked the question, well, why didn't you curious and effective programmers because they're not afraid when I ask the question, well, why didn't you do it this way? They're not afraid to say, I don't know why I didn't do it that way. Let's think through that process. And it kind of comes back to your point about resilience. You'll create more resilient things if you allow

all of these questions and all of these different thoughts to come in and don't close yourself off. Your software, your product, or your network is going to be a lot more susceptible to staying up versus down or something like that. I love your take on, I'm so honored to be the first person to share this with you. That is such a wonderful take of being a mentor and somebody who gets people excited about our field, which can be challenging. Right. People always talk about mentoring. I'm always a little bit uncomfortable with that. Of course, I mentor people all the time, but only about things that I think I can help them with. So if you want to know how to

write a book or to look over your design or something like that, yeah, sure, I can do that. But if you want to know which car to buy, you know, I know wheels are important for some reason. Not much else. So I think everyone should be mentoring everybody at all times, rather than notion of kind of a linear thing that I am more senior than you. So therefore I am the mentor and you are the mentee. Exactly. It's that back and forth relationship. The mentor is getting as much of the mentee as the mentee is getting from the mentor. You're sort of together forging ahead in this area that you thought and you do know a lot about. Yeah, it's more of a relationship than a linear thing, like you said. Right. And actually, the most powerful way you can grow the

next generation is asking them for help. So rather than you graciously sharing your wisdom, that's a good thing to do. But it's also letting them know that they have wisdom that you can learn from as well. Exactly. Exactly. That's a great segue into our final bite question, which is looking towards the future. And I'd like to hear from you, what are you most excited about, scared of, or genuinely curious about in our field over the next, say, five-ish years? What does the future of computing mean to you? Yeah, I'd love to hear your thoughts. Well, if you asked me about five years ago about the internet, I would just be so spectacularly excited about how it had transformed society in so many ways I couldn't even have imagined that all information is available, that a merchant can reach a global audience without even having,

needing to create a storefront. And you can, that you can only find in some obscure part of the world. This was all so magnificent and keeping in touch with friends and family and all this was wonderful. That was like five years ago. Now I actually think it will be the end of civilization or maybe it already is. You no longer know what's true anymore. Back in the days when reporters were, you know, the camera crew from Channel 5 News, kind of knew who they were, they had credentials. But these days, everybody is a reporter,

anyone that has a cell phone. But also you can actually create false videos and false information. But it's happening all over the world. So it's important that any citizen can let the world know what's going on, but you don't know whether that information is true. You can't do it sort of cryptographically by proving who the source was because the source is some unknown person. The end of truth is kind of scary. The fact that you can virally spread horrible mistruths on purpose is the fact that there's all these AI bots going around trying to figure out what keeps you interested. And if there's an article that you seem interested in,

they'll give you more and more things like that and more and more extreme examples. And it's also terrifying about how it is polarizing society to an extremely dangerous extent. So I don't know how to get beyond this. Even simple security things. The theory of security is just so beautiful, where to my bank, it has a DNS name and there's a certificate and public keys and wonderful protocols, wonderful math. All this works great in theory, but in practice, I actually fell for a scam recently, which made everything so clear to me that, oh, my goodness, none of this stuff matters, which is that I wanted to renew my license. And I knew you were online. So I just

put into Google, renew Washington State driver's license. And I clicked on the top result and it looked perfectly reasonable. If I had bothered looking at the URL, the DNS name was something perfectly reasonable, like washington.org. And so I had a choice of renew license, replace license, and I clicked on renew and it asked me all the questions that you would expect, my address, my name, my license number and my credit card. Here's a bunch of offers you're qualified for, which was my first hint that it wasn't the right site. As a matter of fact, they were off just saying, expect your license in six weeks. Of course, they never gave me a license. If I read the website more carefully, it just said it would give me instructions for how to get a license. Oh, good.

One of the offers was a free ebook I could download that would tell me how to get a license, which presumably would have said, if they were at all honest crooks, would have said, this is the URL you should have gone to. But there are similar websites like that. And how is a human supposed to know the right, do you expect a human to look at this three-line URL with all these weird characters and figure out which part is the DNS name? We shouldn't be able to do that.

So it's basically security in so many different dimensions that is terrifying and absolutely must be solved in order to, um, yeah. So that means the good news is for like students, there's so many dimensions in which they can be useful, but the bad news is that it really is very scary. Right. Right. Well, that's a really honest answer. And I, uh, I appreciate that. I appreciate the honesty of the people who are like sort of watching over the whole field because I have the same fears and anxieties. Well, Rydia, this has been so wonderful to talk to you. I've really enjoyed having you here.

I wish you good luck in your further career. And thank you so much for providing such a great peek into your mind and your thoughts and where our whole industry has come from. I really appreciate it. And thank you so much. ACM ByteCast is a production of the Association for Computing Machinery's Practitioners Board. To learn more about ACM and its activities, visit acm.org. For more information about this and other episodes, please visit our website at learning.acm.org slash b-y-t-e-c-a-s-t. That's learning.acm.org slash fightcast.