 Hi everybody. 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 and has also developed and designed protocols from everything from the data link layer to the application layer. Today he will be presenting, how the hell do you lose a layer? So thank you so much for taking the time to join us today, John, and I'm going to let you take it from here. This talk originated some years ago during my crest to figure out how we got where we are. We really need to know how we got here in order to know where we need to go next. And so I'm going to try and stay away from as much of the history as possible, but there are a lot of myths out there and I will need to sort of dispel a few of them and sort of get the, you know, and there are some interesting early results that you probably aren't aware of. So, you know, let's start and figure out where this, how this whole internet work stuff started. As we just said, as you probably all know, you know, things started with the ARPANET and the ARPANET was the first packet switching network to be built. You all know that probably. And the whole idea was to do resource sharing. ARPANET figured that they could lower the cost of research if people, they didn't have to buy big computers for every site that everybody they were funding. And so, you know, and there was also stress, the idea that it was a heterogeneous network. And so, you know, in 1970, 71, there were 12 to, in those first few years, I should say, it was all planned. There were probably 12, over 12 different operating systems and machine architectures on the net. There were also places that were supposed to be compute centers, as well as places that were supposed to be database storage. But, you know, the ARPANET was really the first one. As you probably know, BBN was building the subnet. And it, what they came up with was actually very good for a first attempt. Necessarily, it was somewhere between a traditional Datacom network and a new packet switch network. But there were no layer diagrams at this point. In fact, I even checked with the guy who was in charge of developing the switches and they didn't do that. Now, layers, as you may well aware, came about in 1968 when Dykstra published his paper on the THE operating system. And it really captured everyone's imagination. I mean, people really sort of, you know, glommed onto this really all at once. Because in those days, elegance and the power of a solution mattered much more than it does today. And this really seemed to have, was an elegant solution, as most of Dykstra's were. Now, this, as they said, were not really necessary for the subnet because of how simple it was and what they were doing. Not all that simple, but it was, you know, no really. But the first thing, you know, that was necessary was, you know, when they brought the hosts on board, that changed considerably. And of course, since interfacing hosts to the network was something new. I mean, none of these computers had ever been developed to talk to a network. And there was a real question about how to do this. So the first thing we had to do was a device driver. And, you know, that was the host protocol. And just recently, Steve Veracher noted that one of the first things that he started thinking about when we were getting into this was, what were people doing with inter-process communication? What could they tell us about that? Because it was clear that that was the problem we had here. And they were going to build a resource sharing network. And then on top of that IPC facility, we would have terminal drivers and file transfer and all the usual things that an operating system would have. And that was all going along quite well. And very quickly, we all began to live on the net. It was amazing how fast that happened. But, you know, very quickly, there were new ideas coming from Europe. And there was some really interesting stuff going on. Soon after the ARPANET was operational, Louis Pouzan visits the US. Now, Louis had been on project MAC working on moldings where he had invented the shell. And Louis came over and determined that he was going to build a network in France. But while the ARPANET was a production network to do research on networks, Louis wanted to build, I'm sorry, it was a production network to do research on for the ARPA projects, not to do research on networks. Louis was going to build a network to do research on network. They called the project CICLOD and the switches were called CIGAL, which is of course Grasshopper in French. Their starting point in late 1971 was the first task was to determine what were the minimal assumptions that one had to make to have a basic network. Figure out what those were and then determine what else was needed to really support everything that was going on. Okay. By mid-1972, CICLOD came together and they had come up with some really new ideas. What was the minimal packet? Why assume it had to be sent on a fixed path, route packets independently? And they called this a datagram. Today we call this connectionless. They also reasoned that the host would never trust the network to be reliable. So why go to the extra work to try and make the network perfect, which was really counter to what the phone companies were doing. The host would require an end-to-end protocol to guarantee reliability and with no need for the network to be perfect, it would be cheaper, more resilient, and if it only had to make a best effort. They stepped back to look at the minimal requirements and found that for a data network, other than exploring congestion and routing, for now nothing else was needed. I mean, this was a huge revelation because what they had come up with was far simpler than what everyone else was doing. And it was truly radical because it was a non-deterministic, decentralized, reliable transmission with unreliable components. And this was truly a new paradigm and that constituted a problem. And I don't use that word lightly. This was a shift to non-determinism and to dynamic resource allocation away from what the phone companies were doing. And so just to review, the layers developed by Sue Claude were as follows. So of course, there was the physical layer and the wires, the data link layer corrupted packets and made it may do flow control. The network layer did relaying and multiplexing of datagrams with primary loss due to the congestion and rare memory errors during relaying. And then the end-to-end transport layer provided recovery and loss due, you know, those errors and loss due to congestion. And of course, that implied that the loss rate at the link layer didn't have to be perfect, but the loss rate had to be much less than the loss rate seen at the network layer. So the transport layer would be effective. And this was pretty much their design. Now, in 1972, with all that coming together, Sue Claude started a major program in collaboration with the University of Waterloo to do analysis of and simulation of routing and congestion management. It would, of course, be 14 years before the DARPA and the internet even realized that this was such an issue. Then they, you know, and then of course, they botched it pretty badly. We'll talk about that much later. Layers in the network here are not a decomposition of functions within a single system, but are distributed shared state across systems. And this was one of the things that Sue Claude really figured out. And it's something that's not that well known, that a layer is, you know, the most important property of a layer is its scope. Okay. Layer is a distributed resource allocator. Different layers have different scope. And that's what this is illustrated in this picture here. This is also why the concept of controlling data planes become untenable while it is a stack in the host. The other end of these layers are not in the same system. They aren't all in the same plane. The internet missed this, the importance of scope entirely. And it took us a long time to realize that they had, because for a lot of us, this was just natural. We saw this and just never barred up. We assumed everybody got it. But it was only later that we managed to realize they didn't. This new model had four characteristics. This was not an innocuous change, but a shift of axioms. It was a peer network of communicating equals, not a hierarchical network connecting a mainframe with terminal slaves. The approach required, as I just said, the coordination of distributed shared state and different scopes, which were treated as black boxes. There was a shift from largely deterministic to non-deterministic approaches, to some extent from Newton to Heisenberg, not just with datagrams and networks. But this is also the time when operating systems were making the shift from pole to interrupt driven. And there were also some physical layer things, like the development of Ethernet within about two years of all this, that was also non-deterministic. Those ideas were just in the air. This was a computing model, distributed computing model, not a telecom or datacom model. And that was really important. The network was an infrastructure of a computing facility. Now, 1972 was an interesting year. First of all, Tinker Air Force Base joined the net, exposing the multi-humming problem, at least for the Americans. In the ARPANET, your host address was your import number. Okay, it was the interface to the amp. And so consequently, in fact, I always tell the story, Tinker joined the map, my boss came in one day and said, they're joining the net, they want to take us at our word, they have two connections to the network. And I said, oh yeah, great, that's not going to work. Because to the network, that looks like two different hosts. But of course, a half second after I said that, I said, oh well, this is obvious. We've seen this problem before in operating systems. We need to route to the node, not to the interface. I thought that was obvious. And everyone saw it. It turns out that it wasn't so obvious. The ARPANET had its coming out party in 1972 at ICCC. They put an amp at the conference and did all sorts of demonstrations. The first meeting of NWIG occurred at ICCC 72, where CECLOD was introduced. And everyone had a great deal of interest in it. Everyone just was bowled over by CECLOD when they saw it. And the ARPANET MPL and others were involved in NWIG and it was finally chartered as an IFIP working group. It was clear that the key project would be to develop an internet transport protocol, which was going to be key to this new approach to doing things. They also did a virtual terminal protocol, which was a big deal then and also some more comfortable description techniques. And I can tell you more about what happened at ICCC later. Now, however, this small group, and it's probably hard for you to imagine, but I would even risk to say, I know it was much less than 100 people involved in all of this, and they were new to power politics. And what we were proposing was something like the CECLOD model was very radically different from what was out there, and also very different from where some people had a large, shall we say, vested interest. And a nasty brawl was shaping up with the phone companies against the computer companies and everybody against IBM. Remember, in these days, IBM had 80% of the computer market. Now, but they had their problems. Somebody once told me that IBM got to where they are because they sold to the guy who signed the check. That's very smart. But think about it. In 1970, 71, how much computer science, do you think somebody who could sign a check for millions of dollars when a million dollars actually was worth something, knew about computer science? Not much at all. And when I was told that, I said, you know, this means that as the field matures and people move up the ladder, it's going to be harder and harder for IBM to make a sale because they never had the best technical solutions. Of course, the dropping cost of computers just accelerated that. Of course, when I said that, they all said, hey, you're crazy. They'll never lose their place. Of course, by the mid-80s, they're laying off tens of thousands of people. But they also had a problem in networking because they had built SNA, System Network Architecture, which was, as everything with IBM, centered on the mainframe. Now, of course, the first rule architecture is you can always take a mesh network and subset it to be hierarchical, but you can't go the other way. And IBM knew it. They knew this whole new approach to doing networking was counter to what they had. Now, they were in a position because of antitrust that they couldn't really oppose it. The must they could do was try and slow it down, and which they were pretty effective at. The phone companies, on the other hand, used their architecture to determine who could define the boundary between them and the subscribers and who got to sell what. And there's another slide I could use that shows that, but two groups could have completely different views of the same equipment. But this was a might, but the cloud proposed a much bigger problem for them. First of all, for the French PTT, the cloud was a disaster. And of course, they had the PTTs had this dream that they were going to put services in the network. This became a code word. The many tell us, if you know about that as a good example of this, but they wanted to put essentially what Google and Amazon and stuff do today. They wanted to put it in the network so it would be part of their monopoly. They've never really given up on that. They keep trying to do it. Of course, having a transport layer sealed off the network to just moving the bits. They didn't like that at all. They kept trying to argue that there was no need for a transport protocol because their stuff was reliable. This was a big fight all through the late 70s and early 80s. And it was not helped by the fact that Puzan was rolling around advocating against the PTTs. I've talked to the guy who was Puzan's boss at area, and he was getting a phone call a week saying shut these guys down and we're going to cut your funding. It was getting pretty brutal. Now, you might think that, well, this isn't that much difference, but think again. In the bees, these were two entirely different models. In what I call the beads on a string model or the ITU model, boxes and wires are dominant. Layers are merely modules in a box and hosts are not really part of the network. If you tend to draw diagrams like this, you're probably thinking in the ITU mode. In the ciclode or layered model, processes and layers are dominant. Boxes are merely containers and hosts are part of the network. This is what puts a very different flavor on things. Now, one of the things I should have mentioned in the beginning I did was small differences here can make huge effects. And it's really interesting to see what some of those are. We've already gone past three of them. The first one actually occurred before the ARPA net got started. And I only came to this much later. It turns out that Bob Taylor, who was at ARPA, ran into Roger Scantelberry from National Physical Laboratory in Allen at a conference. And he happened to mention that ARPA was planning to build this network. And they would have many computers for the switches and probably run 9.6 kilobit lines between the switches. And Roger said, well, you know, we use 9.6 in the MPL network. And we really found it was too slow. You really should go for higher bandwidth lines. Now, I don't know that Roger knew what he was suggesting. But in 1970, 50 kilobit lines, which is what the ARPA net had, were outrageously expensive. You know, something like $1,500 a month a month. And, you know, having 50 kilobit lines in the MPL network, which was limited to the MPL campus versus nationwide in the ARPA net was a huge difference, at least in cost. However, it made the ARPA net a success. I really believe that if they had built it with 9.6, and probably none of you have ever experienced a living on 9.6, the ARPA net would have been considered, it would have worked. But it would have considered a curiosity, not really practical. But with 50 kilobit lines, it was a whole new world. And I think that was a real big difference. The other thing that happened here in these early days from the ARPA net's point of view was the US became fixated on the host as an important component of the network. And also for naming and addressing. And to some extent, they still have never really realized that when it comes to setting up communications, the host really has nothing to do with it. The third one is a lot more interesting. And it really shows, you know, how this can happen. The ARPA net assumed that the host had to be within 10 meters of a switch. Okay. On the other hand, Ciclod assumed that the hosts were not co-located with the switches. And in fact, we would be on customer premises where those switches would be on the network premises. And that they would be connected by serial lines. Now, the difference between the DOD largest and what was common business practice at the time is really telling here, because the ARPA net in the ARPA net host tells the amp to create a flow to another host. Whereas in Ciclod, the host maps to a network address and establishes the connection. And also Ciclod assumed that a host could be connected to more than one switch. Okay. Now, obviously, I mean, the ARPA net did relax this constraint later on, but it, you know, but the initial idea of the host was still now very much fixed. Notice this makes the host very much part of the network, whereas over here, the transport protocol had addresses, whereas this makes the host very much part of the network, whereas the host is not part of the network in the ARPA net. In Ciclod, replacing the serial lines with a network was essentially did not had no change. You add a relay on the transport addresses, and there's really no change required. And so by that simple expedient, the ARPA net was a network, whereas Ciclod was an internet architecture in 1972 and operational in mid-73. Now back to Enwick. The group got together and they were all, you know, very much, you know, the idea of moving on something like the Ciclod ideas. And they were going to do a transport protocol as sort of the key thing. Now, there were two proposals that were put forward. These are the document numbers, which they're known by, and much of this is taken from a very good article by Alex McKenzie. And another Enwick 61, which is based on the Ciclod transport protocol. And there was a healthy debate. Now, there were a couple of sticking points, you know, and you'll see, you know, you see how fragmentation works and whether or not it was a stream or letters, you know, that were maintained their integrity. And these were not really major differences. I mean, compared to the forces bearing down on these guys, this was, you know, this was not a big deal. After a hot debate, they weren't getting anywhere. A synthesis was proposed, and that protocol spec was called Enwick 96, again, the document number. There was a vote in 1976, which approved Enwick 96. And as Alex says, MPL and Ciclod immediately said they would convert to Enwick 96. The European Informatics Network said it would deploy only Enwick 96. They were just rolling out at the time. And then he says this, but we were all shocked and amazed when Bob Kahn announced that our researchers were too close to completing the implementation of the updated Enwick 39 protocol to incur the expense of switching to another design. As events proved, Kahn was wrong or had other motives. The final TCPIB specifications were written in 1980 after at least four revisions. Neither of these was totally right. The real breakthrough came two years later. After the announcement and DARPA was unwilling to compromise, the DARPA group goes off on their own. But the differences here weren't the most interesting thing about this event. The similarities among all three is much more interesting. This is before IP is separated from TCP. All three of the proposed transport protocols carried addresses. The TCP, early TCP, the Ciclod TS and Enwick 96. This means that the architecture Enwick was working to was this, an internet transport protocol of greater scope with addresses over multiple network layers with less scope with addresses and data link layers which might have addresses. If this doesn't hit you like a ton of bricks, you haven't been paying attention. This is not the architecture we have today. The Enwick model was this. An internet layer addressed hosts and internet gateways over several different networks of potentially different technologies. Okay. With different scope, different technologies, different addressing. Interdomain routing was at the internet layer. Introdomain routing was at the network layer. The data link layer had the smallest scope with addresses for the devices and hosts on segments it connected. That was their view. The internet lost a layer. Now let's set it back a minute. It was clear to everybody that the networks would have to be interconnected and there were basically two approaches proposed for doing this. The data com approach using protocol translation and the internet approach using an overlay with no translation. Of course, as you would expect, the ITU chose a data com approach or actually in those days the CCITT. Just hook them together and convert one to the other. Basically the same is how the PSTN works. For them, this was reasonable approach because it retained the traditional data com beats in a string model and was what they were familiar with. They were interconnecting relatively similar X25 networks. Protocol translation was feasible and wouldn't be messy. With no transport protocol that would relegate them to a commodity business, it preserved their business model. They were really gung-ho on this. The researchers, on the other hand, chose the internet working approach. Build a common layer over the different networks. The upper layer required at least a minimal service from the layers below. If not, then a protocol was required to enhance the network's service. The researchers in NWIG assumed that there would be a wide variety of potentially very different networks, raising the specter of messy complex translations. Here, layers are a local instrument shared state. The elements of the layer are cooperating to do resource allocation. This is a distributed computing model. Now, at the same time, while all of this was going on in the early 70s, ARPA had created a top-notch collaborative group that had learned how to work well together. The arguments that were had in the development of telnet and FTP and stuff were really pretty incredible because everybody came from different systems and there was different nomenclature. Over time, we figured out that we had the same things going on. We just labeled them somewhat differently or partitioned the functions a little differently, but they had gotten really good at it. In 1973, an attempt was made to finish that work by creating the user's interest group. What they wanted to do was really make the ARPA NAT a truly resource-sharing network with protocols to really enhance that, that will really move on remote job entry. However, I can talk about what came out of that, some of the stuff that came out of that. But anyway, fearing they were losing control, and actually to some extent they already had, ARPA shut down using in 1974. From then on, there is no talk of resource sharing and no new protocols developed in the ARPA NAT internet environment. DARPA withdrew to just do TCP, and by 1978 had separated IP from TCP when they should have been added an IP, but we're getting ahead of ourselves. With new people mainly, this is I think very interesting because as new people started coming in to the NAT, and it was an exciting time, it was incredible stuff going on. But the people coming in, the new people had telecom experiences, without the resource sharing emphasis, they saw what they were familiar with. A comment by Jeff Houston just two years ago really makes that clear. In an email discussion, he said, we originally constructed the internet as the computer-fect stimuli of the telephone network. When I read that, I said to hell we did. The phone system was the anathema of what we were doing. They were the opposite of what we were trying to do. So how did the internet lose a layer? Consider the networks for DARPA's internet. You had ethernet, you had packet radio, you had satellite network, and of course, you had the ARPA NAT, which was a real network, but it was a black box. BBN built the ARPA NAT, BBN built the amps, BBN controlled all that, everybody on the outside, it was just a black box. And they're building an internet, so they need an overlay across that. But the first three are not really networks, they're multi-access media. And with the common overlay, you get something like this, which should look familiar. This is basically what we have today. And there were lots of lands connecting to each other. The ARPA NAT is becoming less and less important, eventually a shutoff. This is not an internet, it's a beads on a string network just like ITU. We've met the enemy and he is us. Interestingly enough, the term internet gateways drops out of use about this time, and all you hear about is routers. So the internet stayed with the data common approach. IP fragmentation is a protocol translation mechanism, not an internet mechanism. To be an internet mechanism, we'd have to put everything back together when it goes from network to network. By now, 1980, it's starting, and by January 1st, 1983, it's complete. The internet is no longer an internet, but an ITU beads on a string network. The term internet gateway has fallen out of use and replaced by router. We have a flat internet network. And they had help in this. IEN number 48, the cat and that model for internet working, had a couple of interesting quotes. Here, the idea that a host may have several addresses depending on how many nets it's connected to. In other words, they're continuing to name the interface. Tinker Air Force Base was six years ago. They should have seen it. And the other one was to simplify translation from internet addresses to local addresses. It is advantageous, if possible, to simply concatenate a network identifier with a local host name. Addresses to create internet addresses. This turns out to be wrong. This makes the addresses path dependent, which, of course, to solve moldy homing, you don't want path dependent addresses. This was a really interesting result because it runs against our intuitions. We do this with file names, and it works perfectly well. But then, you know, when I was thinking about this, you know, you just go back and think about what mold is called a file name. They call it a path name. It defines a path. And what you need with network addresses is to not define a path. You need to define where, but not how to get there. And of course, the same document, the figures are quite interesting. They all look like this. There are no layer diagrams. So what layer did they lose? It's not obvious at first. At first glance, one might say the network layer. After all, the protocol is called IP. Removing the ARPANET, remove the network layer, everything else just dropped down. But IP addresses the interface, something in the layer below, just like the ARPANET addresses did. It's more like IP replaces ARPANET. At best, IP names a network entity of some sort. At worst, a data link entity. Actions speak louder than words. We conclude they lost the internet layer. Now, there's a much longer lecture that goes into addressing. But, you know, naming the interface that derives all this from original work by Salter. Actually, Salter sees the problem, but then fails to actually take advantage of it. But what we actually have here, and if you go through it carefully, what you turn out is that because, you know, we thought Tinker made it obvious, the first thing we have is a mapping from the application names. We're following operating systems here. We have a mapping from application names to network addresses. John Shock made an early paper, a really nice thing of saying applications and application names indicate what you want to talk to. Network addresses indicate where it is and how to get there. So the directory mapping maps application names to node addresses. The node addresses, we find these where it is and how to get there by routing in the network layer. And then unique to networking, it doesn't really appear in computers, is that we can have more than one line between next tops. And in fact, in the 80s, this was probably common. In fact, it still is. And so then we have to choose which path we take to the next to the next top. And this is sort of what we see, you know, in addressing this is how it works. Now, one of the interesting things about this analysis is that this last mapping here and here are the same mapping. They're mappings between nearest neighbors at that level, at that layer. So, you know, that's really interesting. However, in the Internet, all we have is point of attachment addresses, no as an interface, which is named twice once by the MAC address and once by the network by the IP address. We don't have node addresses and we don't have application names. You know, domain names are just macros for IP addresses. Sockets, I don't know if there's anybody old enough to remember this, but sockets are like jump or, you know, well known ports are like jump points in low memory. Was that something that early operating systems did that was really ugly? And URLs are named a path to the application. Yeah, so what? This works signed so far. Really? First of all, it's limited to a very rudimentary form of client server. It may as well be SNA. It's not really any richer than that. Scaling has always been a problem. Requires a global address space. Believe it or not, that's not a requirement in a full architecture. That's caused much greater complexity yet they're needed. God knows, you know, because of the broken network architecture. Can't solve moldy homing. With a full architecture, moldy homing is free. It's inherent, which also makes mobility a terrible mess. But with a full architecture, mobility is inherent. Nothing else is needed. No home agents, no foreign agents, no tunnels, no additional protocols. It just works. You can't, you can't open a connection to a specific instance of an application just to allow, well, you can, you can do it yourself, but the architecture doesn't support it. And you can't open a connections to specific instances of application applications with two different protocols. It's not supported by the architecture. It's like living in the 1970s. I mean, nothing's changed. Oh, I guess I've got a question for you guys. We got this module there and there's a need to partition it into two modules. The question is, along what lines do we partition it? One could partition it one way, but it breaks some internal functions. Or we could partition it a different way and not break anything. Which do you think we choose? Well, I would choose the first one. I mean, I don't know. It's my pre-election. Then why didn't they do that for TCP? Spilling IP from TCP was a mistake. Separating error and flow control from relaying and multiplexing are independent? No, they're not. IP fragmentation doesn't work and never has. IP has to receive all of the fragments, retransmission, you know, et cetera. Oops, the wrong way. There is a fix, of course, an MTU discovery, the equivalent of doc. There hurts when I do this, well, then don't do it. And of course, you know, basically, TCP was split the wrong way. Research into the structure of these protocols shows that they cleave quite naturally between data transfer and the feedback mechanisms, data transfer control. And it's really great because this side over here is fairly simple functions with a very fast cycle time, and it just updates the state factor, whereas this side is more complex, has more stuff to do, reads the state factor, but other than that, these two pieces hardly ever talk to each other. This is a much cleaner separation of functionality. And so TCP was split in the wrong direction, and they failed to incorporate new results. As I said before, in 1978, Dick Watson makes a remarkable discovery. The necessary and sufficient conditions for synchronization for reliable data transfer is to enforce the bounds on three times. He assumes that all connections exist all the time and always have. State vector is merely a cache of state information recently. I really like how he puts this. He says that all connections exist all the time, that the state vector we have is ones we've received data on recently. If there's no traffic for two MPL plus A plus R, we can discard the state vector. Basically, the three-way handshake has nothing to do with why this works. It works because the times are bounded. Now, what he is in the ARPANET or in the internet, a connection starts at the M plus 1 protocol machine and goes to the M plus 1 on the other side. This combines port allocation and synchronization. What Watson is saying when he assumes all connections exist all the time is that port allocation and synchronization are distinct. First, you allocate the ports and then when there's data to send, synchronization occurs and it's bound to the port IDs. Not conflated in these two has significant implications. First of all, we can throw away the synchronization after there's no traffic for a while. The bindings are local. Many of the attacks on TCP connection establishment do not work in this environment. It's much more secure. It's much simpler. It's more robust and there are some interesting things we can do by assigning more than one connection to the same port IDs. They had a chance to get things back on right. In 1972, we knew that we needed something to map application names to network addresses, some kind of directory. Downloading the host file from the NIC was clearly temporary. When time came to automate, it would be a good time to introduce application names. Nope. We just automate the host file. Big step backwards with DNS. It's barely is macros for IP addresses. And then there was the API. They even screwed that up. In 1975, when the first Unix system was put on the net, the API was Filio. Open, close, send, receive. Notice that this would lay the groundwork for a seamless transition to application names and eliminate well-known ports. Not only that, but applications wouldn't have to be modified to use network. And this also puts the name look up under the layer of boundary where it belongs. Instead, we've got domain names and sockets which exposes too much of the internal machinery and requires any application to be modified. Actually, I've heard that transitioning to IPv6, Microsoft was delayed by two years simply because they had to rewrite everything to deal with sockets. Then in 1986, they had congestion collapse. They were caught flat-footed. Why? Everyone knew about this. People have been doing research on it for 14 years, and there had been conferences on it. Now, congestion is a statistical form that occurs in any layer that relays and is contentioned in a point-to-point or multi-axis layer. Load merely increases the probability that there's congestion. The effectiveness of any congestion management scheme deteriorates with increasing time to notify. Put-again transport maximizes time to notify. It works by causing congestion. I mean, the current solution does, maximizing retransmissions. I mean, since when do you do congestion control by causing congestion? Towards any efforts to do quality of service, while people are trying to smooth out the traffic in the network layer, the transport layer is pulsing it. Implicit detection, i.e. lost packets, makes it predatory. Reaction to congestion in one layer can't be limited to a single layer. As near as I can tell, this makes this virtually impossible to fix. Whereas if you had an internet architecture, then clearly congestion control goes in the network layer, which is what everyone else thought. Time to notify can be bounded with less variance. Explicit congestion detection confines its effects to the specific network and to a specific layer. Did we know better at the time? Yes, Ross Chains work in 1988 and already shown this. He also proved that notification should begin when the average queue link is greater than or equal to one. This would make congestion and retransmissions very rare. Be good to manage the network. And they did a bang-up job with SNMP. I'm going to skip over this. Basically, the big thing here was that, first of all, SNMP was probably the worst protocol I could have done. We'd already tried it in 84 and realized that it was too much overhead. And so we had moved to a more object-oriented approach with both CMIP and HEMS. However, the real problem came when the SNB came out. The router vendor said, oh, this would be okay for monitoring, but not for configuration, because it's not secure. Well, SNMP was in ASN 1, which I always thought was an encryption algorithm. They thought you should just open a telnet connection and send passwords into clear, which is clearly a lot more secure. IPv6 still names the interface. We've known about this problem at this point for 20 years. No multi-hauling implies cluges for mobility. And notice the internet architecture, in an internet architecture, this is straightforward. They were actually convinced that routing on the node address wouldn't work, which just baffles me. And then we had the whole debacle that led from IPv7 to IPv6. And in 1992, there was more IPv7 deployed in the net than IPv6 in 2014. This was already over. By that time, the time of IP and G, tradition trumps everything. When they can't ignore it any longer, they get post-ITV and G trauma, and they look for worker rounds, and a deep thought yields loc ID split. In other words, they had the bright idea that we'd been overloading the semantics of an IP address with both locator and identifier semantics. First of all, Salser in 1977 defined resolve as in resolve a name as to locate an object in a particular context, given its name. In computer science, all names are locators. All locators are identifiers. You can't do one without the other. This is a false distinction. Second, the locator is the interface, not the end of the path. We're back to the same old problem. And third, the routing research group found that the flat identifier had to be aggregatable. So this was really a low-glow split. I mean, this stuff was just crazy. Fourth, research has looked at 15 different loc ID proposals, none of them scale. The problem isn't separating location from identity. The problem is and always has been separating physical location from logical location. But to do that, the layer is missing. You never get a busy signal on the internet. In 2010, they discovered buffer bloat. What a surprise. With plenty of memory of the NICS, getting huge amounts of buffer space backing up behind flow control. Well, duh, what did you think was going to happen? This stuff's got to go somewhere. If pure flow control in the protocol is pretty obvious, one needs to have flow control across the interface as well. Actually, if they had adopted Jane's solution for congestion control, buffer bloat would never have occurred. What about security? Don't you know? We read the papers? It's terrible. This is a big problem. And everything is being done after the fact. And we all know about what it means to retrofit security. What about the application layer? Well, what about it? There are applications, so what? Well, if you say so. Remember this? Remember how CICLOD got to it? The internet thought all error and flow control was at the edge. But that was HTLC, which does error and flow control, end to end, just different ends. They saw datagrams and best efforts as it ended themselves, whereas CICLOD knew that datagrams and best effort were just the beginning. They were the minimal assumptions that worked for them. They knew that there would be others. Taking stock, the internet has botched the protocol design, botched the architecture, botched naming and addressing in the API. When they had an opportunity to move in the right direction with application names, they didn't, they did DNS. When they had an opportunity to move in the right direction with node addresses, they didn't, they did V6. More than botched network management provided no direction in application layer. Botched congestion control, so bad it probably can't be fixed. Botched security, by my count, this makes them 0 for 10. Defies reason. I mean, what are these guys got an anti-minus touch? But it's a triumph. That's what they all say. But that argument so was DOS. But it works. You know, you point out all the technical flaws, and that's the only answer they come back with. So did DOS still does. As long as fiber and mortar's law stayed ahead of internet growth, there was no need to confront the mistakes, or even admit that they were mistakes. Now it's catching up to us. Fundamentally flawed from the start to the dead end. Every patch, and that's all we're seeing is taking us further and further from where we need to be. Want to feel really bad? A recent book, actually just came out in the last few weeks, paints a very different picture. First companies in the 80s were developing land products, then products to connect lands together in the workplace, then connecting lands over distances to create corporate networks. But in the late 80s, corporations wanted their suppliers to own their networks. The next step would have been so many corporate networks wanting their suppliers to own them. It would have been some pushbacks from the suppliers to say, hey, guys, we can't be on all these different networks. We need a common network. Not only that, but the medium-sized companies couldn't afford a corporate network. So they needed a common network as well. So all of this was headed in the right direction. This was moving toward the inwig model that we saw in the mid-70s. And then in the middle of all this is dumped free software in a subsidized ISP, but with a flawed architecture and lots of hype. The meddling of big government caused the entire mess. How do I know this would have happened? Because it did. It was the computer companies who were doing the OSI stuff. And they knew they'd have to accommodate different networks. And one of the things they were concerned about was what would happen if you had to communicate between two high-quality networks over a low-quality network. Well, you'd have to enhance it. There are actually figures like this in the OSI reference model. So they subdivided the network layer into three parts. The lower part being, quote, the network layer and the upper part being the internet layer. And so you end up basically back at the inwig model. And actually, this is really confirmation that inwig was right all the time because I was around with both of these and there was no overlap in the two groups. So OSI has an internet architecture. The internet has an IT-like network architecture. You just can't make these up. Just for old time sakes, we find that OSI didn't lose a layer, had a full addressing architecture, including application names and more, still needed a directory. X500 was not the answer. Adopted Watson in TP4, making it a major advance over TCP. Deckwood approved Jane's work for congestion control. Had a reasonable API that could have been improved a little bit but was on the right track. A security dendem and work was ongoing in the layers to do security. Major advances in the application layer and modular and recursive application layer with more to explore. Soon we go back to OSI. Heaven's no. Major advances since then. There's been a lot of cruft stuck in the OSI stuff by the ITU that would all have to be removed. So now what? The search for future internet was doomed from the start. There was no overarching plan to ensure the pieces would fit together. They thought it was all about requirements, which was really face saving. It had to be about the mistakes, the about the flaws. Just because it doesn't work doesn't make, just because it works doesn't make it the right solution. Whereas the mistakes distorted the proposed solution. The flaws had to be fixed and fixed correctly. Otherwise, we were building on sand. Good enough is only good enough in the short term. Good enough adds complexity. And the complexity it adds is not linear. Now what? Well, that's what we'll talk about next time. Thank you again for joining us today, John. Had a great time.