1
00:00:00,000 --> 00:00:02,520
The following content is
provided under a Creative

2
00:00:02,520 --> 00:00:03,970
Commons license.

3
00:00:03,970 --> 00:00:06,360
Your support will help
MIT OpenCourseWare

4
00:00:06,360 --> 00:00:10,690
continue to offer high quality
educational resources for free.

5
00:00:10,690 --> 00:00:13,350
To make a donation or
view additional materials

6
00:00:13,350 --> 00:00:17,190
from hundreds of MIT courses,
visit MIT OpenCourseWare

7
00:00:17,190 --> 00:00:18,400
at ocw.mit.edu.

8
00:00:29,030 --> 00:00:31,010
PROFESSOR: So my goal
for today is twofold.

9
00:00:31,010 --> 00:00:34,130
The first is, we've looked at
the history of the internet

10
00:00:34,130 --> 00:00:35,960
in the '60s and the '70s.

11
00:00:35,960 --> 00:00:37,340
And today, my goal
is to tell you

12
00:00:37,340 --> 00:00:40,850
about what happened in
the '80s and the '90s,

13
00:00:40,850 --> 00:00:43,010
as well as the last decade.

14
00:00:43,010 --> 00:00:45,470
And we'll do that
maybe 30, 35 minutes.

15
00:00:45,470 --> 00:00:48,500
But I want to tell you about
two interesting problems that

16
00:00:48,500 --> 00:00:51,290
got solved, both related
to topics we've studied.

17
00:00:51,290 --> 00:00:56,120
The first is on how the internet
dealt with a serious problem

18
00:00:56,120 --> 00:00:57,500
called congestion
collapse, which

19
00:00:57,500 --> 00:01:02,210
happened in the mid-1980s,
where TCP, the transmission

20
00:01:02,210 --> 00:01:04,790
protocol at the time, was
still the dominant protocol

21
00:01:04,790 --> 00:01:08,510
in the world, didn't have
many of the new ideas

22
00:01:08,510 --> 00:01:09,840
that it now has.

23
00:01:09,840 --> 00:01:14,660
In fact, the implementation
of TCP in the 1980s

24
00:01:14,660 --> 00:01:16,820
was almost exactly
the implementation

25
00:01:16,820 --> 00:01:20,960
of your sliding window
protocol from the second lab,

26
00:01:20,960 --> 00:01:24,260
from the second task
of the last lab.

27
00:01:24,260 --> 00:01:26,720
And in fact, as
some of you are--

28
00:01:26,720 --> 00:01:28,712
I think Tyler
posted it on Piazza,

29
00:01:28,712 --> 00:01:30,170
there was a particular
way in which

30
00:01:30,170 --> 00:01:32,587
he had dealt with the windowing
scheme that happened to do

31
00:01:32,587 --> 00:01:34,040
better than the lab solution.

32
00:01:34,040 --> 00:01:36,830
And I remarked there that the
reason the lab solutions are

33
00:01:36,830 --> 00:01:38,780
the way they are are a
little bit more general

34
00:01:38,780 --> 00:01:40,430
than the particular topology.

35
00:01:40,430 --> 00:01:42,830
But the topology that I
picked was specifically

36
00:01:42,830 --> 00:01:44,810
picked in the lab so
you didn't have to worry

37
00:01:44,810 --> 00:01:46,498
about congestion happening.

38
00:01:46,498 --> 00:01:49,040
But today, I'll tell you what
happens when congestion happens

39
00:01:49,040 --> 00:01:51,260
and the solutions
that were adopted.

40
00:01:51,260 --> 00:01:53,330
And it'll be a little bit
of a preview to 6.033.

41
00:01:53,330 --> 00:01:56,390
You'll study this topic
at some length in 6.033.

42
00:01:56,390 --> 00:01:57,890
The other problem
I want to tell you

43
00:01:57,890 --> 00:01:59,970
about today through
these remarks

44
00:01:59,970 --> 00:02:04,015
is about how easy it is to
hijack routes on the internet.

45
00:02:04,015 --> 00:02:05,390
And I'll go through
some examples

46
00:02:05,390 --> 00:02:07,540
of this happening in reality.

47
00:02:07,540 --> 00:02:09,805
I mean, it is literally
something a bunch of-- you

48
00:02:09,805 --> 00:02:11,180
know, you can do
it in your dorm.

49
00:02:11,180 --> 00:02:13,888
You just have to convince
some sort of-- pretend

50
00:02:13,888 --> 00:02:16,430
you're an ISP, or set yourself
up as a small internet service

51
00:02:16,430 --> 00:02:16,980
provider.

52
00:02:16,980 --> 00:02:19,770
And you can actually
wreak a fair bit of damage

53
00:02:19,770 --> 00:02:23,120
onto the rest of the world
if you're so inclined,

54
00:02:23,120 --> 00:02:26,720
and then pretend that it
was just a, you know, error.

55
00:02:26,720 --> 00:02:28,610
So those are the
two technical ideas.

56
00:02:28,610 --> 00:02:31,640
I mean, none of this stuff
is really on the quiz,

57
00:02:31,640 --> 00:02:35,450
though it's probably helpful
to think about these things

58
00:02:35,450 --> 00:02:38,810
about route hijacking
because those apply to some

59
00:02:38,810 --> 00:02:40,160
of the concepts we've studied.

60
00:02:40,160 --> 00:02:42,607
But a lot of this is just
for-- out of your own interest.

61
00:02:42,607 --> 00:02:44,190
And I'm hoping to
pique your curiosity

62
00:02:44,190 --> 00:02:46,850
so later courses
in the department

63
00:02:46,850 --> 00:02:48,290
would be interesting.

64
00:02:48,290 --> 00:02:52,818
OK, so in the 1980s,
the people designing

65
00:02:52,818 --> 00:02:55,110
the protocols of the internet
started to get organized.

66
00:02:55,110 --> 00:02:57,650
And as you recall,
Vint Cerf and Bob Kahn

67
00:02:57,650 --> 00:02:59,010
were the leaders of the effort.

68
00:02:59,010 --> 00:03:01,010
There was a big community
of people contributing

69
00:03:01,010 --> 00:03:02,750
to what became the internet.

70
00:03:02,750 --> 00:03:05,030
And back in those days,
it was still the ARPANET.

71
00:03:05,030 --> 00:03:06,950
ARPA had funded
this entire project.

72
00:03:06,950 --> 00:03:09,590
And it was starting
to be successful.

73
00:03:09,590 --> 00:03:11,480
In the 1980s, rapid
growth started.

74
00:03:11,480 --> 00:03:13,220
People said how the
internet is booming,

75
00:03:13,220 --> 00:03:16,130
and how it's exploding
at 80% or 90% a year.

76
00:03:16,130 --> 00:03:18,560
It's been growing at
about 80% to 90% a year

77
00:03:18,560 --> 00:03:20,930
since about 1983 or 1984.

78
00:03:20,930 --> 00:03:25,730
This explosive growth has been
happening for several decades

79
00:03:25,730 --> 00:03:26,918
now.

80
00:03:26,918 --> 00:03:28,460
Dave Clark, who was
a senior research

81
00:03:28,460 --> 00:03:31,070
scientist at MIT and on the
faculty in our department,

82
00:03:31,070 --> 00:03:34,760
was designated as the
internet's chief architect.

83
00:03:34,760 --> 00:03:38,330
And one of the things he did was
to get the community organized

84
00:03:38,330 --> 00:03:40,920
and formalize the creation
of internet standards.

85
00:03:40,920 --> 00:03:42,920
You know, you have all
these different companies

86
00:03:42,920 --> 00:03:45,890
and organizations and
universities coming together.

87
00:03:45,890 --> 00:03:48,290
How do you
standardize protocols?

88
00:03:48,290 --> 00:03:53,960
And the argument-- the
approach they came up with

89
00:03:53,960 --> 00:03:55,790
was called the Internet
Engineering Task

90
00:03:55,790 --> 00:03:57,620
Force, or IETF.

91
00:03:57,620 --> 00:04:00,890
And they would write
these proposals.

92
00:04:00,890 --> 00:04:03,440
There had been this trend
of writing these proposals

93
00:04:03,440 --> 00:04:07,425
for people to comment on, called
RFCs, or Request For Comments.

94
00:04:07,425 --> 00:04:09,800
And now, there are several
thousand requests for comment.

95
00:04:09,800 --> 00:04:12,020
Nowadays, requests for
comment are after the comments

96
00:04:12,020 --> 00:04:12,650
have been made.

97
00:04:12,650 --> 00:04:14,840
Usually, you go through
an internet draft stage.

98
00:04:14,840 --> 00:04:16,940
And by the time it's
a request for comment,

99
00:04:16,940 --> 00:04:19,065
it pretty much means that
the comments have already

100
00:04:19,065 --> 00:04:19,640
been done.

101
00:04:19,640 --> 00:04:21,682
But historically, they
were requests for comment,

102
00:04:21,682 --> 00:04:23,720
so they called it
request for comment.

103
00:04:23,720 --> 00:04:26,775
So if you ever go to a company
where you're asked to--

104
00:04:26,775 --> 00:04:29,150
lots of things that are on
internet request for comments.

105
00:04:29,150 --> 00:04:30,817
And often, people are
asked to implement

106
00:04:30,817 --> 00:04:32,000
pieces of various standards.

107
00:04:32,000 --> 00:04:33,667
And you typically
look at this document,

108
00:04:33,667 --> 00:04:36,208
and you try to see if there's
someone written code around it.

109
00:04:36,208 --> 00:04:38,210
And then you adapt it
or write it from scratch

110
00:04:38,210 --> 00:04:39,280
to the specification.

111
00:04:39,280 --> 00:04:41,480
So it specifies the protocols.

112
00:04:41,480 --> 00:04:44,587
And the interesting
part of the standard

113
00:04:44,587 --> 00:04:46,670
was very much in keeping
with the general approach

114
00:04:46,670 --> 00:04:48,500
of the internet ethos,
which was to try

115
00:04:48,500 --> 00:04:49,970
to make everything be open.

116
00:04:49,970 --> 00:04:52,596
There are many standards
bodies in the world.

117
00:04:52,596 --> 00:04:57,050
The IEEE has various committees.

118
00:04:57,050 --> 00:04:58,880
The International
Telecommunications Union

119
00:04:58,880 --> 00:05:00,470
does the various
telephone standards.

120
00:05:00,470 --> 00:05:01,430
There's many, many standards.

121
00:05:01,430 --> 00:05:03,020
And often, they're
based on voting.

122
00:05:03,020 --> 00:05:04,910
And voting means that
people horse trade.

123
00:05:04,910 --> 00:05:06,493
You know, you have
a favorite feature,

124
00:05:06,493 --> 00:05:08,120
I have a favorite feature.

125
00:05:08,120 --> 00:05:10,410
They're both pretty crappy
features, but you know,

126
00:05:10,410 --> 00:05:12,410
I'll vote for your feature
if you vote for mine.

127
00:05:12,410 --> 00:05:14,180
And people end up horse trading.

128
00:05:14,180 --> 00:05:18,127
And in the IETF, in the good
old days, this kind of stuff

129
00:05:18,127 --> 00:05:18,710
didn't happen.

130
00:05:18,710 --> 00:05:19,730
Now, it's changed.

131
00:05:19,730 --> 00:05:23,628
But in the good old days,
there was this quote,

132
00:05:23,628 --> 00:05:25,670
it says, we reject kings,
presidents, and voting.

133
00:05:25,670 --> 00:05:28,140
We believe in rough
consensus and running code.

134
00:05:28,140 --> 00:05:30,780
The idea was that you
show me what it does.

135
00:05:30,780 --> 00:05:32,320
Allow people to
experiment with it.

136
00:05:32,320 --> 00:05:33,960
And only after we
see some prototypes

137
00:05:33,960 --> 00:05:36,060
and some actual
experiments in the lab will

138
00:05:36,060 --> 00:05:38,385
we even consider making
it into a standard.

139
00:05:38,385 --> 00:05:40,720
And this was the good
old days of the internet

140
00:05:40,720 --> 00:05:43,890
in which things were on rough
consensus and running code.

141
00:05:43,890 --> 00:05:46,530
So it wasn't around, you
know what, let's just vote,

142
00:05:46,530 --> 00:05:49,170
and we'll get all our
lousy features in just

143
00:05:49,170 --> 00:05:52,830
because we care enough
about it personally.

144
00:05:52,830 --> 00:05:54,480
A big break happened
in 1982 when

145
00:05:54,480 --> 00:05:56,078
the US Department
of Defense decided

146
00:05:56,078 --> 00:05:57,870
that proprietary
technology was not the way

147
00:05:57,870 --> 00:06:01,290
to go with networking,
and standardized on TCP/IP

148
00:06:01,290 --> 00:06:02,640
as the standard.

149
00:06:02,640 --> 00:06:04,800
And back in those days,
the Defense Department

150
00:06:04,800 --> 00:06:06,660
was a huge consumer of IT.

151
00:06:06,660 --> 00:06:10,800
It still is, but back then,
it was just hugely dominant.

152
00:06:10,800 --> 00:06:14,790
And they could really
influence how the world went.

153
00:06:14,790 --> 00:06:18,630
In 1983, MIT created a
Athena, the first really

