The Preface noted seven fundamental questions uncovered in the early forays into networking. Interestingly, these questions were lost in the ensuing conflict over protocols and remain unanswered 30 years later. What happened? As the 20^th century drew to a close, the excitement over the Internet had begun to wane, with prominent Internet researchers finally beginning to realize that research was stagnating. In 2001, a study into the state of network research by the National Research Council (2001) made a jarring and embarrassing observation:

An entire field’s research program being so strongly criticized for losing sight of the fundamentals? Outrageous! But worse, it was becoming more and more apparent that the current Internet architecture was running out of steam. There were severe problems with scaling, security, addressing, routing, and so on; and although there were endless proposals for fixes to specific problems, the fixes were just that: more band-aids, not fundamental new insights. They tended to further complicate the structure. There was a crisis in fundamentals. DARPA funded MIT and ISI to convene the NEWARCH project, consisting of prominent researchers from those two centers and elsewhere. After two years, their final report (Clark et al., 2003) essentially came up dry.^[1] Sessions on new architecture have been held at various conferences, but the results were always the same. It became so bad that proposing new architectures became the subject of satire. Then with great fanfare, NSF discovered the issue. A grand effort to build an infrastructure (how does this differ from the rationale for Internet2?) to investigate the major questions plaguing the Internet today (a variation on trying all kinds of cannons?) was initiated, along with a new initiative to find a new Internet design. “Clean-slate” has become the new hot topic. But if their announcements are any indication, the slates haven’t been erased well, let alone washed. Few of the problems it sees as important seem to be any of our seven fundamental questions. In the one or two cases, where they have come close to a key issue, they have failed to recognize it as having fundamental implications. There seems to be an inherent assumption that the foundations are firm (leaving the slate less than clean). It is not clear whether this is a blind spot or the old guard protecting its legacy. But so far, the grand effort seems to be recycling old wine in new bottles. Perhaps, it has become just another source of funding. A new take on Alyosha’s dream: We can’t actually solve the problem or the funding will dry up. But there is more going on here. We must look at the socioeconomic forces that got us here. So, where do we stand with our fundamental questions?

Going back to the chronology in the Preface, the first thing that hits one is that none of the outstanding issues have been resolved, with the exception of replacing NCP with TCP, and that is now clearly showing its age. We can see now that TCP was designed to address the immediate problems of the day and had little ability to adapt to the future,^[2] as indicated by the proliferation of transport protocols within the IETF. The Internet is at its core an unfinished demo.

Then why is the Internet seen as such a success? Basically five reasons: abstraction, insensitivity, Moore’s law, military spending, and hard work.

Many people point to this success as proof that the Internet suite of protocols is a paragon of technical achievement and that there is little fundamentally wrong with the Internet. This is the same argument that apologists for DOS used to justify its technical excellence. To quote Stan Lee, “‘nuff said.”

If one looks carefully over this chronology, one is inexorably drawn to the conclusion that the Internet did not begin to stagnate at the turn of the century, but in the late 1970s. It is here that conservative behavior begins to take hold. It is here that each juncture is not seen as an opportunity to fulfill the earlier vision or to synthesize new insights with previous achievements to create a new innovative direction, but more the minimal change is made to solve the immediate problem and go no further. It begins to seem that people are the keepers of some flame and dare not tamper with what has been entrusted to them, the classic behavior of a “second generation” i.e., not the founding generation. Some will argue that this was the policy of small incremental change that has been a stalwart of Internet development. And they are right; caution in maintaining a production system is a necessity but a slow death for research and the research was far from done. But isn’t that just what one would expect from the inheritors of the flame? Is that just a rationalization of a much deeper malaise?

We can now see that after 1975 we were entering a period of consolidation. We were implementing TCP,^[3] the network was expanding, but no efforts were creating new requirements on the Net, efforts that would have forced us to look deeper at some of the things we hadn’t done in that first push.^[4] All the while, Moore’s law was at work pushing the edges further and further out, making problems less and less pressing. In addition, there was never a clean split between operations and research. In some sense, the researchers never let go of their network, but at the same time it was operational supporting more and more people who were not network researchers who could live with the Net being a little flaky on a Tuesday morning. So researchers had to make incremental changes. There was no place to try out major new ideas. Although a period of consolidation was probably necessary and unavoidable, without new developments in other areas the Internet was essentially marking time. Each change becomes permanent. Any attempt to addresses shortcomings of a previous change must be built on top of it. There is no replacement of modules by new solutions as with most products. This has more in common with biological evolution than incremental engineering. We know that with biological evolution, the vast majority of trials (species) reach a dead-end and become extinct. For nature, this is not a problem; it does millions if not billions of trials. We don’t have that luxury.

This mode of operation was reinforced by newcomers to the Net who were mostly nonresearchers and lacked the broad background of the initial developers and who finding a working system (and few alternatives to look at) saw the existing structure as the only way to build a network (early imprinting works again). Myths grew up as to how various stopgaps, kludges, and shortcuts were wonderful pieces of forethought and design.^[5] These myths became “design principles,” making them virtually impossible to overcome and return to the original vision. More than once, the decisions of the early Net have been described as if “handed down on stone tablets.” This was further reinforced by textbooks, which described what existed as the best or nearly best solution instead of doing the extra work of describing the principles along with particular implementations.

