Hello, and welcome back. I just wanted to give you sort of a sense
of the actual physical experience of connecting and communicating and computing
in the 60's and the 70's. The 70's was when I got my start and the
lucky people go to use teletype, like was being used in that video, and other people
used punch cards. You also heard the squealing sound of the
data being converted into sound and back and forth.
You know it's the key goal was there would be, if you were lucky, one computer within
a 20 mile radius of where you were sitting so you could use a local phone call and
you could be on all day and do things all day long and that was really exciting and
a lot of fun. And this was sort of a, a common if you
were sort of, you know, today you have a $2,000 laptop, the fancy people had these
teletypes right in their office because then they could conveniently sort of do
computation and, and not have to go somewhere to do that computation.
So that's pretty exciting. So dial up was kind of like the way the
campus operated. But you could also do data transfer with
leased lines. And the typical thing about lease line is
there the, the phone company is going between 2 cities digs a hole and put a
cable in and has some numbers of copper wires in between those cities.
This is back then of course it's fiber optic now, but back then it was copper.
And every time you would make a call between those 2 cities, it would have to
find a free piece of wire and connect it up so that your call, the audio of your
call would go through that wire. And if you wanted to, you could pay them
to lease one of those pieces of wire. It meant that people couldn't use that
wire for phone calls. So you would sort of take it out of
service. And if they had 500 wires between two
cities and you leased one of them, then they had 499 wires.
And so it was rather expensive. And really very importantly, the cost was
based on distance, right? A mile versus 5 miles, versus 20 miles
versus 100 miles, the cost would go up kind of linear based on distance.
And so that's, that's a key thing that distance is important in these very
limited resource copper wires where you had to dedicate a wire either to a phone
call or to data. And so, we ended up evolving, in the
academic world what we called store and forward networking, with the sole purpose
of compromising everything so that we would keep our cost that we paid for our
phone lines to a minimum. We wanted to communicate in Academia with
people all around the country and all around the world so, we had to keep the
costs low. And so we would lease a lease line, you
know, so, so, so here would be us sitting with terminals in our offices and we would
use dial up to get connected and so this might be a few miles, like 1 to 2 miles,
or, 1 to 2 kilometers. And that's what you had to, you had to
live near a computer or have an office near a computer and then you would use the
local telephone network to dial in to do your work.
And then there would be 1 connection out the back of that computer to another
computer. They would also have users on it and then
other computers with users on it, other computer with users on it.
So this might for example be Michigan, this might be Stanford.
Stanford would have a computer, Michigan will have a computer.
Stanford people will be connected to the Stanford computer.
Stanford will have one little connection on its back end and to the rest of the
world. So you sitting here want to talk to
somebody sitting here, so this is how it worked.
You're sort of always connected so your data would be inside, you know, you type
an email into the computer and then you would say, send that out to my colleague
at Stanford, and so the problem is everyone else was sending and so let's say
for example that somebody send it pretty big thing.
Big purple circle is what they're sending, and then somebody next to you an office
down sends a kind of medium size orange circle and there sitting there being
stored in local computer and then you finally, finally finished typing your
email messages and its kind of a small green circle.
And now, the problem is, is you're in a line.
The way this worked is the software would keep a queue or a line of those who were
going to use the, the line and then, it would sort of start streaming this stuff
out. And once it started, it just kept doing
the same file, over and over and over. Now if it died, it would just start from
the beginning again. And so, it takes some time for that thing
to move across the network. And that would move across the network,
the next message in line would start to be sent across the network.
And it would use that link come on, finish up, there we go.
Okay. It takes a while for these things to move
across the link. And then finally, and this could be ten
minutes later, finally it was your turn. And your stuff would work its way through
the network, and get to the next computer. The problem is, is once it's in that
computer, you face the same problem, because if all these messages are going
from Michigan oop, forgot to hit the button thing from Michigan to Stanford and
they are on the way, they got to go through all these linked, because it
wasn't a direct connection because the direct connection to Stanford would be
very expensive and so you're in, whereas you find yourself in a situation where it
your stored, you sat on these computers. And if there was an outage of a network,
or say this one, this might be hours. You might be sitting on this computer for
hours, on their disk drive, right? Not even in their memory, you would be
sitting on their disk drive for an hour, and then finally this would come back or
maybe this computer was down. They would come back up and then the data
would start flowing again. So it was our pass word, I keeping telling
you, it was awesome, it was just slow, it was awesome but slow.
So don't, don't, don't feel sorry for us, we loved it, we enjoyed it, it was great
talking to colleagues all over the world. So we ended up with the network
architecture that encouraged more hops, which means it encouraged more latency.
It encouraged the likelihood of getting stuck behind something large as it worked
its way through the network. So, for example, we were going to send a
message from East Lansing to say, the East Coast somewhere, and we would have two
connections maybe. We would have a connection between
Michigan State University in East Lansing and Anne Arbor, and then we'd have a, the
data would get stored and forwarded in Anne Arbor and then it would get further
sent to Cleveland. And i-, if you think about it, the, the
wire between Anne Arbor and Cleveland goes like this.
Right, they probably buried wires under the ground, and if we could actually
convince Toledo the cost of the big wire versus the cost of the 2 shorter wires,
the cost of the 2 shorter wires is almost exactly the cost of the big wire, because
it's not really a big wire. And so if we can convince Toledo to join
our little club, then we don't increase the cost of our communications because
we're, it's about the same right? The, the wire length is about the same but
we've got 1 more school for the same cost. And if you keep doing that and you keep
saying oh, well let's put a school here and put a school here, and put a school
here in the middle of a lake and put a school here, in the middle of a forest.
The economics dro-, said that you could connect more schools with effectively
fixed cost by shortening the distance every time you made a connection.
And sometimes they would sort of make 2 connections.
But the way it often worked was from the perspective of this whole thing is, the
data would sort of tend to go you know, up to some central location and then kind of
fan back out from the central location. And, and so these, it, there wasn't a lot
of redundant links in this whole situation.
So we find ourselves in a situation where we can save more money, saving money by
just simply adding hops. So in this environment we, had a lot of
email. Back in those days we didn't have a lot of
images, computers you know, barely could do upper and lowercase sometimes.
It was impressive when we finally got to upper lowercase, let alone images.
And so for the longest time everything we did was very text Oriented.
Some times, we would send small files like programs to each other, but it was either
text. And these days, those are tiny, it's
almost like SMS, right? It's almost like the size of an SMS
message was the size of a typical mail message back in those days.
Images, we didn't have computers that could even display them and so it hardly
mattered. So, you focused your life on this one
computer within a 20 mile radius and it had this connection to like, a snake-like
connection that sort of went over hill and dale and through somewhere and it finally
got to Stanford or wherever your mail had to go.
But again, it was awesome to be able to sit at a keyboard and talk to people all
over the world, even though it took 4 hours.
We didn't, we didn't send as much email back then and a number of networks came up
one of them that would, became sort of pretty widely used was a thing called
Bitnet, and it was where everything kind of came back to Princeton was one of the
main hubs of Bitnet. And it worked really well, and, and there
was a way to say, oh, I need one more school, and we'd go find the ones that are
closest and we'd make the connection. And so that's pretty much how the average
academic saw networking. One common campus computer and sort of
this weird, slow, store and forward networking that worked well enough.
But during that exact same time, from the 1960's to the 1980's, the US Department of
Defense was investing in a research network called ARPANET.
And ARPANET was funded by the military, the ARPA, Defense Advanced Research
Projects Agency. And when we, and later in the lecture,
we'll meet Vince Serf, who will tell the story much better that I can tell it, but
I'll just tell you a short version right now.
A lot of people wonder why the Department of Defense started this project and a lot
of people say, oh it's because of the fear of nuclear war.
And the project was very long, and there were various motivations throughout the
various phases of the effort. But, if, based on what I've been told and
what I've read, I think it's safe to say that the primary motivation Was to improve
the use of their computing equipment that they were used for military purposes.
Make it easier to access them, make it so people didn't have to travel as much.
Made it so that people could work from their office on many different computers.
And also so that people could actually talk more effectively so they could send
email real fast so that the email would move faster for military people.
So the first thing is really kind of end user focus to make them more useful to
people and get people working together more.
More effectively. That was the first kind of heavy
motivation. The 2nd motivation was, actually had to do
with reliably, reliability and redundancy and resistance to partial failure.
And that really wasn't so much about nuclear attack, that was more about
battlefield attack. So, the notion that once you start having
all these links and you make them wireless, and you put them in trailers on
a battlefield, and, you know, you got a few hundred miles and the data's moving
back and forth. Then we have to worry about, in a
battlefield situation, one of those trailers might get hit.
And how would you keep the network running if one of those trailers got hit?
So, the notion that we have sort of a whole nation and we are worried about
communications I'm sure there was some worry about that, but it wasn't really the
main reason. I, I mean, the, the exciting thing to me
is the mean reason, was a ver-, very people-centered reason, of people working
more effectively. But this was a rather exclusive club.
Ra-, rather exclusive network because it was only for the people who were either
military, or funded to build it. So in 1969 there were four hosts on it.
Again, that's research. And these were lease lines, the same ones
we were all using to do our e-mail, and they were expensive, very expensive.
But, because it was a large grant, they just paid it because the research was not
about the money. The research was if you had these
connections, what would be the best way to use them and how to deal with
redundancies, and how to deal with multiple paths to the same place.
All of that stuff is, is interesting research questions that computer
scientists spent many years conceiving of. And so by 1972, looks like we got about
20. We got a couple of cross-country links and
multiple connections, and, and this looks like a great testbed to see, y'know, so
all of a sudden this part goes down, how quickly can we reroute around the outage.
And literally, these things these days reroute around outages in far less than a
second, and so that's really impressive. Our current internet can ooze its history
to the research that was done in the 1960's and the 1970's, but what was
fundamentally different between the store and forward networks of Bitnet and this
ARPANET research network was the notion of packet switching.
So the, it's a real simple concept. It just takes a little more s, complex
software to solve. The store and forward network would start
the, sending data across the link and then keep sending it until it was done that was
seen to be very efficient. You didn't want to like, you wanted to use
it as fast as you can and then put the next 1 out, and put the next 1 out, and
put the next 1 out. It was really simple and it dealt with
outages in a simple manner by storing them all locally on the disc.
But what if instead, you made it so you broke every message.
Let me see if I can even draw this. I should probably make a slide about this.
So, if there's a network here, and here's her'es my computer and it's got a network
connection, and it's got 1 really big message, broken into pieces Many pieces
and it sends the pieces one at a time. If you show up with a really short message
with only three pieces, all you have to do is wait for 1 piece to go and then your
piece goes in and then you share for a while.
Right you share for a while and then your, have made it through because you only have
3 packets. This has like 1,000 packets, and then once
your message is through, they resume sending this data in order.
And so you were able to sneak and bypass the traffic jam that was This large amount
of data. And so, that's the idea of packets.
And packets are these chunks that say, what we're going to send is a piece, and
then, at the end of that we're going to maybe send a piece of a different message.
It was allowing simultaneously multiple message to be in-flight at the same time,
that's packet switching. And what happened then is we also ended up
with these special purpose computers called routers.
They're still computers, but they weren't doing storing in the same way, they were
just forwarding, they weren't store and forward they were merely forwarding, so
we'll get back to that in a second. So my favorite analogy to talk about how
packets work is postcards. So let's say that I want to send a 30
character message to my friend Daphne at Stanford, but all I have is 10 character
postcards. So, off I go.
I break my message into 3 bits of 10 characters.
I write each piece on a different postcard.
I address with a from and a to address, from Chuck to Daphne, and I give a
sequence number so that when she gets the postcard she knows what order to put them
back together. So I have to label each of these.
And these are fixed width and, fixed length.
They, you know, it's like a packet, right? I'm breaking a long message that might be
very long into, nothing, so that each piece is a certain size so that we can all
share it, right? And so then what I do is I send these, I
put them all in my mailbox. And then I wait and this magical thing
called the post office picks them up, puts them in buildings, people sort them.
They end up on trucks, they end up on planes, on trains, on donkeys, by hand.
And each of my postcards might take a different route.
I mean one of my postcards, I'll show you on a map here, now one of my postcards,
nope not that one, let's do that. One of my postcards, you know, goes from
Michigan to Chicago to Kansas City to San Francisco.
Another of my postcards goes from Michigan, to Chicago, to Dallas, to
Denver, to Kansas City, to Chicago, to San Francisco.
And my third postcard goes really crazy, it goes to Cleveland, then it goes to
Atlanta, then it goes to Washington D.C. And then it goes to Chicago, and then it
goes to Kansas City, and then it makes it to San Francisco.
Now the fact that they took different paths and they might not even arrive in
order, some might get past each other, they might get stuck somewhere.
It doesn't matter, because each one of these has been labelled Both with the from
and the to destination. So each of these intermediate locations
doesn't have to get it to the final destination, they just have to get it
closer. They make choices and even if they make
the wrong choice, it can be sort of dealt with one way or the other, okay?
So, this is some big mystery, it's called the Post Office.
It just takes these little cards and moves them, it doesn't know If that's a Youtuve
video or if it's an email, it doesn't really care, it just has these little
chunks to move around that have from and to addresses.
And that's the essence of the network, the internet, the cloud.
That's why draw this picture, you'll see like, ooh, it's a cloud, and that's
because it's, don't worry about what's inside here, it's all super mysterious and
don't worry about it, it just comes out. So after all that happens, Daphne who
happens to have the exact same mailbox as I do, kind of rare.
We both have a mailbox that's copyright creative comments.
That's what's cool about this mailbox. At some point later these things start
appearing. She goes like, whoa, looks like Chuck is
sending me a note. But because of his limitation of postcards
he's only sent me 1. I know who it's from and I know who it's
to, and I know that's the 1st of some number of messages.
And then the next day out comes another 1, because that was the 1 that sort of, went
the more southerly route. And she goes well I'm missing something,
I'll just sit and wait and see what happens.
And then finally, many, many days later, the, the one that took the circuitous,
cir-, most circuitous more s, most roundabout route.
Comes and now Daphne can reassemble the messages because she has the sequences.
So she simply puts them back together. 1, 2, 3, boom.
So she puts them back together, she has it, she sort of throws the post cards away
and she has The ultimate final message. That's packets.
Packets are breaking a big message into small parts, labeling each 1 of them
individually, and then throwing them into the shared network.
And so this is what it looks like. The post office in this is called a
gateway. Okay.
Come on. Gateway.
Okay. So, that's a gateway.
So, here's Michigan, here's Stanford, Stanford has a gateway too, that's like
their post office. In the middle is the post office box.
Right. And the Post Office box basic, the Post
Office has intermediate locations. And it has trucks and locations.
These are links and routers. And messages can take different paths
This. Right?
And then they arrive and they're reassembled.
And we have, like their ability to hook from home, stuff like that.
So there's a local area network, LAN, LAN and there's this sort of like internet,
the network of networks. It's like the post office.
And it still breaks things into packets, they still come out as packets, and then
Daphne has to reassemble them on her computer to create the message.
So, it, so the research network ARPANET solved a lot of engineering problems, and
that was sort of what they did. So here is an example problem to solve.
Now, none of the mailbox, none of the routers, none of the post office offices,
know exactly where the thing is going. And they don't transport it to the final
destination. All they do is they transport it to the
future to further down destination. But what if they get it wrong?
What if one, this is like Michigan, this is Chicago, this is Dallas.
And what if Michigan thinks sending to Chicago is a good idea?
Chicago thinks sending to Dallas is a good idea.
And then Dallas thinks sending it to Michigan is a good idea.
Well, and Michigan's going to get it again and send it back to Chicago.
And so, then what you end up with is this situation where your packet, your data is
in a loop, right? This wouldn't be good for the post office
and it's not good for the Internet. So, you have to say, how do we solve this
problem when something's wrong? Right.
It's, you, you wish it were perfect, but it's not.
And so this is the kind of research question, as to how to solve this kind of
problem, and we'll talk more about this in a bit when we get into a little more
technical detail. But I just wanted to sort of say, that's
the kind of research and engineering that took literally 20 years, and four
different versions of it, of the ARPANET to get right.
And so, by the end of the 1970's there was quite a sophisticated network.
Like I said, they'd rewritten it four times.
It had gotten to be very sophisticated, it had been a good investment.
They had been careful about understanding how to improve it each time they rebuilt
it. And do it was that it really a fine
working piece of software, and the people who used it at these research universities
and at the military, it, it was kind of like a futuristic world, right, you could
send email and a second later it would appear, Right, it was really quick and
everything was nice and you could even have instant message like your actions
where when right then and. The problem is this was a small group of
people. This is maybe, looks like 60 or so.
That was all the computers on the entire internet, right?
I mean now we have our cell phones and we have billions of them, right?
But this is like 60. And so a real question is how did this go
from 60 computers of a very narrow group to A much larger group.
And the answer to that question is at Urbana Champaign, Illinois.
And so, at the same time that, this kind of goes back to Blechley Park, right,
where the computers were part of science. Throughout the 50's and 60's and 70's
scientists, much like the military, were realizing computers were mighty useful to
advance scientific research. And so the National Science Foundation
would fund universities to buy computers, and they'd say gimme ten million dollars
to buy a computer. And another university would be like, give
me ten million dollars to buy a computer. And then three years later the first
University says, my computer is obsolete, I need another ten million dollars.
Now the research questions were good research questions.
And they were important to society. But the National Science Foundation got
tired of giving ten million dollars to every, everybody who.
Wait, hold on a sec, let me. As a matter of fact, I was part of this
because I used to be a high performance computer guy.
This is a Convex C3800 super computer. I would be about this tall on this super
computer, this is a lovely and very expensive model that I was given after,
afterwards, and wouldn't throw it away because this was from, like, 1987.
And, and basically I wanted one of these terribly badly.
Each one of these is about 2,000,000 dollars, so this is like two, four, six,
eight, ten million dollars. And I so badly wanted this, and I thought
that I, I deserved a ten million dollar toy, and I could do such great research
but unfortunately everybody else wanted the exact same thing.
And they were important, too. So National Science Foundation said to
themselves hey, this isn't going to work very well if I can't find my pen.
You know, we're not going to be able to, we're going to make a network.
How about we put a few of these things in, and then make a network and connect them
together. Of course it's never as simple as that, so
now we're going to meet Larry Smarr, at the National Center for Supercomputing
Applications, N-C-S-A, at the University of Illinois Urbana-Champaign.
And Larry was the director of NCSA and one of the, one of the many people, but one of
the most instrumental people in creating the national network, that we now think of
as the Internet, and getting it moving it from being a research project to being a
project that we all, both academics and regular people that we all can, can make
really good use of, and so let's take a look at Larry Smarr.