154
00:06:18,630 --> 00:06:20,880
big, large-scale
computing project.

155
00:06:20,880 --> 00:06:22,650
We still have Athena machines.

156
00:06:22,650 --> 00:06:25,830
And it showed how to
build campus-area networks

157
00:06:25,830 --> 00:06:27,120
and campus-area technologies.

158
00:06:27,120 --> 00:06:28,620
They built distributed
file systems,

159
00:06:28,620 --> 00:06:30,330
they built systems
like Kerberos.

160
00:06:30,330 --> 00:06:33,490
And in fact, they were
one of the first groups,

161
00:06:33,490 --> 00:06:36,390
the first networks to experience
network congestion problems

162
00:06:36,390 --> 00:06:39,270
because everybody started using
the network to do their work

163
00:06:39,270 --> 00:06:42,870
rather than have their own
computers at their desk

164
00:06:42,870 --> 00:06:46,380
or use the terminal to log in
to some remote mainframe, which

165
00:06:46,380 --> 00:06:50,310
was the way in which
things used to be done.

166
00:06:50,310 --> 00:06:52,680
I mentioned last
time that in 1984, we

167
00:06:52,680 --> 00:06:54,000
created the domain name system.

168
00:06:54,000 --> 00:06:56,820
This is the system that
goes between domain names

169
00:06:56,820 --> 00:06:59,910
like mit.edu to an IP address.

170
00:06:59,910 --> 00:07:01,680
And before that, it was an FTP--

171
00:07:01,680 --> 00:07:03,810
how many people
have heard of FTP?

172
00:07:03,810 --> 00:07:04,680
A few of you, OK--

173
00:07:04,680 --> 00:07:05,640
File Transfer Protocol.

174
00:07:05,640 --> 00:07:07,098
Nobody really uses
that these days.

175
00:07:07,098 --> 00:07:10,470
But you used to download
this-- every night,

176
00:07:10,470 --> 00:07:13,260
computers would download it from
one machine located, I believe,

177
00:07:13,260 --> 00:07:14,340
in California.

178
00:07:14,340 --> 00:07:18,600
And it didn't really
scale, you know?

179
00:07:18,600 --> 00:07:20,880
And people decided
that you needed

180
00:07:20,880 --> 00:07:23,610
to get organized and build
a domain name system.

181
00:07:23,610 --> 00:07:25,902
In 1985, ARPA was--

182
00:07:25,902 --> 00:07:27,360
the Defense Department
was starting

183
00:07:27,360 --> 00:07:29,490
to get out a little
bit of maintaining

184
00:07:29,490 --> 00:07:31,650
the entire
communication network.

185
00:07:31,650 --> 00:07:33,450
And the National
Science Foundation

186
00:07:33,450 --> 00:07:35,760
started taking over the
running of the backbone,

187
00:07:35,760 --> 00:07:39,490
connecting all the non-military
networks in the United States.

188
00:07:39,490 --> 00:07:41,560
And this led to the NSFNET.

189
00:07:41,560 --> 00:07:44,560
I'll have more to say about
NSFNET in a little bit.

190
00:07:46,975 --> 00:07:49,350
There were two big growth
problems that were experienced.

191
00:07:49,350 --> 00:07:51,120
The first was congestion,
and the second

192
00:07:51,120 --> 00:07:54,330
had to do with how addresses
started running out,

193
00:07:54,330 --> 00:07:58,270
and we had to deal with
problems in the routing system.

194
00:07:58,270 --> 00:08:00,300
So I want to talk
about congestion.

195
00:08:00,300 --> 00:08:03,060
In 1986, the
internet experienced

196
00:08:03,060 --> 00:08:06,390
the first of a series
of congestion collapses.

197
00:08:06,390 --> 00:08:08,400
A congestion collapse
is a situation

198
00:08:08,400 --> 00:08:10,380
where you end up
with a picture that

199
00:08:10,380 --> 00:08:12,540
looks like this,
where if you were

200
00:08:12,540 --> 00:08:17,950
to draw the offered load on a
network, or any system for that

201
00:08:17,950 --> 00:08:18,450
matter--

202
00:08:21,100 --> 00:08:23,493
which is just how many
people are clamoring

203
00:08:23,493 --> 00:08:26,160
to get access to the network and
send their data on the network.

204
00:08:26,160 --> 00:08:33,210
If you were to plot the
throughput that you get,

205
00:08:33,210 --> 00:08:36,461
or the utilization that
you get from the network,

206
00:08:36,461 --> 00:08:38,669
you typically would see a
curve that looks like this.

207
00:08:38,669 --> 00:08:41,549
As the offered load grows,
you might see a somewhat

208
00:08:41,549 --> 00:08:43,620
linear increase in the
throughput with slope 1

209
00:08:43,620 --> 00:08:44,910
because the network
isn't congested,

210
00:08:44,910 --> 00:08:46,118
no packets are being dropped.

211
00:08:46,118 --> 00:08:49,560
You push some data in,
you get the data out.

212
00:08:49,560 --> 00:08:51,230
The throughput tracks
the offered load.

213
00:08:51,230 --> 00:08:53,970
And at some point, you reach
the capacity of the link,

214
00:08:53,970 --> 00:08:55,888
or of the network in general.

215
00:08:55,888 --> 00:08:57,930
And you might end up with
a flat curve like that.

216
00:08:57,930 --> 00:08:59,490
And that's fine.

217
00:08:59,490 --> 00:09:00,990
What you would
really like to do is,

218
00:09:00,990 --> 00:09:03,090
as the overload load
keeps increasing

219
00:09:03,090 --> 00:09:06,690
and the throughput
saturates at the capacity--

220
00:09:06,690 --> 00:09:08,130
of course, that means that--

221
00:09:08,130 --> 00:09:08,880
what does it mean?

222
00:09:08,880 --> 00:09:11,220
Either the delays are
growing to infinity

223
00:09:11,220 --> 00:09:13,590
or packets are being
dropped, right?

224
00:09:13,590 --> 00:09:16,950
And what you would really like
intuitively is for the sources

225
00:09:16,950 --> 00:09:19,620
to realize that packets
are being dropped

226
00:09:19,620 --> 00:09:22,260
or they're not being delivered
in time, so maybe slow down.

227
00:09:22,260 --> 00:09:23,260
Something has to happen.

228
00:09:23,260 --> 00:09:25,177
But congestion collapse
is a worse phenomenon.

229
00:09:25,177 --> 00:09:27,840
What happens is, beyond a point,
your throughput [INAUDIBLE]

230
00:09:27,840 --> 00:09:31,800
drops, sometimes precipitously,
and it might go down to zero.

231
00:09:31,800 --> 00:09:35,810
So people were running
network applications--

232
00:09:35,810 --> 00:09:38,820
you know, FTP and remote
logins and so forth,

233
00:09:38,820 --> 00:09:40,000
email and so forth.

234
00:09:40,000 --> 00:09:44,340
And what they were finding was
that you could be running--

235
00:09:44,340 --> 00:09:47,850
the ratio between what the
capacity of the network was

236
00:09:47,850 --> 00:09:50,010
and what you were getting
when you were running

237
00:09:50,010 --> 00:09:54,690
was a factor of
100 to 1,000 worse.

238
00:09:54,690 --> 00:09:55,960
So this is a real collapse.

239
00:09:55,960 --> 00:09:58,168
I mean, you wouldn't be able
to get anything through.

240
00:09:58,168 --> 00:10:00,720
So people were talking about
going from, in those days,

241
00:10:00,720 --> 00:10:03,900
tens of kilobits per
second to bits per second.

242
00:10:03,900 --> 00:10:05,400
In fact, there was
a joke that there

243
00:10:05,400 --> 00:10:09,570
was a path in Berkeley between
the University of California

244
00:10:09,570 --> 00:10:11,490
and Lawrence Berkeley
Labs, which is probably

245
00:10:11,490 --> 00:10:13,950
400 meters from each other.

246
00:10:13,950 --> 00:10:17,340
And the network rate was such
that you could actually run up

247
00:10:17,340 --> 00:10:19,800
the hill with a
tape drive and you'd

248
00:10:19,800 --> 00:10:22,953
get 100 times higher
throughput than what you were

249
00:10:22,953 --> 00:10:24,120
getting through the network.

250
00:10:24,120 --> 00:10:26,328
And you know, this was not
even running up very fast.

251
00:10:26,328 --> 00:10:28,603
So this was a serious problem.

252
00:10:28,603 --> 00:10:30,520
This problem was dealt
with by multiple people

253
00:10:30,520 --> 00:10:32,360
who were working on it.

254
00:10:32,360 --> 00:10:34,810
And it led to a
set of algorithms

255
00:10:34,810 --> 00:10:39,580
where the idea was
that you would like--

256
00:10:39,580 --> 00:10:42,320
because all these switches and
routers were already deployed,

257
00:10:42,320 --> 00:10:44,260
people were interested
in end-to-end solutions

258
00:10:44,260 --> 00:10:45,280
to the problem.

259
00:10:45,280 --> 00:10:46,990
By end-to-end, I
mean solutions you

260
00:10:46,990 --> 00:10:49,750
could deploy at the centers and
the receivers in the network

261
00:10:49,750 --> 00:10:53,710
without worrying about what the
network was doing in between.

262
00:10:53,710 --> 00:10:56,860
The actual algorithm
that we all run today

263
00:10:56,860 --> 00:11:00,770
had its roots in an algorithm
developed by Van Jacobson

264
00:11:00,770 --> 00:11:03,213
at Lawrence Berkeley Lab.

265
00:11:03,213 --> 00:11:04,630
And there's a lot
of work that has

266
00:11:04,630 --> 00:11:07,047
been done since then by many
other people in the community

267
00:11:07,047 --> 00:11:07,580
as well.

268
00:11:07,580 --> 00:11:08,997
And in parallel,
there were people

269
00:11:08,997 --> 00:11:11,860
inside of Digital Equipment
Corporation over here

270
00:11:11,860 --> 00:11:14,530
in Massachusetts working
on similar problems.

271
00:11:14,530 --> 00:11:16,072
And they came up with ideas.

272
00:11:16,072 --> 00:11:17,530
And both these
ideas were basically

273
00:11:17,530 --> 00:11:21,280
the same idea, more or
less, except in the detail.

274
00:11:21,280 --> 00:11:24,910
And they also resembled what
we've seen with MAC protocols.

275
00:11:24,910 --> 00:11:28,570
The idea is that if the network
is working reasonably well,

276
00:11:28,570 --> 00:11:30,940
we're going to try to
be greedy and start

277
00:11:30,940 --> 00:11:33,820
to send faster and faster.

278
00:11:33,820 --> 00:11:36,520
At some point, we're going to
find that the network doesn't

279
00:11:36,520 --> 00:11:37,850
work so well.

280
00:11:37,850 --> 00:11:40,588
And we can determine that in
one of a few different ways.

281
00:11:40,588 --> 00:11:42,880
One way to determine that is
that packets start getting

282
00:11:42,880 --> 00:11:44,230
lost.

283
00:11:44,230 --> 00:11:47,500
And we will assume
that packets are

284
00:11:47,500 --> 00:11:51,370
lost because queues overflow
and congestion happens.

285
00:11:51,370 --> 00:11:53,230
We might also
alternatively assume

286
00:11:53,230 --> 00:11:56,200
that as queues in
the network grow,

287
00:11:56,200 --> 00:11:59,020
packets get delayed more and
more when the network starts

288
00:11:59,020 --> 00:12:00,640
to get congested.

289
00:12:00,640 --> 00:12:02,980
And if we find that the
roundtrip times are starting

290
00:12:02,980 --> 00:12:08,902
to increase, maybe we determined
that congestion has happened.

291
00:12:08,902 --> 00:12:10,610
Now, there's been 30
years of literature.

292
00:12:10,610 --> 00:12:12,650
The problem has not yet
been completely solved.

293
00:12:12,650 --> 00:12:15,910
And in fact, we have now
an active research project

294
00:12:15,910 --> 00:12:17,650
going on in my group
about how to deal

295
00:12:17,650 --> 00:12:20,500
with these problems in the
context of video and video

296
00:12:20,500 --> 00:12:23,290
conferencing in cellular,
in wireless networks

297
00:12:23,290 --> 00:12:26,230
that you run with your
phone, on your phone.

298
00:12:26,230 --> 00:12:28,870
So it's still an problem,
lots of interesting research.

299
00:12:28,870 --> 00:12:35,790
But the basic idea is
that you have to adapt

300
00:12:35,790 --> 00:12:37,080
to what the network is doing.

301
00:12:37,080 --> 00:12:40,020
And the way you adapt is by
watching things in the network.

302
00:12:40,020 --> 00:12:42,330
You watch where the
packets are being lost.

303
00:12:42,330 --> 00:12:44,700
You watch whether
delays are growing.

304
00:12:44,700 --> 00:12:47,580
You might watch
what the receiver's

305
00:12:47,580 --> 00:12:50,250
getting-- you know, how fast
is the receiver getting data

306
00:12:50,250 --> 00:12:52,110
from the center and the network.

307
00:12:52,110 --> 00:12:54,200
And the intuition
is the following--

308
00:12:54,200 --> 00:12:59,280
let's suppose that we were to
pick the correct window size.

309
00:12:59,280 --> 00:13:01,560
This goes to the sliding
window and the window size