Reflecting on the events of the past 35 years, I have come to suspect that not pursuing the upper layers, the squelching of USING (the Users Interest Group, see Chapter 4, “Stalking the Upper-Layer Architecture”) may have been a crucial juncture. I had always thought the upper layers should have been explored in the mid-1970s, mostly because there were all of these “neat” things we could use the network for! (The engineer in me.) It was the next obvious thing to look at. But more recently, I have begun to suspect that it was more than just doing the next neat thing. That not pursuing the upper layers removed the driver that would have forced us to complete the architecture; forced a complete addressing architecture; forced greater attention to security, more requirements on the lower layers, and probably many other things. Growth alone was not enough with the effects of Moore’s Law. With no impetus, there was no reason to change, especially given the “second-generation” effects.

In addition to the internal social forces, there were external forces the intensity of which no other effort in computer science (or perhaps any science) had ever been subjected to. Starting in 1974 and 1975, we became aware of the PTTs’ effort to standardize packet-switched networking with X.25. This was our first foray into the world of electro-political engineering and power politics. We were rank novices compared with European researchers, but we learned quickly. Unlike today, CCITT meetings were open only to telephone companies and countries.^[6] For any U.S. manufacturer (other than Western Electric) to attend, they had to be accredited by the Department of State. This began the ongoing war between the “beads-on-a-string” and layered approaches to networking and the incredibly intense connection/connectionless debate.^[7] There was much more at stake for the Europeans. With no Carterphone decision in Europe, the European PTTs could claim that the only equipment that could be attached to their data networks would be theirs. In other words, you had to lease their computers, just as you did their telephones. Research was being pushed into a world of power politics at a very early stage. And not just the power politics of standards; there was also immense pressure to commercialize packet switching and, very soon after, LANs.

Packet-switching networks had always been the underdog, both scorned and feared by the phone companies, beginning with the ARPANET demo at the ICCC conference in 1972. Scorned because the bellheads had been building networks for a 100 years, and the Net flew in the face of everything they knew. Feared by the engineers because computers were at the heart of it, and they didn’t really understand this new world. Feared by management because the layered architecture, and the transport layer in particular, relegated the phone companies to what was clearly a commodity business (unless, of course, they wanted to leave their cushy monopoly for the rough-and-tumble world of competition). In 1975, they saw no reason to. It would be easier to squash the upstarts, or just let it die out when it was realized that it didn’t work very well.

The tensions between the connection and connectionless camps began to heat up. From the beginning, these were some of the most emotional arguments I have ever witnessed or participated in. The first attempt to affect the outcome of X.25 had only modest results.^[8] The connection model held out a possible escape from the commodity trap with so-called value-added networks. The PTTs believed that connectionless was an academic infatuation that would fade away (or at least they hoped). Several PTTs were already well on their way to building networks and were not going to change very much. Because the PTTs were monopolies in most countries, the attitude that customers had to buy what they decided to offer was common.

If communications was going to use computers, it was a new market for the computer industry, and they weren’t going to miss it. The computer industry recognized that they would never have a voice in the CCITT. So, they attempted an end run by creating a network standards effort in ISO, a nongovernmental voluntary standards body. OSI was formed in 1978 over the objections of the traditional ISO data-comm committee.^[9] While OSI was initiated by the proponents of connectionless, the European computer companies wanted and needed rapprochement with the PTTs. Very quickly, with the aid of AT&T, the CCITT effort in this area was made a joint effort between ISO and CCITT. This was unavoidable and at the same time sealed the doom of OSI. On the one hand, a competitive effort in CCITT would have severely weakened any computer industry effort, especially with no inkling of deregulation on the horizon. At the same time, the difference in paradigms was irreconcilable, at least given our knowledge at the time. No one could see a synthesis of the two, and “professional” standards committees did not do the kind of elegant synthesis seen in the early APRANET, but just jammed two (or more) contending approaches together and called them options.

Beginning in 1974 as the International Network Working Group (INWG) and later becoming IFIP WG6.1, INWG broadened the scope of similar groups within the ARPANET, NPLNet, and CYCLADES, along with other researchers. 6.1 had been working on an international transport protocol as well as doing work on a VTP that was a very elegant example of extensibility and the beginnings of the application of FDTs to protocols. Just before OSI started (March 1978), INWG chose a revised CYCLADES TS as the international transport protocol over the NPLnet protocol and TCP (Cerf, et al. 1978). This output was carried into the OSI process as an IFIP liaison contribution and became the basis for the OSI Transport Protocol Class 4 (TP4). Soon after this DARPA researchers ceased participating in OSI. Over time, this separation led to the Internet perception of the OSI connetionless work as a rival rather than an ally against the phone companies.

The resulting separation of the Internet participants from OSI led to essentially a three-way competition between the connection-oriented PTT proponents, the Internet, and the OSI connectionless proponents who saw their effort as essentially the next step in developing connectionless networking. It was clear by the late 1970s that DARPA no longer had an interest in continuing the revolution it had begun. If any of the open issues were going to be resolved, it would have to be elsewhere. OSI offered the only forum where there was a chance to resolve some of the issues the ARPANET/Internet had not had a chance to do.^[10] However, with the confusion created by the warring connection/connectionless factions, it didn’t matter what OSI was trying to do; whatever advances it made were completely obscured by the internal conflicts. The strife within OSI was not limited to connection versus connectionless, but also Japan versus Europe versus the United States, and the computer industry versus the phone companies and everyone against IBM.^[11] The push for OSI was signaled in early 1982 when IBM changed the diagrams in its advertising of SNA from five layers to seven.

