Muriel Medard, MIT Professor

NEC Professor of Software Science and Engineering Muriel Medard discusses Wireless APIs at the Edge.

Transcript

Copy Transcript Copied

Maribel Lopez: 0:40

Hello and welcome back to the podcast. I'm Maribel Lopez and we're here with Jo Peterson, my fabulous co host Hey, Joe.

Jo Peterson: 0:49

Happy New Year Meribel.

Maribel Lopez: 0:52

And we are elevating the edge. And today we're very excited to be joined by another fabulous technical expert. We have Professor Muriel Mytho. She is the NEC professor of software science and engineering at MIT and the chief scientist was Steinhoff, we are so happy to have you here today. Muriel, you are also a member of the US National Academy of Engineering, a member of the German National Academy of Sciences, the Polonia, and a fellow of the US National Academy of inventors, I could go on. It's there's so many great things that Muriel is working on. But first Welcome to the program.

Muriel Medard: 1:38

Thank you very much, Maribel. Thank you, Jo.

Maribel Lopez: 1:42

And thanks to Joe for finding Marielle. So I'm just going to jump right in and say can you share some of the work that you're doing and how it relates to edge computing?

Muriel Medard: 1:52

Absolutely. So the group that I lead at MIT is the network coding and reliable communications group. And I think when we talk about reliable communications, we're really talking about reliable computing. Most of the data that's being transmitted right now is not for communicating in, let's say, an old fashioned sense of just making a phone call, it's really communicating for a purpose for a particular function, which is usually very much associated with computing. So I'm usually communicating with applications, communicating with different services. And those services are communicating with the purpose of computing on the data in order to provide something useful to me. So a lot of the work that I do is around doing all of these different functions in a way that's efficient, reliable, timely, secure, and private. And that's really the core of what I do. And embedded in that is also in a way, which is sufficiently general, to have a real plurality, so that, you know, you're not making sort of point solutions, which may work very well, you know, and might be quite valuable in a narrow context. But solutions which have a wide applicability, and will be of lasting consequence.

Maribel Lopez: 3:29

So it's funny, you started with the making a phone call, and I just realized, I don't remember the last time I made a phone call, because that seems to be a web conference. Now, in a good old fashioned phone call might be interesting. But I really like where you're going with the discussion of we've moved communications from what was a person to person voice thing to a person or thing, thing, the thing, there's a lot of different dimensions in terms of the reliability, the latency, the amount of bandwidth, you need to make different applications and services work. And I think that's at the heart of what we're talking about with a lot of edge computing discussions. And I know that you actually, were chatting about 5g communications at one of the MIT Summer Institute programs. And I wanted to talk about, you know, what are you seeing in 5g? Why is something like opening five d communications important? How does it matter in the realm of edge computing?

Muriel Medard: 4:38