310
00:13:01,560 --> 00:13:03,280
that you use.

311
00:13:03,280 --> 00:13:05,490
We said that the right
value of the window size

312
00:13:05,490 --> 00:13:07,980
is roughly the
bandwidth-delay product, where

313
00:13:07,980 --> 00:13:11,040
the bandwidth-delay product is
the product of the bottleneck

314
00:13:11,040 --> 00:13:14,048
link rate multiplied by
the minimum roundtrip time.

315
00:13:14,048 --> 00:13:15,840
But the problem is the
bottleneck-link rate

316
00:13:15,840 --> 00:13:17,170
is not fixed.

317
00:13:17,170 --> 00:13:19,320
It is in the lab we
studied, but in reality, you

318
00:13:19,320 --> 00:13:21,990
have many connections sharing
the network, many applications

319
00:13:21,990 --> 00:13:22,980
sharing the network.

320
00:13:22,980 --> 00:13:26,010
And people come and go, so
the rate keeps changing.

321
00:13:26,010 --> 00:13:29,020
At one moment, you might be
getting 100 kilobits a second.

322
00:13:29,020 --> 00:13:31,500
The next moment, you might be
getting a megabit per second.

323
00:13:31,500 --> 00:13:33,870
And on wireless networks,
it's even worse.

324
00:13:33,870 --> 00:13:36,780
Quite literally,
if I were to start

325
00:13:36,780 --> 00:13:40,470
an application on my phone now,
connecting to Verizon or AT&T,

326
00:13:40,470 --> 00:13:42,300
and if I step out
of this room, it's

327
00:13:42,300 --> 00:13:45,570
quite likely that the actual
[INAUDIBLE] experience

328
00:13:45,570 --> 00:13:48,870
by my phone might change
by a factor of four

329
00:13:48,870 --> 00:13:52,408
or a factor of eight
within two seconds.

330
00:13:52,408 --> 00:13:54,450
And that has to do, of
course, with the fact that

331
00:13:54,450 --> 00:13:55,575
the signal-to-noise ratio--

332
00:13:55,575 --> 00:13:59,100
I mean, we're surrounded
by thick walls and metal.

333
00:13:59,100 --> 00:14:01,308
And the moment I go out,
it's going to be different.

334
00:14:01,308 --> 00:14:02,850
So how do you deal
with this problem?

335
00:14:02,850 --> 00:14:04,440
There's this one
basic idea that's

336
00:14:04,440 --> 00:14:07,470
used that's a fundamental
idea, very important idea.

337
00:14:07,470 --> 00:14:10,450
And it's called
conservation of packets.

338
00:14:10,450 --> 00:14:12,370
It's the same idea that
you saw when you built

339
00:14:12,370 --> 00:14:13,578
your sliding window protocol.

340
00:14:13,578 --> 00:14:16,090
It says that when you put in
a packet into the network,

341
00:14:16,090 --> 00:14:18,300
and the packet
reaches the other end,

342
00:14:18,300 --> 00:14:21,910
and you get an acknowledgment
for the other end,

343
00:14:21,910 --> 00:14:25,290
it means that one packet
has left this pipe.

344
00:14:25,290 --> 00:14:26,790
If you view this
as that picture,

345
00:14:26,790 --> 00:14:28,290
as you see in that
picture up there,

346
00:14:28,290 --> 00:14:30,390
packets are like
water entering a pipe.

347
00:14:30,390 --> 00:14:33,060
And then they leave the
pipe, and then another one

348
00:14:33,060 --> 00:14:35,090
comes back.

349
00:14:35,090 --> 00:14:38,520
If you have managed to
somehow, by some magic,

350
00:14:38,520 --> 00:14:40,440
pick the appropriate
window size,

351
00:14:40,440 --> 00:14:44,250
then conservation of packets
is a good principle for you

352
00:14:44,250 --> 00:14:45,178
to apply.

353
00:14:45,178 --> 00:14:47,220
Because what it says is
that the only time you're

354
00:14:47,220 --> 00:14:49,770
allowed to put one more
packet into the network

355
00:14:49,770 --> 00:14:53,050
is when you're sure that a
packet has left the network.

356
00:14:53,050 --> 00:14:56,160
And the way you know that a
packet has left the network

357
00:14:56,160 --> 00:15:01,320
is because you receive an
acknowledgment for that packet.

358
00:15:01,320 --> 00:15:04,590
Now of course, this assumes that
you know the right window size.

359
00:15:04,590 --> 00:15:07,423
Conservation of packets has
another really nice advantage,

360
00:15:07,423 --> 00:15:09,090
which is that-- let's
say that you think

361
00:15:09,090 --> 00:15:11,910
you have the right window size.

362
00:15:11,910 --> 00:15:15,510
But in fact, more
traffic comes in,

363
00:15:15,510 --> 00:15:20,100
and the bandwidth, the rate
at which you can send data,

364
00:15:20,100 --> 00:15:21,900
reduces.

365
00:15:21,900 --> 00:15:26,550
What's going to happen is that
because other traffic came in,

366
00:15:26,550 --> 00:15:29,680
the roundtrip times
are going to grow,

367
00:15:29,680 --> 00:15:32,190
which means that
acknowledgments to your packets

368
00:15:32,190 --> 00:15:36,270
are going to come back a little
slower, which means that you

369
00:15:36,270 --> 00:15:37,530
have a natural slowdown.

370
00:15:37,530 --> 00:15:39,600
Because acknowledgments
come slower,

371
00:15:39,600 --> 00:15:44,860
you naturally slow down and
send packets a little slower.

372
00:15:44,860 --> 00:15:47,850
And then of course, then,
if the congestion persists,

373
00:15:47,850 --> 00:15:50,190
packets are going to get lost.

374
00:15:50,190 --> 00:15:52,500
And when packets
get lost, the trick

375
00:15:52,500 --> 00:15:55,585
is you have to reduce
your window size.

376
00:15:55,585 --> 00:15:57,210
So let's say you're
running at a window

377
00:15:57,210 --> 00:16:01,890
size in your lab of 50 packets
when you implement this.

378
00:16:01,890 --> 00:16:03,840
If you find that packets
are getting lost,

379
00:16:03,840 --> 00:16:05,730
you should drop
your window size.

380
00:16:05,730 --> 00:16:09,570
And one way to drop the
window size that TCP uses

381
00:16:09,570 --> 00:16:13,020
is to reduce it by one half.

382
00:16:13,020 --> 00:16:16,380
And then every time you
find that acknowledgments

383
00:16:16,380 --> 00:16:18,660
are coming back, you
get a little greedy

384
00:16:18,660 --> 00:16:21,270
and you try to increase
the window size.

385
00:16:21,270 --> 00:16:25,240
And there are many ways to
increase the window size.

386
00:16:25,240 --> 00:16:27,865
Now, all of this
stuff requires a way,

387
00:16:27,865 --> 00:16:29,740
when you start the
connection, when you start

388
00:16:29,740 --> 00:16:31,850
an application, what do you do?

389
00:16:31,850 --> 00:16:35,080
And I think you pointed out an
idea the last time when I first

390
00:16:35,080 --> 00:16:37,840
talked about this problem,
which is in the beginning,

391
00:16:37,840 --> 00:16:40,880
you let your window
size be one packet, OK?

392
00:16:40,880 --> 00:16:43,070
So you start your window
size at one packet.

393
00:16:43,070 --> 00:16:45,140
So it's like stop and wait.

394
00:16:45,140 --> 00:16:46,640
So at the beginning
of a connection,

395
00:16:46,640 --> 00:16:50,410
If I were to draw time here
against the window size,

396
00:16:50,410 --> 00:16:54,180
you start at one packet, and
you just ship that packet out.

397
00:16:54,180 --> 00:16:56,560
It takes an entire roundtrip
to get to the other side,

398
00:16:56,560 --> 00:16:58,300
you get an acknowledgment back.

399
00:16:58,300 --> 00:17:01,070
At that point, with
regular stop and wait,

400
00:17:01,070 --> 00:17:02,830
you keep the same
window size of 1,

401
00:17:02,830 --> 00:17:04,690
and you send one more packet.

402
00:17:04,690 --> 00:17:06,970
You're not being greedy enough.

403
00:17:06,970 --> 00:17:09,490
So one thing you can do is,
when you get one acknowledgment,

404
00:17:09,490 --> 00:17:12,220
you double the window size,
or rather, increase the window

405
00:17:12,220 --> 00:17:12,857
size by 1.

406
00:17:12,857 --> 00:17:14,440
Every time you get
an acknowledgement,

407
00:17:14,440 --> 00:17:16,420
you increase the
window size by 1.

408
00:17:16,420 --> 00:17:21,960
So the rule is, on
[INAUDIBLE] you take w

409
00:17:21,960 --> 00:17:25,329
and you go to w plus 1.

410
00:17:25,329 --> 00:17:26,869
What does that do?

411
00:17:26,869 --> 00:17:28,390
Well, after one
roundtrip, if I draw

412
00:17:28,390 --> 00:17:30,560
this in multiples of
the roundtrip time,

413
00:17:30,560 --> 00:17:34,540
this is one RTT,
this is two RTTs,

414
00:17:34,540 --> 00:17:38,600
this is three
RTTs, and so forth.

415
00:17:38,600 --> 00:17:41,890
So at the beginning,
at the zeroth RTT,

416
00:17:41,890 --> 00:17:43,660
your window size is 1.

417
00:17:43,660 --> 00:17:47,800
You get an acknowledgment,
you make your window size

418
00:17:47,800 --> 00:17:49,400
be 2, right, 1 plus 1.

419
00:17:49,400 --> 00:17:52,990
So at this point,
your window size is 2.

420
00:17:52,990 --> 00:17:58,120
What is the window
size after two RTTs?

421
00:17:58,120 --> 00:17:59,950
It's 4 because-- why is it 4?

422
00:17:59,950 --> 00:18:01,896
When you send out two packets--

423
00:18:01,896 --> 00:18:02,396
yes?

424
00:18:02,396 --> 00:18:02,810
AUDIENCE: You get
two [INAUDIBLE]..

425
00:18:02,810 --> 00:18:04,180
PROFESSOR: You get
two [INAUDIBLE] back.

426
00:18:04,180 --> 00:18:06,100
So for the first one,
you went from 2 to 3.

427
00:18:06,100 --> 00:18:07,690
Then, you went from 3 to 4.

428
00:18:07,690 --> 00:18:09,070
So your window size grows to 4.

429
00:18:12,340 --> 00:18:14,470
And then out here,
if there's no losses,

430
00:18:14,470 --> 00:18:15,760
then you haven't yet reached--

431
00:18:15,760 --> 00:18:17,950
the window size
hasn't yet reached

432
00:18:17,950 --> 00:18:20,230
the bandwidth-delay
product of the connection,

433
00:18:20,230 --> 00:18:22,380
you're increasing exponentially.

434
00:18:22,380 --> 00:18:24,950
So this is at 8, and so forth.

435
00:18:24,950 --> 00:18:27,190
You're growing fairly rapidly.

436
00:18:27,190 --> 00:18:29,650
And at some point, you're
going to grow too fast.

437
00:18:29,650 --> 00:18:32,530
Your window size
is going to exceed

438
00:18:32,530 --> 00:18:35,980
the bandwidth-delay
product plus the queue size

439
00:18:35,980 --> 00:18:38,450
of the bottleneck, causing
a packet to be lost.

440
00:18:38,450 --> 00:18:40,450
And at that point, you
can do a bunch of things.

441
00:18:40,450 --> 00:18:42,220
But one thing you can do
is to drop the window size

442
00:18:42,220 --> 00:18:42,950
by a factor of 2.

443
00:18:42,950 --> 00:18:45,940
So whenever that happens,
if there's a packet loss,

444
00:18:45,940 --> 00:18:47,800
you drop by a factor of 2.

445
00:18:47,800 --> 00:18:49,998
And you could continue to
try to grow exponentially,

446
00:18:49,998 --> 00:18:51,040
but that would be stupid.

447
00:18:51,040 --> 00:18:53,260
Because you would
grow exponentially,

448
00:18:53,260 --> 00:18:55,330
and if the network
conditions haven't changed,

449
00:18:55,330 --> 00:18:56,710
you're going to again drop.

450
00:18:56,710 --> 00:18:58,627
So at this point, you
could do something else.

451
00:18:58,627 --> 00:19:01,540
And what TCP does is to start
to grow linearly, rather

452
00:19:01,540 --> 00:19:02,540
than exponential growth.

453
00:19:02,540 --> 00:19:05,413
Once you experience congestion,
you start to grow linearly.

454
00:19:05,413 --> 00:19:07,330
And then maybe you
experience congestion here,

455
00:19:07,330 --> 00:19:09,730
you drop by one half
and grow linearly.

456
00:19:09,730 --> 00:19:12,250
And you have this sort
of sawtooth behavior.

457
00:19:12,250 --> 00:19:13,968
And for most web
connections that

458
00:19:13,968 --> 00:19:15,760
involve downloading a
small amount of data,

459
00:19:15,760 --> 00:19:16,900
you end over here.

460
00:19:16,900 --> 00:19:19,150
For video and everything
else, you go all the way.

461
00:19:19,150 --> 00:19:20,323
And this is one strategy.

