Back to top

Chapter 08 - Networking: Diffusion 1972-1979

8.11 TCP to TCP/IP 1976-1979

In 1976, DARPA forwarded its newly specified TCP version 2 to MIT’s Laboratory of Computer Science (LCS) hoping to gain their support for its use. Michael Dertouzos, head of LCS, assigned Dave Reed the responsibility of review and comment. Reed, with help from Dave Clark and others, wrote a memo to DARPA in November 1976, proposing an alternative to TCP they called Data Stream Protocol (DSP). Kahn had absolutely no interest in having one of DARPA’s primary research centers develop an orthogonal protocol to TCP and immediately convened a meeting.

Kahn remembers:

Dave Reed had come up with another protocol because he didn’t like TCP. I sat down with Dave and others from MIT, and they described the Data Stream Protocol, and I said: ‘But that’s what TCP is like, with one minor difference.’ And they said: ‘No, it isn’t. Read what Vint says in this report.’ And I said: ‘ That’s just the way he interpreted it. Go back to our original paper, and you’ll see you could interpret it your way too.’ So even that original paper that we wrote was subject to multiple interpretations about how you actually do the implementation.

Kahn, knowing he had to convince MIT to align behind TCP and abandon DSP, assured them an influential role if they dropped their DSP ideas. Reed and Clark began going to meetings and soon Clark - who was then working on both interconnecting LCS’s Multics computer to the Arpanet and developing their token-passing LAN, LCS Net - became a key participant in TCP activities.44 Clark remembers:

So we started going to the meetings and, in fact, although Dave [Reed] was the one who wrote the DSP memos, I was the one that got interested in the meetings and started going. And during the remainder of the decade, while a lot of local network was going on at MIT, I got more involved in the TCP activities.

Before long, Clark too saw the need to split network-to-network, or internet, functions from the end-to-end, or transport, functions within TCP. Dalal recalls:

The concept of the datagram evolved out of some gentle hints that were coming out of John Shoch, David Boggs, and myself who were working now on Pup and XNS. Pup was then beginning to be disclosed, but even before Pup had been disclosed, we tried to convince Vint and Jon Postel and others of the importance of breaking things into a datagram [internet] and a session protocol [transport] – primarily because datagrams are useful in local area networking contexts. It was Vint and Dave Clark and Jon Postel that saw that immediately, and slowly started modifying TCP.

In 1978, Clark, Reed and Kenneth Pogran published an IEEE paper calling for the separation of LAN communication protocols into two-layers:45

A two-layer structure is a very natural one for low-level protocols in a local area network. The bottom layer should provide the basic function of delivering an addressed message to its (one of many) destinations. This level corresponds to the concept of a datagram network… Above this first layer should be made available a variety of protocols. One protocol should support a virtual circuit mechanism, since a virtual circuit is definitely the appropriate model for a great deal of the communication that will go on in any network, local or otherwise.

By 1978, it had become clear that TCP Version 2 had to be changed to accommodate all kinds of network interconnections and work to split it into two layers, network and transport, began.46 (See Exhibit 6.3 TCP to TCP/IP.) TCP/IP was first known as TCP Version 4.

Exhibit 6.3 TCP to TCP/IP

diagram of TCP to TCP/IP

The new network layer protocols, also to be known as internet protocols (from interconnected networks), enabled seamless interconnection of networks without impacting the internal operations of any network.47 Jon Postel describes the internet layer protocol or IP protocol:48

In summary, the ARPA Internet Protocol (TCP/IP) supports delivery of datagrams from an internet source to a single internet destination. IP treats each datagram as an independent entity unrelated to any other datagram. There are not connections or logical circuits (virtual or otherwise). There are no acknowledgments either end-to-end or hop-to-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is minimal flow control. For flexibility, it is explicitly left to higher level protocols to provide these functions.48

Gateways, specialized computers used to interconnect networks, routed traffic over the networks using the internet protocols49 (See Exhibit 6.3.1 TCP/IP Transmission Model.) The separation of the network functions from TCP then enabled the creation of different transport layer protocols including a reliable end-to-end service, such as virtual circuits (TCP).

Exhibit 6.3.1 TCP/IP Transmission Model

diagram of TCP/IP Transmission Model

In 1979, DARPA decided to emphasize the use of DEC’s new VAX series computers. Since DEC had already decided to use Etherent to interconnect their VAX computers and their peripherals, having TCP/IP operate over Etherent became essential. Only there was first the problem of what operating system to use. Kahn explains:

We came to the conclusion in 1979, with a lot of input from the community, I might add, that what we really ought to do was go with the VAX, since it was the only appropriate machine around. Unfortunately, they weren’t very happy with VMS or UNIX.

So DARPA awarded a contract to the University of California at Berkeley to take the UNIX system, put it on the VAX, and add all these other features, which Bill Joy did. DARPA awarded a contract to BBN to convert TCP/IP to UNIX. Joy was to then take the BBN port of TCP/IP and integrate it with the UNIX port to the VAX.

The need to separate the network and transport layers made so obvious by LANs also affected protocol development efforts in Europe. That story begins in 1975, when IFIP Working Group 6.1 switched its institutional affiliation to ISO.

  • [44]
    :

    Clark, who had received his PhD in 1973 from MIT with a thesis of pulling the I/O system out of the kernel of the Multixs operating system, realized afterwards that he had not solved the problems for multiplexing devices such as networks, and stayed on at LCS as a post-Doctoral to connect a Multixs computer to the ARPANET.

  • [45]
    :

    An Introduction to Local Area Networks, IEEE, p. 1512

  • [46]
    :

    Cerf adds: “ Danny Cohen at ISI who developed two versions of Network Voice Protocol deserves credit also for influencing the separation of IP from TCP.”

  • [47]
    :

    At first, interconnected networks were called Catenets in TCP/IP.

  • [48]
    :

    Jon Postel, et al. (citation needed)

  • [49]
    :

    Postel et al: “In summary, the ARPA Internet Protocol (TCP/IP) supports delivery of datagrams from an internet source to a single internet destination. IP treats each datagram as an independent entity unrelated to any other datagram. There are not connections or logical circuits (virtual or otherwise). There are no acknowledgments either end-to-end or hop-to-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is minimal flow control. For flexibility, it is explicitly left to higher level protocols to provide these functions.”

×