LEN KLEINROCK on the Origins of the Internet: "This is login"

Petrie: So he was not only very good at motivating government and industry to fund this project, but he's also knowledgeable?

Kleinrock: More than that. First off, he's one of the smartest guys I know — he's a brilliant, brilliant engineer. I mean he was not an administrator, he was an engineer. He got his hands very dirty. He was there all the time. He was designing topologies, you know, he's an engineer's engineer. Very smart guy.

Another name that's important is Robert Kahn. He was at BBN in those early days. He was on their side implementing the algorithms and adding his own inventiveness to the algorithms. He did a good job. Bob is a very innovative guy. Then he moved; he replaced Larry at ARPA when Larry went on to become the first president of Telenet. And he continued many of the programs Larry began, such as the packet radio and packet satellite stuff. And now he's heading up CNRI.

Okay, so the IMP was supposed to arrive on the Labor Day weekend, September 1969. And we were late in our preparations for its arrival. We knew they were also late at BBN, and were thrilled since we could really use the time. And it was going to take them two weeks to ship it out, thank God. Except they decided to air freight it. [laughter] And it arrived on the Labor Day weekend. Monday was Labor Day, and Tuesday, the big event. The IMP arrived, we were going to connect the first machine, the first IMP. So everybody and his brother was there. UCLA Computer Science department was there. My guys were there. ARPA was there. Honeywell was there. BBN was there. AT&T long lines was there. UCLA School of Engineering was there. The administration, GTE. Everyone was there, ready to point the finger if it didn't work. [laughter] But it worked. We had bits moving the first day. We had messages working the second day. It worked like a charm. Like a charm! It was unbelievable.

Petrie: You were sending e-mail?

Kleinrock: No, we were sending and watching bits and messages, there was no content to speak of because this was not host to host. This was host to IMP.

Petrie: What do you say to an IMP?

Kleinrock: You just send a message, you know, is it correct? Any bits in error? And if it gives you acknowledgment, then the message got there. You know, it was being packetized and all of that.

A month later SRI [Stanford Research Institute] got their IMP and connected their host computer as well. It was a DEC PDP machine I believe. Now there were two hosts. So one evening shortly after they were connected, Charley Kline and I got together and arranged with a fellow up at SRI to be prepared to receive a message. As it turns out, along with the digital line you could basically take off an audio line, a voice line, as well. So we could talk to our SRI collaborator as well as send to him.

And send we did. The idea was to login to the SRI machine from UCLA; this required that we type in LOGIN. Now the PDP machine was one of these systems that had a character-oriented command language. With such systems, you would type in a few characters. And once the string is unique, it would fill out the rest of the command. So if you were typing in the word "login," and once you typed the L-O-G, it filled in the I-N.

So, Charley typed the L, and he said "Did you get the L?" "Yes, I got the L" came back the reply from SRI. "Did you get the O?" "Yes, I got the O." "Did you get the G?" Crash!

A few hours later we got it running. This is not "What hath God wrought?" This is login. And we didn't even have a camera to record the event. Following that, the network grew. We paused after the first four nodes to test our little network We were testing things like alternate routing, for example.

Petrie: But that first crash, that was because the DEC machine wasn't complete?

Kleinrock: We don't know what happened. Somewhere in the protocol some funny thing happened, a line error? The other interesting story is that one machine was talking ASCII, the other was talking EBCDIC, and Charley had to map the character codes in his head. He happened to know both. He had to go from one and convert it to the other, God bless him. [laughter] You know, these are the things that made it human. So then we paused, we tested, we started doing our measurements, and then by summer of 1970, we had 10 nodes and we spanned the country. And it just grew.

And at my Network Measurement Center, we could crash the network at will.

Petrie: How?

Kleinrock: We would stress it. The point is that the software, the flow control software, was written in ad hoc fashion spread all over the place. And then you add something here and you don't know what the effect there is going to be. I'll give you one example, a very simple one. This is a trivial thing. So much memory was put aside for reassembling packets back into messages. And what's the maximum number of messages you might be reassembling at the same time? Well, the smallest thing you can reassemble is a two-packet message. With a one-packet message, there's nothing to reassemble. Take the number of packets, divide by two; that's the maximum number you can be reassembling simultaneously. Good. Assign that many pointers, whatever the number is.

But one day they found out 16K was too small, so they added 16K more. Now you have much more memory for reassembly, but they forgot to increase the number of pointers. Natural, easy mistake, right? So when memory got full, you couldn't point to it. You'd allocate it, stick it in, and you couldn't find a pointer. Crash! Simple thing. And the reason we discovered that is because our measurement messages were two packets long. And we generated a lot of traffic from all over the network which was designed to back to UCLA. BBN called up and said we crashed the network. What you mean? we said, we're taking measurements. So they restarted, and it crashed it again. And then we finally told them what it was.

« Previous   |   Next »