462
00:19:20,323 --> 00:19:21,490
There are many, many others.

463
00:19:21,490 --> 00:19:24,550
And like I said, in
various kinds of networks,

464
00:19:24,550 --> 00:19:26,050
like wireless
networks, it turns out

465
00:19:26,050 --> 00:19:28,370
this approach is not
really that good.

466
00:19:28,370 --> 00:19:30,970
And there are open questions
around how you should actually

467
00:19:30,970 --> 00:19:33,203
design the system.

468
00:19:33,203 --> 00:19:34,870
Does everyone understand
the basic idea?

469
00:19:34,870 --> 00:19:36,953
This is an example of
adaptive congestion control.

470
00:19:36,953 --> 00:19:40,800
You'll look at this in 6.033
and in 6.829 in more detail

471
00:19:40,800 --> 00:19:42,310
if you took those classes.

472
00:19:42,310 --> 00:19:45,840
Any questions?

473
00:19:45,840 --> 00:19:48,130
OK.

474
00:19:48,130 --> 00:19:50,050
All right, I'm now
moving over to the 1990s.

475
00:19:50,050 --> 00:19:52,240
Nothing else interesting
happened in the '80s.

476
00:19:52,240 --> 00:19:57,010
But in the 1990s,
more things happened.

477
00:19:57,010 --> 00:20:00,580
ARPANET essentially ended as far
as universities and everybody

478
00:20:00,580 --> 00:20:01,720
else was concerned.

479
00:20:01,720 --> 00:20:03,610
And in fact, it transitioned
into-- you know,

480
00:20:03,610 --> 00:20:05,260
there were separate
military networks.

481
00:20:05,260 --> 00:20:09,520
And in 1991, Tim Berners-Lee,
who is also now here at MIT,

482
00:20:09,520 --> 00:20:14,260
a professor, invented a little
thing called the WorldWideWeb,

483
00:20:14,260 --> 00:20:15,292
called with one world.

484
00:20:15,292 --> 00:20:17,000
WorldWideWeb was the
name of the program.

485
00:20:17,000 --> 00:20:20,420
And I found this thing
which was very interesting.

486
00:20:20,420 --> 00:20:27,070
So he wrote a proposal
in 1989, I think,

487
00:20:27,070 --> 00:20:29,230
to CERN, where he was
working, to his boss at CERN.

488
00:20:29,230 --> 00:20:31,063
And it was called,
"Information Management--

489
00:20:31,063 --> 00:20:31,900
A Proposal."

490
00:20:31,900 --> 00:20:33,400
And there were all
these things, you

491
00:20:33,400 --> 00:20:36,700
know, about how what became
the web should work, with links

492
00:20:36,700 --> 00:20:37,540
and so forth.

493
00:20:37,540 --> 00:20:39,760
And his boss at the
time, on top wrote,

494
00:20:39,760 --> 00:20:42,790
"vague but interesting" as
his feedback on the proposal.

495
00:20:42,790 --> 00:20:45,400
Presumably, the interesting
part trumped the vague part,

496
00:20:45,400 --> 00:20:49,000
and allowed him to actually
proceed on this project, which

497
00:20:49,000 --> 00:20:50,420
became the World Wide Web.

498
00:20:50,420 --> 00:20:52,727
Now, obviously, it's been
tremendously successful.

499
00:20:55,470 --> 00:20:58,160
Now, by the
mid-1990s, the NSFNET,

500
00:20:58,160 --> 00:21:01,580
which was the backbone
connecting the US, various US

501
00:21:01,580 --> 00:21:03,560
organizations, the
government decided

502
00:21:03,560 --> 00:21:06,710
to essentially get out of
the internet service provider

503
00:21:06,710 --> 00:21:07,400
business.

504
00:21:07,400 --> 00:21:09,020
Or rather, the
government decided not

505
00:21:09,020 --> 00:21:10,490
to fund that activity anymore.

506
00:21:10,490 --> 00:21:12,050
And many of you
have probably heard

507
00:21:12,050 --> 00:21:14,340
about this joke about Al
Gore inventing the internet

508
00:21:14,340 --> 00:21:16,070
and not inventing the
internet, and people saying he

509
00:21:16,070 --> 00:21:17,280
didn't invent the internet.

510
00:21:17,280 --> 00:21:20,480
Well, there's sort of a
little bit of truth in this.

511
00:21:20,480 --> 00:21:23,450
Al Gore was very instrumental
in the government

512
00:21:23,450 --> 00:21:26,450
kind of getting out of
the internet business,

513
00:21:26,450 --> 00:21:29,065
and was involved in
committees that set up

514
00:21:29,065 --> 00:21:31,190
regulations that led to
internet service providers,

515
00:21:31,190 --> 00:21:34,220
commercial internet service
providers actually forming,

516
00:21:34,220 --> 00:21:36,750
and commercial ISPs
starting to take off,

517
00:21:36,750 --> 00:21:39,050
which was a really, really
big change for the internet.

518
00:21:39,050 --> 00:21:41,990
Because no longer was
it the case that there's

519
00:21:41,990 --> 00:21:44,930
this one organization
and one backbone network

520
00:21:44,930 --> 00:21:48,500
that connects MIT and Harvard
and everybody else together,

521
00:21:48,500 --> 00:21:49,850
and all the companies together.

522
00:21:49,850 --> 00:21:52,970
You had many, many people who
could offer internet service,

523
00:21:52,970 --> 00:21:55,530
and in fact compete
with each other.

524
00:21:55,530 --> 00:21:58,730
The idea was the
internet service

525
00:21:58,730 --> 00:22:00,800
providers or different
network operators have

526
00:22:00,800 --> 00:22:03,020
to cooperate with
each other because we

527
00:22:03,020 --> 00:22:05,300
are interested in connecting
everybody on the internet

528
00:22:05,300 --> 00:22:06,380
together.

529
00:22:06,380 --> 00:22:08,403
But they also compete
with each other.

530
00:22:08,403 --> 00:22:10,820
And their reason to compete
is they compete for customers.

531
00:22:10,820 --> 00:22:13,920
If I'm a customer of Verizon,
I'm not a customer of Comcast,

532
00:22:13,920 --> 00:22:14,510
for example.

533
00:22:14,510 --> 00:22:17,870
And yet, Verizon and
Comcast and other ISPs

534
00:22:17,870 --> 00:22:20,160
have to actually cooperate
to get packets through.

535
00:22:20,160 --> 00:22:21,230
So how do you do this?

536
00:22:21,230 --> 00:22:24,170
And it turns out that
this is a tougher problem

537
00:22:24,170 --> 00:22:26,000
than you might think.

538
00:22:26,000 --> 00:22:29,210
And the world-- people
invented this protocol

539
00:22:29,210 --> 00:22:32,310
called BGP, or the
Border Gateway protocol,

540
00:22:32,310 --> 00:22:33,790
which uses an idea
that we've seen.

541
00:22:33,790 --> 00:22:36,980
It uses Path Vector
to solve this problem.

542
00:22:36,980 --> 00:22:39,695
And I'll talk a little
bit about that as well.

543
00:22:39,695 --> 00:22:41,570
The other thing that
happened in the internet

544
00:22:41,570 --> 00:22:45,860
was that IP addresses
started to get depleted.

545
00:22:45,860 --> 00:22:47,810
And we saw why the
last time-- everybody

546
00:22:47,810 --> 00:22:49,970
wanted those Class B addresses.

547
00:22:49,970 --> 00:22:53,120
And now, in fact
quite literally,

548
00:22:53,120 --> 00:22:57,050
there are no more IP
version 4 IP addresses.

549
00:22:57,050 --> 00:22:59,960
And so there was a lot
of work done on moving

550
00:22:59,960 --> 00:23:01,760
to other versions of IP.

551
00:23:01,760 --> 00:23:05,240
But the part that is
interesting is this idea

552
00:23:05,240 --> 00:23:07,980
of classless addressing.

553
00:23:07,980 --> 00:23:11,750
So the idea was rather
than have organizations

554
00:23:11,750 --> 00:23:15,320
that either have to have
2 to the 24 addresses,

555
00:23:15,320 --> 00:23:17,670
or 2 to the 16 addresses,
or 2 to the 8 addresses,

556
00:23:17,670 --> 00:23:20,520
let's allow organizations to
have any number of addresses.

557
00:23:20,520 --> 00:23:21,920
So I want to tell you
a little bit about what

558
00:23:21,920 --> 00:23:23,462
an IP address means,
because everyone

559
00:23:23,462 --> 00:23:25,190
has seen an IP address.

560
00:23:25,190 --> 00:23:27,350
I want to explain what it
means, and how it really

561
00:23:27,350 --> 00:23:30,090
actually works.

562
00:23:30,090 --> 00:23:33,595
So if you look at an
IP address, 18.31.0.82,

563
00:23:33,595 --> 00:23:36,410
which is one of
my machines, that

564
00:23:36,410 --> 00:23:40,010
dotted decimal notation
with human-readable numbers

565
00:23:40,010 --> 00:23:41,790
used to make sense
in the old days.

566
00:23:41,790 --> 00:23:44,780
It used to be that this is
a Class A address from MIT.

567
00:23:44,780 --> 00:23:48,680
It's 18 dot whatever, and
MIT owned all of that stuff.

568
00:23:48,680 --> 00:23:50,360
Now, that also
happens to be true,

569
00:23:50,360 --> 00:23:53,182
but as far as the network
infrastructure and the switches

570
00:23:53,182 --> 00:23:54,890
are concerned, this
thing is nothing more

571
00:23:54,890 --> 00:23:57,870
than a 32-bit number
that looks like that, OK?

572
00:24:00,480 --> 00:24:03,480
Now, when a packet
with that number

573
00:24:03,480 --> 00:24:05,520
shows up at the switch
with a destination

574
00:24:05,520 --> 00:24:08,970
address with that number,
really what happens

575
00:24:08,970 --> 00:24:10,740
is that the switch,
the router does not

576
00:24:10,740 --> 00:24:14,128
have an entry for every
one of those destinations

577
00:24:14,128 --> 00:24:14,670
in the world.

578
00:24:14,670 --> 00:24:16,840
If it did, it just would
be too much information.

579
00:24:16,840 --> 00:24:19,110
So what it has is
information corresponding

580
00:24:19,110 --> 00:24:21,140
to a certain prefix.

581
00:24:21,140 --> 00:24:24,300
Now, that prefix could
be of arbitrary length.

582
00:24:24,300 --> 00:24:28,050
It could have an entry in
it with just the first 8

583
00:24:28,050 --> 00:24:33,510
bits, which would signify
that all packets that show up

584
00:24:33,510 --> 00:24:37,350
with that first prefix of 8
bits would have to be forwarded

585
00:24:37,350 --> 00:24:38,790
according to a rule--

586
00:24:38,790 --> 00:24:41,970
according to the link that was
set for those first 8 bits.

587
00:24:41,970 --> 00:24:45,120
Or it could have an entry in
the routing table for 16 bits.

588
00:24:45,120 --> 00:24:47,730
Or it could have an entry in
the routing table for 19 bits,

589
00:24:47,730 --> 00:24:48,420
or whatever.

590
00:24:48,420 --> 00:24:50,775
And that depends on how
the routing system--

591
00:24:50,775 --> 00:24:53,640
how we advertise the routes,
and what it contains.

592
00:24:53,640 --> 00:24:55,320
So there's an
important lesson here.

593
00:24:55,320 --> 00:24:58,170
When a switch advertises
a route for a destination,

594
00:24:58,170 --> 00:25:01,110
on the internet, the destination
is not the destination of--

595
00:25:01,110 --> 00:25:03,690
is not the IP address
of an endpoint.

596
00:25:03,690 --> 00:25:08,310
But what that destination
is is a prefix

597
00:25:08,310 --> 00:25:11,550
that represents a range of
IP addresses, all of which

598
00:25:11,550 --> 00:25:16,350
are forwarded the same
way by the switch.

599
00:25:16,350 --> 00:25:18,930
So one way of writing
this in notation

600
00:25:18,930 --> 00:25:22,410
that we can understand as human
beings more conveniently is

601
00:25:22,410 --> 00:25:26,190
this idea of writing
it as 18 slash 8.

602
00:25:26,190 --> 00:25:27,780
What that means is--

603
00:25:27,780 --> 00:25:33,540
this notation stands for all IP
addresses which have the first

604
00:25:33,540 --> 00:25:38,100
eight bits in common,
which will be 0001011010,

605
00:25:38,100 --> 00:25:41,160
which stands for the
human readable number 18.

606
00:25:41,160 --> 00:25:45,720
And it contains all 2 to the
24 addresses corresponding

607
00:25:45,720 --> 00:25:47,380
to that prefix.

608
00:25:47,380 --> 00:25:49,050
So as another example,
if I have that

609
00:25:49,050 --> 00:25:52,260
in my routing table
with a slash 17,

610
00:25:52,260 --> 00:25:56,580
it stands for 2 to
the 15 consecutive IP

611
00:25:56,580 --> 00:26:01,950
addresses, all of which share
the first 17 bits in common,

612
00:26:01,950 --> 00:26:03,150
OK?

613
00:26:03,150 --> 00:26:05,550
Does this makes sense?

614
00:26:05,550 --> 00:26:07,050
So this is what an
IP address means.

