To reviewers: Please try to think of other contributors. When did Joe Rinde come? Art Caise? What other dates can you reconstruct?

The Origins of Tymnet

Here is a rather detailed description of Tymnet.

Tymshare began operations in 1966 providing timesharing service on the SDS 940. The machine came from Scientific Data Systems with “CTE equipment” that attached about 16 terminals or modems, each with an RS232 voltage mode plug. Until recently modems had the same shape plug. The only practical terminal then was the model 33 Teletype from Teletype corporation, a subsidiary of AT&T. It ran at 110 baud yielding 10 characters per second. It was upper case only, heavy and noisy. It was also cheap and reliable.

During the first year or so customers dealt with the phone company to reach our computer center in Palo Alto, California. Most were in toll free calling radius. We soon established another computer center near Los Angeles and developed a largely disjoint set of customers there. We planned further expansion.

There were frequency division multiplexers on the market that would handle about 16 Teletype circuits over one voice grade line. Each user was assigned a frequency and full duplex leased voice lines would connect the multiplexers. We tried these but they were expensive and error prone. Mini computers, costing several thousand dollars, were then becoming available and it seemed clear that they could do a variety of communication tricks which would soon pay their way in saving communications costs. Laroy Tymes joined Tymshare in 1968 from Lawrence Livermore labs to help us in this adventure. Howard Steadman, already at Tymshare, dealt in hardware and encouraged us to suggest innovative solutions to interfacing with modems. Dave Schmidt was vice president of Tymshare and understood the technical and economic advantages to Tymshare of these schemes. Laroy wrote almost all of the early Tymnet code. He and I did the design.

At that time the phone company (AT&T) was considered a natural monopoly. They held that modems were the sole province of the telco. Tymshare had already produced acoustic couplers that competed with the telco’s 103A data sets (data set = modem), but AT&T’s lawyers were busy fighting what they considered to be more serious encroachments on their turf.

Initially we found a strange little computer called the SPC12. It had 4K of 12 bit words. Most significantly it had parallel input and output, 12 bits wide, that could be interfaced with modems with simple voltage converters. The software would prepare and time the signals and there was no hardware devoted to timing the bits for each communications line. Precursors to this plan had been done at Livermore and in military applications before that.

The first deployment used the SPC12 as a fixed time division multiplexor, providing full duplex service for 29 terminals, each running at 110 baud. Pairs of such multiplexers were connected with a voice grade line, leased from AT&T, and two AT&T 201 data sets at 2400 bits/sec. There was no error control. These were deployed for a short while. We found the SCP12 too small and had located another machine, a Varian Data Machines model that used 16 bit words, and which could be expanded beyond 4K words. This machine, and its direct descendants, served as the Tymnet workhorse for the next several years. Howard Steadman equipped the machine with parallel I/O like the SPC12. We programmed this machine to do statistical multiplexing which took advantage of the fact that not all lines ran continuously. This allowed more users per leased line. We added backward error control on the multiplexed lines.

With this phase of Tymnet (not yet so named, however) pairs of nodes would be connected by a leased line. One node, the base, would sit next to the host computer, connected thereto by many cables. This still required the CTE equipment. The other node would typically sit in some Tymshare sales office. That office could access only that one host computer.

Remote Echoing

This software statistical multiplexing was deployed from Palo Alto to Los Angeles. Very quickly it became apparent that the variable echo delays were very disturbing since the sound of the Teletype’s printer was the visceral signal that one had indeed pressed a key. While people were delighted that the most transmission errors had been eliminated, they found it difficult to type accurately.

We had anticipated that this might be a problem and already had a plan. The plan was difficult enough that we had not coded it before first deployment. We went all-out to code remote echoing.

The plan was to usually echo characters at the node (multiplexor) nearest the Teletype. The 940 system was prone to situations where the echoed character came from the application program and not the operating system—the application could request that characters not be echoed. The logical way of handling all of this is for the operating system to cease echoing characters until the application has had a chance to say “don’t echo” in response to the characters that have arrived but it has not had a chance to interpret. With this plan, however, people found it disconcerting that echoes would cease after each line when they already knew that more input would be read by the application. In these common situations the user would already type the next input, and want it to be immediately echoed. If one wanted echoing to be properly inhibited, he would have to wait until the application had reached the point of canceling OS generated echoes. The additional latency exacerbated this problem! [This stuff should go elsewhere.]

Several developments then began. We began to modify the 940 operating system to supplant most of the function of the local node, thus avoiding work both in the host and in the node. With this change the CTE equipment was retired and one cable connected the host to the base. We also began to introduce forwarding logic in the nodes so that traffic could travel thru several nodes, each hop via another leased line. This required routing which was provided by static routing tables. A dial-up access port would reach the same host for weeks at a time, but at least we had much greater flexibility in allocating ports to hosts. Sales spent many painful meetings devoted to this allocation.