Yes, thank you that that is, that is definitely one of the the topics that's been I think of most interest to me, certainly, personally, but I think has been emerging as a topic that really needs to have much more attention paid to it. I'm gonna start by latching on to two things you said Maribel, which I think are key, one is bandwidth, and the other is latency. And very often, we've sort of been using bandwidth in order to give us more latency, or better latency rather, to give you an example, suppose that you were ordering a meal service and you said, Look, I want 52 weeks of food. And your meal service only gave you four weeks worth of food, but once a month, you know, somewhere towards the middle of the month, your food would be stale. You got enough food, but it's there. So now you would have to choices choice. One is you would try to engineer your system so that you actually get, you know, one delivery a week, and then you get the same amount of food. But rather than having to throw it out halfway through half of it out halfway through the week, you're actually getting week by week. Okay? That's what I try to work on with, for instance, network coding, and having, you know, much smarter management of the data itself. The other approach, which is the approach to a large extent that we've been taking, is to say, well, you know, why don't you instead increase the amount of food you get, you're gonna get four different services staggered in time, sure, you'll get four times more food than what you needed, you know, one week, you get to one service, four baskets of food, you know, another week another service. And that's an effect, what happens with with replacing latency, which is bandwidth. So a lot of the extra banner that we talk about right now, is not necessarily because there is a need for more throughput, more food, if you will, now, you do need a certain amount of food, right? If you don't get 52 baskets of food, you will, you know, run out of food, you won't have enough bandwidth, you won't have enough volume there to sustain your services or sustain yourself. But to a large extent, we have been replacing, in effect, intelligent engineering, which is you know, getting your food delivered once a week, with just overprovisioning, which is getting four different surfaces staggered in time. And I think that when you look, in particular, at the very large amount of bandwidth that has been bought, if you look, for instance, at the latest, you know, FCC about auctions for for for spectrum, you can see that, you know, you see these massive demands, and as I said, this doesn't come from phone calls, right? This comes from computing. So, what happens with computing? And, you know, I think this has a lot to do that with edge computing is, to some extent, you're trying to, again, reduce the latency. And are you going to reduce the latency only by adding more and more bandwidth? Well, at some point, there's also just a question of delay because of proximity. So what do you do you cache, you try to make the the proximity higher, so that you're reducing those delays. And in fact, again, reducing that need for bandwidth. Again, it would be a bit like, if you had a food service system, and you know, you were ordering your food from very, very far away, you know, you wouldn't get it on time for you for your next week. Right. So you're going to order from from a provider that that is closer to you that that can deliver your food in in in a timely fashion. So to me, what happens with edge computing is that it has been interacting to some extent, in a very uncoordinated fashion, I would say, to a large extent, with respect to what's happening in the layers that are actually providing the communication, that is to say, you know, providing the transportation going back to our example, it's like, you know, you managed to get yourself a provider that was very close to you, you said, great, but then their providers sending out somebody on a bicycle once a week, not going to do it. Right. So So you need all of these pieces to be there. I'll give you two concrete examples of of, of the kinds of work that we do. So one example I mentioned, network coding is, you know, of course, you know, been using examples of food. But you know, data is algebraic and food generally, I hope isn't. So you know, the difference being that, you know, I can't take an apple and an orange and merge them together, I guess I could puree them, but it's not very attractive. But you know, that's not what happens with with data, I can take, you know, one piece of data, call it x, another piece of data called y. I mean, in the end, I want x which is my apple, I want y which is my orange, but one of the clever things I do is I can merge them together algebraically, I can solve them, say 2x plus y. And now I have a much more flexible way to represent my data. So suppose that for instance, I have a lossy system, which is one of the big issues in particular in wireless systems. And you know, you're talking about 5g. One of the great things about 5g is that it's looking at developing In some fairly underutilized spectrum, in the higher frequencies, where we often call millimeter wave, think around 28 gigahertz. So, like 10 times higher than the frequencies that we generally use currently, which are usually around like two and a half gigahertz. And that's great. There's lots and lots of spectrum there. But there are a lot more issues to deal with. It's more unreliable, right? It's, it's, it's a very abundant, but much more tricky resource to use. So now, I might be sending you these two pieces of data. And you really need both of them. And you need them quickly, right. So I sent you x, and I sent you y, and say, you lose X. And you see Y and say, Well, I really need x and y, you know, it's this is data, these again, this is not voice, we're okay, some part of it went away, I really need all the data, I cannot make a decision, I cannot provide a service, if I don't have x and y. So you say, look, Muriel, I got one of your variables, but I didn't get X and said, Okay, fine. I'll resend x g. Okay, this is perfectly reasonable. But that whole time that it took for me to send X for you to realize that you don't have X for you to request x back for me. And for me to send it back to you, there's a lot of delay there. There's a lot of you know, coordination and back and forth around are having to decide that. So now, I could say, well, you know, it looks like some of my variables get lost. Maybe I'm going to repeat them. So maybe I repeat x twice, and I repeat y twice, so you get x, then the second x gets lost, and you get y and y. So this is great. You got x and y, but I ended up using twice as many resources and you got two copies of Y when you're going to do with it. Right. That's so you got two oranges, you only need one orange. Okay, so that wasn't that wasn't as you know, that works. But that wasn't very efficient.