615
00:26:07,050 --> 00:26:08,550
And as far as a
switch is concerned,

616
00:26:08,550 --> 00:26:12,420
a routing table
entry is not the IP--

617
00:26:12,420 --> 00:26:13,890
it's not a destination
IP address.

618
00:26:13,890 --> 00:26:15,223
But it's something in this form.

619
00:26:15,223 --> 00:26:19,710
It contains a prefix, and
it contains a [INAUDIBLE]..

620
00:26:19,710 --> 00:26:27,090
So in human notation, 18.31
slash 17 would be 17--

621
00:26:27,090 --> 00:26:32,700
2 to the 15 bits, which share
the first 17 bits in common.

622
00:26:32,700 --> 00:26:35,400
So what this means is
that with this notation,

623
00:26:35,400 --> 00:26:37,590
inside the forwarding
table, you can have an entry

624
00:26:37,590 --> 00:26:43,230
for one IP address, or two,
or four, or eight, or 16,

625
00:26:43,230 --> 00:26:48,060
all the way up to whatever
the maximum is, right?

626
00:26:48,060 --> 00:26:51,600
So it allows us to build
networks of different sizes,

627
00:26:51,600 --> 00:26:54,213
and let that network's
identifier be known

628
00:26:54,213 --> 00:26:55,380
to the rest of the internet.

629
00:26:55,380 --> 00:26:58,350
Now, in principle, you could
put every host in the network.

630
00:26:58,350 --> 00:27:00,690
And that would mean that you
have an entry that-- each

631
00:27:00,690 --> 00:27:02,940
of which looks like a slash 32.

632
00:27:02,940 --> 00:27:06,450
If I did a slash 32, it meant
that it's an individual IP

633
00:27:06,450 --> 00:27:07,680
address.

634
00:27:07,680 --> 00:27:08,823
But that wouldn't scale.

635
00:27:08,823 --> 00:27:10,740
And so we want to allow
people the flexibility

636
00:27:10,740 --> 00:27:12,750
of having very
different ranges sitting

637
00:27:12,750 --> 00:27:15,060
inside the routing system.

638
00:27:15,060 --> 00:27:16,170
And there's one more rule.

639
00:27:16,170 --> 00:27:17,310
And this rule is
important because I

640
00:27:17,310 --> 00:27:18,977
want to tell you this
rule-- because I'm

641
00:27:18,977 --> 00:27:21,630
going to tell you how YouTube
was hijacked by an ISP

642
00:27:21,630 --> 00:27:22,620
in Pakistan.

643
00:27:22,620 --> 00:27:24,720
And it relies on
your understanding

644
00:27:24,720 --> 00:27:26,910
this particular forwarding rule.

645
00:27:26,910 --> 00:27:29,610
And then I'll tell you
about how an ISP in China

646
00:27:29,610 --> 00:27:32,040
hijacked 15% of the internet
for a couple of hours,

647
00:27:32,040 --> 00:27:33,270
for a few hours.

648
00:27:33,270 --> 00:27:35,340
And that didn't
require this rule,

649
00:27:35,340 --> 00:27:37,620
but it's two examples I
want to tell you about.

650
00:27:37,620 --> 00:27:39,600
But let me explain the rule--

651
00:27:39,600 --> 00:27:41,880
the forwarding at a
switch uses an idea called

652
00:27:41,880 --> 00:27:43,590
the longest prefix match.

653
00:27:43,590 --> 00:27:46,440
So what that means is
that if you have entries

654
00:27:46,440 --> 00:27:48,390
in your forwarding table--

655
00:27:48,390 --> 00:27:49,640
let's take those two examples.

656
00:27:49,640 --> 00:27:51,890
And let's say I have an entry
in the forwarding table.

657
00:27:51,890 --> 00:27:54,810
This is a particular switch,
I have a forwarding table

658
00:27:54,810 --> 00:27:56,200
or a routing table.

659
00:27:56,200 --> 00:27:59,730
And the first entry
says 18 slash 8.

660
00:27:59,730 --> 00:28:05,400
So what this means is it's 2
to the 24 addresses that share

661
00:28:05,400 --> 00:28:07,830
the first eight bits,
which is whatever

662
00:28:07,830 --> 00:28:10,500
corresponds to 18.0.0--

663
00:28:10,500 --> 00:28:11,870
whatever it is, right?

664
00:28:26,310 --> 00:28:28,320
And then let's say I
have another entry, which

665
00:28:28,320 --> 00:28:31,500
is some 18.31 slash 17.

666
00:28:31,500 --> 00:28:33,190
And what that would
be, of course,

667
00:28:33,190 --> 00:28:36,240
is 2 to the 15 addresses.

668
00:28:36,240 --> 00:28:39,060
And the prefix would be shown
in that picture there, whatever

669
00:28:39,060 --> 00:28:41,450
the first 17 bits--
so some 17 bits.

670
00:28:47,080 --> 00:28:51,460
Now, if the switch received
a packet with an IP address,

671
00:28:51,460 --> 00:28:54,466
and that IP address matched
multiple entries-- you know,

672
00:28:54,466 --> 00:28:58,075
you might have other
entries sitting here.

673
00:28:58,075 --> 00:29:02,260
Let's say that I have
128.32 slash something.

674
00:29:02,260 --> 00:29:04,150
And I might have
various other entries

675
00:29:04,150 --> 00:29:05,800
sitting in my forwarding table.

676
00:29:05,800 --> 00:29:08,290
When a packet arrives,
it may, in general,

677
00:29:08,290 --> 00:29:10,090
match multiple
entries here, right?

678
00:29:10,090 --> 00:29:13,780
Because the packet has a certain
bit string in its destination

679
00:29:13,780 --> 00:29:14,530
address.

680
00:29:14,530 --> 00:29:18,370
And that destination address
now matches multiple of these.

681
00:29:18,370 --> 00:29:21,610
It could match one or more
of these entries here.

682
00:29:21,610 --> 00:29:24,280
What an IP router does
when it gets such a packet

683
00:29:24,280 --> 00:29:28,720
is to find the entry which
matches in the longest prefix.

684
00:29:28,720 --> 00:29:31,510
In other words, the
routing table entry

685
00:29:31,510 --> 00:29:35,080
that corresponds to
the longest prefix

686
00:29:35,080 --> 00:29:39,160
match between the destination
address of the packet

687
00:29:39,160 --> 00:29:42,070
and between the entry
in the forwarding table

688
00:29:42,070 --> 00:29:44,590
is what you use to
send the packet on.

689
00:29:44,590 --> 00:29:48,910
So if you got a packet
that was 18.31.6.5

690
00:29:48,910 --> 00:29:51,550
and it happened to match this
entry, it would go on one link.

691
00:29:51,550 --> 00:29:53,490
Let's say this was link 1.

692
00:29:53,490 --> 00:29:55,990
And if you have got this other
thing that didn't match this,

693
00:29:55,990 --> 00:29:58,073
but matched that, you might
have a different link.

694
00:29:58,073 --> 00:29:59,360
Let's call it link 0.

695
00:29:59,360 --> 00:30:02,320
So the output link that you use
depends on the longest prefix

696
00:30:02,320 --> 00:30:03,400
match.

697
00:30:03,400 --> 00:30:06,110
And MIT and many organizations
use this extremely well.

698
00:30:06,110 --> 00:30:09,790
So I was remarking to some of
you at the end of last time

699
00:30:09,790 --> 00:30:10,360
that--

700
00:30:10,360 --> 00:30:12,970
You know, it's funny, MIT
has multiple internet service

701
00:30:12,970 --> 00:30:13,540
providers.

702
00:30:13,540 --> 00:30:17,200
And it turns out that if
I use this network here

703
00:30:17,200 --> 00:30:19,180
and I download-- you
know, I go to linux.org,

704
00:30:19,180 --> 00:30:21,490
which is a place you
could download Linux code.

705
00:30:21,490 --> 00:30:24,740
If I go from here, it so
happens that MIT users

706
00:30:24,740 --> 00:30:27,310
level three, which is I think
the world's biggest, or US's

707
00:30:27,310 --> 00:30:30,190
biggest internet service
provider to get those packets.

708
00:30:30,190 --> 00:30:33,160
The same thing-- if I just go
up to [? Stata, ?] and I connect

709
00:30:33,160 --> 00:30:36,240
to the [? Stata ?] wireless,
and go to linux.org,

710
00:30:36,240 --> 00:30:38,980
packets from linux.org come back
to me through a different ISP,

711
00:30:38,980 --> 00:30:40,090
Cogent.

712
00:30:40,090 --> 00:30:43,810
So MIT has decided that it wants
to load balance its traffic.

713
00:30:43,810 --> 00:30:47,830
So it advertises the prefix
corresponding to the network

714
00:30:47,830 --> 00:30:50,650
in this room, whatever the
Wi-Fi network in this room,

715
00:30:50,650 --> 00:30:52,360
through one of the ISPs.

716
00:30:52,360 --> 00:30:55,840
And it advertises the
other prefix in Stat

717
00:30:55,840 --> 00:30:56,890
through the other ISP.

718
00:30:56,890 --> 00:30:59,530
And it does it presumably
to load balance traffic.

719
00:30:59,530 --> 00:31:02,020
And it also has this idea
that if one of those links

720
00:31:02,020 --> 00:31:04,120
were to fail, it would
switch the traffic

721
00:31:04,120 --> 00:31:05,350
through the other link.

722
00:31:05,350 --> 00:31:06,820
Organizations do
this because they

723
00:31:06,820 --> 00:31:09,325
would like to provide
good service to the people

724
00:31:09,325 --> 00:31:11,332
inside their organization.

725
00:31:11,332 --> 00:31:12,790
So the longest
prefix match is very

726
00:31:12,790 --> 00:31:17,140
crucial to how this stuff
really kind of works.

727
00:31:17,140 --> 00:31:18,938
So keep that in mind.

728
00:31:18,938 --> 00:31:20,230
I'm going to come back to this.

729
00:31:20,230 --> 00:31:21,120
On to the next slide.

730
00:31:25,940 --> 00:31:29,790
In the rest of the 1990s, a few
interesting things happened.

731
00:31:29,790 --> 00:31:32,930
One of them was that work
started on this new proposal

732
00:31:32,930 --> 00:31:37,100
for IP called IPv6, which said,
let's not use 32-bit addresses.

733
00:31:37,100 --> 00:31:39,050
Let's go to 128-bit
bigger addresses

734
00:31:39,050 --> 00:31:41,330
and try to solve the
address depletion problem.

735
00:31:41,330 --> 00:31:43,460
IPv6 has taken a
really, really long time

736
00:31:43,460 --> 00:31:46,080
to get deployed for reasons
I won't go into here.

737
00:31:46,080 --> 00:31:47,805
But it seems to
be happening now.

738
00:31:47,805 --> 00:31:50,180
But people keep saying that
it seems to be happening now.

739
00:31:50,180 --> 00:31:51,600
I said that three
years ago when I

740
00:31:51,600 --> 00:31:52,850
did the wrap-up in this class.

741
00:31:52,850 --> 00:31:54,878
So some time-- at some
point in the future,

742
00:31:54,878 --> 00:31:56,420
that statement will
actually be true.

743
00:31:59,690 --> 00:32:02,660
Now, you know, everybody
knows about Google

744
00:32:02,660 --> 00:32:05,490
reinventing how search is done,
and it starts to dominate.

745
00:32:05,490 --> 00:32:07,100
Another thing that
happened in 1998

746
00:32:07,100 --> 00:32:08,760
was content
distribution networks

747
00:32:08,760 --> 00:32:10,200
started getting created.

748
00:32:10,200 --> 00:32:13,260
And these are networks that
you deploy as overlay networks

749
00:32:13,260 --> 00:32:15,590
atop the internet to
serve content better,

750
00:32:15,590 --> 00:32:17,960
in a more reliable way.

751
00:32:17,960 --> 00:32:20,135
Now, in the 2000s,
the internet matured.

752
00:32:20,135 --> 00:32:21,860
And I have the top
five things that I

753
00:32:21,860 --> 00:32:25,190
think happened in the networking
industry and the networking

754
00:32:25,190 --> 00:32:25,980
world in 2000.

755
00:32:25,980 --> 00:32:31,840
So this dot-com bust happened,
and then 9/11 happened.

756
00:32:31,840 --> 00:32:33,590
The first thing that
happened was the rise

757
00:32:33,590 --> 00:32:34,610
of peer-to-peer networks.

758
00:32:34,610 --> 00:32:36,152
I'm sure many of
you have used this--

759
00:32:36,152 --> 00:32:39,507
Gnutella and Freenet,
BitTorrent is the latest one.

760
00:32:39,507 --> 00:32:41,840
There was a lot of research
done, including here at MIT,

761
00:32:41,840 --> 00:32:44,120
on how you build these
peer-to-peer networks,

762
00:32:44,120 --> 00:32:47,010
the idea being, you don't have
a central point of failure.

763
00:32:47,010 --> 00:32:49,263
And you can use this
to distribute files

764
00:32:49,263 --> 00:32:50,180
extremely efficiently.

765
00:32:50,180 --> 00:32:52,160
I mean, BitTorrent is
still highly dominant.

766
00:32:52,160 --> 00:32:55,348
And distributed hash
tables like Chord,