We had been thinking about dynamic routing tables to be built as new users logged in. We had no computer with enough power to do this in a brute force way. We could have put it on a Varian machine but that lacked sufficient core. We chose to program it for the 940 with a slightly modified version of the operating system. Laroy wrote that program using algorithms to dynamically sense the network topology. That first “Supervisor” knew several versions of the node software and the sizes and absolute addresses of routing tables in each of those versions. The supervisor would send out “data-grams” to cause the distributed nodes to change their routing tables. Several 940s (at least two) would simultaneously host supervisors who would politely agree among themselves which was to supervise the network. If such a supervisor or its host crashed, another supervisor would notice, discover the current net topology and assert control. This might take a few minutes, during which current sessions were unaffected but new users could not log in. Most days went by without such disturbances.

One day in a marketing meeting, Virgil Swearingen suggested the name “Tymnet.”   Few liked the name but it was clear that it was the best that had yet been suggested. It improved with time.

That was Tymnet I. It is described here too fairly well.

Tymnet II

The PDP-10 was arriving and it too was adapted by Bill Weiher to Tymnet so as to avoid the expensive “per-user” communications equipment from DEC.

Any programmer will tell you that one program knowing addresses in another is a very bad idea. It worked pretty well but did limit architectural progress. Laroy broached the idea that the supervisor would merely construct a needle which would pass thru the net guiding the creation of a new circuit. The needle would carry a 4 bit nibble, for each node, to steer the needle as it passed that node during the circuit construction. The supervisor would still need to know the network topology and how each node numbered each link. It would also know the node and link loads. It would no longer need to model the routing tables in each node. Routing table entries would be allocated locally. 25 years later this pattern became the main notion behind MPLS routing. The cost of core memory for nodes had come down and the new node code was larger but more modular and efficient. At this time nodes typically had 8K or 12K of 16 bit words. A few had 16K.

One particularly nasty bug would strike the New Orleans node. Usually node bugs would have the civility to strike first, or eventually, near Cupertino. We loaded an extra core bank with the code for New Orleans and mailed it there in a shoe box. Upon the next crash they swapped core and mailed the core module with the crash state back to Cupertino. We found the bug.

When we opened the Paris office with its own 940 computer, there was consternation over the idea that the European network would be managed from the states. This consternation was largely overcome by rewriting a few manuals to describe the operation differently. The Paris 940 ran a supervisor so that when the trans-Atlantic link was out they would still be in service. Once when all of the American supervisors had gone down, (a very rare occurrence) the Paris node tried to take over the American network via a 2400 bit/sec link. It failed for by that time 2400 bit/sec did not suffice to control even a night load in the states.

Tymnet Service

Our timesharing computers attracted business now by those who found it convenient that their program and its data were accessible at a large number of geographical sites. Some customers, however, found our timesharing computers inadequate to their tasks, even with special pricing. There was increasing call, inside Tymshare and out, to make Tymnet serve hosts other than our own. We gradually did this. This required a considerable programming staff to work with owners of diverse hosts to connect those hosts to Tymnet. Many techniques were used.

This new business was easy to start because the simplest host interface mechanism was the early cable per connection configuration that required no changes to the host; just power, floor space and termination of a leased line to our site. The prospective customer had very little up-front cost to impede him. After the first day his computer would be accessible by a variety of terminal types from a variety of US cities and even several foreign countries. Here is a memento from the NLM, and some perspective from our first customer. Also see a contemporary directory of institutions with computers connected to Tymnet.

All through this development new varieties of terminals were coming to market. They came with higher baud rates and peculiar timing requirements. We would teach Tymnet about these new terminals and the node near the terminal would take care of the peculiarities. Other users of these terminals would have to adapt their host software to accommodate these strange timing requirements. It gradually dawned on us that the adaptation of various hosts to various terminals was a strategic marketing advantage.

With the advent of Tymnet service the division began to become a company in its own right. After McDonnell Douglas bought Tymshare, and then sold it to EDS, Tymnet was sold to MCI or British Telecom who were busy merging. It is still running today. At its peak there were 6600 nodes in Tymnet, at nearly as many locations.

P.S. Don Johnson has been connected with Tymnet for many years. On Monday, March 24, 2003 he said:

We shut down Tymnet this morning at 11:48 AM PST this morning.

Some notes on internal stream formats and link formatting.
The book “Computer-Communication Network Design and Analysis” by Mischa Schwartz has a great deal more technical information on Tymnet and other networks of the 70’s.
Recent Tymnet information and good links.
Tymnet Today
Tymnet II recollection
Some more recent history