After IBM’s endorsement,^[12] the desire to lead the commercialization of OSI yielded many interests who all had their own agendas, fighting over who would get a piece of the pie, who would essentially control its implementation: NBS/NIST, MAP/TOP, EMCA, COS, DEC, IBM, and others. IBM played them like a violin. It was truly magical to watch.^[13] IBM played them not by direct action or pushing specific proposals but by creating an environment that would maximize confusion and complicate whatever the result. IBM played on the egos of a few key people to create new initiatives, separating the designers from the implementers (a standard organizational tactic to kill a project) by encouraging the formation of implementer’s workshops distinct from the standards organizations.^[14] As it usually turns out, the designers had a much better idea of how to implement than the implementers did.

The implementation profiles were supposed to be a means around the connection/connectionless dichotomy. Different environments would use different profiles. It merely served, as predicted, as a forum to rehash the same arguments in different groups, adding to the confusion. The dichotomy in OSI immensely complicated its output. Because vendors were unwilling to bet on the outcome, they felt they had to implement the whole thing. As with all organizations, it is the internal problems that are the most deadly. There were just too many disparate camps under one umbrella, too many wanting to “lead” OSI, and no common direction for OSI to have ever succeeded.^[15] And while there were elements buried in OSI that would have advanced the state of the Internet, it would have been impossible to extract them in the political climate, and there were still many things that were not “right.” The lesson to take away from the OSI experience is plain: No matter how reasonable it may appear, collaborating with the legacy will lead to failure. If the new model does not have enough advantage to stand on its own, it does not have enough to stand with the old guard either.

Probably the greatest beneficiary of all this turmoil was the Internet, which for the most part was left out of this multisided conflict. The Internet had been left to its own devices and was in the best position to push the technology ahead while everyone else was distracted. But, this did not happen. At the same time, the isolation had its own effects when the IPng effort brought them together again. By this time the Internet had rewritten its history to reflect its crowning achievement, having lost sight of the list of open issues and that the Net was really an unfinished demo that had never been “productized.”

What was required was a true synthesis of connections and connectionless, like the syntheses that the early ARPANET had been so good at pulling off. However, the political situation was so intense and the problem so much more difficult that it was hard to find the middle ground.^[16] Instead, a bunker mentality set in: each group unwilling to bend for fear of losing the whole thing. One cannot stress too much the intensity or affects of this bunker mentality on all three camps. A less-intense environment might have been able to find the synthesis, but it was impossible in the environment that existed.

It is also worthwhile to bring up another factor that is sensitive and embarrassing for many of us: immaturity. Although there were many “standards professionals” who knew the ropes and understood how to get things done, the vast majority of participants in all three camps were young, bright, hotshots new to the game. We had been weaned on the kind of raucous design sessions that were prevalent in the 1970s and 1980s, and I am afraid that our behavior often contributed poorly to the process. Often ridicule and loud abusive language was substituted for logic and reason and trying to understand the opposing view. The idea of winning the position at whatever cost overrode any need to “get it right.” Although it has moderated considerably, a strong current of intolerance and lack of listening still characterizes these discussions on all sides (often compared to religious fervor).

If OSI buffered the Internet from the bulk of the turmoil with the PTTs and the connection/connectionless debate, how does any of this affect the Internet? This is one of the oddest effects in this whole story, and one I still don’t understand. The Internet participants developed a deep visceral aversion for anything associated with OSI, which exists to this day. Much of what is believed about OSI is not based on firsthand knowledge and is often simply wrong. It is an odd reaction for something that was doomed to fail on its own.

But as I noted in Chapter 5, “Naming and Addressing,” the oddest reaction is that if OSI did something, then the Internet wouldn’t. The reaction wasn’t, “They didn’t understand it; let us show you how to do it right.” The reaction was to do anything else but (hardly the behavior of professional scientists or engineers and often resulted in “cutting off their nose to spite their face”). We saw this with the decision to continue to name the interface in IPng. Something we had known was wrong since 1972 in the ARPANET. And something like this may have been at work in the rejection of an object-oriented approach for network management that chose SNMP over HEMS.^[17] As discussed in Chapter 4, SNMP was a step backward from even the rudimentary IEEE 802.1 protocol that preceded it.

We also see it with respect to the concept of layers. Internet proponents try very hard to avoid layers, primarily because it is strongly associated with OSI, although it is doubtful any would admit it. However, they can’t completely forsake them. To do so would put them squarely in the beads-on-a-string camp. Recently, however, it does seem that some prominent Internet researchers have lost faith with the connectionless model, just when a renaissance is in the offing. Many papers have been written trying to get rid of layers. Most still assume that a layered architecture implies a particular implementation strategy. And they assume that the only possible layers are the ones arrived at in the early 1970s. Both of which we have seen in this book are not the case. They have de-emphasized interfaces to the point that the lack of clean interfaces was a major source of the work in doing IPv6, and the interfaces provide little or no abstraction. They have tried to concentrate everything in the network and transport layers to the point that the Internet architecture is more beads with stripes than layered, with TCP/IP rather than X.25/LAPB.

It is easy to see how in all the turmoil, research has suffered.