767
00:32:55,348 --> 00:32:57,890
which was developed here, and
other schemes that are used now

768
00:32:57,890 --> 00:33:01,070
by systems like Skype, they
are used inside data centers

769
00:33:01,070 --> 00:33:01,723
like Amazon.

770
00:33:01,723 --> 00:33:03,140
If you go to Amazon
and buy stuff,

771
00:33:03,140 --> 00:33:05,480
it uses a system
called Dynamo, which

772
00:33:05,480 --> 00:33:08,360
is a key value store that
basically builds a distributed

773
00:33:08,360 --> 00:33:08,930
hash table.

774
00:33:08,930 --> 00:33:11,780
So it's had a lot of
impact, both in data centers

775
00:33:11,780 --> 00:33:15,763
and in systems like Skype.

776
00:33:15,763 --> 00:33:17,180
The second thing
that happened was

777
00:33:17,180 --> 00:33:21,350
that in the early to mid-2000s,
security became a huge deal.

778
00:33:21,350 --> 00:33:23,450
People started attacking
the internet, which

779
00:33:23,450 --> 00:33:25,640
came as somewhat of a
surprise to people who grew up

780
00:33:25,640 --> 00:33:27,140
in the good old
days of the internet

781
00:33:27,140 --> 00:33:30,080
where, as I mentioned
last time, computers

782
00:33:30,080 --> 00:33:32,360
with root passwords that
were empty because everybody

783
00:33:32,360 --> 00:33:33,248
could be trusted.

784
00:33:33,248 --> 00:33:35,540
And then they found that as
people started making money

785
00:33:35,540 --> 00:33:37,123
on the internet,
people started trying

786
00:33:37,123 --> 00:33:40,550
to attack the internet as well.

787
00:33:40,550 --> 00:33:42,020
Denial of service
attacks started,

788
00:33:42,020 --> 00:33:44,420
where people would launch
attacks on websites.

789
00:33:44,420 --> 00:33:47,840
And they would often
use it to extort money.

790
00:33:47,840 --> 00:33:50,112
This would be like,
if you don't pay me,

791
00:33:50,112 --> 00:33:52,070
I'm going to continue to
pummel your website so

792
00:33:52,070 --> 00:33:53,862
that you can't sell
flowers, or whatever it

793
00:33:53,862 --> 00:33:56,990
is you were doing on the web.

794
00:33:56,990 --> 00:33:58,940
People found
vulnerabilities in software,

795
00:33:58,940 --> 00:34:01,910
and there were many worms that
spread, often pretty quickly.

796
00:34:01,910 --> 00:34:04,520
SQL slammer is a particularly
interesting one of these.

797
00:34:04,520 --> 00:34:08,389
We studied this stuff in 829
and in 6.033 in some detail.

798
00:34:08,389 --> 00:34:11,150
But this was remarkable
because in 30 minutes,

799
00:34:11,150 --> 00:34:12,800
it clogged the world's networks.

800
00:34:12,800 --> 00:34:14,630
I mean, here's a
picture of a screenshot.

801
00:34:14,630 --> 00:34:22,130
This was at 5:30 in the morning,
I guess UTC, Greenwich Time.

802
00:34:22,130 --> 00:34:26,210
And you know,
nothing's going on.

803
00:34:26,210 --> 00:34:29,630
And then half an hour
later, the blue splotches

804
00:34:29,630 --> 00:34:31,219
show the networks
that were clogged.

805
00:34:31,219 --> 00:34:33,580
And almost every computer
that was vulnerable to this--

806
00:34:33,580 --> 00:34:34,699
there weren't that
many computers,

807
00:34:34,699 --> 00:34:35,940
relative to the
world's computers,

808
00:34:35,940 --> 00:34:37,219
that were vulnerable to this.

809
00:34:37,219 --> 00:34:39,230
But all these
networks got hammered,

810
00:34:39,230 --> 00:34:41,360
and in fact, traffic
came to a halt.

811
00:34:41,360 --> 00:34:45,020
And this worm showed
that the power

812
00:34:45,020 --> 00:34:48,110
of spreading-- if
machines trust each other,

813
00:34:48,110 --> 00:34:51,110
either implicitly
or explicitly, it's

814
00:34:51,110 --> 00:34:53,840
very easy to actually find a
vulnerability in one and then

815
00:34:53,840 --> 00:34:55,560
spread very, very quickly.

816
00:34:55,560 --> 00:34:58,820
So a lot of work was done on
how to handle worm attacks.

817
00:34:58,820 --> 00:35:02,345
A lot of this has to do
with putting things inside

818
00:35:02,345 --> 00:35:04,220
of networks, which is
running at high speeds,

819
00:35:04,220 --> 00:35:06,620
to identify patterns that--

820
00:35:06,620 --> 00:35:08,570
in the payload of--
in the data that's

821
00:35:08,570 --> 00:35:12,020
being sent in packets to quickly
identify that this corresponds

822
00:35:12,020 --> 00:35:14,450
to a worm, and then throw
those packets away before they

823
00:35:14,450 --> 00:35:16,488
hit the actual endpoints.

824
00:35:16,488 --> 00:35:18,530
Right now, we don't see
too many worms spreading.

825
00:35:18,530 --> 00:35:21,680
The ones that spread now
are slow-spreading worms

826
00:35:21,680 --> 00:35:24,680
that are often spread
by human contact.

827
00:35:24,680 --> 00:35:27,200
It's like people clicking on
links they shouldn't click on.

828
00:35:27,200 --> 00:35:30,230
It runs the program, finds a
vulnerability on their machine,

829
00:35:30,230 --> 00:35:32,690
and then it resides
on their machine.

830
00:35:32,690 --> 00:35:35,870
And often, these are then used
to create these big botnets

831
00:35:35,870 --> 00:35:38,540
that are used to launch
denial-of-service attacks,

832
00:35:38,540 --> 00:35:41,967
or are often used to send spam
and do other things like that.

833
00:35:41,967 --> 00:35:44,300
So they're still going on,
but you don't hear about them

834
00:35:44,300 --> 00:35:46,820
in the newspaper.

835
00:35:46,820 --> 00:35:48,350
Spam became a huge problem.

836
00:35:48,350 --> 00:35:51,950
And it continues to be
somewhat of a problem,

837
00:35:51,950 --> 00:35:54,920
though these days, the
distinction between spam

838
00:35:54,920 --> 00:35:59,210
and internet marketing
is kind of coming down--

839
00:35:59,210 --> 00:36:00,710
the gap's closing.

840
00:36:00,710 --> 00:36:04,852
But by and large, spam
now is, while I wouldn't

841
00:36:04,852 --> 00:36:06,560
say it's a solved
problem, it's generally

842
00:36:06,560 --> 00:36:09,830
combated by big
organizations that

843
00:36:09,830 --> 00:36:11,930
have enough data, enough
email coming in that they

844
00:36:11,930 --> 00:36:15,500
can identify spam and
then filter those away.

845
00:36:15,500 --> 00:36:17,060
Route hijacking is
the other problem.

846
00:36:17,060 --> 00:36:18,550
That remains a
huge vulnerability.

847
00:36:18,550 --> 00:36:21,050
So I want to tell you about two
examples of route hijacking.

848
00:36:21,050 --> 00:36:23,702
And I don't think there's easy--

849
00:36:23,702 --> 00:36:25,160
the technical side
of this problem,

850
00:36:25,160 --> 00:36:26,630
we understand how to solve.

851
00:36:26,630 --> 00:36:30,330
But how to deploy good
solutions is still unclear.

852
00:36:30,330 --> 00:36:32,868
So the first example is from--

853
00:36:32,868 --> 00:36:34,160
this problem has been going on.

854
00:36:34,160 --> 00:36:36,535
Every three years, you see a
big route hijacking problem.

855
00:36:36,535 --> 00:36:38,735
The first one was from 2008--

856
00:36:38,735 --> 00:36:40,850
I think it was
2008, where YouTube

857
00:36:40,850 --> 00:36:43,250
was unavailable to
people for a few hours

858
00:36:43,250 --> 00:36:45,770
everywhere in the world.

859
00:36:45,770 --> 00:36:48,762
Now, you could argue
whether watching cats dance

860
00:36:48,762 --> 00:36:49,970
or whatever is not important.

861
00:36:49,970 --> 00:36:51,970
But the fact is that
YouTube has a lot of money.

862
00:36:51,970 --> 00:36:53,990
Google has a lot of
money, and even they

863
00:36:53,990 --> 00:36:56,070
were vulnerable to this trouble.

864
00:36:56,070 --> 00:36:58,580
The second example was
a little different.

865
00:36:58,580 --> 00:37:03,410
China Telecom managed
to get about 15%,

866
00:37:03,410 --> 00:37:06,530
roughly speaking, of
the internet traffic

867
00:37:06,530 --> 00:37:07,640
to go through them.

868
00:37:07,640 --> 00:37:09,560
Now, the interesting
thing about that attack

869
00:37:09,560 --> 00:37:12,980
is that it wasn't
clear it was an attack.

870
00:37:12,980 --> 00:37:18,108
I should just say that
error, or failure, was

871
00:37:18,108 --> 00:37:19,400
that people didn't even notice.

872
00:37:19,400 --> 00:37:21,818
Because unlike
YouTube, where you go,

873
00:37:21,818 --> 00:37:24,110
you couldn't get your data,
and then people noticed it,

874
00:37:24,110 --> 00:37:27,170
and then they were scrambling
to solve the problem,

875
00:37:27,170 --> 00:37:30,050
with the Chinese attack, or
the Chinese vulnerability,

876
00:37:30,050 --> 00:37:31,790
what happened was
that China Telecom

877
00:37:31,790 --> 00:37:34,572
managed to divert the
traffic that wasn't supposed

878
00:37:34,572 --> 00:37:35,780
to go through them-- to them.

879
00:37:35,780 --> 00:37:37,130
And then they
forwarded the traffic

880
00:37:37,130 --> 00:37:38,672
on to the rest of
their destinations,

881
00:37:38,672 --> 00:37:40,110
the actual destinations.

882
00:37:40,110 --> 00:37:41,720
So you would find
things like, instead

883
00:37:41,720 --> 00:37:43,700
of my latency being
100 milliseconds,

884
00:37:43,700 --> 00:37:47,120
it might be 500
milliseconds, which is--

885
00:37:47,120 --> 00:37:49,190
you may not even notice.

886
00:37:49,190 --> 00:37:50,690
Or sometimes, you
notice it, and you

887
00:37:50,690 --> 00:37:52,490
go, ah, yeah, that's just the
internet being the internet,

888
00:37:52,490 --> 00:37:52,990
you know?

889
00:37:52,990 --> 00:37:54,260
Sometimes, that happens.

890
00:37:54,260 --> 00:37:56,567
But the fact is that they
were able to-- an ISP

891
00:37:56,567 --> 00:37:59,150
was able to essentially divert
a large fraction of the world's

892
00:37:59,150 --> 00:38:00,080
traffic.

893
00:38:00,080 --> 00:38:02,697
And both these
attacks fundamentally

894
00:38:02,697 --> 00:38:04,280
stem from the following
problem, which

895
00:38:04,280 --> 00:38:07,208
is that at the end of
the day, despite all

896
00:38:07,208 --> 00:38:08,750
of this investment
into the internet,

897
00:38:08,750 --> 00:38:10,208
and the importance
of the internet,

898
00:38:10,208 --> 00:38:14,800
and the amount of money in it,
internet routing works because

899
00:38:14,800 --> 00:38:17,170
of essentially an honor code.

900
00:38:17,170 --> 00:38:19,930
It's like, ISPs at some
level, internet service

901
00:38:19,930 --> 00:38:22,600
providers and organizations
trust each other.

902
00:38:22,600 --> 00:38:24,230
And there's this
transitive trust,

903
00:38:24,230 --> 00:38:27,160
which is I might trust you,
and you might trust her.

904
00:38:27,160 --> 00:38:29,020
And implicitly, the
way routing works

905
00:38:29,020 --> 00:38:31,480
is that ends up in
me trusting her.

906
00:38:31,480 --> 00:38:33,610
Because I trust
everything you tell me,

907
00:38:33,610 --> 00:38:35,050
and you happen to
trust everything

908
00:38:35,050 --> 00:38:38,890
she tells you, which means that
if she were to make a mistake,

909
00:38:38,890 --> 00:38:41,680
and you were to believe
it, then in essence,

910
00:38:41,680 --> 00:38:45,830
everybody else in the world
is vulnerable to this problem.

911
00:38:45,830 --> 00:38:51,040
So let me explain what happened
in the case of YouTube,

912
00:38:51,040 --> 00:38:53,600
because it's reflective
of how things really work.

913
00:38:53,600 --> 00:38:57,490
So here's this little ISP
called Pakistan Telecom.

914
00:39:00,790 --> 00:39:02,358
Tiny, tiny ISP, you know?

915
00:39:02,358 --> 00:39:03,650
Hardly anyone uses it outside--

916
00:39:03,650 --> 00:39:05,680
I mean, everyone in
Pakistan probably uses it.

917
00:39:05,680 --> 00:39:09,820
But in the grand scale of
things, it's completely tiny.

918
00:39:09,820 --> 00:39:11,560
So they end up
connecting to a bunch

919
00:39:11,560 --> 00:39:13,830
of people outside in
different parts of the world.

