How the Bell System Missed the Internet 2
“ARPANet and Scaleability”
Today the ubiquitous Internet is taken for granted as being obvious and necessary. But in the 1970s things were different.
There were a multitude of competing networks. Tymnet, Telenet, and Compuserve all offered nationwide networking. Later, Canadian Datapac a plethora of other systems existed.
ARPANet was not widely used. For one thing, it just didn’t scale up in size. For another, it was a military project and so information was not openly shared. In the mid 1970s it was uselessly small, with only a few dozen computers attached to it. It used active processing to switch packets and so it was horribly non-cost effective.
The Bell System was prohibited from acquiring companies from several of the settlements it had reached with the US government. So acquiring Tymnet or Telenet was not really an option.
The basic problem with all of the existing solutions was that Bell understood the explosive nature of data. None of the existing solutions could grow to handling 10-million data connections or more. Nothing could scale to 1/1000 of that size. And, eventually Bell knew that more than 10-Million connections would be required.
A Bell System delegation did go up to meet with BBN, the prime contractor for ARPANet. But BBN was not thrilled with the Bell System’s needs. Bell wanted a massively scaled system, they needed it in just a few years, and they wanted to manufacture it through their Western Electric division. Also, Bell wanted control over the software. BBN was, to be quite honest, fat and happy feeding on the teat of military contracts. They had little need to move quickly, no pressure to scale things up quickly, and they were not receptive to any design changes contrary to what the military wanted.
One of the key pieces of functionality of the Bell System ACS was a seemless way to migrate traffic off the PSTN public network. And, BBN was utterly disinterested in this.
Billy Oliver knew that there was a chicken-and-egg problem with a new data network. So an elegant way was needed to migrate customers to the data network. ACS was elegant.
Internally, ACS would packet switch data within its nodes and between notes. This would achieve the efficiencies of circuit utilization that packet switching offered. On the periphery there would be banks of modems. And, every termination on the ACS network would have a conventional phone number. That phone number would have area codes, central office codes and subscriber numbers in the NPA-NNX-XXXX format of the existing PSTN. (We would break the pattern by using area codes ending in 0 to overlay existing areas. Chicago was assigned ACS Area Code 310 because it was similar to 312.)
If a customer with an analog modem needed to call an ACS subscriber they would dial the ACS subscriber’s phone number and would be routed to a modem in a pool. The data would then be packetized and be sent over the packet network through ACS. If an ACS subscriber needed to call somebody on the analog side then they would connect to the POTS phone number and data would be packet switched to the periphery of the ACS system and then hop off via a modem to connect to the subscriber. It was believed that businesses and heavy data users would quickly choose to connect with digital subscriber lines to the ACS system and data would shift over to ACS.
The problem was scalability. No existing system could scale.
In looking back, people see the ARPANet as the obvious evolutionary choice for the internet. But in the 1970s it was not. ARPANet was closely controlled by BBN, a military contractor. And, ARPANet required hugely expensive IMP processors that has very limited capacity. The ARPANet served just dozens of computers and was nothing of the size that the Bell System envisioned. Worse, addressing was fixed and inflexible rather than being logical routing. An address specified a specific termination on a specific piece of hardware…moving a customer to a replacement piece of hardware meant changing their “phone number” under the ARPANet system. But mostly, there was no way to cost effectively scale ARPANet up to millions of subscribers.
By far, the biggest obstacle with ARPANet was that Bell wanted to seamlessly integrate their data network into the PSTN infrastructure. Even little things like the need to run the network off 48 Volt battery plant became an issue. The BBN engineers were disinterested in accommodating Bell, to put it politely.
Meanwhile, AT&T made the decision to build their own data network using in-house development and in-house technology. It was a reasonable decision. By the mid 1970s Western Electric was manufacturing its own computers (The 3B20) and memory chips. It knew how to build robust central offices.
The Holmdel Bell Labs was instructed to tap into the best and brightest and was almost given an unlimited budget. Above all else, development needed to be accelerated. The need for a data network was most urgent….
I remember our teams working on ACS when I was with Cincinnati Bell. It had such promise at the time but never really came to be.