From reading the popular press, one has the impression that the Internet is an amazing intellectual achievement, a triumph of American innovation. But a close look reveals a quite different picture. There are only two major innovations: the central one, Pouzin’s connectionless insight for a French network;^[18] and Saltzer’s application of operating system naming to networks. Technologically, the Internet has been languishing since the mid-1970s, creating one band-aid after another as it rode Moore’s law around the hard problems facing them. When OSI self-destructed from its internal contradictions and the corporate squabbling over whom would set its agenda, the Internet, much to its own surprise, was the only thing left. And the Internet was only standing because of the efforts of Al Gore and others to make it freely available in the United States. So in the end, it was more politics and economics that determined the success, not the technological innovations.

Maybe it is time we quit loafing and get back to doing some serious intellectual work, if we still know how.

The short answer is a combination of effects. The push to commercialize networking came on very fast, before the science was really understood. The business world and the research community to a large extent assumed that the “productization” of networking would occur in commercial products. And academia was intimidated from exercising its responsibility to distill fundamentals by the intense flame wars that erupted when pointed questions were asked. “Facts” were often articles of faith, and desires were couched as principles, and wonderful technical doubletalk was created to obscure the lack of hard evidence. By the time it became clear that the Internet was to be the focus of those products, no one in the Internet remembered (or ever knew) that it had not been finished.

The effect of business cannot be underestimated. The press to commercialize networking had a tendency to freeze solutions much too early. But by the same token, the public success of this commercialization led to research taking up the pattern of venture capitalists looking for a quick ROI. Each agency or program director measured by how much they are on the “bleeding edge.” This has led to research programs that are not so much concerned with solving problems as funding for two or three years, declaring victory and moving on to the next big problem. (Clearly, the “bleeding edge” can’t be the same as three years ago.^[20]) Meanwhile, researchers must adjust their research program to the new fads to keep the dollars on which they are measured rolling in. No one is measured on solving problems and producing science. This leads to a proliferation of technique, with no theory to distill them and to hold them together. And with no theory, there is no way to determine how good the results are.^[21] Note that in other sciences, the fact that they are trying to understand an external object (e.g., nature) to a large extent keeps this from happening. It is only in computer science, where we don’t have nature, that this seems to occur. We have nothing to keep us close to Clauswitz’s “proper soil.” It seems that it is as important to keep practice close to theory as it is to keep theory close to practice! As in any science, it is the boundary conditions that are the most enlightening. Computer science provides an interesting boundary condition to the “philosophy” of science.

Much more damaging was the political milieu that networking found itself thrust into. Almost immediately (within just a few years of its first proposal), the concept of the connectionless network was under relentless attack by the PTTs. This led not only to a bunker mentality, but also to a feeling of being a “chosen” elite initially, because the Net was so much more advanced than anything the PTTs could do, and later with the exponential success of the Web. In the 1970s, this was the camaraderie of excitement about new ideas. In less than two decades, this perception had become institutionalized, so that today the mindset of the Internet bears a stronger resemblance to the mindset of the PTTs of the early 1970s than to the ARPANET of the early 1970s. Our textbooks present the Internet as the only network. (Just as 40 years earlier, the study of telecommunications was the study of how the telephone system worked.) Rationales are invented to portray what was done 30 years ago as near perfect, rather than our partial understanding at the time. Even when it is recognized that a “Copernican revolution” in networking is required, it is with the caveat not to change what we have. What sort of revolution is that?

There are uncanny parallels elsewhere in science. In Lee Smolin’s recent book, The Trouble with Physics (2006), he describes the “seven unusual aspects of the string theory community:”^[22]

This is a striking list. Smolin could be describing networking rather than theoretical physics. He notes that sociologists recognize these characteristics as groupthink and quotes Irving Janis of Yale as defining groupthink as “a mode of thinking that people engage in when they are deeply involved in a cohesive in-group, when the members’ strivings for unanimity override their motivation to realistically appraise alternative courses of action.” He goes on to quote a description of groupthink excerpted from an Oregon State University Web site dealing with communication:

Groupthink members are themselves as part of an in-group working against an outgroup opposed to their goals. You can tell if a group suffers from groupthink if it

As Smolin says about theoretical physics, this doesn’t match up one for one with what we see in networking, but it is close enough to be worrying! And as Smolin points out, the in-crowd of networking will have no problem countering these critiques. But all one has to do is look at the contributions surrounding the current NSF initiative to see this groupthink at work. They are all remarkably similar, and yet none get at the core of the problem or strike out in a new direction. It would appear that the groupthink arose as part of the bunker mentality created during the “protocol wars” of the late 1970s and 1980s, when the connection versus connectionless battles were most intense. The attitude has persisted. Note how some commentators still drag out the OSI bogeyman even though it is long dead. This is reminiscent of a tactic used by countries who create an incident with a traditional rival to direct attention away from their own internal problems. Part of the problem in networking is that we now have generations of engineers and professors who have never seen anything else and don’t seem to be able to imagine another way to do things; reinforced by luminaries saying there is no point in changing the underpinnings, even though the underpinnings are deeply flawed (our seven unanswered questions). To not question the underpinnings is not only intellectually dishonest, contrary to the scientific tradition, but is building on sand!

Smolin goes on to attribute this to the increased professionalism of the field, and the same thing seems to apply to networking. He distinguishes between master craftsmen and seers. Smolin characterizes them as follows:

I would refer to Smolin’s seers as “theoreticians.” These are people who need to get to the bottom of things to understand the deep structure and assure themselves that everything is based on something firm, to find the similarities, the invariances. A recent article (Kramer, 2007) in CACM touched on this in lamenting the decline of abstraction in computers science. We can see how networking (and to some degree computer science) has been selecting for the excellent programmer (master craftsman). But reading between the lines of Kramer’s paper, one realizes that the characteristics of the super-coder are essentially antithetical to the characteristics of someone good at abstraction and theory.^[23]