920
00:39:13,830 --> 00:39:15,288
And one of the
people they ended up

921
00:39:15,288 --> 00:39:19,180
connecting to was another ISP
out in Hong Kong called PCCW.

922
00:39:22,750 --> 00:39:26,110
And these guys connect to
the rest of the internet.

923
00:39:26,110 --> 00:39:28,720
And presumably, Pakistan Telecom
connects to other people--

924
00:39:28,720 --> 00:39:30,730
I don't know.

925
00:39:30,730 --> 00:39:32,460
Now, here's what happened.

926
00:39:32,460 --> 00:39:34,210
Now, where does YouTube
fit into all this?

927
00:39:34,210 --> 00:39:36,252
You know, YouTube is
sitting somewhere over here.

928
00:39:41,740 --> 00:39:43,450
And presumably,
it's not directly--

929
00:39:43,450 --> 00:39:46,520
I mean, these guys have
nothing to do with each other.

930
00:39:46,520 --> 00:39:49,480
These guys are connected to some
other big ISPs and small ISPs.

931
00:39:49,480 --> 00:39:52,210
And eventually, there a set
of internet service providers

932
00:39:52,210 --> 00:39:57,675
that somehow constitute
the internet.

933
00:39:57,675 --> 00:39:59,050
And each of these
is independent.

934
00:39:59,050 --> 00:40:03,100
Each of these is known as
an anonymous system, or AS.

935
00:40:03,100 --> 00:40:04,720
And each of these
autonomous systems

936
00:40:04,720 --> 00:40:07,450
has a number, a 16-bit number.

937
00:40:07,450 --> 00:40:08,642
MIT is an anonymous system.

938
00:40:08,642 --> 00:40:10,600
And because MIT was very
early in the internet,

939
00:40:10,600 --> 00:40:14,080
MIT'S autonomous
system number is 3.

940
00:40:14,080 --> 00:40:16,870
But right now, there
are many, many ISPs.

941
00:40:16,870 --> 00:40:19,765
You know, right
now, you can have--

942
00:40:19,765 --> 00:40:21,890
there are tens of thousands
of autonomous systems--

943
00:40:21,890 --> 00:40:24,585
I don't know, 35,000, 40,000,
45,000, something like that.

944
00:40:24,585 --> 00:40:26,170
We're number 3!

945
00:40:26,170 --> 00:40:27,452
So anyway--

946
00:40:27,452 --> 00:40:28,870
AUDIENCE: Who's number one?

947
00:40:28,870 --> 00:40:30,037
PROFESSOR: Who's number one?

948
00:40:30,037 --> 00:40:31,820
BBN.

949
00:40:31,820 --> 00:40:32,380
Yeah, BBN.

950
00:40:32,380 --> 00:40:34,390
I don't know what AS2 is.

951
00:40:34,390 --> 00:40:36,003
BBN, of course, is number one.

952
00:40:36,003 --> 00:40:37,420
But actually, that
number is owned

953
00:40:37,420 --> 00:40:40,840
by somebody who acquired
BBN and who acquired--

954
00:40:40,840 --> 00:40:41,740
somebody acquires it.

955
00:40:41,740 --> 00:40:43,905
Now, here's an interesting
thing that's happening--

956
00:40:43,905 --> 00:40:45,280
these autonomous
system numbers--

957
00:40:45,280 --> 00:40:47,410
I remember I was a
very young graduate

958
00:40:47,410 --> 00:40:50,290
student when people were talking
about these autonomous numbers.

959
00:40:50,290 --> 00:40:52,247
And I remember these
mailing list discussions.

960
00:40:52,247 --> 00:40:53,830
I wasn't working on
this problem then,

961
00:40:53,830 --> 00:40:55,120
I worked on it much later.

962
00:40:55,120 --> 00:40:56,812
But people were
saying, yeah, 16 bits

963
00:40:56,812 --> 00:40:59,020
is plenty enough for an
autonomous system identifier.

964
00:40:59,020 --> 00:41:01,480
Because remember,
NSFNET was one.

965
00:41:01,480 --> 00:41:03,580
There was one internet
service provider.

966
00:41:03,580 --> 00:41:07,120
And in the early '90s, mid '90s
people were talking about ISPs,

967
00:41:07,120 --> 00:41:09,032
and they said, oh,
16 bits is plenty.

968
00:41:09,032 --> 00:41:10,990
And I remember there were
some people, actually

969
00:41:10,990 --> 00:41:12,407
graduate students
who were saying,

970
00:41:12,407 --> 00:41:14,620
maybe we should make it 32 bits?

971
00:41:14,620 --> 00:41:16,417
Because people remembered that--

972
00:41:16,417 --> 00:41:19,000
you know, the internet started--
you remember those old things

973
00:41:19,000 --> 00:41:22,330
on the internet
where people said,

974
00:41:22,330 --> 00:41:24,490
8 bits for a network
identifier are plenty enough.

975
00:41:24,490 --> 00:41:26,668
And of course, they got screwed.

976
00:41:26,668 --> 00:41:28,460
So anyway, what's
happening now, of course,

977
00:41:28,460 --> 00:41:30,970
is the older guys were saying
16 bits is plenty enough

978
00:41:30,970 --> 00:41:33,730
because we don't have too
much overhead on packets.

979
00:41:33,730 --> 00:41:36,320
And they put in 16 bits.

980
00:41:36,320 --> 00:41:38,680
And now, we're at
45,000 or 50,000.

981
00:41:38,680 --> 00:41:40,210
And guess what,
there's a proposal

982
00:41:40,210 --> 00:41:42,790
now on how do you-- how
the heck do you extend this

983
00:41:42,790 --> 00:41:46,570
to more than 2 to the
16 autonomous system,

984
00:41:46,570 --> 00:41:48,490
because now, the
internet is growing.

985
00:41:48,490 --> 00:41:51,790
So you know, if ever
you're given an opportunity

986
00:41:51,790 --> 00:41:53,750
to design the number
of bits for something--

987
00:41:53,750 --> 00:41:56,395
and you will always have
to do something-- just pick

988
00:41:56,395 --> 00:41:58,270
something much, much
bigger than you imagine,

989
00:41:58,270 --> 00:42:00,670
and then double it.

990
00:42:00,670 --> 00:42:02,680
Because it's always--
you'll never get it right.

991
00:42:02,680 --> 00:42:05,560
So anyway, each of
these autonomous systems

992
00:42:05,560 --> 00:42:07,930
has an identifier in it, OK?

993
00:42:07,930 --> 00:42:10,540
And each of these
guys, when they

994
00:42:10,540 --> 00:42:12,760
make an announcement
in the routing system,

995
00:42:12,760 --> 00:42:15,640
the way it works is that
you create your identifier,

996
00:42:15,640 --> 00:42:19,760
and then you tell people all of
the IP prefixes that you own,

997
00:42:19,760 --> 00:42:20,260
OK?

998
00:42:20,260 --> 00:42:23,770
So when I create my distance
vector, or in this case

999
00:42:23,770 --> 00:42:28,420
a path vector advertisement,
if I am autonomous system 3,

1000
00:42:28,420 --> 00:42:29,940
I have a set of IP addresses.

1001
00:42:29,940 --> 00:42:33,640
So MIT might have 18
dot whatever slash 8.

1002
00:42:33,640 --> 00:42:37,870
MIT has 128 dot something
slash-- let's say 19.

1003
00:42:37,870 --> 00:42:40,000
MIT has a whole slew
of these IP addresses

1004
00:42:40,000 --> 00:42:40,990
that they've acquired.

1005
00:42:40,990 --> 00:42:43,570
And what they're going to say
is, I'm autonomous system 3,

1006
00:42:43,570 --> 00:42:47,560
and I know how to get to these
guys because I own these guys.

1007
00:42:47,560 --> 00:42:49,180
This is the origin announcement.

1008
00:42:49,180 --> 00:42:52,360
And then other people-- you
know, MIT might-- this is AS3.

1009
00:42:52,360 --> 00:42:55,900
MIT sends it to its ISPs, and
they send it to their ISPs.

1010
00:42:55,900 --> 00:42:58,000
And every time an
autonomous system

1011
00:42:58,000 --> 00:43:01,960
receives multiple advertisements
along different paths

1012
00:43:01,960 --> 00:43:04,940
for the same prefix,
they pick one.

1013
00:43:04,940 --> 00:43:06,540
They select among them.

1014
00:43:06,540 --> 00:43:08,290
They have some rules
to select among them.

1015
00:43:08,290 --> 00:43:11,945
And these rules have to do
with the length of the path

1016
00:43:11,945 --> 00:43:13,070
between autonomous systems.

1017
00:43:13,070 --> 00:43:14,740
They have to do with
how much you're paying.

1018
00:43:14,740 --> 00:43:16,930
So for example, MIT might
be getting a better deal

1019
00:43:16,930 --> 00:43:19,120
from Cogent than from Level 3.

1020
00:43:19,120 --> 00:43:22,210
And so it would want more of
its traffic to come from Cogent.

1021
00:43:22,210 --> 00:43:26,230
And therefore, it would
decide that it would only

1022
00:43:26,230 --> 00:43:29,137
advertise certain of its
addresses on certain paths.

1023
00:43:29,137 --> 00:43:30,220
So there's lots of policy.

1024
00:43:30,220 --> 00:43:31,810
It's very, very complicated.

1025
00:43:31,810 --> 00:43:34,780
But yet, you know, some
miracle, the whole thing works.

1026
00:43:34,780 --> 00:43:37,495
So anyway, these things go
through from autonomous system

1027
00:43:37,495 --> 00:43:38,380
to autonomous system.

1028
00:43:38,380 --> 00:43:39,797
So what's this
path vector, right?

1029
00:43:39,797 --> 00:43:41,588
Remember, I told you
about the path vector.

1030
00:43:41,588 --> 00:43:43,280
The path vector is
a sequence of paths.

1031
00:43:43,280 --> 00:43:46,838
So it could be 3,
17, 26, and so forth.

1032
00:43:46,838 --> 00:43:48,380
So I have an animation
of this thing.

1033
00:43:48,380 --> 00:43:50,600
So I want to show that
to you because it's

1034
00:43:50,600 --> 00:43:51,840
totally interesting.

1035
00:43:51,840 --> 00:43:57,030
So there's this website called
[? BGPlay, ?] if I can find it.

1036
00:43:57,030 --> 00:44:01,130
So there's a way to get
MIT'S route advertisements

1037
00:44:01,130 --> 00:44:03,500
over the past month.

1038
00:44:03,500 --> 00:44:05,690
And you can kind of see
how these stats change.

1039
00:44:05,690 --> 00:44:07,440
So anyway, what
happened to YouTube?

1040
00:44:07,440 --> 00:44:10,400
What happened to YouTube was
the government of Pakistan

1041
00:44:10,400 --> 00:44:12,020
decided that what
they would tell

1042
00:44:12,020 --> 00:44:14,750
Pakistan Telecom
was to not allow

1043
00:44:14,750 --> 00:44:17,000
their users to go to YouTube.

1044
00:44:17,000 --> 00:44:19,820
So what they did was,
rather than simply drop

1045
00:44:19,820 --> 00:44:23,120
those requests, they wanted
to get Pakistan Telecom, when

1046
00:44:23,120 --> 00:44:26,780
somebody clicked on a YouTube
link, to go to a website

1047
00:44:26,780 --> 00:44:29,893
that Pakistan Telecom would
run that basically said,

1048
00:44:29,893 --> 00:44:31,310
you're not allowed
to use YouTube,

1049
00:44:31,310 --> 00:44:33,960
but would you like to
see something else?

1050
00:44:33,960 --> 00:44:36,050
OK, so the way they did
that was, they decided--

1051
00:44:36,050 --> 00:44:37,220
YouTube has some address.

1052
00:44:37,220 --> 00:44:40,105
Let me call YouTube's address
Y something, something.

1053
00:44:40,105 --> 00:44:41,480
Let me just call
it Y, all right?

1054
00:44:41,480 --> 00:44:44,847
Y is a set of IP addresses
that correspond to YouTube.

1055
00:44:44,847 --> 00:44:46,430
It's not one, they
have many machines.

1056
00:44:46,430 --> 00:44:49,063
So what these guys did was,
they did something they thought

1057
00:44:49,063 --> 00:44:49,730
was very clever.

1058
00:44:49,730 --> 00:44:51,740
They have a whole
network of users there.

1059
00:44:51,740 --> 00:44:54,300
They decided they
would advertise

1060
00:44:54,300 --> 00:44:59,300
a route for destination
Y inside their network.

1061
00:44:59,300 --> 00:45:05,750
But rather than use the actual
route advertisement for Y,

1062
00:45:05,750 --> 00:45:08,460
they would actually send
it to their own machine.

1063
00:45:08,460 --> 00:45:10,580
So remember, they
changed the routing now.

1064
00:45:10,580 --> 00:45:11,840
They're telling the users--

1065
00:45:11,840 --> 00:45:13,007
they're hijacking the route.

1066
00:45:13,007 --> 00:45:15,710
They're telling their users
that to go to YouTube,

1067
00:45:15,710 --> 00:45:17,127
you should not use
the actual link

1068
00:45:17,127 --> 00:45:18,835
that I'm telling you
to use, but instead,

