Embedded - 75: End Up in a Puppy Fight

Episode Date: November 5, 2014

Glenn Scott and Nacho Solis spoke with Elecia about content-centric networking, being research scientists, and working at PARC. [Note: Elecia was the recording engineer and her inexperience showed by not hitting that other little button on the software. Nacho's mic ended up bad but Chris mostly fixed it... the sound gets better after the first five minutes.] Twitter: Nacho (@isolis), CCN (@projectccnx), and PARC (@PARCInc)  CCNX website (includes contact link) CCN enabled Riot OS

Welcome to Embedded, the show for people who love gadgets. I'm Elysia White, hosting and recording on my own today. And I have two guests. Glenn Scott is a senior research scientist and principal engineer at PARC. Glenn, welcome. Thank you. And Nacho Solis is a principal scientist at PARC. Welcome, Nacho.

Hi. I have been working with Glenn and Nacho for the past few months. PARC is Palo Alto Research Company. It's the research arm of Xerox. It's a neat place, lots of awesome inventions and people with interesting backgrounds doing strange stuff. With that as an introduction, Nacho, could you tell us about yourself? Sure. I've been at PARC almost 10 years now. My training is in computer engineering and networks

in general. I've been doing some interesting stuff and networking here at PARC, looking at the new way to build internet and try to turn things upside down. Not as easy as it sounds. No, it took a long time for IPv6 to get adopted. You say that like you did it. And I would say a lot of people would disagree with that. That's what Nats are for.

Glenn, what about you? You've taken a less direct route to PARC. What is your background? Well, pretty wide. So I've been at PARC almost two years, coming up on two years. Prior to that, I was at Sun Microsystems for 20-some years in Sun Labs and in product groups. And actually, in retrospect, I spent most of my time with one foot in the lab and one foot in the product group.

So I've got a lot to say, I think, and a lot of past stories, certainly, about moving research into something real, something where you can use it. Other people can use it, not just the researchers. And I find myself doing that here, too, CCN. Although originally I came here to work on more distributed systems aspects of CCN, which, you know, as things have happened and evolved, have turned into a larger, broader picture. Well, that's science is you don't always get to go the direct route. Yeah.

CCN is content-centric networking. What is that for somebody who's never heard of it? Because, you know, I did go to that meeting. Content-centric networking. There's a concept that we started playing around with kind of where I joined almost 10 years ago. And at the time, the term used to mean making a network where at the lowest most layers you would talk about content.

Is it like movies or like emails? It includes movies. It includes BitTorrents. It includes emails. It includes audio. But it also includes parts of a conversation or an audio or, it includes emails, it includes audio, but it also includes parts of a conversation, of an audio, or for that matter, sensor readings. At the time when we started talking about it, it was very nebulous.

It wasn't very clear. And a few years later, we started a project that we named CCN. And we made public releases a few years after that, and the project is continuing and creating kind of a community around it. So now the area, which originally we kind of called it CCN, is called ICN Information Sector Networks, and our project specifically, the project at PARC, is called CCN. So when you ask what CCN is now, it's a project at PARC where we use named pieces of data to communicate between all devices.

So all data has a name. All data has a name. Everything from a simple movie, or I guess a complex movie, to a reading of a temperature sensor, or for that matter, audio audio from this microphone or from anything else anything if you want to communicate about it you communicate about the data and the name of that piece of data so already everything has a name i mean if somebody wants to listen to this podcast it's going to be embedded.fm number 75 or something um but that's not what you mean. That's not where the naming is.

It's much lower level. It's replacing IP addresses, right? It is. It is. So we basically use names all throughout the architecture. So we still want to keep the embedded name of the podcast. So we're not trying to change how you name things. At the top, actually, we're trying to give you

a more richer framework for naming things. But those names, some of them get mapped and transformed into what we use at the bottom of the network. So when a packet goes out on the network, it's either requesting something by a name or moving something by a name. We don't use IP addresses at all.

And we run over the Ethernet wire without IP addresses. Correct. So like any modern networking technology, we can run on top of IP. For that matter, we can run on top of TCP or UDP or we can print it out on a piece of paper. But we can also run it below, meaning on top of Ethernet or any other layer 2 technology for that matter. And then if this podcast was distributed over CCN, it would have sections and names broken

up by whatever the data chunk size was. And it would... Can you walk me through the process just a little bit? So it's an interesting thing. So the first thing that I'm going to mention in here during some of Glenn's territory is when we change the way the network works at this level, when we do a paradigm shift,

we have to change how you use a network. So the stack changes. So in this case, when you put a piece of user-level data, this podcast, this whole audio file, potentially with some metadata, and you give it to the network, wherever you define the network to be, it'll do different things to it. It'll chop it up into what you just referred to chunks. So it'll chop it up into pieces. One example is we chop it into 1K blocks. So every 1K, we will make a little piece and we'll send it out.

And we'll give a name to that 1K piece of the big file. And we can communicate about that. But we can also create metadata about all the 1K pieces. They refer to this podcast. And that will be used to talk about the podcast itself. So underneath, at the bottom most layer we communicate about this and we request piece one piece two piece three or for that matter in a more complex mode but there could be other modes where we we divide this podcast by

seconds a second of audio or or 50 samples or whatnot it depends on the way that we're using so to come back a little bit what nas Nasir just said, I want to amplify that because this is, we joke that there are three stages to understanding this kind of networking. There's sort of the incredulous disbelief mode. Folks go through that. Then there's the head explosion mode. This is where you kind of, you start to get it. And then there's the third mode, which is the wholehearted, enthusiastic approach, which of course, where we are. But one

of the things he just mentioned, and it's a little different than what we're just saying, we're swapping out IP, our names for IP addresses, is that not so just described using names to name individual packets. That is a name and a CCN name. But also that CCN, another CCN name can represent all of those names as a bundle. And this is different. You don't have IP addresses necessarily that represent other IP addresses. This is a hierarchical structure in the naming system that allows for all kinds of flexibility in how the data is named and used. And so when we start talking about CCN as content-centric networking, what I often say is that it's not just about the N.

It's not just about the networking. What we end up with is a whole structure of stuff above that networking that make all kinds of things different for applications, for developers, for the way you think and design your applications. You're no longer making a TCP connection like a phone call. You're decoupled from your companion on the other end of your request. All these things change the way that you do many, many things we're used to doing today.

So CCN isn't exactly a one-for-one replacement of IP addresses with CCN names. It's much richer than that. And this takes a while to sort of get your head around. Well, one of the possibilities was, say, this podcast, if it had lots and lots, you know, millions of users, like, say, a Netflix movie might, it doesn't have to reside on the server where I put it anymore. Right now, it's in Libsyn. Anybody who wants to get the podcast has to go to Libsyn. Even Stitcher, which hosts another copy, goes to Libsyn for the original. And there is only one original. But with CCN, it can be distributed, right? Yeah. What happens in CCN networking is that you will make a request for a piece of content by name. That name will route itself through the network, arriving at some location,

which is essentially advertising that that content is available from there. In the first case, it's likely to come from the producer. And as the content object, the reply, comes back through the network to satisfy your request, it can be arbitrarily or opportunistically cached at various places in the network. Such that a subsequent request for the same data may be served out of that cache. It may be faster because it'll be served more locally. Yes, more dynamic in the sense that if everyone's watching the football game right now, it's quite likely those packets

will be more local to you than if you're watching from some central server, which is what you do today. And that seems like it would ease the traffic on the backbone. Certainly. That makes sense, mostly. I think I'm kind of, I'm not quite, I'm in the head-exploding part. But most of our listeners are hardware and software engineers, embedded software engineers. Why should they care about these routing protocols? Yeah, I don't know if they should care about the routing protocols themselves. I guess the part is... You had a whole section on Internet of Things. We did, we did, and we do have it.

I'm just saying the routing protocol specifically is not the part that they might care about. The architecture itself is something they will care about. I guess first, before we go into your listener audience, for users, most users are not going to care. I don't know your audience in particular, how many know what port this audio is coming through on your computer. Somebody just shouted it at their car stereo,

just so you know. Somebody did. So, and I don't mean hardware port, just to be clear on that. I mean network port. But a lot of people don't know. So from the user perspective, not a lot of stuff has been changed. From the developer perspective, whether it's hardware or software, we are trying to provide

a framework so that you don't need to care about the network if you don't want to. In this case, we'll try to abstract most of what's happening underneath. But if you do want to care about the network, if you want to know specifically what's happening, we'll give you the tools to do that. So from the perspective of a specific developer, the big mindset that you need to adopt, that the change that you need to be aware of is don't try to focus on what to connect but focus more on what data you're producing and what data you're consuming. So when you produce data from your device, figure out

what could I name this data? How is it organized? How is it related to other pieces of data that I'm creating? What kind of data do I want to request for what use? Can this be shared? Is there some relation between this and the next thing I'm gonna request or the next thing I'm gonna produce? And more specifically, how do I wanna protect this?

So we haven't talked a lot about this about security, but in CCN, we secure each piece of data as opposed to securing the connection. So when you produce data, you have to think of who's going to consume it and under what conditions to be able to determine what security to apply to it. Say I had a temperature sensor at my house and I wanted access from me and from my husband and let's just say I wanted to give it to NOAA, the weather people, so they

would know what my house temperature was too. But I don't want everybody to know. And I do temperature, say, every minute, every hour, whatever. So the data isn't really related. Well, it is, because it's the same location, potentially the same sensor, and you're producing maybe every minute, you were saying? Yeah.

So one data to the next to be a relation per minute. If you actually knew that that's what you were doing, you would know that given a certain reading, what the previous reading was, or at least what it would be called, or how to refer to it. So if you wanted to determine patterns, you would know what to request to try to figure out a pattern. In terms of security, most of security is enforced by keys and encryption. And the way to distribute keys

between you and your husband, and for that matter, how you would share that data to an OAA. Government agency. Pick an agency. So they're trying to figure out if there's a big crime, then it's not just your house burning. There's different ways to do that. Strangely enough, once you start sharing with larger communities, there's other things that take into account. And now they might want to know,

not that you're sending them protected data, but you're actually sending them valid data. And they want to validate that your data is actually true. My sensor is still on. It's not just spewing. Right, not to mention calibrated and whatnot. So there's a number of different concerns to deal with that part. But if they trusted you, then you could still produce data that would be readable by them.

And you can either use traditional public-private key crypto or other forms of certificates and authorities. Or you could have some unique relation. That is a lot of the things that happen now today, maybe not in general embedded situations, but on phone and mobile, where you have a lot of security embedded in the app that you downloaded. So you downloaded an app, the app came with some form of trust because you trusted the app store, and now the app could have embedded keys of who it communicates with. So if you had an app that communicated with NOAA, then it could figure out the communication with them securely.

Between you and your husband, I don't know, that's a separate thing. I don't know how much temperature you're willing to share. But some access control might be needed there. One of the other things that I personally found interesting with CCN was the ability to name an item and then travel between different types of networks. For example, if I had a personal camera, GoPro or any flip as though that still existed, but you know, a personal camera and I wanted to let my family peer out through it whenever they felt like it. And so it wouldn't matter if I was on Wi-Fi or on hardwire or even mobile. With a named thing, it can travel between and it doesn't really matter. That's kind of CCN over IP probably.

Did I make this up? I think you're onto something. I mean, the sense that CCN doesn't have to care what the network technology delivery mechanism is, right? The name is request, and the content object is the reply. That's it. However it gets from you or to you is irrelevant to CCN. So the networking can take care of that. And, of course, transiting from one kind of technology to another is handled by,

we have, of course, network elements like routers. We call them forwarders that take care of that translation from one to the other. But ultimately there's nothing in the packet that says anything about the technology or anything like that. So, yeah, you could be on your home Wi-Fi, have a video, walk out to the street, get on 3G or 4G, do video over that. You could go back into your neighbor's house, get on their Wi-Fi, and this could all appear as a completely uninterrupted stream. Right. So, obviously, at some point, part of the network cares where you are. But from the perspective of a user or even from a mid-level developer, you would not care.

You would know it has a name and that's it. That's all you need to know. The network still has to do some minor switching, depending on the situation, if you're producing data as you move from network to network. Right now, in the current internet, we do that through a number of levels of indirection, whether we're going from layer two to layer three three or layer three going up and switching via DNS. We do many different things to be able to achieve that. CCN, because we use name stuff,

that is kind of built into the network. So whether we want to do that via a third party indirection service, maybe you're going through a GoPro service that registers GoPro cameras and then you can share via them. Or you're doing it via your own namespace, maybe your own embedded namespace, and have routers help you along with that. Or you have something even lower layer where the network is helping you discover where content is, which by the way

I've done advice for everybody. We want to provide that framework, the ability for the network to allow you to build different types of solutions. We have a set of solutions that we built that we believe are appropriate for different scenarios, but it's a long road and then maybe somebody will find better solutions as we move along. So when might people be seeing CCN-enabled router on their, I don't know, work, big routers? I mean, when is this going to happen for the rest of the world? Is it 5, 10, 30 years? What is the timeline for this sort of thing?

That's a good question. I don't know how long until somebody will see it. It depends on who you ask, I suspect, too. Somebody will see it. Because we can run on top of IP, finding CCN traffic on your network, as in you'll do a TCP dump

where you'll be able to see the packets going through and you say, hey, look, it's a CCN packet. That might run over IP or over TCP or over UDP, and that might happen in five years. That's possible.

When will you have optimized hardware that has specific modes of operation for CCN? That will probably take a little bit longer. And caching, all of these things you said, it sounded cool. No, but we can still do that over IP. So there's a couple of coordination services that might be required for the network to achieve this. But with now a lot of devices being able to support SDN and SDN software-defined networks where you control some of your network elements,

you might be able to do things a little bit easier. Again, until you see real full deployment of CCN as a general technology, it will be a while, a long time. 10, 15 years. And until you'd imagine that you could completely replace TCP, UDP, IP functionally, it might be a little bit longer. It'll be a while. There's no risk in you having to go out and buy new equipment anytime soon. Yeah. So that actually segues into the other part of what I wanted to talk to you two about.

And that is that your titles are scientists. And what you're doing doesn't need to ship for Christmas next year. I spend so much time working on consumer products that need to ship within 18 months is a fairly long development cycle sometimes. But you're doing 5, 30 I mean, this is a long time. This is a long time. Takes a lot of planning.

And we've been doing it for a while too. The internet has been developed has been in development for a long time. We're not done yet, right? So we use the internet every day and we're not done. The IETF, which is one of the organizations that is in charge of writing down, let's say, internet technology, is still working hard and figuring out new ways to do better networking with all that we have today. And we're still learning.

We're figuring out new ways to do web traffic, or new ways to do audio traffic, or new ways to cooperate. It's taking us a while, and we're still doing it. For CCN, it'll be the same thing. It'll take us a while to figure out the first stage, and once we do that, it'll take us a while to figure out the next stage and the next stage. Because these projects are big in scope and nature, and of course, we're building on stuff.

All this internet stuff we've had, we're building on that. So all of that experience and all of those ideas are still fresh and going on. So yeah, this is research in the sense that we don't know exactly where this is going to go or when it's going to be there. But we do know, you know, we all have experience in making the path to go down a path to try and, you know, prune those pieces that we know aren't going to work and get the best ones that we do know work and so forth. This kind of project also introduces new kinds of problems. And one that folks may have already clued into already is that names are really going to matter. And CCN uses a name. We call it a name.

It really is a hierarchical structured name. If you see it displayed, it will look just like a URI. The name is used for routing. It's also used for naming specific things. And names actually have components in them that represent what they mean. So, for example, you can have a name that has a chunk number. So this podcast, every audio chunk would have a number. Quite likely they'll be in

some kind of serial order and so forth. And so what will happen is that unlike the internet today, where you don't really concern yourself necessarily with the format of your IP address, CCN names will matter. And they may have as much impact on the design of your application as the choice of data structures. And so part of our research has to include what are the best techniques for arranging names to do various kinds of operations. Movies and individual data packets is one example. But there are other things that can be done. Well, even the temperature sensor, how to name it so that you get the latest value as opposed to if

you want historical value. Exactly. It's a different naming problem. Exactly. Do you think there's going to be a big land grab for names? Yes. Yeah, there will be. I think, yes.

I agree with Nacho. We're somewhat familiar with land grabs right now. Yeah, because Park owns all of the 13 subnet. That is so cool. Xerox owns all the 13 13 subnet. That is so cool. Xerox owns all the 13s. Yeah, sorry, Xerox does. Yeah, but we were there. We helped build it.

So I think that we deserve to have the 13. In this case, strangely enough, as opposed to the 13... And this is 13.x.x.x. It's the IP address. So as opposed to the.13, where there's only a limited number of, one, IP addresses, but more limited class A networks, that's not going to be the case for names.

So for names, you might find that you want a shorter name, because that's really cool. But we're not going to run out of names. In this land grab kind of situation, there'll be some entity coordinating the bloodbath, potentially charging large sums of money. But I'll just interject here. I think when it's all said and done, that won't matter. Because the names that will be part of this land grab, these probably will not be names

that you will see as a user, maybe even as a developer. These names, although on slideware and talks and things we do, we show these names as being human readable. You write them down. We always start our examples off with PARC slash something, something, something. But in the end, the names that are on the packets

could just be just some MD5 hash of something. All it has to do is route. It has to be routable, and it has to uniquely identify something. So the land grab is somewhat artificial, I think. Right. There's a land grab thing that we will gravitate towards, and it might not be exactly where you think the names are,

but even though I know this is an embedded podcast, there's something in the networking world, specifically the naming networking world, that we call the bus test. What do you put on the side of a bus as an ad that people will be able to remember to get to where you want them to go? So if you were to put an ad on the side of the bus,

what do you put in there? Oh, that has huge effect. I mean, this podcast used to be called Making Embedded Systems, and then we got the embedded.fm URL, and eventually just kept saying embedded until we got bored of the other words. Yeah. So that is an important test.

And how this maps to network names is important because right now a lot of people just type stuff on their search bar. Or, I mean, for that matter, our search bar now, our URL bar is now also a search bar. So it doesn't matter what you type in. It'll go to Google or Bing or whoever is answering your thing. I've heard that Google, one of their highest rated, highest searched for items is google.com.

Yes. Because of the URL search thing and people want to see the little, I don't know why people do that. But yeah, they want to know where they are. So that bus test, what do you map to a human the human can remember and put somewhere to take you to where you want to go is an important test. Now, for us, the names that we carry in the network underneath, they don't have to pass the human readable test. Now, there may be some names that can do both.

Right? So embedded.fm could potentially do both. Right? It's short enough. You can see it on the side of a bus. You might remember it. And the network can carry embedded.fm no problem. But for more complicated things, or things that are ambiguous, let's say the word water.

I don't know. I don't know. I mean mean water is pretty easy to remember but what is it related to? there's a bunch of water companies or for that matter automobile or sex for that matter who really owns that word?

it's hard right? so then you start I guess recently we had Ebola being sold for a lot of money, Ebola.com. Why? Yeah, okay. Because people can, right? Who really owns that? And it doesn't matter, right?

So for us, from the networking perspective, we don't care what you put in the names. This is a policy decision. So it's more of a politician decision or a researcher decision. We just want to make sure that the system allows for this to happen and potentially create better ways to alleviate the land grab kind of situation. And we have technology in the project now that provisions for various context-based names. Like you could say, this room's projector, where the name is, I don't know, this room.

Or within your house. Within your house, you can name stuff inside your house. Where my thermostat, where the word, the name my means something, which is different than the neighbor's my. This kind of naming can happen as well. I mean, there's translation obviously going on, but yeah. And so kind of like I have a home IP address that is the same actually as my work IP address, 192.168 sort of thing. Yeah. Being careful to not conflate a lot with IP addresses and naming. But my can indicate my home or myself.

Yep, some context. Right, right now that happens a lot when you buy one of those routers, and you can go to my router, and because it runs a DNS thing, it can say, hey, my router, that's me, that's me. Right here. But with many different things, we use relative names. That's me. That's me. Yeah. Cut. Right here? Yeah. But with many different things we use relative names.

So right now, for example, what we do for MDNS, which is the local domain, right, where your laptop, if your laptop is called puppy, puppy.local will go to your laptop no matter where you are. Because we resolve that via MDNS. It doesn't matter where you move your laptop. So when you build devices and you don't know what context they're in, you can assign them some form of local context to put their names.

I guess if two people name their laptops W. Then you end up with a puppy fight. Yeah. But we were going to stop talking about CCN. Oh, great. And we were going to start talking about... Can we do the fun part now?

We were going to talk about being scientists. Ah, scientists. I mean, because you two aren't... I get so caught up in shipping products. But that isn't what your daily world is about. It's about actually thinking through hard problems. But I don't know how

you can call yourself scientists since I've never seen you with either a beaker or a lab coat. I don't have a lab coat, that's true. I've got a cape. Yeah, you have a cape. I have a helmet. That's a good question.

I remember a completely slight anecdote here. My mom is a scientist. Even though she doesn't wear that many lab coats, she does own a few. I guess she's retired now. She does gastric cancer research, what she used to. So she would look at

large amount of population and how they eat, what they eat, and what gives them cancer or doesn't give them cancer or what changes the ulcers. It's complicated. But there's like 5-year, 10-year studies over large populations. And growing up and becoming an engineer, quote-unquote,

I always thought, that's real science. That's real science. And she doesn't do, like, test tubes and stuff, but her colleagues did, and then she would do the other part, like looking at biopsies and all this kind of stuff. And I'd go, Mom, you're doing real science. I'm just kind of futzing around here with a computer. I'm just typing on my keyboard.

And she would laugh and say, I see what you mean, but I think you're wrong because the reason I can do the work that I can do is because I can collaborate with people across the world. And I would not be able to do that without email. That whole internet thing worked out pretty well for a lot of people. It did. She was pretty happy. She was pretty happy with email.

So is email a science or just an engineering problem? Well, engineering is about getting it so everybody can use it. But somebody has to figure out how to do it the first time. I agree. Right. I mean, the way I look at this is that the job or the role of the scientist is to figure stuff out and make it possible for someone to build it. Granted, I'm not shipping a product here at PARC. I've shipped products before, but I'm not doing one here. But I know what it takes if someone were to. And so I'm trying, you know, every day, all day, making sure that what we're doing

would be able to be transitioned into something, some product group somewhere else, won't be a park, can make this real. Because otherwise, if we just end up making a prototype and just a thing, no one's going to want to pick that up, just a thing,

and try and shoehorn that into some product. So what we have to do here is not only figure out all of these pieces that I mentioned, right, prune off the bad ideas and pull in the good ones and invest time and thought into those things. We need to do it in a way that it will live beyond us. It needs to move into real product development, whether that's hardware or software or combinations. That has to happen. Well, I know you have worked on making a test-driven development system here for the code. I believe there's a whole framework now for testing. Yes, there is.

Is that part of that? It wasn't originally. Okay, so part of this endeavor is both figuring out the hard problems, writing those solutions down, or writing down the things you know didn't work. That's part of it. And that's pretty early sort of design, exploratory, speculative research. We're also building a system that we expect that people that don't work at PARC, other people elsewhere, will be able to get, like they download it or get it from their friends, and use in a way to experiment on their own. And I mean experiment. It's not just a little toy. It's just to be substantive enough to actually write production-level software for your application.

Whether you're related to anything Park's doing or not, you should be able to go with this. So part of that, as I mentioned earlier, I've had experience transiting that from lab to product group. And what is necessary for that to happen? And one of the things is that nowadays you really can't get a buy without a real structured testing thing. And so we're implementing all of the foundation stuff we're doing now is in the C programming language. Test frameworks for C programming languages, you know, things.

There are some out there. I found all the ones I found, I found them all sort of wanting. So in my own style, I made a new one, and that's what we're using. It's working pretty well so far. And the tests provide verification it works, as well as documentation on how this code is intended to be used. Yeah, that's more disciplinary. That isn't necessarily enforced, right? You can write bad tests. Oh, absolutely.

But yeah, one of the things that we're doing is the tests themselves continue to live on as individualized little demonstrations of code that works. So when we deliver our software, along with that will be the tests. And that is the goal, is to deliver, I want to say, a reference design, because that's what I usually get in hardware when I'm starting out with a chip. But it's sort of a software reference design. Yeah, software can have reference designs, and this would be one of those, because we're not targeting a specific product. We're targeting users that would make specific,

you know, developers that would make specific products. And so to make that easy for them is part of our job. Right. So the software that we're trying to build is meant to be used as a reference platform, might be a better way to put it. And you should be able to use it to run experiments looking at the technology we're building, but also easy enough to modify to look at the part that you might be really interested

in, right, of all the things that we do. And I assume this is potentially similar to some hardware projects where you might take a reference design and modify the parts that you're trying to differentiate yourself on. In our case, we're trying to do exactly the same. So we're trying to do a software base that will work. You have all the base functionality. It'll do everything you want it to do, basically. But if you want to do something more advanced or something unique, whether it is to your

system or because you think, hey, I have a better idea on how to do this, then you can use the software to build upon. Not everybody needs to rewrite the same code over and over again, that's what it does to read transmission. At least we hope so. So for everybody else, the read transmission code is there. Just use the code. Use the code and then focus on the part

that you want to do. Maybe you have a new encryption module that you want to do, or you have a way to do simpler names, or you have a way to do shorter encodings. Some people do that. Other people, for example, let's say from maybe the audience of this podcast, is you're trying to build a system and networking is not what you're building. You are building some small component to go somewhere, capturing some data, or producing some data, or requesting some data, or having some actuators, and all you need to do is communicate. And what you need is a messaging framework that has certain capabilities. You want it to be reliable, you want it to have some sort of

latency guarantees, and as much as have some sort of latency guarantees, and as much as the network can give you guarantees, some security, and you're just looking for a tool, a tool to communicate. Our system should be able to provide you with that tool. If you don't need to modify it for anything else, you're good to go. Tools on. You compile it, you build it into your system, voila. To add a little to that, I'd say most of this work happened last summer, summer 2013, where I was just started on CCN and I was experimenting a lot with the system and I had some particular troubles and some ideas that I thought should happen. And one of the things I realized only now after coming to PARC is this, that for me, I had a lot of experience in the lab transferring projects out of the lab.

Either they were whole projects or little bits and pieces of projects. And what happened over time is I got pretty adept at, as I characterize it, putting Barbie clothes on my projects every week to make them look or fit into some other product group's needs or process or frameworks that they were using. And I realized now that that experience brought a lot with me about how to design a system that we can make it such that you could. Because you want to build the Barbie. I want other people to be able to build the Barbie.

So we've got all the parts here, and the idea is, and the design is such that you should be able to swap out pieces without having to know or swap out the whole system. And that's a big part of it. That makes it a reference. You know, ultimately, ultimately you will probably not want to use that necessarily for performance reasons. You might want to take the collection of things that are loosely chained together

and collapse them into one thing. But this is a design thing. Maybe. Maybe, yeah, maybe. The stuff we have is actually pretty good. It is pretty good. It is pretty good. It's really fast.

There's a critical section, right? There's a section that consumes most of your resources. You can always optimize that to your hardware, right? If you are building a big router or you're joining some deeply embedded system, you want the memory manager to be mapped into how you have your memory modules laid out. Who knows?

There's a bunch of embedded things you can think of. But the general code, there's not another critical path. That might not matter that much. But hey, if you want to make it matter, make it matter. You could. You could make it matter. But hey, if you want to optimize the last 1%,

then I guess I would devote most of your effort to the 80% of the work that you can compress quite a bit. Yes. Right? So whether you're doing zero copy or you're doing some special form of buffer management between you and the bottom half of your driver, hey, that part might matter.

Whereas the stuff where we're moving little bytes around here and there or adding one or whatever. But in the end, we care a lot about the developer's experience with using the software. And so that experience needs to be positive, which means it needs to be fast to get up to speed. It means to be able to be, you know, performance needs to be good enough to make your own good demo out of and so forth and so on. That experience is very important to us. Right. The code is definitely exemplar. Right. It's example code and not only is it an example, but it's exemplar, right?

It's meant to be something that you strive for. Code that is understandable, easy to use, and you understand quickly what it does. Especially when you deal with a new networking technology, you can't make it that complex because you're going to confuse people really quickly. We run into that in the past where we use the wrong words to refer to stuff. I mean, we still struggle with that. Oh yeah, vocabulary. Coming back to the internet issue where some technologies are victims of their own success, right?

You deploy something, everybody adopt it. And now you can't change it. Screwed. You're like, I wasn't serious on that. It wasn't ready, but now everybody's using it. So we kind of seem to have fallen into that with some of our terminology, which we inherited from the past. And now we're like, I can only change that. But it's now so popular that people would get confused.

So we struggle with that as much as us. Software people, I think a lot of software people understand this too. If you put something in, it's terrible to try and take it out later. And sample code. If you put sample code on the internet, it's going to make it everywhere. It's going to make it everywhere. So we want to be real careful not to make too much. I don't mean too much software. I mean we want to make it everywhere. It's going to make it everywhere. So we want to be real careful not to make too much. I don't mean too much software.

I mean we want to make things very general and generic so that as time progresses, we will be able to specialize in areas that we know that are solid. If we just end up making, for example, APIs that have 80 function calls in this API and all these 80 function calls, each one does a little different twiddly thing. We'll never be able to back out of that.

So there's a whole lot of things that happen here that have to do with the things Nacho's talking about. Is this a science versus engineering thing? I mean, is this where you're trying to solve a very, very generic problem and engineering is more go optimize and make it apply? No, I think this is engineering. But what's happening to us is we are doing science.

And as we discover and develop stuff, we have to figure out what is the best way to instantiate this. Right, exactly. And this is part where we feel Park has a good strength. And where we're dealing with the science more amorphous thing of like, hey, I have an idea on how to do that. Let's name stuff.

Let's give you an example. And then you have to figure out, you know, the name is going to happen through like some piece of code. Right? It's not just a PowerPoint slide or a document describing like the euphoria that we feel when we're like, oh, yeah, let's name it. There's going to be a function call and there's going to be some way to execute a function call and you're going to relinquish your thread or not relinquish your thread or have like three parameters or two parameters that may or may not return.

Figuring that out, figuring the step of calls to take, the code that should be executed for that to instantiate, that's engineering and science just battling it out. And as you're aware, and some of the hardware stuff that we do, we have that. We have now some ideas in our head on how we think things should go. And then you look at the board. The board doesn't move, right? The board is laid out.

The board is ready. You can push on those ICs, they're not changing. And when you look, I imagine, you're like, all right, let me build a CCN router. And you open your software to drive this VLSI and it's an empty, big block. What do I put down first? Right, you don't start from scratch, you're probably going to go and look at some libraries of things that were done in the past and then you're like, I don't know. That's engineering.

That's engineering meaning science right there. When the change that you're trying to make is small, it's like you have this big board and you're like, you know what, this little component, I need to add a new connector there. Or you need to whatever, I need to switch the voltage. Those things compartmentalized don't seem like a big problem. When you're like, there's a new way to think of things, people, we're now having, instead of binary, we have like trinary networking or whatever, logic. It's not the same, right?

The minus ones don't work that well on what we currently have in mind. So switching gears a little bit, you've each filed for many patents. I want to say dozens, but I didn't actually count. What advice can you offer to engineers who haven't, who are maybe more on the junior side and are intimidated by the patent process? Pair up. Talk to a lawyer. You have to talk to a lawyer eventually, but pair up with somebody. Ideally, pair up with somebody who's done it before, and you'll see it the process through, and you'll get it.

Not everything is patentable, of course. You need to worry about all the prior art stuff. You can't patent a table, despite what a lawyer might tell you. A lawyer will tell you to patent the table. Yeah, but you can't do it. It ain't going to happen. I wrote novel software on this table.

Therefore, this table should be patented as applied to. Yeah. It's funny. Coming in, I didn't deal with patents until I joined PARC. And at PARC, I have to deal with them quite a bit. And it's true. The lawyer will tell you to patent everything.

Originally, I was more against the patent side. Now I have conflicted feelings because due to current regulations, if you don't patent it, you don't own it. And even if you wanted to make it free, you still have to own it to make it free. And depending on whether you're an individual or a big corporation, patents come into play all the time. I do echo Glenn's thought here of pair up. Not only are you going to get good advice from a peer, hopefully it's somebody that you trust and they give you good advice,

but you also come up with better ideas. And the better the idea and the cleaner your description, the better you're going to do with the patent. Yeah, I agree completely. You don't want too many people on the patent because then that just totally dilutes it and makes it troublesome perhaps later. You know, about a thousand claims.

Two is probably minimum. I mean, one person patent, watch out. But two is pretty good. Three is kind of entering into the sweet spot, I think, of three people because then you've pretty vetted two is pretty good. Three is kind of entering into the sweet spot, I think, of three people because then you've pretty vetted the ideas pretty well. A lot of folks, I think, don't understand patents. They think patents is being – they need to give you runway.

If you have an idea and you want to explore and push on that in a way in a public space, you need a patent to help clear your runway. Otherwise – and that's what they're for. They're to make a runway for ideas. But a lot of times, I think people misunderstand them as like obtrusive, obstructive kinds of things. And that's not the point. Like Nacho said, if you want to own something and you want to make it free for the world, you can't do that if you don't own it. It's just straight up. If I have a patent on something and I want to make that available to the world, I'm the only guy

in the world that can do it. So don't think of patents as being obstructive. They're also enabling. They can make other people's lives better as well. But if you have a really novel idea and you want to protect it and then not make it free, pair up with somebody, find somebody that's done it before, and then get a lawyer.

A patent lawyer will help you quite a bit. You can do it all yourself. But sometimes it's easier with a lawyer. It's your time versus theirs. Also keep in mind that writing a patent is not the same as writing a paper. No, not at all. Or an RFC or... Very different.

Very different thought process, very different requirement for what's written, very different sort of maturity descriptions. Sometimes papers can describe things that are pretty mature. Patents usually try to abstract a little more. Yeah, and we did have Judith on from Hip Legal about a month ago. So if you're really thinking about patents, check out that show. And also check out the Nolo Press Patent It Yourself book, because even if you aren't going to patent it yourself,

you should understand the process. Oh, yeah, you should know what the lawyer is doing. It's a lawyer's time, but you should know what they're doing. Most of the time, because especially, I mean, it's patents, right? That means you invented something. It's something new that nobody else invented before you. Chances are the lawyer is not going to get it 100%. No, they're experts in law.

That's what they do. So they're going to figure out how to try to scope your claims out of the text that you gave them or the number of meetings that you had with them. But yeah, you need to understand the patent process so you can know what's happening, what is being done. Yeah. And just to echo, because I'm activated now. So what happens with the lawyer is that they're not going to be an expert in your thing. They're an expert at writing stuff down that gets through the patent office. It's your job to make sure that what they wrote down is your thing.

Even through all of that incredibly arcane language. That too. Yeah, it's tough to read. Yeah, one thing to be aware of, depending on your patent, it might take a while. There might be a number of iterations you have to go through. One with your lawyer, or for that matter with yourself, and number two with the patent office. Yeah, those poor guys are neck deep in patent applications.

So three years is a great time. Oh, yeah, that's fast. I had a patent just issue. I spent eight years sitting. So you also present at conferences and write papers. And I understand the writing papers part because it's communication is such an important piece of what you do. But conferences take a lot of time. I mean, a lot of time. I've seen you guys prep for a conference.

Is it really the most effective use of your time? You could be writing papers and writing code. Right. So we do a number of things. We obviously write papers and present at conferences. But we also want to organize conferences ourselves, either conferences here at PARC or through the general professional organizations. And that takes a lot of time. Now, the reason that we do it and then we're willing to spend the resources to do that, mostly meaning time, our time, is that because we're defining a new paradigm in how we do networking, we need to have

everybody help us learning, thinking about what this means for the future and have buy-in from the different companies. And for that we need to foster an external community. It's not like we release one product and we're good to go, hey, go out and sell it. We need everybody to be at least in the same wavelength, even if we don't agree on everything. And for that we need, to be at least in the same wavelength I mean if we don't agree on everything and for that we need right now at the research stage at the science stage We need to be able to be to talk to other researchers and this includes students professors research institutions academia in general And then that's what we do in these type of conferences meaning like ACM or IEEE or that sort of a conference world.

We also from the practical perspective collaborate with things like an ITF looking at not only possible standardizations but having other companies that build systems like this be able to give us their feedback on what we're building and sometimes they're trying to build it themselves so we give them our feedback especially what we're building. And sometimes they're trying to build it themselves, so we give them our feedback. Especially because we're dealing with a networking technology and we need other people to participate in the network, to add value, then we need to have buy-in from a number of participants

and have a number of stakeholders as the technology moves forward. So that is really important to us. And it is definitely, I don't want to call it a time sink, but it takes up a lot of time. And it's worth it, getting the feedback and making sure everybody is truly on the same page and not just nodding along bored.

Yeah. So to back up a little, get a little more abstract. So for me, I think the job of a scientist is to communicate. So who do we communicate with, right? So the conferences are one way to communicate. Clearly, writing papers is another way to communicate. Oftentimes, those things are joined together. Writing code and making code available for other people to use, that's another way of communicating.

But all of these things involve kind of a funny phrase, and I'm not the guy that said this. I imagine everybody listening to this podcast knows who said this, is that the difference between science and screwing around is writing it down. And writing it down is communication. So, yeah, we spend time with conferences. We spend time with visits. We invite people here to come and talk with us. We spend a day oftentimes with other researchers. We spend time and worry a lot about the code we write,

the words we use, all of that. Is all of that to communicate? Because again, we're not going to be able to do it all ourselves, so we need to communicate with other people, either to keep them in line, online so that we know that we're thinking the same kinds of things or whether we're wrong, or communicating, showing folks how to do stuff.

Here, do it this way. Do it that way. This is all part of the job. So where do you see yourselves in 10 years or 20? At a desk, typing code, papers. Yeah, actually. Maybe more keynote. Yeah. Yeah. I. Maybe more Keynote.

Yeah, I'll be in front of a screen presenting something. Or last minute, figuring out the things to put on a screen to be presenting something. Yeah, that's the slide deck. Personal style stuff here, exactly. Yeah, did you mean individually or do you mean as a project like the ccn project i mean individually i mean ccn is very cool but we've talked about it has a future and it's not yet but as as scientists and and where do you do you see yourself happily here continuing doing more networking or i don't know there have been a lot of park people who

spin out on startups on whatever their research is about and i'm amused that park then invites them back in five years well park is a very unique place in that regard right so this is a real it's a on one hand it's kind of like a farm you you know folks will do stuff here and then spin out and go do and this is famous for that right ethernet was probably one of the most famous examples just in the front of the right down there by the copier yeah that was the original ethernet original ethernet yeah and the floor we're on yeah so but i mean there's a lot of historic things that Park has done, but there's also stuff going on in the future. Oh, yeah.

And CCN is part of that. Oh, yeah, CCN is a big part of Park. But Park does... Many important people have come through Park and then gone to other foreign companies or joined big companies or do their own startups, some more successfully than others. Being a good scientist does not mean being a good CEO. That is absolutely true, or CTO, or CFO, or anything else.

But also, having a good idea is not enough to form a company. And vice versa, you can form a company and have a good idea, and then be on the ropes. But people that come to the park learn the parkway and then they move on and sometimes they take some of that culture with them. And many of the companies here in the Valley hire from us

because we have a lot of good people. I believe the word you're looking for is poach from us. Yeah, yeah. They do poach from us quite a bit. And I think that's actually very good. It keeps us relatively on our toes and fresh,

but it also creates for us specifically a very big, strong network throughout the Valley. Absolutely. We know people everywhere. And many of the big companies have roots or leaders that were at some point at Park. Now, from our perspective of CCN and individually, in 10 to 15 years, there's some possibility that I'll be here at Park in 10 to 15 years. There's some people that have been here at Park for like 40 years.

Yeah, even our IT guy has been here for like 20 years. Yes. That's amazing. He knows all the dark corners he knows where all the cables are under the floor he knows where all the IP addresses are all those spares yeah but we do live in a dynamic

dynamic place and people come back and forth sometimes they return to work and move to other companies dynamic place and people come back and forth sometimes I return to work and move to other companies both Glenn and I are relatively flexible enough that we could be doing other stuff in this case because Park is the epicenter of the ICN world information centric networking world with CCN. It is hard to think of doing something else right now because we want to ride this

and see where this goes and where this... We're in the enthusiastic support stage. Yeah, whether this is here at Park or on a spin-out or as part of a larger company, I think CCN has a ways to go still. At some point, it'll migrate more into a product, and it'll kind of stabilize a little bit more, maybe not be as exciting. And then research will take us in different directions.

Potentially, sub-modules or sub-children of CCN, or for that matter, will be working on carpeting. I don't know. There's a thousand things that things could develop. Mars drones. Mars drones. Mars drones. Drones. Drones on Mars, yeah.

But we will probably have similar roles to what we have right now. Yeah. Whether it is slinging code, making plans, talking to clients, presenting. Thinking about hard problems. Thinking about hard problems for sure, not being bored. Paving the way for other people too. Life is short to be bored. So if we don't get stumped by a problem here or there every once in a while,

then something's not right. Nacho mentioned something a minute ago which kind of struck with me, the parkway. People come to park to learn the parkway. I came to park, but I knew the park way because I realized also in retrospect that I ended up in Sun Labs some time ago at Sun Microsystems. And Sun Labs was put together at the time in the beginning by Bert Sutherland, who was a park guy. And actually Bert Sutherland and a variety of other people, Jim Mitchell and,

oh man, the names go on and on. All park people landed, Jeff Rolofson landed at Sun Labs. And that really shaped the way that Sun Labs did things. So when I came to park, the transition was really easy. It was just like I went to a different building, practically speaking, with a different set of people. But there is a certain parkway, I realize now, that is useful for folks to pick up. And to be fair, the parkway has been changing, mostly because we have to modernize over time, right? Originally being part of Xerox and having funding come from the mothership, and then spinning off into a separate company and trying to find our own funding, we've had to adapt quite a bit.

But as such, now as an independent company, we're very flexible in how we deal with things. And that makes us relatively nimble in adapting, which doesn't mean that it's not challenging. It's still challenging to have a research institute, right? We don't produce any products. So there's not a lot that we can just sell. We can create new stuff. We can build new technologies. We can advise, we can consult. We can do mercenary for hire work in these deep industries. And most of the time, our greatest value

comes from doing these kind of interdisciplinary works, whether it's science and engineering, or just looking at the interaction of material science and systems, or all these things where, because of our breadth, we can normally look for good integrated solutions. And that's normally where we shine, where Park shines. Well, I think that's a pretty good place to leave it, and we're about out of time. Glenn, do you have any last thoughts you'd like to leave us with?

Well, a whole bunch of stuff. I think that people should spend some time thinking about CCN. I think we have a lot of information available on our ccnx.org website. More information comes, of course, as we do more stuff.

I don't want to make any announcements of timing or anything like that, but we do our planning on certain releases coming up for software, which I'm very eager to get to.

So that's something folks should also look out for. And we appreciate the feedback, especially for building embedded systems. Right now, CCN, there's a project called Riot OS. It's an OS for embedded systems that has a version of CCN called CCN Lite. And it's not compatible with our current standard,

mostly because we haven't released our current standard to be able to do interop testing, but it's a good place to start if you're trying to look for embedded type of stuff. Obviously, if you have any interesting projects that might match, you always feel free to send us an email. I'm also, for myself, I'm also interested a lot in the experience of the embedded developer,

what kinds of things they run into. I see a lot of C code. A lot of C code gets embedded. I see a lot of really bad C code. So I'm curious about how folks manage that and what can be done there. I have some ideas, too, which I'm applying in our CCN work, but that's not all embedded. I think there's things that can be done for the embedded folks as well. So I'm interested in that.

People can contact me directly if they want to. How do they contact you? I am glen2n. Are you going to give your email address? Well, how else would they connect? There is a contact link on ccnx.org, and I'm pretty sure that will find the two of you. I will.

So let's go with that. You can contact me through the ccnx.org and I'm pretty sure that will find the two of you. I will. So let's go with that. You can contact me through the ccnx.org website. All right. Even though I'm not a very active Twitter user, you can contact me at isos. Yeah, your Twitter handle will be part of the links. Glenn doesn't have one. I do, but I don't care. It's not

for our consumption. Nacho, what about you? Any last thoughts you'd like to leave us with? No, not at all. It was great to be here. Thanks for having us over. Well, thank you both for chatting with me. My guests have been Glenn Scott and Nacho Solis,

research scientists at PARC. If you have questions or comments for them, check out the www.ccnx.org webpage, where you can find that contact link, which, once you submit, it'll find them, I'm sure. And as you might have noticed, I am hosting solo today. I'm also doing the recording, so any sound issues are my fault. Or mine. Or mine. Or mine. Really, we should check with my

co-host producer before scheduling guests. Nonetheless, I'm certain Christopher will do his best to improve the tracks I give him. If it's good, thank him. If it isn't, blame me, which sort of covers a lot. Finally, thank you for listening. If you have questions or comments, hit that contact link on embedded.fm, which sort of covers a lot. Finally, thank you for listening. If you have questions

or comments, hit that contact link on embedded.fm, which will find us. Final thought for this week comes from Niels Bohr, which I think, he didn't say this about CCNX, but it sure sounds right. And that is, your theory is crazy, but it's not crazy enough to be true.