Looking back over the events chronicled in the Preface, we see the work of master craftsmen. At each juncture, a stopgap patch is found. There is no consideration of how it fits into a theory or whether it does. No consideration is given to how this sets things up for the next step because there is no vision of the goal. Only once does a theoretician insert an idea (Saltzer), and it is lauded but studiously ignored.^[24] Smolin traces this distinction back to Kuhn’s Structure of Scientific Revolutions (1968) and points out that master craftsmen are precisely what is required during periods of “normal” science: the period in which a new paradigm is established and is being explored and exploited. But when the new paradigm becomes the old paradigm and is showing its age, it becomes clear that a new paradigm is necessary; a different perspective is necessary.

It is when a new paradigm is needed that a period of revolutionary science has been entered, when Smolin’s seers are needed. To find a new paradigm requires seeing new distinctions, questioning everything, looking carefully at what is really going on. Master craftsmen are not suited to finding the new paradigm. Their characterization of the problems tends to look at the edges, at the surface. Their reaction tends to be to start building things, anything, in the hope that it will be better. It is disconcerting to realize that a paradigm one learned as a student and that has always appeared hugely successful and that the world has heralded as a wonderful achievement (perhaps that one has built a career on knowing its ins and outs) will not meet fundamental needs and must be replaced. After all, the paradigms’ success was based not on its own merits but elsewhere (Moore’s law and politics). But this is where we find ourselves.

In our case, however, it appears the craftsman took over before the new paradigm shift was complete. In 1974, we were just beginning to get an understanding. Saltzer tried to jump-start a look at theory, but we lacked a driver. It would seem that we have a case of arrested development. It is interesting to note how various stalwarts of the Internet—small incremental change, the emphasis on running code, the rejection of technical sophistication—are all characteristics of an artisan tradition rather than a scientific one. There is science, actually more engineering, in specific topics, but overall the tradition has become artisan, dedicated to the development of technique, not to comprehensive theory.

We have an added problem. Hundreds of millions of people rely on our unfinished demo. But they are just a drop in the bucket of what is to come. There is no way that the current model will provide what is needed for the next 50 years or more.^[25] The change has to come, and the sooner the better.

In most fields, the fundamental science comes first, at least a basic understanding. First, we understand how nature works and predict what it will do, and then we figure out how to build things that exploit that knowledge, i.e., engineering. It seemed that in networking we were doing the engineering but not the science. But before condemning too quickly, it is good to remember that in computer science, we build what we measure. Not only does this make it difficult to separate artifact from principle, but it also means we must build something (engineer) before we can measure (science).^[26]

Networks present a much different problem than our experience with, for example, operating systems. With operating systems, it is relatively easy for many different approaches to be tried. All one needs is a machine. For a network, one needs considerably more. By the time Multics and VMS were designed (usually considered the canonical bases for most modern operating systems), there had been at least 20 or 30 different operating system designs tried and explored. We might say that Multics and VMS are roughly v30 of operating system designs. With networks, it is much more difficult to try different approaches. At most, we had XNS, CYCLADES, NPL, ARPANET, and the few X.25 networks to draw on, and they were all small networks. This is not to say that we still would not have done something fairly close to what we have, but we had much less experience with the problem space when we settled on what we do have. And it was much more difficult to try other forms. Even doing just one new protocol was (and is) a major effort, let alone a new architecture.

When we step back and look at what we have, given what we have seen here, it is apparent that what we have is closer to DOS, what we need is Multics, but we would probably settle for UNIX.

Very quickly, research on networks became more “engineering the Internet.” How many good ideas have been squashed by “But how would it work in the Internet” or “You could never do that in the Internet.” When did good research start to be predicated on whether it could be deployed in a single product? The telephone network prior to the 1970s? With that attitude there would never have been an Internet. Little work has been done to understand general properties of networks, to understand the deep structure and how architectures other than the one we have may work. Basically, we have been engineering and not doing much, if any, science. There has been too much emphasis on the next neat whiz-bang thing, too much emphasis on the latest hot topic, too much emphasis on academic research as angel funding, and not enough emphasis on science on what these new hot topics tell us about general principles.

The difference between science and engineering is crucial. When most people think of “doing science,” their first thought is of experimental method, as we saw in the NRC report cited at the beginning of this chapter. But experimental method is a key element of both good science and good engineering. This is not what distinguishes science and engineering. The crux of the difference between science and engineering is that science is concerned with understanding, whereas engineering is concerned with applying that understanding to real-world situations. One might say that engineers are fascinated by exploiting the differences, whereas scientists are fascinated by the similarities, with finding the invariances. The Holy Grail of every scientist is to do for his field what Euclid did for geometry. What Newton did for mechanics. What Maxwell did for classical electricity and magnetism. What Mendeleev did for chemistry. Accomplishing the goal matters less than striving for it. We have lost sight of that in our corner of computer science.

