 Hey everyone, welcome to today's Protocol Labs Research Seminar. Today we are joined by Boston University Master Lecturer, John Day. John has been involved in research and development of computer networks since 1970, when his group at the University of Illinois was the 12th node on the ARPANET. He has developed and designed protocols for everything from the data link layer to the application layer. And today he will be presenting part two of his talks with us, this one titled, Back to the Future, Welcome to the Renaissance. He will discuss the past and bright future of the recursive internet work architecture. The YouTube link of part one of this talk is linked in the description, in the chat, sorry. And if you're watching live, I will share it in the chat for you to watch afterward. We're excited to welcome John as part of our series on revolutionary internet architectures in conjunction with our open request for proposals, RFP 11, changing the internet. So thank you so much, John, for taking the time to join us again. And I'll let you take it from here. So I'm going to talk about how, you know, how Rina came about and or actually our quest for principles. And first of all, I have to say, back in the we were very lucky at Illinois in that we were building the world's first supercomputer, which was totally uninteresting. But we had probably the finest example of computer design to use to do our work. And that was a Burroughs 5500, something probably none of you have ever heard of. But I can talk about more about it later. But believe me, it was one of those systems that had no special cases and no clutches. Everything just worked. And for us, it was a life changing experience because it told us that those kinds of solutions were out there. At the same time, we were very fortunate that there was a professor on campus who claimed to be Wittgenstein's nephew and was one of the four founders of cybernetics. And he put us through the ringer and learning how to think. And we actually use that in the how we developed operating systems back in the early 70s. So let me get started here and see where this is going. I've got my my usual favorite quote here that a good architect is, you know, suffers from a topologist's vision defect, that old joke. You know, it can't tell a coffee cup from a donut. Now, as far as the origins of Rina Go, let me say right off the bat, I embarked on this not to fix anything. My goal was not to fix anything. My goal was to figure out what I knew about networking. Over the years, I had seen a number of patterns go by that looked promising, but hadn't had a chance to follow them. And, you know, there were four topics that I really felt like I needed to care, you know, to look at the separation of mechanism policy, which we'll talk a bit more about in a minute, the resolution of the the connection connectionless debate, the virtual circuit versus datagram debate, which has really torn things apart. Work through the implications of a comprehensive addressing architecture. I thought I knew what it ought to be, but we hadn't really worked through the implications. And, you know, often you get the argument that, well, you know, if we simplify here, it'll only get more complicated somewhere else. And because of the fifty five hundred, I didn't believe that. Also, I wanted to really make use of Dick Watson's result that I talked about last time, that the necessary and sufficient conditions for synchronization are put an upper bound on three times. Actually, exploring these and how we got that, how I got there is a bit interesting, but it really all came back to the beginning. It's funny how after twenty thirty years of doing this, you sort of get away from what you were thinking at the beginning. But in the early days of the ARPANET, we all believe that networking was inter-process communication. And, you know, Dave Walden wrote an RFC on it. Mike Bedlipsky wrote, said it was axiomatic in RFC 871. Bob Metcalf, you know, article on how to write an NCP, just mentioned it in passing that, well, you know, just like we all know that. And, you know, basically what we come up with is the layers of distributed application that does IPC. Rita is what you get when you try and build from these principles. Now, over time, we had come to rely on three principles, you know, separation of mechanism policy, you know, saying I, you know, suffered from this policies, vision defect were all things I was using to try and get at that. But then I had, I was browsing a bookstore, one of my favorite things to do. And I came across that the logicians had defined abstraction as invariance. And it was one of those head-slap moments, you know, like, well, of course it is. Why hadn't I thought about that? And so our rule became maximizing invariance and simplifying or minimizing the discontinuities, maximizing invariance, maximizes simplicity, minimizing the discontinuities. In other words, we prefer generate cases to special cases. Essentially says we're saying within the invariances. Construct the, and then we construct the model to not break the invariances. And when we do that, quite interestingly, we don't find devils in the details. We find angels. We pick up a topic we haven't looked at before and we find out the model already tells us how to do it. So that was a real, real interesting. The other one was do what the problem says. It's smarter than we are. And the thing is, even if you, you know, even if you sort of charge ahead and don't, sooner or later, the problem is going to get its retribution. And the longer you wait, the longer, the more it's going to cost you. You know, and the other thing we found is that good enough is only good enough in the short term. Sooner or later, it's no longer good enough. And the cost of repairing it becomes really great. Also, the more good enough to throw in the friction they create goes up exponentially. It doesn't go up linear. And the third one is always try to prove what you're doing to be wrong. We can't prove it right. Therefore, we have to continue to try and make sure we've heard what the problem said, you know, to begin with. You know, it speaks softly and we need to care. Figure that out. So the beginnings were separating maximum policy. I'd always found it odd that every operating system textbook talks about this. But it's never mentioned in networking textbooks. And it seems like it was pretty obvious that it should be because, you know, if you guys look at protocols, it's probably as much or more than I do. And, you know, we have all of these mechanisms. But and the only thing that really changes is the policies. Now, what do I mean? OK, well, you know, in operating systems, the machinery for memory management is always the same. The policy is what do we roll out to disk and what do we keep in main memory? OK, and what do we throw away? In networking, the example I always use is, you know, the machinery to do acknowledgments is always the same. The question is, when do you do it? Now, to give you an example, we always thought we'd do another version of of transport for voice because you care about order, but you don't care about gaps. You know, a small gap, nobody's going to hear it. So what? And then one day I realized, no. We don't need a new protocol. We just change the policy. We lie. There's nothing in these protocols that says you have to tell the truth. So if you have a bunch of data, there's a small gap you don't care about, act it anyway, who's going to know the difference? You know, but that told me I'd had the semantics of ACK wrong all this time. ACK doesn't mean I got it. ACK means I'm not going to ask you to retransmit it. It's small, but it's significant. So that looked like it would be a powerful thing to do. It turned out it was. It was clear from this outset that layers were going to be that occurred naturally in networks, even though, you know, and everyone pretty much agrees that, you know, Dijkstra came up with the idea of layering and operating system in 1968. And of course, we started the net in 1969 and that that paper had really captured our our imaginations. And so using layers had become, you know, we're quite natural to the problem because we were doing OS stuff there. But also just because the problem actually calls for layers. Experience showed that mechanisms kept reappearing. Dijkstra said that they shouldn't, but they kept doing it. So that kind of caught us by surprise. We could see that there was a repeating structure. But what held us together and, you know, was not exactly clear. And from Ciclod's, we knew the scope was probably the most important property of layers, which I've talked through. You know, I've talked about last time. Then I got a breakthrough out of left field when I, another professor asked me a question about port IDs. And I really didn't like the answer I'd given them. And so it rolled around my head and I'm going to very quickly go through what I came up with. I can do a whole hour's lecture on this and I do it for my class. I decided that it was time to go back. That networking was IPC. So I went back and I started with two applications in a single computer communicating via IPC. And I figured I laid out how it should work. And, you know, in some detail. And then I went from there to let's have two two applications in two different computers, what went away, what I have to come back. And what you find is, well, you need a protocol to find the other application, but then you need another protocol, an error flow control protocol that makes sure the first stuff gets there intact. And so you talk about how that should go about. Now, and it turns out that that, you know, some machine that goes on underneath, but you really don't change much of anything. And then I went to, let's have more than two applications in two computers, you know, now what do we have to do? Well, it's pretty clear that we have to be able to distinguish messages that are important for or on one flow to one application are distinguished from the other. And so what we really need is a connection I need to make that happen. And there was some discussion about how to do that. And then over some time, you know, people said, well, wait a minute, we've got these poor IDs, which are acting like file descriptors. Why don't we just use those and we'll concatenate them to make the connection ID? And that's pretty much what we do. But we have another problem. We have this makes us have multiple users of a single resource. My gosh, that's the definition of an operating system. And so we're going to need basically to have an application that manages the use of the wire. This guy. So we got that. Let me tell you in this section, we talk about how that works. And then we go to in systems directly connected. Well, you know, this is, you know, actually, in some sense, this is no big deal. We just did one of those. So let's do one for each wire. OK, so we do that. But now we have another problem. You know, the application really shouldn't have to know which you know, figure out which wire the application he wants to talk to is that, you know, so we need to have positive some kind of finder. So when you you requested application, you know, a destination application, he figures out which wire it's on and then reports back and says, you can have it. We know that's just not going to scale. I mean, this directly connected stuff is just going to blow up like that. So, you know, machines were getting pretty cheap. So let's let's pause and we've got some machines that are only needed for relaying. You know, so what are those look like? Well, you know, we're going to have to have one of our things we've already created for each wire and then a little application that does relaying. And that's going to require some new things in our scheme of things. And we'll talk about all of that. You know, that's also going to require that we put, you know, relays cause trouble to because you can't avoid transient congestion from time to time or rare memory errors while you're relaying. And so you're going to need an error and flow control protocol to go across the whole thing. And of course, you had in the last step, you had to add addresses to everything so you knew where the packet was going because, you know, before it was just a point to point wire. I mean, if it went in one end, the only place you could come out was the other, but here that's not the case. So we had to actually add addresses. But it's interesting that we only have to add addresses when the layer has more than, you know, two ends. Now, if we step back and look at what we've constructed, it looks like this. And you're going to say, well, Dave, you know, you just wasted 15 minutes because that's the same old model we already had. Well, no, it isn't. What I just described was that there aren't five or seven layers. There's one kind of layer and it repeats. This is a distributed computing model. OK, that's what pulled everything together. And this is the core of Rena, everything derives from that. There are five or seven layers. There's one kind of layer that repeats over different ranges of capacity, quality of service and scope. With different policies, a layer is a distributed application that does IPC. Virtual circuit and datagram is a function of the layer, not a service. Which one you use is determined by the density of traffic. The denser the traffic, the more connection like the less dense, the more connection less. One thing in that whole debate that kind of got things from Australia was that the feedback mechanisms in error and flow control protocols like TCP, the flow control and retransmission control were categorized as connection oriented and they really aren't part of the same problem at all. And then we had the separation of mechanism of policy, which we applied to these protocols. And that actually was very interesting because what you find about those mechanisms is they fall into two categories, those that have to be with the data and those that don't have to be. They can be, but they don't have to be. OK, and the two pieces are virtually separate. They really don't talk to each other. Now, the other thing we had, I have this implication of ASM-1, you may be wondering what the heck that's all about. Everybody thinks ASM-1 is a encoding scheme. It's much more. ASM-1 divides stuff up between an abstract syntax and encoding rules. It essentially makes a protocol invariant with respect to syntax. The procedures remain the same. But the syntax that's sent over the wire changes. And so when you apply all of that, what you end up with is that there's really only one data transfer protocol with different policies and encodings. The other thing that's interesting here is the data transfer protocols modify state in turn over the protocol. Application protocols modify state external for the protocol, and they just differ by having different object models. You know, this is a huge complexity collapse. And what this yields, first of all, our layers all have different scope. And we talked about that last time. And it's recognizing this scope and using it that makes the traditional ITU model or Bayesian string model untenable. You really can't talk about things like control and data planes if you're really working about scope. And of course, we also have Watson's Theorem, which I mentioned before, which we're going to apply here. And Watson's Theorem actually has some really major implications. First of all, it makes the protocol a lot more robust. There's better quality of service support. We can change quality of service during a flow by merely replacing the connection because port allocation and synchronization are distinct. We can have different quality of service for the different directions. There's no problem. It's also better security. The attacks on TCP connection establishment don't work on a protocol built to Watson's specifications. But Watson implies even more fundamental result. It defines the bounds of networking. It's networking if maximum packet lifetime can be bounded. If it can't, it's just a file transfer. This leads to a very natural structure within the IPC process and layer. And notice, again, this naturally falls out into just exactly what you'd expect or what you would want, that we have data transfer, which is our IPC transfer, which is very fast cycle time and very simple computationally decoupled through a state vector with the feedback mechanisms, retransmission and flow control decoupled through another quote, state vector or management information base from resource allocation and routing. This is exactly the kind of structure you want to see. I'll even reiterate here on the data transfer stuff. This stuff here, the data IPC transfer updates the state vector. The data transfer of the IPC control reads the state vector and generates AC and flow control. These two barely interact. And the only time this side does anything to the other side is when it says, oh, the windows closed, we have to turn on, tell you you can't send anymore. That's it. This, I've said, is a big complexity collapse. Consider, you know, we've got this structure where we just talked about, and these are the mechanisms and then plugging into those mechanisms are policies. OK, now we've found this structure repeats in the layers. But what is the way to implement this? Well, you might think that just doing something like this would be the obvious thing to do. And yeah, you could do this. This is what, you know, P4 tries to do, although it doesn't do it very well. But this does have, I mean, it has some advantages, but we can do so much better. Consider the following. Remember your automata theory? You're kidding. I mean, you think I'm kidding, right? Nope, really. Now, remember, a Turing machine is like a program. It executes one algorithm. A universal Turing machine reads a description of a Turing machine and its data and does that. Now, suppose the mechanisms are looked at as a universal Turing machine. The policies define a Turing machine. And of course, the PDU, the passage coming in is the tape. You point a policies at layer one, process the layer one header, move the tape down, point the policies for layer two, process the PCI header for layer two, and so on. No context switches, no data copies. This makes much more efficient, much simpler implementation, a huge complexity collapse. You can put the universal Turing machine in silicon. And these are code and data. Actually, we did an operating system like this in the late 70s. We know this works and also remark about one other thing here. Almost all of these results, and I can point to other places, too, the insights have come from the theory, not from the implementation. This leaves that in this kind of a system, we only need three kinds of boxes. We don't need no stinking metal boxes. A layer turns out to be a secure container, which we'll talk about in a minute. And of course, we can repeat this structure to any depth. Now, what this means is that what we're doing here, and you'll see people trying to do this in IP now, but they don't have the structure to do it, is that you're going to come across here and you're going to find out that the next hop in this routing layer here is over here. But the port you want to use to get there brings you down here and you get routed across here. OK, from above, this looks like this, that there's a hole in the metal. But that's not what's, you know, but that's just, you know, it's going down a layer. The basics are, you know, separating mechanism poly creates a huge complexity collapse. The user of a layer only knows the destination name and its local port ID. Addresses are never visible outside the layer. Addresses belong to layers, not protocols. And also, one thing I sort of left out in this is the members of the layer, I call them IPC processes, to distinguish them from user processes, you know, are really just applications. They're just processes. So they have a process name like any other. That means that addresses are synonyms. Whose scope is limited to the layer and may be structured to facilitate its use in the layer. Because mobility is just multi-homing, where points of attachment change more frequently. Mobility requires nothing new. It just works. Well, multi-homing comes up for free here because we have a full addressing architecture. There are no home or foreign agents, no tunnels, no anchors, no new protocols are required for mobility. Use layers of different scope to ensure updates are made in time. And I'll show you how that works in a minute. Because addresses are synonyms, a network can just, we'll talk about that in a minute here. Now, all communications goes through three phases. Enrollment, allocation, data transfer. You know, this is this goes back decades, even before. I well, actually, I heard it, you know, even before we started the OSI work. Enrollment has been in the past one that we tend to ignore. Or actually, it was all manual, but it's becoming more and more automated. And basically, I've got some abstract definitions here. But basically, enrollment is how you join a layer. So how does that work? Well, suppose we have this new IPC process and you want to join this layer. How does it work? Well, as I'll keep saying, do what the model says. It's a process. It wants to join a distributed process. It needs to establish communication with a member of the layer, which he does. And then once they have established, they've got a communication via a lower layer, then they set up a connection between themselves, authenticate each other. That's the first thing any application should do with talking to any other application is authenticate each other to make sure that they are who they say they are. And if everything goes well, he's assigned an address and he's a member of the layer. That's all there is to it. And we have a couple of different enrollment procedures, so a simple one and a more involved one for things that bounce a lot. So how are connections set up? Well, it's sort of like it's done today. Application A wants to establish communication with application B, you know, using a supporting diff. So we do what the model says. You know, we do it allocate, which create, you know, which generates a create flow request. We determine that the application B isn't here. So we look at our forwarding table and we send it over to the next to where it points. Who sends it over to there, who initially says, well, look there, OK, and in this scheme, rather than just report back the way TCP does, we go there, confirm that it's there, and then we report back. This allows us to do access control at that point. We can decouple, you know, decouples for allocation, synchronization, the application never sees the address. If B had moved, it simply keeps looking using the forwarding tables to figure out using a search rules. Port IDs are not carried in protocol. A's port ID is not known to B or B's is not known to A. Access control falls out naturally, as it did from the IPC model. And it sets a structure to avoid a whole separate scheme for IP, something like IPsec. Can I jump in and ask a question? Sure. Great. I want to refer back to something you said a few minutes ago, because it's been on my mind. You said all the insights at that point have come from theory and not from implementation. Are there any are there any implementation details that popped out? Did you learn anything from implementing this or any doubles? Are there any? Actually, no, there have been no surprises of the implementation. Instead of finding devils in the details, we've found angels. And I think the reason is, is because we've constructed the model to not break the invariances. I already went over mobility. What's the big deal? It works just like boldly homing, only the M minus one port IDs come and go a little more frequently. That's all there is to it. I've got some other extra slides I can look at if we have time. Again, no special cases as I was saying before. But then we have the problem of, well, if you move and your point of attachment changes, we may have to tell a whole bunch of people. And that's going to take time. Well, we can take care of that, but there's another problem. If the host moves and his address no longer aggregates, is no location dependent with respect to where he is, we ought to be able, we ought to change of address. Now you can't do this with IP because of the way things work. But this actually turns out to be quite simple. First of all, how do we do this? Well, we assign a new synonym to the IPC process. Using the flow allocator, we notify all EFC flows that originate here of the change in source address, which we can do securely, tells the destinations of a new address. We stop advertising the old address as a route to this IPC process. We start advertising the new address via our router updates. And it just works. Slowly the old address dies out while other people are being notified via the router updates and everything just works. You want to renumber a network? Same procedure. We can renumber networks in seconds. We've done it. They had a demo like that running for over five or six years. There's a problem with the fact that things take time to update. And this is where the repeating layers can come in to save you. Basically what you can do, and I've got an extended example if we have time. Basically you can make the layers wide enough that the time to cross a layer is much greater than the time to update the layer about the existence of a new member. And so basically addresses may change frequently down here, but less frequently here and even less frequently here and may even just stay constant across the top. So this allows the whole thing to scale. And in fact the number of layers doesn't have to be constant. If I'm in an area where there's not much, I have very large areas at the bottom, very large cells. I can have fewer layers. If I'm in the middle of a city and I've got a high density of traffic and I need more layers, I have more layers. And notice that, you know, any box here only handles the same number of layers. There was an unexpected implication here. In the derivation of the IPC model, and this is another one of the things about the advantage of the theory I said. In the derivation of the IPC model, remember when we had in systems directly connected and I had to posit that finder so the application wouldn't have to figure out which type of network it was on. Well, it turns out, and it only took me two or three years to realize that it's actually maybe even longer, that the application, you know, should not see all the wires so a finder function was necessary. And we had this sort of thing. Well, if that works for wires, why wouldn't it work for networks? Right? If this is a network instead of a wire, there's one of these little guys at the end of all my layers, and we've subset it to be the ones that involve management because doing this is going to be required management. They are going to be able to see different layers that I see. Maybe they can find the application I'm looking for if it's not on any of my layers. And if that's the case, I ask around to see whether it is and if we find it and I don't have a layer in common, then we just create a layer over the top so they can talk. This has major implications. There's no global address space required. This is, you know, this is the network generator function and it caps the recursion. This was a completely, this was a completely complicated result. We had no idea it was going to be in there. So a global address space is unnecessary, but all applications could still be reached. Routing on the node reduces router table size by a factor of at least four or five. Router table size could be bounded by sizing the layer accordingly and having the number of layers you want. Flow allocation verifies the existence of the application and the other thing here, because the addresses are never seen outside the layer, all networks are private. Public networks are just more open private networks. Okay. This can have major effects. Most must be a member of a network to allocate a flow without management aware. And a layer is a secureable container. No firewalls are necessary. All members of a layer are authenticated within policy. None of the attacks on connection establishment work. No overloading of IDs. And it scales. I mean, to look at the security. Again, I put off doing looking at security for a long time. And if you remember when I flashed through the IPC model, I never mentioned security. And when I got to do thinking about it, I said, okay, well, what do we know? Well, first off, we know what I just said that the only thing that the user, the user of the layer knows is the destination application name. And his port ID is local port ID is a local ID. Okay. The layer ensures the source has access to the desk destination. That's part of it comes out of the IPC model. Once they're in communication, the applications must ensure that they are who they purport to be. So they authenticate each other. The members of the layer are all authenticated when they join. If you don't trust the layer below, which you shouldn't. SDU protection can protect from eavesdropping and integrity, et cetera. Basically. The only thing that a layer and Rita trust the layer below is to deliver something to someone. That's all. We don't care about anything else. It's protected. So the layer itself is a secure container. We did a little of our grad students for a master's thesis did a comparison of this, of this approach with the current internet approach and got to secure add security to the internet requires the left hand column in the AC model. You have the right hand column. Basically, you're just adding mechanisms for the, for the various, you know, for integrity, confidentiality, you know, et cetera, authentication. So how does it work? Well, basically the internet, I've left out a slide here that I would do the internet separately, but you know, the internet is simply an election. You know, it's an electronic model, a layer that runs over the top of ISPs, you know, and, you know, and they overlap. These are the layers of the ISP I'm trying to draw here. And if you really think about it, this is what we do today, except we try and do it in one address space. You know, there can be, you know, of course, if we can have one layer laying across the top, we can have a bunch of them. Okay. And then there was something that came about that I first thought of is just sort of, well, isn't this kind of cute? And I said, suppose the following. Suppose I have an ISP and he provides an electronic model for all of his users and they connect to it. And then he goes out to the half dozen, dozen, whatever it is, CDNs and data centers and forms contracts to provide their websites in his electronic mall. Okay. And that covers no 80, 85% of all the places that his customers want to go. If his customers want to go some, one of the 20 or 15%, then he simply creates one of these special layers across the top that I was describing earlier and they can talk to each other. Among other things, notice the implications for security. An attack has to come from either the customer's network, the ISP, one of the CDNs or data centers, or the special layer that I created. It can't come from anywhere else. And I have contractual relations with all of those things. I can nail track down and nail the guy who's doing it. Even if say my user gets infected somewhere else, unless the controller he's trying to communicate to is a member of one of these, these, he can't even report home. This has some really interesting implications. I call this the Wallace Garden, just to torque the net neutrality people. Also, one other thing about this, which is a slide I've left out, notice that it's up to you and your home network to join an electronic mall or an outside layer. And not only that, but you have a choice of joining. When you want to join, you can have your home network join, you can have your laptop join, or you can have your browser join. It's up to you. Okay. Now we've got talked about a little bit about congestion last time. As I said last time, the effectors of any congestion management strategy will deteriorate with increasing time to notify. So we use only congestion avoidance with ECON, limits the effects to a single layer, and can coordinate with quality of service policies. Right now we can't do that. Guarantee quality of service source to destination, implications of application layer naming, a flow can be allocated to a specific instance of destination application. Two applications using different protocols can allocate flows to the same instance of a destination application. We can't do that now. Actually, the whole reason that we have SIP is because we can't do this first one. We have known since the 80s that the most important property for effective management was commonality, commonality, commonality. So we can't do that. And not only does Rita do that, but it enables much more complex changes because we can choose the policies to be supporting rather than designing protocols that were sort of independently. And this meets or exceeds all the requirements for a future internet efforts. But it also begs the question. And it came up relatively soon after we started this. If a layer is a distributed application that does IPC, what's a distributed application? A layer is a specialization of a distributed application facility. We needed this for management as well, but we went back and did this. And so in analyzing the nature of layers, we realized that operating systems were recursive as well. When I said that layers repeated in networks, it appeared I was contradicting Dijkstra because he said that once you do a function in a layer, you don't have to repeat it. Well, actually we aren't contradicting Dijkstra. What we're saying is that once you do a function in a layer of a given scope, the function doesn't repeat in that scope. And I contend that in the given how tiny machines were in 1968, we just couldn't see the scope in operating systems. Virtualization is not actually recursion. Recursion is a little cleaner than virtualization. A process consists of the tasks, threads, the functions to manage its resources, scheduling to storage IPC. And a task is also a process. The lowest level process is usually called the kernel, the next level is the supervisor. And then the next thread management and heap management are just the OS for the process. And then you have the task to actually do the function. So basically what we're saying is that a process has a recursive structure consisting of task scheduling, memory management, inter-process communication to manage its tasks, which are then in turn processes. And so this whole thing can recurse as much as possible. And of course, an operating system, I have a whole another presentation I do called RIPVAN OS, where I came back to OSs after 30 years and everything had changed, but the implementations were still the same. And basically in my day, a device driver was bolted on the side of the machine and you were manipulating electronics. Today, that's not the case. Every peripheral has its own processor and is connected to the machine via a standard IPC mechanism. Okay. OSs seem to be moving in that direction, making, they're doing it at a glacial speed. As, you know, if you do this, then it's, you know, a minor step to go to this. And so what we end up with is that the RETA model is not just a layer for distributed, a layer is a distributed application that does IPC. In fact, the reference model is written that we describe a distributed application facility first. And then we describe a layer in a network as a specialization. That forces us to answer what is a distributed application. We're now working on a unified model for application processes, distributed applications, operating systems and networks. It's all one model. Transition? I don't believe in transition. I believe in adoption. You know, don't worry about transition. Transition will solve itself. We can operate RENA over, under, alongside, you know, the current internet. The old stuff is okay and the internet just leave it there. I mean, who cares? If you need security, much lower costs, advanced application capabilities, far less expensive mobility, use RENA. Operate RENA over, under, through, and probably start with, you know, private networks.