Maribel Lopez: 12:38

Reminds me a lot about how we were originally talking about the concepts of quality of service and classes service, just an IP in general. Just like how to how you when you think about it is how do we advance that? How do we move it?

Muriel Medard: 12:55

How do we advance that? Exactly. So you know, X and Y, I mean, everything I told you up until now, they really could have been an app home that orange right that you just don't really look, I didn't get the apple, I didn't get x or I didn't get the orange, I didn't get why or you know, I send you two apples to oranges figuring you know, one of the fruit is gonna get lost. But again, now, what if I happens that I said, Look, I know that some of the fruit gets lost, she really needs one apple and one orange. But what I'm going to do is I'm going to do x plus y. Now again, you know, I can't do this with apples and oranges. But I can do this with with numbers, right as sum of two numbers is still a single number. So like I sent you one piece of fruit, it's a funky piece of you know, it's a orange Apple or Apple orange, or whatever it is, I send it to you. And you know, if you have that Apple orange, you can subtract an orange or subtract an apple and you get back the other fruit. So what I'm gonna do is I'm going to send you X, I'm going to send you y I'm going to send you x plus y. Now, if you got X and Y, fine, right, if you get x lose y get x plus y, you can recover y, if you lost X get y get x plus y, you can recover x. Okay, so now I've what I've done is I've sent you three pieces of fruit, one of them get lost, you got two pieces of fruit, and no matter which one got lost, you're happy, right? And we didn't have to spend that whole time going back and forth trying to identify what thing you lost. We don't I don't also just have to duplicate or triplicate, or you know, however many placate the fruit, which is really, really wasteful, a lot of it is going to go to waste. So I got the data, what you needed to you quickly now, you know, how do we do that in a way which is network ready, right? There's going to be maybe other nodes in between and some nodes are going to lose the fruit and others are not. I may have multiple paths, you know, I mean, basically, I may have particularly go into 5g, you know, 5g is a very heterogeneous suite of, of technologies I mentioned. I mentioned the very high frequencies is also the same frequencies we use in 4g. There's also frequencies like 600 megahertz, or you know, a much lower we, you know, many cases we sort of hadn't used for a while or at least not in this context. And so now you're looking and there's Wi Fi you know, most of the traffic that we think of as 4g is actually Wi Fi you know, my phone is usually on Wi Fi. I have a 5g phone, it's mostly a Wi Fi my home, my family office, it's on Wi Fi. It's only when I'm going around that it's not I Um, so, you know, how do we use all of these resources? So that now again, you don't have to go? Well, you know, send me my apple on Wi Fi and sending my Sunday my orange on on on millimeter wave. And by the way, if the Apple gets lost, and we have to tell you back about it, oh, wait, you're not on that Wi Fi anymore. Let me let me see where you are, you know, instead of doing that, we're basically coding, which is what these algebraic combinations that give you the simplest one, which is a summation, with coding, and then you get a very fluid, very malleable and, you know, highly responsive, adaptable type of system. So that's one example. I can give another example that we're working on, right now I gave you fruit is missing. Sometimes fruit also goes bad, it's there. But you open it, you know, you open the box, and you wish that fruit weren't there, you know, it's just not looking very good. Those are errors, right? So, um, you know, what can you do, you can ask for another piece of fruit. But maybe, you know, sometimes it's not so bad, you can just cut off that piece of fruit. And I'm not giving you listeners any suggestions. You know? No, it's not good to cut off the bad piece from the fruit. But let's face it, we all do, right? The difference with data as you're not quite sure necessarily where it is. And it also depends on how much have you your apples gone bad, you know, how much are you going to cut off. So that's what we call redundancy, you end up ended up sending you bigger, juicy apples than what you needed, maybe because you know that some part may go bad, and you may need to chop it off. Okay. So how do you do that? Well, in traditional systems, you do that by having codes. And the way these codes work is, again, the very, very algebraic in nature, as I was describing before, and then there's a lot of back and forth between the sender and the receiver to figure out what codes to use, the receiver has to be, you know, generally equipped with bespoke, highly specialized, highly expensive, often highly energy inefficient hardware to try to decode that particular that particular system. That's to say, imagine that you had a system where you basically have a paring knife, which will only work for, you know, hon honeydew melon, or for you know, Granny Smith apples, I mean, it's literally to that level, right? It's for that one, not even that kind of fruit, that that that type of fruit, but that that particular type of fruit, let's and even for Apple. So, you know, it's not even just for low density parity check codes, or apples is for low density Pacha codes of a particular type at a particular rate, you know, I mean, it's that specific. And the receivers right now have, you know, all these specific knives to try to cut off the bad parts. And gentle, so you end up having to send really huge amounts of fruit again, remember the example with all the waste, basically, we're now we're sending a huge amount of waste. So we know how much of the fruit goes back, I say, you know, I mean, this called a bit error rate, it's like, one in a 100th of a bit. Okay, so like, 0.1% goes bad. And if you look at how, and that means that normally, I would only have to send extra fruit, you know, of about a 100th of about a 10th of a percent. And instead, what we're doing is we're sending 50%, more fruit 30% more fruit, again, you know, it's because of an effect. Let's just call it, you know, inefficient engineering, that we're wasting all those resources. And because of that, we need more bandwidth. So a lot of what we work on right now is actually being much more conscious. Using optimal codes, and decoding there. Now, why weren't optimal codes used up until now? Well, because we had these knives, which, by the way, you know, only let you cut off like, an apple in half or a third bit off or lop off, you know, maybe a fifth of it, you know, it's like, right now, what we have is a decoder, you know, this, this, this item that fixes the errors removes the bad part of the fruit, and you know, removes it no matter you know, 1% or a 10th of a percent. And for any code, so you have the same knife, whether, you know, somebody sent you an apple or an orange, or, you know, a cantaloupe, you know, you're just using the same knife, and we're actually presenting that this is work with Professor Duffy at Northeast Northeastern University, and Professor Yazici JL at Boston University. We are presenting this at ISSCC which is the major Circuits Conference in in February in in the Bay Area, so we're very excited and and it's very efficient. It's the first one that it actually also does below one pico joule per bit in in terms of energy for, for the decoding. So it's about an order of magnitude from the state of the art.