Previously in computer science, this kind of abstraction and theory was common. Everyone knew the basic results of automata theory, for example. Today one would be hard pressed to find a computer science graduate who had ever heard of the halting problem, let alone knew what it means. Perhaps this is because everyone has been trained in a field where theory and abstraction is part of the tradition. But some bad experiences with theory run rampant, and a continuing push for applicability, not to mention visions of dollar signs, has seen a waning of theory (as well as appeals to futility, as in “X is 80% of the market. Why worry about knowing what is the right way?”). It has been decades since theory has been seen in networking. Maybe I don’t read the right journals. But if it exists, it isn’t in the mainstream, and it needs to be. Everyone needs to be aware of how what he is doing fits into the bigger picture (or doesn’t).

We have seen another example in the history of science where a rich and successful scientific tradition stagnated and lost information. For millennia, China had such a successful scientific tradition that China was ahead of Europe, sometimes by centuries. The Chinese developed Pascal’s triangle 300 years before Pascal, and Western medicine did not surpass the cure rate of Chinese medicine until the beginning of the 20th century. These are just two examples of the sophistication of the tradition. But ultimately, Chinese science stagnated. In his multivolume magnum opus, Science and Civilization in China (1965), Joseph Needham concludes that the reason for stagnation was that the merchant class was low in the social hierarchy. Without merchants to create demand for new innovations, the need for progress declined when the power structure lived as well as it thought it could. Half-jokingly, one could turn Needham’s argument around to say that it was a strong reliance on government funding that caused science to stagnate in early China. China was a hegemony, a very strong one. If you were in favor with the emperor, everything was golden, if not.... This was in contrast to Europe, where there was no hegemony. When Galileo first got into trouble with the Pope, he went to teach at Padua, then under the control of Venice, a major power that could afford to be independent. There was little the Pope could do. In Europe, if new ideas caused political problems and made things a bit untenable, there was always someplace to go.^[27] My enemy’s enemy is my friend.

But there is more to the stagnation of science in China. It is sometimes difficult to compare Western science with what one finds in China. Much of what is in Needham’s comprehensive survey (seven volumes, some volumes consisting of multiple books, all quite copious) is more technology than science. Many of the advances came out of an artisan tradition, as they did in the West during this period. But unlike Western science, they stayed there. This belies what is perhaps the greatest difference between Western and Chinese science. Although Needham recognized the lack of theory, neither he nor other historians have assigned much importance to it as a factor in maintaining a vibrant scientific tradition. The most significant difference is that more than a lack of theory it is that

There was essentially no tradition of theory in Chinese science, and certainly not axiomatic theory, of systematizing the results. Needham points out that the body of knowledge represented by Chinese science was more a set of individual techniques than an organized corpus of knowledge.^[29] There was no attempt to develop the kind of overarching theory to integrate a set of results into a comprehensive whole that has characterized Western science. It is hard to find much evidence of attempts (outside of astronomy) to develop predictive theories, or anything analogous to the discipline of proof found in Western science.^[30] The pressure of commerce alone would generate new results but not the impetus for consolidation that comes from theory. As we have said, the Holy Grail of every scientist is to do for his field what Euclid did for geometry: reduce it to a small number of concepts from which every thing can be derived.^[31] Early China is not the only example. There is definite evidence that artisan or craft traditions have a tendency to become insular and protective—more concerned with perpetuating the guild than invalidating its raison d’être. In other words, they stagnate.

Working toward a comprehensive theory, even if one is not found, is beneficial. We seem to have fallen into a bad habit that our only criteria for a solution to a problem is whether the code can be made to work in a reasonable amount of space.^[32] Every time we solve a problem, we should consider how it fits the current theory. If it doesn’t, we need to ask which is wrong: the solution or the theory. What is it we don’t understand? As different models are proposed and tested, a deeper understanding of the problem domain is achieved, even if the proposed model is wrong. It will get better. A good theory is, at the very least, a good mnemonic. There is less to remember. One only need remember the central concepts, a few intermediate principles, and roughly how things relate, and everything else can be derived. Many major results of Chinese science were forgotten, some because they weren’t needed very often. For example, when Matteo Ricci first entered China at the end of the 16th century, he was convinced that he had brought the knowledge that the Earth was round (Day, 1995). As it turns out, the Chinese had determined this 300 years earlier, but the knowledge had been lost.^[33] We are seeing similar loss of knowledge today in computer science as the same solutions are published as new, as the technological pendulum swings back and forth.

Without a unifying theory to simplify knowledge, the amount of information was eventually overwhelming. But theory is much more than just a mnemonic. A theory, even a partial one, leads to deeper understanding of the phenomena being studied and to further insights. Proposals of a unifying theory (even if unsuccessful) raise questions relating disparate phenomena that would not otherwise arise. When there is a theoretical framework, results can be derived that were far from obvious before. Theory not only provides a simpler, more logical explanation, but it also has a tendency to simplify individual techniques (making them easier to understand and apply). Many techniques coalesce to become degenerate cases of a more general method. To see this, one only need read accounts of electricity and magnetism before Maxwell, chemistry before the periodic chart, or geology before plate tectonics.

It is the individual discoveries combined with the search for an encompassing or simpler theory that is the essential tension that gives science direction and allays stagnation. Theory questions the meaning of the observations and techniques that make it up. Theory points at experiments that test its veracity and attempt to invalidate it. Theory points at its own limits. Theory becomes a map of our knowledge and thus pushes us toward better theories.

