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.