How the Internet Came to Be - Page 3

Around Labor Day in 1969, BBN delivered an Interface Message Processor (IMP) to UCLA that was based on a Honeywell DDP 516, and when they turned it on, it just started running. It was hooked by 50 Kbps circuits to two other sites (SRI and UCSB) in the four-node network: UCLA, Stanford Research Institute (SRI), UC Santa Barbara (UCSB), and the University of Utah in Salt Lake City.

We used that network as our first target for studies of network congestion. It was shortly after that I met the person who had done a great deal of the architecture: Robert Kahn, who was at BBN, having gone there from MIT. Bob came out to UCLA to kick the tires of the system in the long haul environment, and we struck up a very productive collaboration. He would ask for software to do something, I would program it overnight, and we would do the tests.

One of the many interesting things about the ARPANET packet switches is that they were heavily instrumented in software, and additional programs could be installed remotely from BBN for targeted data sampling. Just as you use trigger signals with oscilloscopes, the IMPs could trigger collection of data if you got into a certain state. You could mark packets and when they went through an IMP that was programmed appropriately, the data would go to the Network Measurement Center.

There were many times when we would crash the network trying to stress it, where it exhibited behavior that Bob Kahn had expected, but that others didn't think could happen. One such behavior was reassembly lock-up. Unless you were careful about how you allocated memory, you could have a bunch of partially assembled messages but no room left to reassemble them, in which case it locked up. People didn't believe it could happen statistically, but it did. There were a bunch of cases like that.

<- Previous | Next ->