The processes that have been operating on our science are creating a situation similar to the one found in China of the late Ming Dynasty. Network research has come to this juncture by a different route. Hopefully, it will not have the same end. While we have innovation being driven by the merchant class, they are looking for a quick ROI, i.e., technique, not great leaps forward. To compound the problem, research funding is flitting from fad to fad every few years, generating techniques but giving theory little time to gestate. This, in turn, has a strong effect on researchers. Ross Ashby (1956) noted that the longer a state machine operated, the output became independent of the input and began to reflect the structure of the machine itself.^[34] We are conditioning researchers to produce techniques, not science. There is no theory.^[35] It isn’t that the basics of Research 101 are unfamiliar in our field. What is unfamiliar is that our research must contribute to building a theory. The problem is that the bulk of our researchers have not had training in doing good theory. In mathematics, yes, but not in science.

As anyone who has taken a science course knows, the first step in science is not to measure as the NRC study says. The first step is to state a hypothesis. To state a hypothesis, one must start with a theory to be invalidated.^[36] As Einstein is often quoted, “It is the theory that determines the data.” Without theory, you don’t know what questions to ask, and you don’t know what data is relevant or how to measure it.

I once asked a good friend and Nobel laureate^[37] in physics about Galileo as a theorist and got a strong reaction, “No! Galileo was the great experimentalist!” True, Galileo’s experimental method was exemplary and important to the development of science. But his method would have meant nothing had he not had the insight to see the model that was at the core of the problem. Galileo had thought long and hard before those famous experiments were done. Galileo’s brilliance was in picking the right model on which to base his experiments: falling bodies in relatively controlled conditions. If Galileo had attacked a problem of practical value such as predicting where cannonballs would land (and I am sure that APRAF^[38] would have funded him), he would have found his equations useless. In fact, people did try to apply his results to cannonballs and found his equations were off by as much as 50%.^[39] But Galileo did not start by trying to find equations that would take into account wind drift, air resistance, or that cannonballs were not perfect spheres. The solution to where a cannonball lands requires far more complex equations, at least a system of three-dimensional second-order partial differential equations.^[40] Whereas Galileo’s model could be described with a simple polynomial and confirmed by relatively simple, well-controlled experiments. After the basics of the theory had been worked out, the results for cannonballs could be reasonably achieved by enhancements to Galileo’s equations; but almost impossible if you were to try to start it from the start with a clean sheet of paper. Galileo had the insight to pick an initial model that had a small number of independent variables, could be tested experimentally, and could form the basis to solve more complex problems. But then (and I hesitate to say this), Galileo and his colleagues had the faith to believe in the elegance of the solution even when it contradicted experience, the great Aristotle, and important real-world data. (This is not uncommon in the annals of science [Fleck, 1981].)

Needham recognized that a strong central government as the only patron of science could lead to stagnation. Not surprisingly, he did not foresee that the short ROI demanded by a successful merchant class could have the same effect. It would seem that we have created the conditions for stagnation. Depending on your degree of pessimism, it is now up to us to avoid it or get ourselves out of it.

Avoiding the proliferation of technique or, more positively, encouraging the consolidation of technique by theory is difficult. Although, the private sector is more interested in technique, or as they call it product differentiation, theory is not just the responsibility of the research community. Such consolidation is just as important to the private sector for decreasing cost, improving performance, and creating new opportunities. Furthermore it occurs at many levels, some only the purview of those building product. At the same time, we must keep theory from its flights of fancy and close to “its proper soil,” the practical.

There are many platitudes for encouraging theory and good research. As previously mentioned, it is exceedingly hard to rush theory but it is easy to discourage it. It often seems that all one can do is to create a fertile environment and hope for the best. But there are some things that will help create fertile ground. One can argue that research programs and funding should do more to stress theory. But how many researchers have a sufficiently broad exposure to multiple paradigms, the history of science, and to some extent philosophy to be able to think about it from the outside? And how quickly will it be viewed as just another means to exploit the funding process? This could harbor a lot of less than serious work, and it would be very hard to distinguish between that with real potential and that that had done. Clearly, keeping an eye on the fundamentals is important, always holding proposals up to those fundamentals. A better understanding of the fundamentals is never a waste of time or money. On the other hand, this book demonstrates that new insights are more a product of hard thought than hard cash.

But what are the fundamental principles that can be taken from theory in computer science? Fundamental principles are relations that are invariant across important problem domains. The more fundamental, the greater the scope of their use. To have principles, we need good theory. But developing theory in computer science is much more difficult than in any other field because as I have said many times before,

Because there are few principles to rely on, we often see new efforts going all the way back to the beginning. Hence, many different decisions are made in each new effort, which in turn makes it more difficult to compare different approaches to the same problem, which further complicates our ability to discern principle and artifact.

But we can leverage this unique nature of computer science to get our arms around the problem of separating theory from artifact. There are essentially two parts to computer science: a part that is mathematical, and a part that is scientific. Mathematics is not a science. In mathematics, the only requirement is that a theory be logically consistent. In science, a theory must be logically consistent and fit the data. Many aspects of computer science are purely mathematical: automata theory, complexity theory, algorithms, even to a large extent programming languages, and so forth. Although they are rooted in mathematics, it is the “systems” disciplines of computer science that are the more scientific: computer system design, operating systems, networks, database systems, and so on.^[42] For theory to consolidate knowledge, it must find models that emphasize the invariants in the logical structure. This is much of what we have tried to do in this book.

Because mathematics is independent of the data, this can provide us with a means to develop theory in the systems disciplines of computer science. In a real sense, there are principles in these fields that are independent of technology and independent of the data. Principles follow from the logical constraints (axioms) that form the basis of the class of systems.^[43] This is the architecture.^[44] Within this structure, there are additional principles, which are dependent on the data and independent of the technology or implementation. Specific choices in this space yield specific designs. These two should form the content of university-level texts in a field. And finally, there are the “principles” or relations that are dependent on the technology. These form the basis of product manuals and technical books.

