0:12
Packet switching was an idea which was specifically
studied by Len Kleinrock in MIT who is actually looking at message switching.
And he did a brilliant dissertation on the use of queuing theory to
analyze what networks of queues would look like using this message switching approach.
And his analysis although he never used the word packet,
is equally applicable to packet switching as it is to message switching.
So, that's one important milestone in around 1961.
In 62 or thereabouts,
Paul Baran is doing work for the RAND Corporation and he's deeply concerned
about the ability to preserve command and control in a post-nuclear environment.
We were seriously worried that the Russians would actually launch
and that we would suffer a nuclear attack and then we had to be able to respond.
And we needed command or control for that.
So, Paul in 1962,
before the existence of integrated circuits,
or anything else, is saying,
"We really should be digitizing and packetizing voice.
And then using sort of the pole-mounted radios
that are able to transmit in all directions,
to create a highly connected environment.
So that if poles were knocked down a bit by nuclear explosions,
you would still if it's a fabric that's in any way connected,
information could get from one end to the other."
So, he envisioned the notion of a message block.
And it was dynamically routed and he used hot-potato routing.
If he got something he got rid of it as fast as he could.
He chopped up the speech into little 20 millisecond pieces.
He didn't talk so much about data as I remember it.
And this was supposed to be a highly resilient voice network for command and control.
I may have just done him a disservice because, later,
he was very much conscious of the importance of data communication too.
So, that's around 1962.
It gets documented in an 11 volume series called Non Distributed Communications.
And he can't sell it to anybody.
The traditional telcos, AT&T in particular,
and the people that was in the Defense Communication System,
Defense Communications Agency, laughed him out of the room,
and said, "This was a silly idea.
It couldn't possibly work and so you should just go away."
So, he never got anywhere with that in spite of all the documentation.
In '66, Larry Roberts along with one other guys whose name I'm now not remembering,
does a point to point experiment to test packet switching.
It was between the NSFQ-7 machine at the System Development Corporation in
Santa Monica and the TX-2 machine at MIT in Lincoln laboratory where Larry was.
They demonstrated on a 2400
bits-per-second line that you could move packets back and forth.
Then in the '64, '65 time frame,
a man named Donald W. Davies of
the National Physical Laboratory in London also gets the bug,
tries to get money from
the Science Research Commission in England and gets only enough to build one node,
you know, the one node network.
So, he builds this packet net,
he invents the term packet to describe what these objects are.
And it works. He's got a bunch of, you know,
terminals and other things hanging off of this one node.
So, in a funny way,
he build a local area network, if you like.
But it was based on physical wires.
So. Those three guys introduced packet switching.
Larry and whoever it was that he worked with,
demonstrate that it's possible to get
two very distinct kinds of computers to talk to each other using the standard way.
J. C. R. Licklider is a psychologist actually at MIT,
but he's convinced, in the early '60s,
that computing is important to non-numeric processing.
That it will allow people to work
together and collaborate in ways that they never could before.
He comes and starts
the information processing techniques office at ARPA with this being his moment.
And who does he encounter?
He encounters Douglas Engelbart at SRI International.
And the two bond basically because Engelbart was all about non-numeric computing and
the ability of people to build up
the superstructure of communications and documents interact with each other,
hyperlinking, the mouse, the portrait mode display,
black and white presentations.
I mean the guy had a World Wide Web in a box at SRI.
And Licklider understands that.
Licklider is sending out notes to his little community
of people talking about the intergalactic network,
a mini time sheet.
So, he really gets credit for having put this mean in place at ARPA.
Then Taylor comes along to pick up
the responsibility for running the IPTO from Licklider.
And it's all hacked off because he's got three terminals in
his office at the Pentagon connected to three different machines.
And he can't figure, he says,
"Why can't there be one terminal talking to all three?
We need a network."
And so as he's pursuing this idea with Charlie Hertzfeld,
he's the head of ARPA at the time,
Charlie hands him a million bucks over
a 20 minute conversation and now Taylor's got the problem,
"Who's going to actually do this?"
Because Taylor is not a technologist either,
he's been another kind of psychologists type.
So he decides to get Larry Roberts from Lincoln Laboratories who did that packet thing.
And Larry doesn't want to come.
So he goes and complains about this to Charlie Hertzfeld.
Charlie calls up the guy that runs Lincoln laboratories and says,
"We pay for a significant fraction of your research budget every year.
You should tell Larry he should show up."
And in fact, I thought that maybe Larry had been forced to do this by Charlie.
I think it was probably a little less awful than that.
But Larry was persuaded to come down,
eventually of course inherited the operation of the office from Bob Taylor.
But in the meantime he's the guy responsible for doing the,
initiating the Internet or the ARPA NET project.
So, they write an RFC,
an RFQ, requests for quotation.
A bunch of responses come back probably on the order of a couple dozen.
I don't know personally for sure how many.
I know that I wrote one of them with my colleague Steve Crocker while we were
still at UCLA as graduate students but we were consulting with
a company called Jacoby Systems in Santa Monica.
Jacoby Systems wrote one of the responses.
Colburn and Newman wrote another response primarily written
by Bob Kahn who came to BBNN from MIT.
So, the responses come back and they get evaluated and four of them end
up and the Jacoby Systems isn't one of them or if it was it didn't get selected.
BBNN got selected.
So, Steve Crocker and I and kind of hike back to UCLA as graduate students.
And the next thing we know Len Kleinrock who's at
UCLA and who had written this original dissertation work and packet switching,
has come to UCLA to teach and explore queuing theory,
is of course compatriot of Larry Roberts because they were both in Lincoln Labs together.
So, he gets the network measurement center piece of the ARPA NET project.
And Steve Crocker and I and John Postel,
all of us from the same high school in San Fernando Valley,
end up in Len Kleinrock operation running the network management center.
So, I was the principal programmer for that.
Steve Crocker took the responsibility for
managing and leading the network working group that led to the protocols,
host to host protocols.
And John Postel eventually becomes the keeper of the documentation.
He's the RFC editor which Steve Crocker started requests for comments.
He's the guy that becomes the numbers czar and which is keeping
track of address spaces and applications,
and eventually becomes the domain name manager
of the Internet assign numbers authority when the Internet happens.
That hasn't happened yet. This period of time of
the ARPA NET program brings us up to 1972.
And this is an important moment in this whole history
because the first demonstration of the ARPA NET
happens in the Washington Hilton Hotel basement in October '72.
A whole bunch of people from the interested networking community,
packet switching community attend.
Not only in the US,
but from France and from England and Italy and Germany and elsewhere.
That group of about 25 or 30 people convenes,
sees the Arpanet in operation sees applications that were being done,
including Doug Engelbart staff.
And then forms this international network working group,
modeled after the working group that Steve Crocker managed to build the ARPANET system.
And at this point I become the chairman of that group,
because Steve is busy at ARPA doing artificial intelligence.
At the end of that year Bob Kahn leaves Bolt Beranek and Newman,
and goes to ARPA.
I leave UCLA where I'd been working with Kleinrock,
and Crocker, and Pastel and they go to Stanford.
So Bob is at ARPA.
I'm at Stanford.
And in the spring of 73 Bob comes out from ARPA and he says, "I have a problem. "
He says, "What's your problem? " He says,
"Well we got this Arpanet. " I said, "Yup."
"But, we also are working on other networking capability,
to make command and control work for the military."
If you're going to be serious about putting computers in command and control,
they have to be mobile.
They have to be in armored personnel vehicles and tanks, and all these other things.
They have to be seaborne,
so we can have ship to ship and ship to shore communications. Which means satellite.
So we need more radio,
we need satellite in addition to
the fixed wire systems that are represented by the ARPANET.
We have fixed installations that are not moving around.
So, you have all these different technologies,
and Bob's Brilliant idea is not
to build one network with all those technologies embedded in it.
Instead he breaks them apart and says,
let's build the packet satellite network which optimizes the use of satellite,
takes into account that it's got a half a second round trip time.
Let's build a packet radio network,
which optimizes a system whose connectivity is changing with time as things move around.
And if you get variable delay and also variable interference.
So, these were three different packet networks.
Then the problem is how do you hoop thing together.
You wouldn't have this problem if you put all the technologies into one net.
But if you put them all into one net,
it makes it really hard to do control over all these highly variable parameters.
So, instead he says break them into different networks and connect those together.
So, we design and build a gateway which today we call a router.
And that concept also introduced a whole bunch of other things like,
"How do you refer to another network?"
Each network thinks it's the only network in the universe.
This is true of the proprietary networks like SNA,
and DECnet, and so on.
And you didn't have a vocabulary to say take this packet,
and move it to another computer on another network somewhere else,
that you might not even be connected to.
So, we have to invent an internet address space in order to solve that problem.
We have to find a way to allow packet losses in this path to be recovered,
which is where TCP now becomes a manager of reliability on an end to end basis,
instead of relying on each net to be reliable.
The ARPANET was built on the assumption you could build a reliable underline net.
The internet was based on the assumption that no network was necessarily reliable,
and you had to do end to end retransmissions to recover.
So, during this 1973 period Bob and I get
the first paper written and published in
IEEE transactions on communications, May of 1974.
And I think mostly nobody paid too much attention to it.
Meanwhile ARPA is funding us to go make this actually work at Stanford.
I am working with my graduate students some who are in Xerox part,
some are at Stanford,
on this detailed specifications of TCP/IP.
We publish that in December of 1974,
and it's the first time the word internet shows up in print anywhere.
Is the first papers we talked about internetworking.
So, internet shows up in a complete spec in December 74,
and it's also got bugs.
But we don't know that yet, until we started implementing
it 1975 with two other organizations.
So, Bob Kahn says,
"You can't have just one implementation."
Bolt, Beranek and Newman becomes one of the implementers.
University College of London and Peter Kirstein
group in England is the second or third implementation.
So, we have three implementations of TCP/IP.
In fact by this time it's only TCP.
We haven't broken off the IP part.
Three implementations are going.
We instantly find problems with the design, and we start evolving.
So, over a period from 1973 to 1978 we go through four iterations of the design,
and implementation, and test until we have a very stable thing.
And then we standardize.
And so, 78 we fix everything.
It's now by this time the internet protocols was split off,
because people like David Reid and Danny Cohen are saying,
"We need to have real time communications that is not necessarily reliable,
but which is latency."
So, voice communications, radar tracks, and all that.
You don't care where the missile was two seconds ago,
you want to know where is it now.
So, and in the case of voice if you lose
a packet you just say say that again I missed them.
So, we split TCP into TCP and IP.
And we created something called user datagram protocol,
which is parallel to TCP,
and it is the real time low latency version of the reliable TCP.
All of those little components IP, TCP,
and UDP now go into
the Internet architecture starting in 1978, and we started implementing.
For the next five years,
we do everything we can to get TCP/IP implemented on every operating system we can find.
It goes onto the IBM machines,
it goes under the digital machines,
HP, goes in the Unix.
We have a Unix version built by Bolt, Beranek and Newman,
we send it out to Berkeley to
the Berkeley BSD release guys and Bill Joy says, "I don't like that code."
He writes his own,
puts it into BSD 4.2.
And that's the version of Unix that carries a lot of TCP/IP to the academic world,
because at the same sort of time frame,
some Microsystems comes along and builds these fantastic workstations.
And they want this open source,
or at least open protocols,
and open operating systems,
so they adopt Unix and the TCP/IP comes with it,
and they use ethernet as a way of connecting the workstations together.
So, they are the engine that's driving
the academic community which are all
gangbusters for workstations and high speed local networking.
So, all of these course places huge demands on the ARPANET backbone,
which is only running at 50 kilobits a second,
and it eventually leads to the need for higher speed.
NSF jumps into the fray,
seeing how valuable all of this is for the academic community,
and concludes that each build a network that runs even faster.
And it does so, and it's called NSFNET.