Transcript


00:00
the following content is provided under
00:01
a Creative Commons license your support
00:04
will help MIT OpenCourseWare continue to
00:06
offer high quality educational resources
00:08
for free
00:09
to make a donation or view additional
00:12
materials from hundreds of MIT courses
00:14
visit MIT opencourseware at ocw.mit.edu
00:26
you
00:30
so this is the last but one lecture of
00:32
the term so what I'm going to do today
00:34
is in about 45 minutes give you a quick
00:38
history of the internet from will start
00:41
in the late 1950s and then get to get to
00:44
today and then next time on Monday I'll
00:47
conclude this class by first doing a
00:49
wrap-up of 602 and then also telling you
00:51
a little bit about where I think the
00:52
future of communication systems might be
00:54
going I'll probably be wrong about it
00:57
but I will be confident about it the and
01:03
today the the idea is to try to connect
01:05
some of the topics we've studied in the
01:07
class so far to this history of course
01:11
we're not going to be able to do all of
01:12
it so the story so far
01:14
in terms of the history you know you
01:16
have to assume so we're going to start
01:18
in 1959 or 1957 and by this time you
01:23
know the history of communication
01:24
systems has had a lot of successes and a
01:28
common theme is that there's a
01:30
technology that comes around it succeeds
01:32
it you know tries to take over the world
01:36
and right at the time when it looks like
01:38
there's nothing else that's going to
01:39
happen some other new technology comes
01:41
around that over time kills it
01:43
so the first successful Network
01:47
technology was the electric telegraph
01:49
and the electric telegraph was done by a
01:52
number of different people Wheatstone
01:54
and Cooke built an electric telegraph in
01:56
England Morse and Vale built one in the
01:57
US the Morse code was developed as part
02:01
of the electric telegraph and that did a
02:04
great job in the 1830s 1840s 1850s and
02:08
so forth and then other technologies
02:11
came around now this would this sort of
02:15
story keeps repeating and so by the
02:16
1950s the dominant player in the
02:19
communication area is the telephone
02:21
network so we have the Bell Telephone
02:24
Company and in the US it dominates
02:26
there's equivalent telephone companies
02:28
in other countries and you have this
02:31
so amazing telephone network and
02:33
increasingly many people have telephones
02:36
on the wireless side there isn't a
02:41
wireless telephone system in the 1950s
02:44
but what we have a radio broadcast radio
02:47
and broadcast television and some very
02:49
powerful companies that own wireless
02:52
spectrum to offer television and radio
02:57
so the story starts in the late 1950s
03:00
and in 1957 a big thing happened Sputnik
03:02
launched and that caused the u.s. to
03:05
assume that they were falling behind in
03:07
science technology and that led to the
03:08
creation of art by the Advanced Research
03:10
Projects Agency that still exists it's
03:12
known as DARPA today and is a probably
03:15
the biggest federal funder of
03:16
fundamental research and a lot of
03:19
Applied Research and Development Paul
03:23
brand in many ways is one of the fathers
03:25
or the father of packet-switched
03:27
technologies he was working at a think
03:29
tank called the RAND Corporation which
03:31
was which had a lot of UNAM which was an
03:33
organization that really was a
03:34
think-tank it allowed people to think
03:37
about long term fundamental directions
03:39
in terms of Technology in where
03:41
technology was heading and he was
03:44
looking at the problem of trying to
03:46
build a what he called a survivable
03:49
communication network and you know the
03:51
story is that he's trying to build a
03:53
network that can be that can continue to
03:55
work in the face of a nuclear war but
03:57
that's really not what he was trying to
03:58
go after what he was trying to build was
04:00
just understanding how do you design
04:02
communication networks that allow you to
04:04
handle failures and a lot of the then
04:08
telephone network was a very centralized
04:10
kind of structure where you would have a
04:12
network that had very little redundancy
04:14
built into it and you'd have lots of
04:17
these central star-like topologies and
04:19
the problem of course when you connect
04:20
these stars together and these star-like
04:22
pieces connect to other star like pieces
04:24
is that you had better make these
04:28
points here these nodes or switches here
04:30
extremely extremely reliable and because
04:34
I add those links that are connecting
04:35
them to these other central structures
04:38
because otherwise the failure of those
04:39
things would kill the system and the
04:42
bell telephone company actually
04:43
understood how to build these very
04:45
expensive very very reliable switches
04:47
but they were very very extremely
04:50
expensive the other problem is and we'll
04:53
get back to this later today is that a
04:55
telephone network is a great network but
04:56
it supports exactly one application the
04:59
application is you pick up the phone and
05:00
you talk it's very hard on the face of
05:03
it to imagine how a telephone network
05:04
would do a great job at supporting the
05:08
web for example the web was no-one even
05:10
thought of the web but even something
05:12
basic like being able to watch a video
05:16
stream whose quality might vary with
05:18
time and these are things that the
05:22
internet did differently and did better
05:23
than the telephone network but the
05:24
telephone network fundamentally had in
05:26
those days a fault tolerance issue and
05:28
the way they dealt with it was to build
05:30
extremely reliable components Paul
05:34
Behrens idea which other people had been
05:36
thinking about and talking with was he
05:38
observed that and in those days the
05:39
telephone network was largely analog
05:42
digital telephony wasn't really there
05:44
and digital computers were just starting
05:46
to come in and Paul Baran was probably
05:49
one of the first few people who realized
05:50
that computing and digital technologies
05:53
can change life in terms of how you
05:55
build these systems because the digital
05:58
abstraction allows you to know for sure
06:01
whether a component is working or not
06:03
because if it works it gives you an
06:04
answer that then you can verify and if
06:07
it doesn't work it just stops working it
06:09
isn't like an analogue system where the
06:12
you know it may or may not be working
06:14
and as the noise increases or some fault
06:16
occurs you know you're starting to see a
06:18
lot of noise and it's garbled you don't
06:19
quite you're not quite sure with a
06:21
digital system the other works or a
06:22
doesn't work you can build systems like
06:24
that and he noticed that you could now
06:27
start to think of
06:28
building reliable systems out of lots of
06:32
unreliable individual components and
06:34
this is the fundamental guiding theme
06:36
for large-scale computing systems from
06:39
the late 1950s I mean this goes all the
06:41
way to how you know Google or Amazon or
06:43
Facebook or any of these big data
06:44
centers work any single one of those
06:46
computers there is highly unreliable
06:48
relative to what you could do if you put
06:51
in a lot of money to build a very
06:52
reliable computer but the ensemble is
06:54
highly reliable and to do that requires
06:56
a lot of cleverness and care and the
06:58
first real example of this is the
06:59
digital communication network built out
07:02
of this idea of packets in a couple of
07:06
papers that he wrote in the 19th late
07:08
1950s and early 1960s he said that with
07:11
the digital computer you could now start
07:13
to build highly reliable communication
07:15
networks out of unreliable components
07:19
and so he articulated this idea that you
07:23
can connect these switches or nodes
07:26
together in highly redundant structures
07:28
and if you have a stream of data to send
07:31
you don't have to really pick a
07:33
particular path through the structure
07:36
you could take that message and break it
07:39
up into different pieces and ship them
07:41
in different directions and even if you
07:43
chose to ship them all in one direction
07:45
if a failure occurred these switches
07:48
could themselves start moving the data
07:51
in different directions which meant that
07:53
you no longer think of a communication
07:56
as a big stream that you have to send in
07:58
one way but you can start thinking about
08:01
splitting it up into these different
08:02
pieces now like with many of these ideas
08:05
you know it's rare to find sometimes it
08:08
happens it's rare to find
08:10
exactly one person in the world thinking
08:12
about it no matter how groundbreaking
08:14
the idea there were other people working
08:15
on it and Donald Davies in the UK the
08:17
early 60s was looking at similar ideas
08:19
and he came he actually coined the term
08:21
packet we use packets now to mean you
08:24
know these little messages that you ship
08:26
through the network that are atomic
08:28
units of delivery this term was coined
08:31
by Donald Davies in the 1960s now all of
08:36
this was wonderful in sort of
08:37
theoretical abstractions but how do you
08:39
start to come up with some design
08:41
principles for building communication
08:43
networks in particular how do you deal
08:46
with the problem of having these you
08:49
know links come together at a switch and
08:51
try to share the links going out of a
08:54
switch in a way that allows traffic from
08:58
different conversations to multiplex on
09:00
the same link the idea of having a queue
09:03
in a switch in retrospect seems
09:05
completely obvious but you know here the
09:07
first time you're seeing something like
09:09
this and the telephone network had
09:10
really no queues the idea that you would
09:12
build a queue and now start to analyze
09:14
it is a pretty groundbreaking result
09:17
again there were many people involved
09:19
but probably the most the leading
09:21
contributions came from a person called
09:23
Len Kleinrock who was a PhD student at
09:26
MIT and in his 1961 PhD thesis
09:30
information flow in large communication
09:32
Nets wrote about how you could use
09:35
queueing theory to analyze and to model
09:38
communication networks now around the
09:42
same time again at MIT
09:43
Lickliter and Clark wrote a really
09:47
interesting paper it's actually worth
09:48
reading
09:49
now it means fifty years ago but it's
09:51
interesting base or you know you have to
09:53
go back and think you know this was at a
09:55
time when people didn't really have this
09:57
idea that people could sit in front of
09:59
computers computers were used to you
10:00
know maybe count votes
10:02
I suspect they get it wrong today more
10:04
than they did in those days but you know
10:06
computers were used to count words they
10:08
were used to count you know help with
10:10
the US Census but nobody thought about
10:12
people sitting in front of computers and
10:13
they wrote this wonderful paper called
10:16
online man computer communication I
10:18
guess in those days you know man many
10:21
people so anyway they wrote this paper
10:23
and in fact Licklider had this vision of
10:26
what he called a galactic network that
10:28
would span the globe and beyond which
10:30
was in the for the early 60s it was
10:32
pretty remarkable vision now using these
10:36
ideas in particular length line rocks
10:38
ideas and this idea of man computer
10:40
interactions which of course you know
10:42
the idea of everybody having their own
10:44
computer wasn't this papers vision this
10:46
papers vision was there's a lot of
10:47
computers out there but people just had
10:49
remote terminals and you would log in
10:51
and have these big computers that you
10:53
could use but then you would have nice
10:55
you know interactions on your own
10:57
terminal that was what that paper was
11:00
about Larry Roberts was first at MIT and
11:03
then moved to our partner on this
11:04
program created something called the
11:06
ARPANET and wrote a paper and wrote a
11:09
program there is a call for proposals
11:11
for the ARPANET which was a plan for
11:14
time sharing remote computer so the
11:16
internet at the ARPANET was the
11:18
precursor to the Internet and it started
11:20
not because we wanted to build a
11:22
communication network to prevent it to
11:25
work when there was nuclear war or any
11:27
of these major disasters it actually had
11:29
a very concrete goal just allow people
11:31
computers were really really expensive
11:33
just allow people no matter where they
11:36
were to be able to harness the power of
11:39
expensive computing far away and make it
11:42
look to the extent possible
11:44
as if
11:45
the computers were with you that's that
11:47
was the vision pretty compelling but
11:49
simple and they decided for very good
11:53
reason to pick packet switching the
11:55
reasons primarily had to do with
11:56
economics this was a network that was
11:59
being proposed for an application whose
12:01
utility was questionable and the idea of
12:03
investing huge amounts of money was not
12:06
quite palatable they and Larry Roberts
12:09
and others were very taken by this
12:10
vision of packet switching so they said
12:12
you know what the ARPANET is going to be
12:14
a packet switch network I'll come back
12:17
to this later but of course the
12:18
telephone companies like AT&T just
12:19
thought this was a terrible idea and
12:21
we're using every opportunity to
12:23
ridicule the idea the ARPANET was
12:26
created and a few teams bid on the
12:29
contract for it and BBN bolt Beranek and
12:31
Newman that's near alewife in Cambridge
12:34
they're still there they're part of
12:35
Raytheon now and they still continue to
12:38
do pretty interesting research they got
12:40
they won the contract to build this
12:43
network build the technology for this
12:45
network and because the processing
12:48
involved in the network the protocols
12:50
that were involved were considered
12:53
complicated and considered to be
12:55
computationally intensive they had to
12:58
build a separate piece of hardware that
13:01
they named the IMP or the interface
13:03
message processor and BBN won the
13:06
contract to do that the idea of an
13:08
interface message processor is that
13:09
every computer as well as every switch
13:12
that in the switch would have some
13:13
hardware to forward stuff but you needed
13:16
something to do the computation of both
13:19
the routing tables as well as actually
13:21
every packet every packet would show up
13:22
and you would have to compute some sort
13:24
of a checksum on it and you'd have to do
13:26
this computational task of figuring out
13:30
how to forward that packet and that was
13:32
just considered too much work to have on
13:35
an actual little computer so they
13:37
actually had to build a separate piece
13:38
of hardware that you would attach to
13:39
your computer and some probably about as
13:41
big and you can see the picture
13:42
here these imps were attached to bigger
13:44
computers or computers of the same size
13:46
and these did the networking I mean
13:48
today you know that all of that stuff
13:50
you know a million times more is you
13:52
know going on on this device but back in
13:55
the day that's how it was so they want
13:57
this interface message processor
13:59
contract called the IMP and you know
14:01
when you win a big federal contract
14:03
oftentimes your congressman or senator
14:04
writes to you
14:05
in fact it's funny because a bunch of us
14:08
got you know for a period of time before
14:10
the Senate election bunch of us were
14:12
getting emails letters from Scott Brown
14:14
congratulating us on winning some dinky
14:16
little NSF proposal I don't know other
14:18
people he regarded other faculty here
14:20
got it but you're sort of like you know
14:22
in those days if we want a big contract
14:25
you'd get money from you get a letter
14:26
from your Congressman so in fact Ted
14:28
Kennedy who was the the senator at the
14:30
time and was for many years
14:32
congratulated the team for winning this
14:33
except he got it wrong he congratulated
14:35
them on worthy a contract to build the
14:37
interfaith message processor and I
14:40
assumed that if they actually had built
14:42
that might have been a more useful
14:44
contribution to the to world peace but
14:47
you know all they managed to get was the
14:49
contractor will the interface message
14:51
processor are just details anyway so
14:55
this team was a pretty remarkable team
14:57
they built the first they didn't build
14:59
the first email program that was done
15:01
over at MIT in the 60s but what they did
15:03
do was the first email program that
15:05
crossed different organizations and in
15:07
fact the axe symbol in your email
15:09
addresses which of course and that is
15:10
sort of the right symbol to use if you
15:12
use the axe symbol but there was a
15:15
person at BBN ray Tomlinson who said I'm
15:17
going to put the @ symbol and email
15:18
addresses and a lot of early stuff
15:20
happened that continues to this day so
15:23
they built this network and Kleinrock
15:26
over at UCLA was the principal
15:28
investigator on this you know now
15:30
building systems out of this piece of
15:32
hardware that was built and this was the
15:34
picture of the ARPANET in 1969
15:36
this became the Internet it's it's
15:38
there's a continuous evolution from this
15:40
4-node picture
15:42
to the Internet today and in 1969 they
15:45
finally connected initially - and then
15:47
four nodes and they had to do the first
15:50
demonstration and to listen to Len
15:53
Kleinrock tell the story this is his
15:55
story he says that his group at UCLA
15:58
tried to log into a computer and SR I
16:00
which is in Palo Alto and he said we set
16:05
up a telephone connection between us and
16:06
the guys at s RI we typed the L and he
16:09
asked on the phone because they had to
16:10
check whether it was working so they add
16:11
the phone to check we asked the phone do
16:13
you see the L yes we see the L came the
16:15
response we typed the O and we asked do
16:17
you see the oh yes we see the O and we
16:20
typed the G and the system crashed now
16:23
but you know but they got something
16:25
working and of course the there's a nice
16:28
statement here in a lot of people
16:30
worried about performance optimizations
16:31
but the most important optimization in a
16:34
system is going from not working - to
16:37
working and the fact that something
16:39
worked is is extremely important very
16:44
soon after they connected the East Coast
16:47
a bunch of computers and organizations
16:50
on the east coast to the west coast MIT
16:52
among them so there was a team over at
16:54
BBN a lot of them were from MIT so MIT
16:57
BBN Harvard and Link labs on this side
17:00
and mitre got connected over Carnegie
17:03
today it's Carnegie Mellon University I
17:05
think it was called Carnegie Tech at the
17:07
time University of Illinois and
17:09
long lines across the country there was
17:12
a group of Gouda and in California now
17:16
what were these links anyone want to
17:19
guess these links across the country or
17:21
between you know Harvard and MIT or
17:23
across over there do you think they
17:26
actually went and put in new cables and
17:28
laid these wires what do you think they
17:30
were they were phone lines and so this
17:34
idea shows up over and over again the
17:37
ARPANET was essentially a an overlay
17:40
built on top of the telephone network
17:41
and in fact it was a it was a hostile
17:44
overlay because the telephone network
17:46
didn't really like I mean at the time
17:48
they thought this was just an academic
17:49
joke but you know over time it became
17:51
clear that this underlying network was
17:53
being used on top to do something
17:55
different and so the there is an overlay
17:58
network that's built and overlay show up
18:00
again and again and again it's just that
18:01
they're not as hostile these days you
18:04
know another example of an overlay is
18:06
BitTorrent or any peer-to-peer
18:09
application Skype all of these things
18:11
are overlays that are built on top of
18:12
the Internet and in fact a lot of the
18:17
reason for their existence is because
18:18
the internet doesn't quite do the right
18:20
thing in terms of the right behavior for
18:22
certain applications so people say let
18:24
me go build an overlay on top of it
18:26
wherein you take a path involving
18:30
multiple links on the underlying network
18:32
and make it look like one link in the
18:34
higher-level network and when you do
18:36
that you get an overlay network so this
18:39
single link on the ARPANET is actually
18:41
many many links with many switches and
18:42
who knows how expensive it is underlying
18:44
than the telephone network but all you
18:46
have to do is to pay the net telephone
18:47
network some amount of money and make a
18:49
call or whatever and you get to view it
18:52
as a single link and you can do the same
18:53
thing
18:54
on the internet now this protocol the
18:58
routing protocol they used was a
19:00
distance-vector routing protocol it
19:02
wasn't actually even as sophisticated as
19:03
the one we we studied but it was a
19:06
distance-vector protocol and
19:09
distance-vector was the first routing
19:12
protocol never used in a packet switched
19:14
network and it continued on the ARPANET
19:16
for many years they continued running
19:18
this protocol okay moving on we move
19:21
from basic packet networks to this
19:23
problem of internet working and that
19:25
went through a series of demos so one of
19:27
them was they had a big conference in
19:29
1972 and they were demonstrating the
19:32
simple packet switched ARPANET and it
19:34
worked really well except when they
19:36
demonstrated it to a team from AT&T and
19:39
it didn't work at all and in fact there
19:41
were news articles that were written
19:42
some people wrote this was a nice
19:44
Network some people wrote it never
19:45
worked and AT&T just thought a bunch of
19:48
academics it's never really going to
19:49
work they wrote a modified email program
19:53
and the u.s. was not the only place
19:56
where work was going on where work was
19:57
going on in France there was a really
20:01
good team building a network called
20:02
'cycle ADIZ and Louis Poisson was the
20:05
principal investigator of that system I
20:08
think that cycle this doesn't get enough
20:10
credit because often as it is with these
20:12
things the winner kind of you know
20:14
ARPANET became the Internet and so sort
20:16
of everybody forgot everything else but
20:18
cycle T's actually came up with some
20:20
pretty interesting groundbreaking ideas
20:22
the idea of articulating that this
20:25
network is going to be a best-effort
20:27
network with these packets that they
20:29
call datagrams which is a word that
20:31
continues to be used to this day was in
20:34
this French networks they originated the
20:38
sliding-window protocol
20:39
though you know it looks obvious but
20:41
it's not you can see there's a lot
20:42
subtleties and how you build such a
20:44
protocol and how you argue that it's
20:45
correct
20:46
the first sliding window protocol was in
20:48
cycle days and TCP which which today is
20:50
the world standard used a very very
20:53
similar idea and they also use distance
20:56
vector routing and they also implemented
20:57
for the first time a way to synchronize
20:59
time between computers and they had a
21:02
number of interesting ideas in this
21:03
network it the work was not just being
21:07
done in the wide area in 1973 Ethernet
21:10
was invented at Xerox PARC by a team
21:13
that included Bob Metcalfe who was
21:15
another alumnus from MIT that was
21:18
inspired by this Aloha protocol that we
21:20
studied and Ethernet was essentially
21:23
Aloha with carrier sense multiple access
21:25
very similar to what we did study this
21:28
idea of contention windows is a new idea
21:30
they actually used the probability
21:31
method ethernet standard evolved in the
21:33
late 70s and 80s to use the contention
21:35
window that we now know and that same
21:37
contention window idea and carrier sense
21:39
is used in Wi-Fi so it's it's sort of
21:41
you can draw the stream of ideas through
21:44
that continue to exist to this day it's
21:46
interesting that Ethernet today doesn't
21:48
use carrier sense multiple access
21:50
because Ethernet today is no longer a
21:52
slow speed network it's a very fast
21:54
network it's not a shared bus its
21:57
point-to-point links but it's called
21:59
Ethernet
22:00
and it doesn't use the same Mac protocol
22:02
other than when you have low-speed
22:04
Ethernet on the other hand Wireless uses
22:08
the idea from Ethernet in fact a lot of
22:10
people call a total Evan they used to
22:12
call it wireless Ethernet and the ideas
22:15
just got moved to a different domain but
22:18
it's the same ideas and in fact a lot of
22:20
the a lot of the early chipsets that ran
22:25
the Mac protocol on 802 11 networks
22:27
essentially were the same as the
22:29
Ethernet protocol they used the Ethernet
22:31
MAC they had that piece of hardware they
22:33
would buy it and build the box around it
22:35
so this idea of taking older technology
22:38
and applying it to a new context and
22:40
then modifying it is something that
22:42
works pretty well because it means that
22:44
you can leverage something that already
22:46
exists and start making changes to it
22:48
and over time it becomes it looks
22:49
completely different now the US
22:56
government and ARP ARP I was funding the
22:57
ARPANET but there were companies and
22:59
other research groups in the mix here
23:01
and in those days it was not very clear
23:03
what was going to win and everybody was
23:05
doing research on coming up with
23:06
different ways of connecting networks
23:09
together and Xerox had a system called
23:12
pop I don't know what it stands for I
23:14
think it stands to the park Xerox PARC
23:17
Palo Alto Research Center Park something
23:18
protocol I don't know what the U is and
23:22
in a way there were many technical ideas
23:26
in the Xerox system that actually were
23:28
arguably better in technical terms from
23:31
the ARPANET and tcp/ip but it was
23:35
proprietary whereas tcp/ip was
23:37
completely open
23:39
and open meant that you didn't have to
23:41
pay anyone you didn't have to get
23:43
someone's permission to do it the
23:44
process by which things were
23:46
standardized was far more open and
23:47
democratic and it won not because it was
23:50
better but it because it was out there
23:53
and open and free there's a lot to be
23:56
said for that model because for a red
23:58
book to succeed you need everybody you
24:00
know you need to lower the barrier of
24:02
entry so everybody can you know
24:03
participate and implement it and if you
24:06
make network protocols proprietary it
24:08
usually ends up not benefiting anybody
24:10
so now I think companies have started to
24:13
realize that so everybody understands
24:15
that you want to make standards open and
24:17
then keep secret any particular
24:19
implementation strategy for how you
24:21
implement it so you might gain
24:24
commercial advantage from implementation
24:27
but you gain no commercial advantage
24:29
from keeping a protocol closed there are
24:32
exceptions to this rule like Skype is an
24:34
exception to this rule but who knows in
24:37
five or ten years there may be you know
24:38
I suspect that Skype is not likely to
24:40
remain dominant there there are going to
24:42
be other things that will come about and
24:45
some of them might be open
24:52
in the mid-1970s this idea that you now
24:56
really start to connect many different
24:58
kinds of networks together networks that
24:59
are being run in different organizations
25:01
took root and this was the internet
25:02
working problem and this is the problem
25:04
we ended up people who are working on
25:07
these packets which technologies and
25:08
there were many different kinds of
25:09
packet switch networks that showed up so
25:11
there was the Aloha Network over in
25:13
Hawaii there were people building packet
25:15
switch networks out of Ethernet at MIT
25:18
and Cambridge University there were
25:20
people who are very enamored of
25:21
something called token ring I don't know
25:24
if Victor was at MIT at the time or any
25:26
of my colleagues were but people were
25:28
building these token ring based systems
25:30
that were technically pretty superior in
25:32
some respects and interesting and so
25:34
there were many different kinds of
25:36
networks that people were building and
25:37
connecting their own campuses internally
25:40
and you had to communicate between each
25:42
other the trouble was there was no
25:44
single protocol to do this so Ethernet
25:46
had you know back in the day when you
25:47
bought an Ethernet technology from say
25:49
Digital Equipment or Xerox or one of
25:51
these companies you wouldn't just get
25:53
Ethernet you'd get the Ethernet MAC
25:55
protocol then you'd get some sort of
25:57
network communication network layer
25:59
between the different Ethernet devices
26:01
and you'd get something called EF TP
26:03
which was an Ethernet file transport
26:05
protocol so you get applications around
26:07
it so imagine now you're buying a
26:08
networked thing and you don't get to run
26:10
your own applications you get a stack of
26:11
everything and you get a box and you
26:14
only get to use whatever the vendor gave
26:16
you that was the state of networking at
26:19
that time and people recognize this
26:22
probably wasn't a very good thing
26:24
because what you would like is to have a
26:25
network where people can come up and
26:28
invent their own applications and run
26:30
their own applications on it but you now
26:32
needed a way to communicate between
26:34
these different networks
26:35
so how do you do this so this was a huge
26:40
project that a lot of different
26:42
organizations were involved in but a
26:45
large part of the credit is given to two
26:47
people Vint Cerf and Bob Kahn who were
26:49
in some sense the lead people in getting
26:53
the community of other people together
26:56
in building the system and they
26:58
articulated these visions and these
26:59
ideas so towns rules of interconnection
27:01
are as follows he first said that each
27:04
network is independent and must not
27:06
change so the idea that you can bring
27:08
networks together and communicate if it
27:10
required every network to you know
27:12
change that that wasn't a palatable idea
27:14
the second is that he agreed with
27:16
psychologists and said best effort
27:18
communication is what we need because we
27:20
cannot assume that every network will
27:22
guarantee delivery there are some
27:24
networks that may guarantee delivery in
27:26
order but you can't mandate that and
27:28
what they said was we will design this
27:31
network with these boxes that will call
27:33
gateways and these gateways will
27:35
translate between different network
27:37
protocols and in a very pretty radical
27:39
departure from the Bell Telephone
27:41
Network they said that there will be no
27:44
central global management control there
27:47
is no central place where the operation
27:49
of this worldwide network or countrywide
27:51
network is going to be managed so it's
27:53
kind of a simple idea you have your own
27:55
internal network you know this might be
27:56
an Ethernet this might be some sort of
27:58
Aloha network or what have you but you
28:01
have these gateways here that set and
28:03
translate between these different
28:04
protocols and we know the stuff as
28:09
we now know that what they did was a
28:13
pretty good decision which is they made
28:14
it so that these gateways will all agree
28:17
on one protocol and the protocol they
28:20
standardized they got it wrong initially
28:22
but they eventually by the late 70s they
28:24
figured out that that protocol will be
28:27
called IP or the Internet Protocol so a
28:29
node is on the Internet if it implements
28:32
the Internet Protocol which means it has
28:34
a agreed upon plan for how the
28:37
addressing of nodes works and has a plan
28:39
for what happens when you forward a
28:41
packet you have a look up in a routing
28:43
table that looks up the IP address and
28:45
then decides on the link and that's all
28:47
you have to agree upon so the to be on
28:50
the Internet all you have to do is to a
28:52
network has to support IP address saying
28:54
and it has to agree that it will send
28:57
packets of at least 20 bytes in size
28:59
because that's the length of wipey
29:01
header there's very little else that it
29:02
has to do so much so that people have
29:05
put written standards on how you can
29:06
send Internet Protocol over you know
29:09
carrier Pidgeon and you can in fact
29:11
someone demonstrated something like this
29:12
where you know they have these things
29:14
and these pigeons were delivering these
29:15
scraps of paper and there was something
29:17
looking it up and sending it on so you
29:19
know it doesn't take much to be on the
29:21
Internet
29:25
so Cerf and Kahn said that you know they
29:28
started then designing the network and
29:30
they said they wrote in their original
29:31
paper that you needed to identify the
29:35
network urine and within the network a
29:36
host that you were in and they said the
29:41
choice of network identification allows
29:43
us up for up to 256 distinct networks
29:46
like how many networks do you possibly
29:47
need how many organizations can you
29:49
possibly have and they wrote you know
29:52
famous last words
29:53
this size seems sufficient for the
29:54
foreseeable future the problems they
29:57
were slightly wrong you know the first
29:59
simple future in their case was probably
30:00
less than 10 years and we may not have
30:02
been more than five or six years but you
30:04
know they made a mistake but what was
30:07
interesting was the next time they you
30:09
know the community got to make a change
30:11
in that decision they still made a
30:12
mistake they decided that 32-bit packet
30:14
you know IP addresses are enough and
30:17
we've run out literally run out right
30:20
now of IP addresses so they had these
30:25
gateways that would translate and you
30:26
would run the internetworking protocol
30:28
or IP so in the 1970s this idea of
30:32
internet working was all the rage and in
30:36
1978 there was a really good decision
30:39
made to split TCP from IP and a lot of
30:42
that motivation was from a group of
30:45
people at MIT there's a paper here that
30:47
you'll study at length and 603 three
30:48
it's one of these papers that you'll
30:50
study two or three times because it'll
30:52
keep coming back because these concepts
30:54
are pretty important is called
30:56
end-to-end arguments and system design
30:57
by salsa readin clock
31:00
they have many examples but the gist of
31:03
the end-to-end arguments is that if you
31:07
have a system like let's say a network
31:08
and you want to be able to you want to
31:12
be able to design a network and you have
31:14
to make a decision of what features do
31:16
you put into the network the end-to-end
31:19
arguments say that you only put in
31:23
features in the network that are
31:24
absolutely essential for the working of
31:26
the system anything else that's not
31:28
crucial to the working of the system you
31:30
leave to the endpoints so if you think
31:34
about reliability as a goal like does
31:36
the network need to put in a mechanism
31:38
to guarantee the delivery of packets the
31:41
answer is no the reason is is that that
31:44
property is required for example if
31:47
you're delivering a file but not if
31:48
you're in or delivering a video stream
31:50
or talking because not everybody needs
31:52
to get there which means you don't put
31:55
that functionality inside the network
31:57
you leave the function of achieving
31:58
reliability to the endpoints because not
32:00
everybody needs it and the only
32:03
exception to the rule that the only
32:06
function you put inside of the network
32:08
is functions that are absolutely
32:10
essential for the system to work is if
32:12
the mechanism leads to significant
32:14
improvements in performance so for
32:16
example if you run on a network with a
32:18
20% packet loss rate it makes sense to
32:21
have some degree of reliability and
32:23
retransmission built on a network hop
32:26
like that's what Wi-Fi would do because
32:29
you know if you didn't do it you'd have
32:30
sometimes a 20 or 30% packet loss rate
32:32
and that would make everything not work
32:35
but we don't try to design our networks
32:38
so that between the Wi-Fi access point
32:40
and your computer we produce perfectly
32:43
reliable transmission if you did that it
32:45
would then mean that you would have you
32:47
know really long delays and you would be
32:50
providing that function for applications
32:53
that don't need it if I want an
32:54
application that I would like to just
32:56
send the bytes through it gets through
32:58
great if it doesn't then I'll do
33:00
something else but that's a bad nip of
33:02
design unfortunately there are networks
33:04
real networks today that don't obey this
33:06
principle cell cellular networks are
33:07
sometimes problematic like you know
33:11
Verizon or AT&T or something you might
33:13
you find there in real data that there
33:15
are long delays in these networks
33:17
because between the cellular base
33:19
station and your phone they have decided
33:22
to provide something that looks like
33:24
highly reliable TCP it's kind of a bad
33:27
network design but that's that's how
33:29
they do it some of them and so this is
33:32
an old principle but it's sometimes not
33:34
followed and that's that's not so good
33:38
now the reason why packet switching in
33:41
this tcp/ip split one in the internet
33:44
compared to various other proposals that
33:46
were floating around at the time is that
33:49
this architecture the Internet
33:51
architecture is good enough for
33:54
everything but optimal for nothing there
33:56
is really no application for which the
33:59
design of the Internet network
34:01
infrastructure is optimal if you wanted
34:04
to run a build a network to support
34:06
voice you'd go build the telephone
34:08
network you wouldn't build a network
34:09
that looks like this if you wanted to
34:10
build a network to distribute television
34:12
to you know data to television streams
34:14
to a bunch of people you wouldn't build
34:16
the Internet if you wanted to build a
34:17
network that wanted to support you know
34:19
Facebook and nothing else you probably
34:21
wouldn't build the Internet but if you
34:23
want a network that's going to support
34:24
all those applications reasonably well
34:27
including applications that you cannot
34:29
imagine today this design is a very good
34:32
idea because it's very minimalist
34:34
there's almost nothing that the network
34:36
does it leaves everything to the
34:37
endpoint so I would say in fact that the
34:40
most useful lesson which you will apply
34:41
over and over again I mean you go let's
34:43
say you go work at a company or work on
34:46
some sort of research project and
34:47
there's you know at various stages of a
34:49
project there are endless discussions on
34:51
what you need to do and you know whether
34:55
it's worth doing something or not doing
34:56
and the most important lesson that you
34:59
can take away from system in system
35:01
design is that when faced with a choice
35:04
try to make a choice that's the simplest
35:06
possible choice that gets the job done
35:08
because most likely if you get the
35:11
application wrong of whatever it is
35:13
you're building if it's simple and
35:15
minimalist you could probably pivot
35:17
around and use the same thing for that
35:18
other application so there's a famous
35:24
set of quotations here one should always
35:26
architect systems for flexibility
35:28
because you will naturally never almost
35:30
never know when your design everybody
35:32
has these use cases in mind but let's
35:34
face it when you're in the early stages
35:35
of a project nobody actually knows and
35:38
you'll almost always get it wrong so
35:40
it's important to architect them for
35:41
flexibility not for performance not for
35:43
the you know lots of functionality just
35:45
for being flexible and bare minimum to
35:48
get the job done based on what you think
35:50
is necessary
35:52
and it usually means doing that even if
35:54
it means sacrificing performance like I
35:56
said the most important benefit meant in
35:58
the systems performance is getting it to
36:00
work everything else is secondary so
36:03
there's a nice quote here I don't know
36:04
if any any French speakers or readers
36:07
yes yeah I know just tell me in English
36:15
good laughter
36:26
that's great yeah perfection is achieved
36:29
not when there's nothing more to add but
36:30
when there's nothing you have to take
36:31
away and this is a really really good
36:34
lesson I mean you guys every one of you
36:36
is going to go into the real world and
36:38
you know either at a startup company or
36:42
a big company where you're defining a
36:43
new project product or a research
36:44
project you go to graduate school at the
36:48
beginning you wouldn't know you won't
36:49
know the right answers you have some
36:52
vague ideas of what it's useful for when
36:54
you design anything and it's really
36:56
important to understand that you should
36:57
do the bare minimum to get it work and
36:59
it's really good it's a really really
37:01
good idea unless is more or you know I
37:04
have a very simple way to think of it
37:06
you know I tell my students this
37:07
repeatedly when in doubt just leave it
37:09
out if you're not sure if you need it or
37:11
not don't don't do it there's enough
37:12
stuff to do and that's that's probably
37:15
the most important lesson from many of
37:17
the classes not least on the system side
37:19
that you'll be learning of course it
37:21
takes a lot of good taste and insight
37:23
and intuition to figure out you know
37:24
what's really important I can't help you
37:27
there ok so by the 1980s the internet
37:31
started to grow up and the way in which
37:35
we wanted you wanted to handle growth
37:36
was this brilliant idea simple but
37:39
brilliant idea called topological
37:40
addressing so I'm going to explain what
37:43
that means
37:44
in the very early days of the net
37:46
internet and including the simple small
37:48
networks that we studied every network
37:51
node had a network identifier
37:54
an IP address or some sort of a name for
37:56
that node so in the way in which we look
37:58
at it nodes would have names like ABCD
38:01
and E but in reality you know ABC of
38:04
course there's some sort of bits that
38:05
communicated and in the old days of the
38:07
internet you would have a two phase
38:09
identifier you'd have a sort of a
38:13
network identifier or organization
38:14
identifier so MIT would have a set of
38:17
eight bits and then you would have a set
38:19
of other bits here that communicated
38:21
within MIT what that number meant so
38:24
just kept strictly I mean these numbers
38:26
meant nothing in the global Internet
38:27
this could just be you know one one zero
38:30
one one something and then you have
38:32
another sequence or something else that
38:36
was the basic idea now in the networks
38:39
we studied so far we wouldn't even have
38:41
this every network node would just have
38:43
some name so what that meant is you
38:46
could have a network address that was
38:48
some set of bits I could have a network
38:50
address that was some other set of bits
38:51
and the switches in the network in order
38:56
to forward packets to you or to me would
38:59
have to have entries in their routing
39:01
tables that were one-to-one with all of
39:05
the different nodes that they wanted to
39:07
communicate with so you would have a
39:08
routing table that would be essentially
39:10
one entry for every host in the network
39:12
which doesn't scale it's just too much
39:15
information
39:15
so topological addressing is the idea
39:19
that per node routing entries don't
39:22
scale very well so what you would like
39:23
to do is organize the network
39:25
hierarchically and the it's sort of
39:29
similar to the way in which the postal
39:31
system works so I in the 1980s they came
39:36
up with a way of doing it using three
39:37
kinds of addresses called Class A B and
39:40
C address we don't use those anymore but
39:42
let me describe what what this kind of
39:45
area based addressing means so here's a
39:48
very simple abstract view of this the
39:49
internet you know adopts this since I
39:51
used to adopt this in some
39:53
Midway but this is the conceptual idea
39:55
you design the network in two areas so
39:57
MIT might be an area you know Stanford
40:00
might be an area Berkeley might be an
40:01
area you know BBN n all these different
40:03
people are their own areas organizations
40:06
areas have numbers that everybody knows
40:08
so that's this first part which might be
40:11
an area identifier and then this is a
40:15
within the area you might have a host
40:19
identifier or more generally an
40:21
interface identifier what I mean by
40:25
interface is that really on the internet
40:28
my computer doesn't have an IP address
40:30
the if I'm connected to the Internet by
40:33
the Ethernet the Ethernet has an IP
40:35
address it gets an IP address by virtue
40:37
of connecting to a switch upstream of it
40:40
my Wi-Fi network has an IP address if I
40:42
use the Bluetooth my blue 2000 IP
40:44
address in fact in general sometimes my
40:46
computer might have four IP addresses
40:48
one if I'm connect on Ethernet one on
40:50
Bluetooth one on Wi-Fi and if I have one
40:53
of those cellular modems if I tether
40:55
through my phone you know every time I
40:57
do one of those things I get an IP
40:58
address okay so IP addresses on the
41:01
internet name the network interface so
41:04
the way this area routing idea works is
41:06
that within these areas there's routing
41:09
as usual and forwarding as usual so all
41:11
these nodes have you could recursively
41:14
build sub areas but if you didn't each
41:16
of these guys would have an entry for
41:17
all of the other nodes here and within
41:20
these areas you would have border
41:22
routers and these border routers would
41:24
only have entries for the other areas so
41:28
if you sent a path you wanted to send a
41:30
packet from area one to area of let's
41:33
say area for what you would do is you
41:35
would send a packet to one of your
41:36
border routers and that border router
41:38
would have an entry in its routing table
41:41
to get to area four it wouldn't know
41:44
anything about the details inside area
41:46
four and so you have a nice hierarchy
41:49
where
41:50
inside the network you only know how to
41:52
get inside your network and to the
41:54
border the borders know how to get
41:56
inside and the borders know how to get
41:58
to other borders
42:00
but the borders don't know but the
42:02
border of one area doesn't know how to
42:03
get inside any other network so you can
42:06
see now you can recursively apply this
42:08
idea and start to scale the routing
42:11
system now on the internet what ended up
42:15
happening was well they had to apply
42:18
this area hierarchy and very soon
42:20
organizations started saying well I have
42:22
a big area and now I have a small area
42:24
so how big do you make this thing in the
42:26
very old internet these were eight bits
42:29
long and these were the rest of the
42:30
address if you have eight bits you can
42:32
only have 256 organizations and although
42:36
a Khan and serf thought that was plenty
42:38
enough that clearly wasn't the case so
42:41
they did you know by this time people
42:42
were starting to build equipment with
42:44
these 32-bit addresses and all this
42:47
hardware was out there so what do you do
42:48
so what they said was alright let's have
42:51
three classes of areas we will have for
42:54
the really big guys will have Class A
42:56
addresses
42:57
then for the medium guys will have to
42:59
ask me and for the little guys will have
43:01
lost see what that meant is that we're
43:03
going to have class a allows an
43:06
organization to have up to two to the 24
43:08
addresses because Class A is identified
43:14
by eight bits so you get 24 which is 32
43:18
minus 8 so MIT was pretty smart they
43:23
decided that they would go and you know
43:25
they were up there they were doing a lot
43:26
of networking research so they said
43:28
we're going to go get ourselves one of
43:29
these Class A addresses because we're a
43:31
big university and we got lots of
43:32
computers and it was probably the case
43:34
that at the time an IT probably had more
43:35
computers than most other places so they
43:37
even to this day they maintain this
43:39
address which was 18 dot star where the
43:43
star refers to well technically start or
43:46
star dot star so all 2 to the 24
43:49
addresses that start with the number 18
43:52
or in binary terms whatever the 18 is 0
43:54
0 0 I'm going to get this wrong but
43:57
there's some 8 bit number for 18
44:03
so anyway they were really you know they
44:05
went and got this stuff now nobody
44:08
wanted the class C's because the class
44:09
C's were you know you could get two to
44:11
the eighth addresses because the Class C
44:16
was defined as 24 bits so you have 24
44:20
bits to define the organization so you
44:22
could have 2 to the 24 or some large
44:23
number of organizations not quite go to
44:25
the 24 but you'd have some large number
44:27
of organizations but then you'd only get
44:29
256 now the organization doling out
44:32
these numbers there's a there's a
44:34
particular organization actually it was
44:35
not even an organization at the time was
44:36
like this Jon Postel at UCLA who I was
44:40
during this route and then it came an
44:42
organization and Jon Postel was great I
44:46
mean he was really you know the social
44:48
aspects of how he managed this were
44:49
remarkable but so he didn't build these
44:52
out you know randomly and nobody wanted
44:56
this everybody wanted this and nobody I
44:59
mean everybody wanted that but they got
45:00
this and this was 16 and 16 so you get 2
45:03
to the 16 addresses and you get your
45:06
16-bit identifiers for these areas and
45:09
over time as the internet grew you know
45:12
the obvious thing happened because the
45:14
thing is this is like the Goldilocks
45:15
story right this is like it's too big
45:17
and this is too small this is just right
45:19
and you know pretty soon there were 2 to
45:21
the 16 organizations on the internet we
45:22
ran out which literally they ran out of
45:25
Class B addresses and by this time by
45:27
the early 90s they realized that this
45:29
rigid decomposition into addresses in
45:33
this form was just not quite right you
45:35
know because what you really wanted was
45:36
a system where you allowed organization
45:38
and this idea of an organization ID
45:40
didn't make sense like what if I need 2
45:43
to the 12 addresses today you would have
45:46
to give me 2 to the 16 which is
45:48
ridiculous
45:49
so if I need a two to the twelve you
45:51
know how do you actually do that well I
45:52
could get four through to the aides but
45:54
if the stood the aides were not
45:56
contiguous then those routers in the
45:59
middle of the Internet would have to
46:00
would not be able to treat them as one
46:03
and have the same prefix to define the
46:06
rest you know to define the entire
46:07
network they would have to have four
46:09
different entries defeating the purpose
46:11
of in fact using this kind of area based
46:15
routing so the whole thing was kind of
46:17
messed up so they actually got wise to
46:20
this problem and they came up with a
46:21
more sensible same way to deal with this
46:25
problem I'll talk about that probably on
46:29
Monday now in the meantime in the 1980s
46:32
this growth was happening pretty rapidly
46:34
and the internet started getting
46:35
organized the vint cerf was by then a
46:38
DARP at ARPA appointed Dave Clark who
46:42
was a senior research scientist
46:43
professor at MIT to a position of
46:47
Internet's chief architect and he was a
46:50
instrument in writing and bringing
46:52
together a lot of people in organizing
46:53
how people do this kind of
46:55
standardization so there was an
46:56
organization called the internet
46:58
Engineering Task Force or IETF that's
47:00
the organization that determines and
47:02
sets the standards for the protocols
47:03
that run on the Internet
47:05
in 1982 a really important thing
47:07
happened this idea of this open
47:09
community with the with the Internet
47:11
architecture community got a real boost
47:16
when the US Department of Defense looked
47:19
at various ways and competing ways of
47:21
designing networks and kind of
47:23
remarkably for a Department of Defense
47:25
decided to pick the open standard rather
47:27
than some proprietary standard rather
47:29
than some closed standard that
47:31
is potentially more secure though really
47:33
isn't they actually remarkably they said
47:35
we'll be on a standardized our entire
47:37
systems on tcp/ip and and the Defense
47:39
Department I don't know if it's still
47:41
the case
47:41
it probably is but in those days it was
47:43
a huge consumer of information
47:45
technology it still is it's just that
47:47
other people consume it too but in those
47:49
days it was probably the dominant
47:50
consumer of information technology and
47:53
they standardized on it and they awarded
47:55
a contract to the Berkeley computer
47:58
systems a group to build tcp/ip which by
48:02
then had become standard and there were
48:04
many implementations but they said take
48:06
UNIX and go build the tcp/ip stack and
48:10
Berkeley did a lot of interesting things
48:11
with it including creating the Sockets
48:13
Layer they came out with what today is
48:16
known as open source implementations of
48:18
the TCP stack in 1983 MIT created
48:23
project Athena which was were the worst
48:26
first campus-wide campus area network
48:29
system and they did a lot of work on
48:32
things like file systems distributed
48:34
file systems and and a Kerberos
48:38
authentication scheme and a lot of
48:39
important ideas from this network and
48:42
they also ran the tcp/ip stack they
48:44
didn't draw on anything proprietary in
48:47
1984 the domain name system was
48:50
introduced for those who don't know it
48:51
you know when you go type in www.mit.edu
48:54
something converts it to an IP address
48:56
and then your network stack communicates
48:59
and sends packets over TCP or UDP or
49:03
these protocols to that address
49:05
how do you convert this well again
49:08
originally this was maintained in a file
49:10
this file was called host star Tech host
49:13
dot txt and believe it or not the way
49:15
this file would work was that every
49:17
night I think in the middle of the night
49:19
every computer on the internet would go
49:21
and download this file from one computer
49:23
that was located somewhere on the west
49:25
coast like literally you would get a
49:27
hosta text file of course you could hack
49:29
it if you do whatever you are in the
49:30
assumption of course was that no one was
49:31
you know I was told that in the early
49:33
days every computer had a root password
49:35
which was empty or these computers at
49:37
MIT had a root password is empty
49:38
everybody could log in to any computer
49:40
everybody was completely trusted which i
49:43
think is sort of not true anymore
49:45
but you would download this host our
49:48
text file every day and you know it
49:49
started as the internet grew really fast
49:52
you know the Internet has been growing
49:54
by 80 to 90 percent a year not just in
49:57
the past few years not just in the
49:59
nineties you know it's been growing at
50:01
80 to 90 percent a year since 1980 so
50:03
it's just this amazing tear and
50:09
so anyway this idea of downloading a
50:11
file every night is just not a good idea
50:13
so they created the domain name system
50:16
they had to create a the NSF which was
50:20
the National Science Foundation gotten
50:21
to the AG and they became the first
50:23
Internet backbone and the backbone the
50:26
idea is that this is a backbone that
50:27
connects all of these different networks
50:29
together in particular all of the
50:31
universities together so they also pick
50:34
tcp/ip as a standard and again the
50:36
important lesson here is they picked it
50:37
as a standard because it was open
50:39
because it was very clear that these
50:42
implementations were available they were
50:43
free everybody could contribute to it
50:45
and everybody could beat on it and
50:47
improve it and there was no proprietary
50:49
technology that was held so what I will
50:52
do here is I'm going to stop I'll pick
50:54
it up at this point on Monday to talk
50:56
about congestion control how to hijack
50:58
routes and how to send spam without
51:00
being detected and then talk about the
51:02
future of network networking and
51:05
communications
51:14
you