The first two are pure theory. Here is where the pressure to emulate Euclid is most felt. One wants to find the minimal set of principles needed for a model that yields the greatest results with the simplest concepts. The general principles derived from the empirical will often take the form of a trade-off or principles that operate within certain bounds or relations between certain measures. Goodput in networking is a good example of this. We have seldom distinguished these three forms of knowledge. We have not subjected ourselves to the same discipline that other sciences follow. This tendency contributes to the proliferation of techniques and ultimately to the stagnation of our field. This is hard work. It requires disciplined experiments. But it is possible. And it beats working in a stagnant field.

As a start in extracting us from this malaise, this book has attempted to show how we have come across more of the principles than we may have thought. To lay the groundwork for a general theory of networking. To tease out the fundamental structure of a complete network architecture, not just an unfinished demo. So, let’s review the high points of what has been covered here and consider their implications.

In the first five chapters of this book, we looked at major aspects of networking and what we had learned along the way. We considered the patterns that fell out when we extracted the invariances from protocols, and how we might create a synthesis for the connectionless/connection dichotomy. And while we found that there was no upper-layer architecture, we did find concepts that would prove crucial to understanding the structure. We dug into naming and addressing and found much good work had been done that was still waiting to be applied, which when extended to accommodate new conditions presaged the structure we found when we came to sorting out layers. Sorting out layers proved to be a little embarrassing; the answer had been staring us in the face all along, being precisely what we had always said it was: IPC! We had been skipping steps and getting sloppy! But after we assembled it, there was a lot to reflect on:

Reflecting on this model and looking at what we have been working with, it is clear that what we have today is more analogous to a rudimentary operating system like DOS than to a full-fledged operating system like Multics or VMS. Like DOS, all the pieces are there to call it an operating system, but there are a few things missing that give it everything we think of when we think of a “real” operating system. There are many reasons why this was the case and we have discussed many of them. But still, it should serve as a lesson for the future. We should have seen this sooner (me included).

I must admit this model was constructed not so much looking to solve specific problems, but carefully analyzing interprocess communication between distinct systems with an eye to extracting invariances and minimizing discontinuities. Trying to see what was really going on. It would not be going too far astray to say that finding an elegant, simple structure was the primary overriding concern.^[46] But, of course, this pursuit of elegance was not without a clear knowledge of the problems it needs to solve. Even so, on numerous occasions it became clear only long after arriving at the structure that the structure solved a particular problem, not something I had consciously set out to solve. With this structure, we find that it has a number of interesting properties:

Does this throw out much of the work of the past 20 years? Not really. As with any shift in thinking, there will be a few topics that were once popular that will be mentioned much less frequently. However, because much of the research of the past 20 years has been on technique, much of it can be translated into what we would call policy; this work can be carried over. In fact, more research may find application since there is less requirement that all equipment do the same thing and hence greater diversity in the networks and layers that may occur. This model will make it easier to evaluate when which policies should be used and the boundary conditions within which well-behaved policies should be constructed.

Where do we go from here? This book is an attempt to bridge the gulf between what we have seen in our experience with networks over the past nearly 40 years and to get us out of the blind alley we seem to have marched into. With any luck, this book will help to restart the revolution begun by the ARPANET, CYCLADES, NPLnet, and all of those other “old guys” but was derailed by two decades of conflict. With even more luck, this book will serve as an inspiration for a new generation of young Turks^[47] to have the excitement that we had and to make the kind of mark we made. I hope this book helps rally the seers still left in computer science to throw off the corruption of Moore’s law and return to distilling principles and abstractions and maybe even theory, making the advances that have been lying in wait all these years. Rescue us from the stagnation of mounting technique.

By the time this book publishes, there should be specifications available for a DIF that can be debated and implemented and for which policies can be written. Discussion, experimentation, and exploration can begin—working out the policies for different forms of DIFs from what used to be called the data link layer through the resource-allocation layers and into what we called applications. I hope this book opens up new ideas about providing QoS and routing using addresses. I intend to also begin assembling a textbook that uses this model and its results as its organizing principle (a book based on invariances and principles, a true university-level textbook).

What do I expect the reaction to this book to be? Some are going to be intrigued and probably enjoy the read (I hope). I would hope that people will read this, consider its foundation in IPC, and realize that although it doesn’t agree with much accepted wisdom, it is well founded and might just represent the basis for a new generation to have their day in the sun. Clearly an approach to networking like this benefits the owners of networks more than the vendors. Major vendors will hate it because it represents further commodization and simplification. Engineers will hate it, because it requires many fewer engineers to develop and configure policies than developing whole new protocols and will come up with all sorts of excuses to continue their expensive proliferation of special cases and unnecessary optimizations. The greatest expense in networking today is staff, both operations and engineering. This direction requires much less of both.

But the bulk of the reaction? That is easy. In Hafner’s Where Wizard’s Stay Up Late, Bob Metcalfe describes the reaction of the AT&T engineers to the ARPANET demo at ICCC in 1972. Pretty much the same response is likely here. I hope not, but I won’t be surprised. Do we care? They are the new bellheads and already well past their prime. The future belongs to IPC!

No, technology does not change the world. Imagination does.