1069
00:45:18,835 --> 00:45:20,730
go to this other place
inside my network,

1070
00:45:20,730 --> 00:45:22,790
where I can show you
this other website--

1071
00:45:22,790 --> 00:45:25,130
maybe pretend it's
YouTube, or whatever.

1072
00:45:25,130 --> 00:45:27,290
Now, everything is so
far so good, right?

1073
00:45:27,290 --> 00:45:28,820
I mean, people do
this all the time.

1074
00:45:28,820 --> 00:45:31,910
When you go to a hotel or any
internet kiosk, internet place,

1075
00:45:31,910 --> 00:45:35,085
you take your laptop,
and you go to cnn.com.

1076
00:45:35,085 --> 00:45:37,460
And the next thing you see
is, would you like to sign in?

1077
00:45:37,460 --> 00:45:38,720
How does that work?

1078
00:45:38,720 --> 00:45:41,480
Well, that works because they
essentially hijack the route.

1079
00:45:41,480 --> 00:45:43,400
They make it look like
you're going to CNN,

1080
00:45:43,400 --> 00:45:45,770
but in fact, you're going
somewhere else, right?

1081
00:45:45,770 --> 00:45:48,880
After all, your computer
wrote to go to CNN.

1082
00:45:48,880 --> 00:45:51,470
And the IP address used
was presumably CNN.

1083
00:45:51,470 --> 00:45:52,760
But then they made a mistake.

1084
00:45:52,760 --> 00:45:55,700
Some guy here-- probably,
he was too tired--

1085
00:45:55,700 --> 00:45:56,840
set up a configuration.

1086
00:45:56,840 --> 00:46:00,080
So he advertised
his new route to Y

1087
00:46:00,080 --> 00:46:01,420
that he created out to PCCW.

1088
00:46:04,190 --> 00:46:07,760
Now, PCCW was to
some degree at fault.

1089
00:46:07,760 --> 00:46:13,310
Because PCCW should have known
to some degree what actual IP

1090
00:46:13,310 --> 00:46:17,030
addresses Pakistan
Telecom owns, and only

1091
00:46:17,030 --> 00:46:20,210
honor route requests,
route advertisements coming

1092
00:46:20,210 --> 00:46:21,350
from those things, right?

1093
00:46:21,350 --> 00:46:24,080
PCCW needs to know
how to go, how

1094
00:46:24,080 --> 00:46:28,490
to send packets to nodes
inside of Pakistan Telecom.

1095
00:46:28,490 --> 00:46:30,800
But clearly, this
guy has nothing

1096
00:46:30,800 --> 00:46:33,710
useful to say about how to
send packets to YouTube.

1097
00:46:33,710 --> 00:46:35,887
But yet, this guy
honored this message.

1098
00:46:35,887 --> 00:46:37,220
So there were two mistakes here.

1099
00:46:37,220 --> 00:46:38,220
Actually, there
were many mistakes.

1100
00:46:38,220 --> 00:46:39,763
But the two big ones were--

1101
00:46:39,763 --> 00:46:41,930
there was a mistake made
here sending something out.

1102
00:46:41,930 --> 00:46:44,700
There was a mistake made
here honoring this request.

1103
00:46:44,700 --> 00:46:46,520
By this time, you
have transitive trust.

1104
00:46:46,520 --> 00:46:48,860
Because PCCW would find--

1105
00:46:48,860 --> 00:46:51,950
And what they also did
was, they made this a more

1106
00:46:51,950 --> 00:46:53,820
specific prefix.

1107
00:46:53,820 --> 00:46:55,820
So YouTube was
advertising a slash--

1108
00:46:55,820 --> 00:46:58,430
I believe it was
slash 21, which meant

1109
00:46:58,430 --> 00:47:02,210
it was many, many bits in the
prefix, 11 bits in common.

1110
00:47:02,210 --> 00:47:05,690
And there were-- sorry, 21
bits in common, a slash 21.

1111
00:47:05,690 --> 00:47:07,970
But these guys
advertised-- to guarantee

1112
00:47:07,970 --> 00:47:12,780
that all traffic would come in,
they advertised to slash 24.

1113
00:47:12,780 --> 00:47:13,830
So it's more specific.

1114
00:47:13,830 --> 00:47:16,460
So what happened was
PCCW believed that,

1115
00:47:16,460 --> 00:47:19,160
and they advertised
that to their ISPs,

1116
00:47:19,160 --> 00:47:21,600
and then to their
ISPs, and so forth.

1117
00:47:21,600 --> 00:47:23,540
Now, the reason why
this really got--

1118
00:47:23,540 --> 00:47:25,000
all of the internet's
traffic were

1119
00:47:25,000 --> 00:47:27,620
sent toward this
poor guy in Pakistan

1120
00:47:27,620 --> 00:47:31,760
was because everybody is doing
this longest prefix match.

1121
00:47:31,760 --> 00:47:33,900
And it's true that
there's a legitimate route

1122
00:47:33,900 --> 00:47:35,255
to YouTube in those routers.

1123
00:47:35,255 --> 00:47:37,880
But they're ignoring it because
they find a more specific route

1124
00:47:37,880 --> 00:47:39,230
that somebody had advertised.

1125
00:47:39,230 --> 00:47:41,643
So if you want to get
traffic sent to Google,

1126
00:47:41,643 --> 00:47:43,310
figure out a way to
convince some bigger

1127
00:47:43,310 --> 00:47:47,900
ISP to take your route to a more
specific prefix that you know

1128
00:47:47,900 --> 00:47:50,633
is owned by Google, and
just advertise it out, OK?

1129
00:47:50,633 --> 00:47:52,550
You're probably going
to get a lot of traffic.

1130
00:47:52,550 --> 00:47:57,230
Now, you may not want all the
traffic, but you'll get it.

1131
00:47:57,230 --> 00:47:59,510
So you see how this
stuff spread, right?

1132
00:47:59,510 --> 00:48:00,920
How do you solve this problem?

1133
00:48:00,920 --> 00:48:02,540
All right, this is going
on, and then people

1134
00:48:02,540 --> 00:48:03,832
are not able to see their cats.

1135
00:48:03,832 --> 00:48:06,500
And they're--
they're scrambling.

1136
00:48:06,500 --> 00:48:08,810
I mean, this is literally
the whole internet

1137
00:48:08,810 --> 00:48:11,060
wasn't able to get to YouTube,
which admittedly is not

1138
00:48:11,060 --> 00:48:12,435
the biggest problem
in the world.

1139
00:48:12,435 --> 00:48:15,720
But still, if you're YouTube,
this is a big problem.

1140
00:48:15,720 --> 00:48:17,770
So how do you
solve this problem?

1141
00:48:17,770 --> 00:48:18,770
What do you actually do?

1142
00:48:18,770 --> 00:48:20,730
I mean, the whole
world has this now,

1143
00:48:20,730 --> 00:48:22,785
this bad entry in
the routing table.

1144
00:48:22,785 --> 00:48:25,160
Now, there's this long-term
solution, which is of course,

1145
00:48:25,160 --> 00:48:26,570
let's figure out a
way to authenticate

1146
00:48:26,570 --> 00:48:29,195
the advertisements, and use some
public key, and this and that.

1147
00:48:29,195 --> 00:48:33,140
And you'll study this in
6.829 and other courses.

1148
00:48:33,140 --> 00:48:35,240
But today, we don't have that.

1149
00:48:35,240 --> 00:48:37,873
And this problem exists, so
how did we ever come out of it?

1150
00:48:37,873 --> 00:48:39,748
AUDIENCE: [INAUDIBLE]

1151
00:48:39,748 --> 00:48:42,040
PROFESSOR: Yeah, actually--
you know, it's interesting,

1152
00:48:42,040 --> 00:48:42,690
you and I--

1153
00:48:42,690 --> 00:48:44,990
you certainly thought
about this in 30 seconds.

1154
00:48:44,990 --> 00:48:47,548
But YouTube actually did-- it
took them a while to figure out

1155
00:48:47,548 --> 00:48:48,590
what was really going on.

1156
00:48:48,590 --> 00:48:49,550
Because one of the
problems is, you

1157
00:48:49,550 --> 00:48:52,190
don't want to do something like
that without knowing for sure.

1158
00:48:52,190 --> 00:48:54,180
But eventually, they
did exactly this.

1159
00:48:54,180 --> 00:48:56,880
They figured out the prefixes
that were being advertised.

1160
00:48:56,880 --> 00:48:59,377
And that took a while, because
you don't know somebody

1161
00:48:59,377 --> 00:49:00,960
else's-- what's in
your routing table?

1162
00:49:00,960 --> 00:49:01,637
I don't know.

1163
00:49:01,637 --> 00:49:03,220
I have to pick up
the phone, or email.

1164
00:49:03,220 --> 00:49:05,960
And email may not work because
it's coming back to YouTube.

1165
00:49:05,960 --> 00:49:07,960
But whatever, there's a way--

1166
00:49:07,960 --> 00:49:10,790
there's a way to figure this
out, phone and [INAUDIBLE]

1167
00:49:10,790 --> 00:49:11,960
Gmail or something.

1168
00:49:11,960 --> 00:49:14,670
And then they figured
out what it was.

1169
00:49:14,670 --> 00:49:17,970
And then they inserted slash
25 that were more specific.

1170
00:49:17,970 --> 00:49:20,390
And then once the problem
kind of resolved itself,

1171
00:49:20,390 --> 00:49:22,350
they got out of it.

1172
00:49:22,350 --> 00:49:24,320
So let me jump on and move on.

1173
00:49:24,320 --> 00:49:28,190
Give me two more minutes,
and I'll finish up.

1174
00:49:28,190 --> 00:49:30,140
A similar problem happened
with China Telecom.

1175
00:49:30,140 --> 00:49:31,973
They didn't advertise
a more specific route,

1176
00:49:31,973 --> 00:49:34,110
so they only got about
15% of the internet.

1177
00:49:34,110 --> 00:49:36,290
And they were nice enough
to forward it around

1178
00:49:36,290 --> 00:49:38,090
to the actual destinations.

1179
00:49:38,090 --> 00:49:40,490
But this was a problem.

1180
00:49:40,490 --> 00:49:42,170
I'm going to skip
through the decade

1181
00:49:42,170 --> 00:49:47,233
ahead because you know what,
you'll find out soon enough.

1182
00:49:47,233 --> 00:49:48,650
All right, what I
do want to do is

1183
00:49:48,650 --> 00:49:51,885
to summarize 6.02 in one slide.

1184
00:49:51,885 --> 00:49:54,260
This course was about how to
design digital communication

1185
00:49:54,260 --> 00:49:55,400
networks, right?

1186
00:49:55,400 --> 00:49:57,410
I'm sure you all
kind of know that.

1187
00:49:57,410 --> 00:49:59,450
We did this with three
layers of abstraction,

1188
00:49:59,450 --> 00:50:01,190
very simple story--

1189
00:50:01,190 --> 00:50:04,190
bits, signals, and packets.

1190
00:50:04,190 --> 00:50:06,230
And I think as far as
these kinds of courses

1191
00:50:06,230 --> 00:50:09,807
go across the world, it's
a pretty unique storyline.

1192
00:50:09,807 --> 00:50:11,390
There aren't very
many courses that we

1193
00:50:11,390 --> 00:50:15,170
know of which have this vertical
study across all the layers.

1194
00:50:15,170 --> 00:50:18,440
And there are some
schools that we

1195
00:50:18,440 --> 00:50:20,420
know of that are starting
to adopt this idea.

1196
00:50:20,420 --> 00:50:22,790
And we feel like this
is a pretty unique way

1197
00:50:22,790 --> 00:50:24,320
in which to teach
this, because it

1198
00:50:24,320 --> 00:50:26,030
demystifies all of the layers.

1199
00:50:26,030 --> 00:50:27,695
So we didn't cover
anything with-- we

1200
00:50:27,695 --> 00:50:29,900
didn't tell you 15 ways to
solve any given problem.

1201
00:50:29,900 --> 00:50:32,870
But we told you one good way
to solve each of the problems

1202
00:50:32,870 --> 00:50:34,740
that you will see.

1203
00:50:34,740 --> 00:50:36,560
So we went from
point-to-point links

1204
00:50:36,560 --> 00:50:39,980
to multihop
communication networks.

1205
00:50:39,980 --> 00:50:41,810
And across these
different topics-- and you

1206
00:50:41,810 --> 00:50:44,730
can see that we studied
these different topics.

1207
00:50:44,730 --> 00:50:46,850
The two big themes that
I want to leave you with

1208
00:50:46,850 --> 00:50:49,280
are reliability and sharing.

1209
00:50:49,280 --> 00:50:52,403
Because that's really what makes
our communication systems work.

1210
00:50:52,403 --> 00:50:53,570
How do you make it reliable?

1211
00:50:53,570 --> 00:50:56,690
We don't have a perfectly
reliable communication

1212
00:50:56,690 --> 00:50:58,170
medium at any layer.

1213
00:50:58,170 --> 00:51:00,440
So how you make things
reliable is important.

1214
00:51:00,440 --> 00:51:02,450
We studied this
over and over again.

1215
00:51:02,450 --> 00:51:04,040
And how do you share?

1216
00:51:04,040 --> 00:51:07,270
Those are the two big topics.