Maribel Lopez: 20:56

So there has been dying to jump in with question here.

Muriel Medard: 20:59

Sorry, I've been rambling on

Jo Peterson: 21:01

really, really interesting, because it sounds like, you know, what the work that you and your peers are doing around coding is actually going to improve latency. Right. So that's, that sounds pretty interesting to me, because one of the ways that folks had gotten around that in the past is the caching example that you used, or the overprovisioning, right, sort of a way to combat those two things. I want to switch focus here a little bit and talk about wireless API's. And I, I think folks are trying to understand how they might matter at the edge. We've lost me real.

Muriel Medard: 21:57

Apologies, I got disconnected. So I was API's and then let me

Jo Peterson: 22:07

so so Muriel, I wanted to talk about wireless API's, and why they might matter to folks, as the edge evolves, what are your thoughts?

Muriel Medard: 22:19

So, in my view, so let me actually step back and maybe say that it defines that, you know, I think that defining what an API is, is also super important. Yeah. I mean, it's this type of thing that everybody knows what it is. But on the other hand, nobody quite can quite tell you. Like everybody goes, well, of course, you want an API, you know, how could you not want some sort of multipurpose, well defined a robust way to connect to modules? You know, you, you know, I don't want an API Said no one ever right? Although, you'd be surprised, I have heard it. But But then what does it do? Right. And I think what we've seen right now, particularly in the realm of standardization, is we've seen, you know, sort of the API zation, if I may, you know, create a really awful portmanteau of, let's say, the higher layer. So efforts, like open rap, you know, are very much in the API domain. What we haven't seen, and this is something I'm pushing very much for is sort of the API zation. At lower layers. You know, standards have still been, I would say, at the, you know, medium access, or maybe datalink layer and below, extremely, extremely monolithic, let's say, okay, so, one example is error correcting codes I told you before, right, there's, like, you know, if you look at 5g, for instance, is like two different kinds of codes as low density parity check codes, LDPC and CA polar codes, you know, CRC aided polar codes. And that's it. Yeah, this is a huge Wildwater codes, you're going to use those two codes. And, you know, for given number of rates, and that's it, that's all you're gonna do, you know, and things like LDPC is very long and long is usually not very good for low latency. Okay. Now, if you consider the API's ation, I say, No, really, what I have is I have an API, which is, this is my Aircrack ng module, right? Now, you can use the old fashioned incumbent codes, if that's what you want. You can use whatever legacy technology you have, you can use new stuff, which is, you know, better suited to your application, it doesn't matter, right? Basically, the API is data goes in data comes out with a certain measure of reliability out of your system, right. So the chip I mentioned to you, that's called Grand by the way guessing random additive noise decoding. That is, exactly you know, what it does, it just decodes any code, you know, with with moderate or low redundancy. Okay. So, having an a, you know, another example is, prisons, we're doing a lot of work on optimizing modulation modulation is how you actually create say, in the wireless domain in the electromagnetic spectrum, how you actually create the signals that are going to convey information. Okay. Okay. Um, you Right now there's only a certain small number of modulations. If you look at, again, how much performance you're leaving on the table, it's a huge amount of performance. And if instead of being monolithic through standards that are, you know, in many cases, replicating stuff, I mean, you know, LDPC is, for instance, fantastic, but they're from the early 60s. I mean, obviously, there's been improvements, but you know, this is, this is inherently pretty old technology, right. modulations, again, you know, you're doing modulations that are the same ones that I learned when I was a grad student, and that was in yesterday. So you know, how do we actually go beyond that? In a in a in a system, which actually is doing the best thing that you can add every time?

Maribel Lopez: 26:32

So I know that you've got the sound of your next meeting coming up? No,

Muriel Medard: 26:37

I have to do. Sorry about that. To not disturb.

Maribel Lopez: 26:43

But if if we were going to wrap it up in a sentence, what would you say you're thinking about that people need to do?

Muriel Medard: 26:53

I really liked this issue of modularization API's API creation API zation. I think that really moving away from you know, making standards define how API's talk to each other, not defining things that should not be defined that don't need to be defined, not fixing the codes, error correcting codes, not fixing the modulation, fixing as little as possible so that you can have the best performance we are being so staggeringly wasteful right now, you know, and as an engineer, it's, it's,

Maribel Lopez: 27:32

it's just basically do it. Like,

Muriel Medard: 27:36

as an engineer, and yeah,

Maribel Lopez: 27:39

we we'd like to close the podcast with a fun fact, you have a fun fact you can share with the audience.

Muriel Medard: 27:47

So I'm gonna share a fun fact, which is that a lot of people don't know who one of the pioneers in wireless communications was. And her name was Hedy Lamarr. She was an actress, you know, a very successful actress, particularly in the 40s had a fascinating life. There was a wonderful movie by Susan Sarandon called Bombshell about her. And I've given a few lectures actually, about her patent. While this patent, you know, much has been written about her her artistic careers, you know, as an actor, and, and a, you know, a they're quite a polymath. But I think that I don't think there's something that people don't know about, but it's maybe an under unknown fact.

Maribel Lopez: 28:52

That's a great fact. And we'll put a link to some of that in the show notes. You know, thank you so much for your time.

Muriel Medard: 28:59

Thank you both. And if you can send me a link I will, I will make sure to publicize it in my network.

Jo Peterson: 29:08

Thank you so much for taking time with us. Here today.

Muriel Medard: 29:12

You too, have to New Year