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

2
00:00:02,490 --> 00:00:04,059
Commons license.

3
00:00:04,059 --> 00:00:06,360
Your support will help
MIT OpenCourseWare

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

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

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

7
00:00:17,290 --> 00:00:18,294
at ocw.mit.edu.

8
00:00:28,160 --> 00:00:30,070
PROFESSOR: So the
goal for today is

9
00:00:30,070 --> 00:00:33,730
to talk about a particular kind
of communication network called

10
00:00:33,730 --> 00:00:35,085
a shared medium network.

11
00:00:35,085 --> 00:00:36,460
And there are
many, many examples

12
00:00:36,460 --> 00:00:39,730
of shared media communication
networks that exist today.

13
00:00:39,730 --> 00:00:41,770
Now, these are,
generally speaking,

14
00:00:41,770 --> 00:00:44,710
networks that don't span the
globe or even span the country,

15
00:00:44,710 --> 00:00:46,840
with one exception,
and that exception

16
00:00:46,840 --> 00:00:49,030
is the satellite
network shown here.

17
00:00:49,030 --> 00:00:53,390
The model here is that you
have a set of ground stations.

18
00:00:53,390 --> 00:00:55,960
This is a picture from an
actual internet service provider

19
00:00:55,960 --> 00:00:59,780
in the middle of the Pacific.

20
00:00:59,780 --> 00:01:02,050
I mean, I'd love to go
there on assignment.

21
00:01:02,050 --> 00:01:04,438
And the way this network
works is in order

22
00:01:04,438 --> 00:01:05,980
to communicate
between these islands,

23
00:01:05,980 --> 00:01:08,063
the way they do this is
they have satellite ground

24
00:01:08,063 --> 00:01:10,570
stations that can receive
and transmit data.

25
00:01:10,570 --> 00:01:13,490
And there's a satellite
up in the sky.

26
00:01:13,490 --> 00:01:15,490
So you communicate between
two of these islands

27
00:01:15,490 --> 00:01:17,770
by transmitting data from
one of the ground stations

28
00:01:17,770 --> 00:01:20,080
up to the satellite
and down there.

29
00:01:20,080 --> 00:01:25,000
And the way this system works
is not to divide frequencies

30
00:01:25,000 --> 00:01:26,655
amongst the
different satellites.

31
00:01:26,655 --> 00:01:28,030
And the reason
they don't do that

32
00:01:28,030 --> 00:01:31,210
is that they don't
know how often each

33
00:01:31,210 --> 00:01:33,160
of these satellites--
these ground stations

34
00:01:33,160 --> 00:01:34,183
is going to communicate.

35
00:01:34,183 --> 00:01:36,100
So you don't divide up
the frequencies upfront

36
00:01:36,100 --> 00:01:37,570
between the ground stations.

37
00:01:37,570 --> 00:01:41,470
So all of the ground stations
sending to the satellite

38
00:01:41,470 --> 00:01:44,050
do so on the same frequency.

39
00:01:44,050 --> 00:01:47,540
And the satellite downlink
is on a different frequency.

40
00:01:47,540 --> 00:01:50,260
So what could happen if two
satellites communicate up

41
00:01:50,260 --> 00:01:53,373
at the same time is
that the satellite up--

42
00:01:53,373 --> 00:01:54,790
if two ground
stations communicate

43
00:01:54,790 --> 00:01:56,350
to the satellite
at the same time,

44
00:01:56,350 --> 00:01:58,600
the satellite may not be
able to pull together the two

45
00:01:58,600 --> 00:02:00,475
different transmissions
apart because they're

46
00:02:00,475 --> 00:02:02,270
on the same frequency.

47
00:02:02,270 --> 00:02:04,600
Now, they could use frequency
division multiplexing.

48
00:02:04,600 --> 00:02:06,620
That's a perfectly
reasonable solution.

49
00:02:06,620 --> 00:02:09,789
But they don't do it because
if one satellite-- one ground

50
00:02:09,789 --> 00:02:12,220
station has data to send
and the other doesn't, you

51
00:02:12,220 --> 00:02:14,650
end up wasting
frequencies and not

52
00:02:14,650 --> 00:02:16,160
getting as high a throughput.

53
00:02:16,160 --> 00:02:19,503
So that's one example of
a shared medium network.

54
00:02:19,503 --> 00:02:21,670
This here is a picture of
something called ethernet,

55
00:02:21,670 --> 00:02:23,742
which was one of the most
successful networking

56
00:02:23,742 --> 00:02:24,700
technologies developed.

57
00:02:24,700 --> 00:02:27,460
It was invented in
the early 1970s.

58
00:02:27,460 --> 00:02:31,780
And the idea here is you have
a shared bus, a shared wire,

59
00:02:31,780 --> 00:02:33,610
and many stations connect to it.

60
00:02:33,610 --> 00:02:37,420
And if two stations
transmit at the same time,

61
00:02:37,420 --> 00:02:39,040
the two transmissions
could collide

62
00:02:39,040 --> 00:02:41,053
and you don't actually
receive the data.

63
00:02:41,053 --> 00:02:42,970
And what you would like
to do is to figure out

64
00:02:42,970 --> 00:02:45,460
a way by which these
different stations

65
00:02:45,460 --> 00:02:48,790
or nodes on the
ethernet can somehow

66
00:02:48,790 --> 00:02:54,640
manage to communicate by
collaboratively figuring out

67
00:02:54,640 --> 00:02:57,730
how to transmit on the medium.

68
00:02:57,730 --> 00:03:01,690
And the idea is to make it so
that only one node transmits

69
00:03:01,690 --> 00:03:04,270
at any point in time.

70
00:03:04,270 --> 00:03:07,790
Other examples of shared
media are wireless networks.

71
00:03:07,790 --> 00:03:11,170
802.11 is an example of a
shared communication medium.

72
00:03:11,170 --> 00:03:14,860
If a bunch of us communicate
and share that access point,

73
00:03:14,860 --> 00:03:17,050
we're all running
on the same channel.

74
00:03:17,050 --> 00:03:19,420
And in 802.11, or
Wi-Fi, there are

75
00:03:19,420 --> 00:03:21,940
a bunch of different
channels available.

76
00:03:21,940 --> 00:03:24,190
But any given axis
point tends to have

77
00:03:24,190 --> 00:03:27,340
a cell, which is
some area around it

78
00:03:27,340 --> 00:03:30,340
that, in order to communicate
with that access point,

79
00:03:30,340 --> 00:03:32,000
you use the same channel.

80
00:03:32,000 --> 00:03:36,310
So we need a way by which we
have to take the shared network

81
00:03:36,310 --> 00:03:39,370
and allocate access
to this medium

82
00:03:39,370 --> 00:03:41,207
amongst these different nodes.

83
00:03:41,207 --> 00:03:42,790
And if you look at
an entire building,

84
00:03:42,790 --> 00:03:45,190
there's a big plan in place
for how the different access

85
00:03:45,190 --> 00:03:48,137
points communicate potentially
on different channels

86
00:03:48,137 --> 00:03:48,970
or the same channel.

87
00:03:48,970 --> 00:03:52,900
And there's an entire process
by which this building's network

88
00:03:52,900 --> 00:03:55,160
is laid out and the
campus network is laid out

89
00:03:55,160 --> 00:03:56,050
and so forth.

90
00:03:56,050 --> 00:03:58,450
And cellular
networks-- you know,

91
00:03:58,450 --> 00:04:01,450
Verizon, AT&T, Sprint and
T-Mobile and all these guys

92
00:04:01,450 --> 00:04:04,100
have the same problem
that they have to solve.

93
00:04:04,100 --> 00:04:06,430
So these are very
interesting questions

94
00:04:06,430 --> 00:04:10,840
which boil down to how
you take a shared medium--

95
00:04:10,840 --> 00:04:15,550
whether it be a wire like an
ethernet net or radio, which

96
00:04:15,550 --> 00:04:18,565
is over the air, or
it could be acoustic--

97
00:04:18,565 --> 00:04:21,190
how do you take all of that and
have these different nodes that

98
00:04:21,190 --> 00:04:22,690
are communicating
with each other on

99
00:04:22,690 --> 00:04:29,320
that medium somehow make
it so that they can all

100
00:04:29,320 --> 00:04:32,370
share the medium without
colliding with each other?

101
00:04:32,370 --> 00:04:35,110
And that's the problem
that's solved by these media

102
00:04:35,110 --> 00:04:37,970
access or MAC protocols.

103
00:04:37,970 --> 00:04:40,360
Now, all of the stuff
that I'm going to tell you

104
00:04:40,360 --> 00:04:43,470
is based on chapter 15,
which is on MAC protocols.

105
00:04:43,470 --> 00:04:45,220
And there's a little
more in it than we'll

106
00:04:45,220 --> 00:04:48,820
be able to cover in recitation,
in lecture and recitation.

107
00:04:48,820 --> 00:04:51,370
But it's hard for me to keep
straight what we cover and what

108
00:04:51,370 --> 00:04:52,090
we don't.

109
00:04:52,090 --> 00:04:55,520
So you're sort of responsible
for everything in that chapter.

110
00:04:55,520 --> 00:04:57,223
We'll cover most of the issues.

111
00:04:57,223 --> 00:04:59,140
There's a bunch of details
in the chapter that

112
00:04:59,140 --> 00:05:01,120
are worth understanding
in order for you

113
00:05:01,120 --> 00:05:03,160
to really get your
understanding to be clear.

114
00:05:03,160 --> 00:05:05,838
So I want to caveat
that upfront.

115
00:05:05,838 --> 00:05:07,630
We lost a lecture
because of the hurricane.

116
00:05:07,630 --> 00:05:10,270
And I just can't keep straight
what I tell you and what I

117
00:05:10,270 --> 00:05:10,960
don't.

118
00:05:10,960 --> 00:05:14,840
So everything in that
chapter is fair game.

119
00:05:14,840 --> 00:05:18,640
But we'll cover the
most important issues.

120
00:05:18,640 --> 00:05:19,140
OK.

121
00:05:19,140 --> 00:05:21,700
So here's the abstract model.

122
00:05:21,700 --> 00:05:23,650
And you know, there's
a shared medium.

123
00:05:23,650 --> 00:05:24,620
It could be a wire.

124
00:05:24,620 --> 00:05:26,960
It could be wireless.

125
00:05:26,960 --> 00:05:28,702
And you have these nodes.

126
00:05:28,702 --> 00:05:30,160
And the nodes have
two things there

127
00:05:30,160 --> 00:05:31,960
that you have to worry about.

128
00:05:31,960 --> 00:05:33,550
The first thing here
is just a detail.

129
00:05:33,550 --> 00:05:34,675
It's the channel interface.

130
00:05:34,675 --> 00:05:38,740
It's a way by which
the data on that node

131
00:05:38,740 --> 00:05:40,630
gains access to the medium.

132
00:05:40,630 --> 00:05:43,000
And then each node
has a set of queues--

133
00:05:43,000 --> 00:05:45,490
or one queue or two queues,
a transmit queue and a

134
00:05:45,490 --> 00:05:48,250
receive queue, which
has packets waiting

135
00:05:48,250 --> 00:05:50,860
to be sent on that medium.

136
00:05:50,860 --> 00:05:53,050
And the basic idea
is that you have

137
00:05:53,050 --> 00:05:54,400
all these nodes on the medium.

138
00:05:54,400 --> 00:05:56,650
And it may be that
these nodes are all

139
00:05:56,650 --> 00:05:59,260
trying to communicate with
a single router or a switch

140
00:05:59,260 --> 00:06:00,263
or a satellite.

141
00:06:00,263 --> 00:06:01,930
Or it may be that the
nodes are directly

142
00:06:01,930 --> 00:06:04,060
communicating with each
other, like your laptop is

143
00:06:04,060 --> 00:06:05,320
communicating with mine.

144
00:06:05,320 --> 00:06:07,870
Your phone is communicating
with your laptop.

145
00:06:07,870 --> 00:06:10,540
And somehow they're all
sharing this medium.

146
00:06:10,540 --> 00:06:13,480
And we're going to come up
with the world's simplest

147
00:06:13,480 --> 00:06:15,760
shared medium network
because it's simple

148
00:06:15,760 --> 00:06:18,880
and because it's a reasonable
model of reality, which

149
00:06:18,880 --> 00:06:24,850
is that at any point in time if
more than one transmission is

150
00:06:24,850 --> 00:06:29,020
on that shared medium,
then you end up

151
00:06:29,020 --> 00:06:30,790
having what's
called a collision.

152
00:06:30,790 --> 00:06:33,160
And you cannot
decode the packet.

153
00:06:33,160 --> 00:06:34,360
So let me repeat.

154
00:06:34,360 --> 00:06:36,058
The model here is
if there's exactly

155
00:06:36,058 --> 00:06:37,600
one transmission on
the medium, we'll

156
00:06:37,600 --> 00:06:39,868
assume that it's
delivered correctly.

157
00:06:39,868 --> 00:06:42,160
If there is no transmission
on the medium at some point

158
00:06:42,160 --> 00:06:44,110
in time, nothing happens.

159
00:06:44,110 --> 00:06:45,610
The channel is sort of wasted.

160
00:06:45,610 --> 00:06:46,695
It's not used.

161
00:06:46,695 --> 00:06:48,820
If there's more than one
transmission on the medium

162
00:06:48,820 --> 00:06:52,480
overlapping in time,
neither transmission

163
00:06:52,480 --> 00:06:54,370
successfully gets decoded.

164
00:06:54,370 --> 00:06:55,750
So there are two
or three or four

165
00:06:55,750 --> 00:06:57,542
people hitting the
channel at the same time

166
00:06:57,542 --> 00:06:58,990
overlapping in time.

167
00:06:58,990 --> 00:07:00,290
Nobody succeeds.

168
00:07:00,290 --> 00:07:00,790
OK.

169
00:07:00,790 --> 00:07:03,220
That's the abstraction.

170
00:07:03,220 --> 00:07:06,490
And what we want is a
communication protocol or rules

171
00:07:06,490 --> 00:07:08,470
of engagement between
the nodes that

172
00:07:08,470 --> 00:07:11,210
allow us to get reasonably
good performance in sharing

173
00:07:11,210 --> 00:07:11,710
the medium.

174
00:07:14,270 --> 00:07:17,470
Now, depending on the
details of the network,

175
00:07:17,470 --> 00:07:19,850
the nodes that are
on this shared medium

176
00:07:19,850 --> 00:07:22,390
may be able to hear
each other perfectly.

177
00:07:22,390 --> 00:07:24,910
Or maybe they can't
hear each other at all.

178
00:07:24,910 --> 00:07:27,070
Or maybe they can
partially hear each other.

179
00:07:27,070 --> 00:07:29,290
And we're going to deal
with all of these cases.

180
00:07:29,290 --> 00:07:31,480
But for now, just
assume that you

181
00:07:31,480 --> 00:07:33,250
have these nodes on the medium.

182
00:07:33,250 --> 00:07:35,630
And for simplicity
and completeness,

183
00:07:35,630 --> 00:07:38,372
let's take the example
of the satellite network.

184
00:07:38,372 --> 00:07:39,580
You have a satellite up here.

185
00:07:43,180 --> 00:07:46,570
And you have a bunch
of ground stations

186
00:07:46,570 --> 00:07:50,890
that are all trying to
communicate up to the satellite

187
00:07:50,890 --> 00:07:52,900
whenever they have data to send.

188
00:07:52,900 --> 00:07:57,610
And just assume for now that the
nodes cannot hear each other.

189
00:07:57,610 --> 00:07:59,290
And the satellite
doesn't really know

190
00:07:59,290 --> 00:08:02,980
whether a node has packets
waiting to be sent or not.

191
00:08:02,980 --> 00:08:04,450
And somehow, we're
going to invent

192
00:08:04,450 --> 00:08:07,210
a protocol or a rules
of engagement that

193
00:08:07,210 --> 00:08:10,300
allow these nodes to,
in a distributed way,

194
00:08:10,300 --> 00:08:13,210
figure out when it's OK
for them to transmit data

195
00:08:13,210 --> 00:08:16,330
and when they should
keep their mouth shut.

196
00:08:16,330 --> 00:08:18,430
And each of these
nodes has a queue

197
00:08:18,430 --> 00:08:23,530
of packets waiting to be sent.

198
00:08:23,530 --> 00:08:25,720
Sometimes the
queue may be empty.

199
00:08:25,720 --> 00:08:28,270
Sometimes the queue may
have one or more packets.

200
00:08:28,270 --> 00:08:30,160
That depends on what
the application is doing

201
00:08:30,160 --> 00:08:34,210
and how quickly that node has
been able to transmit data

202
00:08:34,210 --> 00:08:36,880
on the channel.

203
00:08:36,880 --> 00:08:40,220
If the node has packets
waiting to be sent,

204
00:08:40,220 --> 00:08:47,270
so a queue can either be empty
or it has one or more packets

205
00:08:47,270 --> 00:08:48,490
waiting to be sent.

206
00:08:48,490 --> 00:08:51,100
In which case, we're going
to use the word backlogged.

207
00:08:54,880 --> 00:08:57,640
So at any point in time,
some subset of the nodes

208
00:08:57,640 --> 00:09:01,450
may have backlogged packets and
that may have backlog queues.

209
00:09:01,450 --> 00:09:05,980
And our goal is to come up with
a way by which these nodes can

210
00:09:05,980 --> 00:09:08,090
transmit data on the channel.

211
00:09:11,270 --> 00:09:13,220
Now, there are two or
three different ways

212
00:09:13,220 --> 00:09:15,460
of solving this problem.

213
00:09:15,460 --> 00:09:17,210
The first approach to
solving this problem

214
00:09:17,210 --> 00:09:22,430
is to do frequency
division multiplexing.

215
00:09:22,430 --> 00:09:25,220
You could just allocate
different frequencies

216
00:09:25,220 --> 00:09:26,630
and you've solved the problem.

217
00:09:26,630 --> 00:09:28,100
But as I mentioned
before, we don't

218
00:09:28,100 --> 00:09:30,560
want to do that because if
you've allocated and predefined

219
00:09:30,560 --> 00:09:33,710
a frequency to a node
and the node is empty,

220
00:09:33,710 --> 00:09:35,720
it doesn't have packets,
then you've essentially

221
00:09:35,720 --> 00:09:38,060
wasted bandwidth
because you've allocated

222
00:09:38,060 --> 00:09:40,850
a portion of the frequency
to a node that isn't actually

223
00:09:40,850 --> 00:09:42,470
going to send any data.

224
00:09:42,470 --> 00:09:44,810
Somebody else who
had data to send

225
00:09:44,810 --> 00:09:47,840
could have more profitably
used it and helped you win,

226
00:09:47,840 --> 00:09:50,910
helped you get
better performance.

227
00:09:50,910 --> 00:09:54,240
The second thing you can do
is to somehow divide up time.

228
00:09:54,240 --> 00:09:56,630
In other words, they all
run on the same frequency.

229
00:09:56,630 --> 00:09:59,840
And somehow make it so
that you give the illusion

230
00:09:59,840 --> 00:10:03,590
that each node gets
access to the channel

231
00:10:03,590 --> 00:10:06,520
for some fraction of the time.

232
00:10:06,520 --> 00:10:08,730
And if you do that,
it's a model of sharing

233
00:10:08,730 --> 00:10:11,330
called time sharing as
opposed to frequency sharing.

234
00:10:11,330 --> 00:10:19,370
So one approach to dealing with
it is frequency sharing, which

235
00:10:19,370 --> 00:10:21,170
is a good idea in
some cases, but not

236
00:10:21,170 --> 00:10:23,897
in this case when the
traffic is quite bursting.

237
00:10:23,897 --> 00:10:25,730
The second thing you
can do is time sharing.

238
00:10:30,440 --> 00:10:32,600
And there are two ways
of doing time sharing.

239
00:10:32,600 --> 00:10:37,670
One of them is called time
division multiplexing, or TDM.

240
00:10:37,670 --> 00:10:41,870
It's also called TDMA for
Time Division Multiple Access.

241
00:10:44,928 --> 00:10:46,970
And we'll talk about this
in recitation tomorrow,

242
00:10:46,970 --> 00:10:49,940
so I won't belabor it here.

243
00:10:49,940 --> 00:10:51,810
The second approach to
solving this problem,

244
00:10:51,810 --> 00:10:54,080
which is what we'll spend
the rest of today on,

245
00:10:54,080 --> 00:10:56,420
is the class of protocols
called contention protocols.

246
00:11:01,350 --> 00:11:03,260
And these protocols
are really beautiful,

247
00:11:03,260 --> 00:11:05,510
because they're
completely distributed.

248
00:11:05,510 --> 00:11:08,500
There's no central intelligence.

249
00:11:08,500 --> 00:11:10,090
It's highly distributed
intelligence.

250
00:11:10,090 --> 00:11:13,060
Each node makes its own
independent decisions

251
00:11:13,060 --> 00:11:16,600
as to what it should do based
on very little information

252
00:11:16,600 --> 00:11:19,390
that it learns as it sends
its packets and determines

253
00:11:19,390 --> 00:11:21,250
what happens to those packets.

254
00:11:21,250 --> 00:11:23,650
And yet, somehow the
nodes are able to come up

255
00:11:23,650 --> 00:11:27,430
with a way of sharing the
channel by essentially

256
00:11:27,430 --> 00:11:29,588
cooperating but yet
competing with each other.

257
00:11:29,588 --> 00:11:31,630
That's why these are called
contention protocols.

258
00:11:31,630 --> 00:11:34,697
That ends up getting
pretty good performance.

259
00:11:34,697 --> 00:11:36,280
There's a third kind
of sharing, which

260
00:11:36,280 --> 00:11:44,230
we won't talk about at all in
602, and that's code division.

261
00:11:44,230 --> 00:11:46,750
The slides that are online
say a little bit about it.

262
00:11:46,750 --> 00:11:49,137
And you can look it up on
the internet, if you want.

263
00:11:49,137 --> 00:11:50,720
We're not going to
talk about it here.

264
00:11:50,720 --> 00:11:54,820
So for today, my goal is to tell
you about contention protocols.

265
00:11:54,820 --> 00:11:57,700
And largely speaking, for
MAC protocols right now

266
00:11:57,700 --> 00:12:00,230
in this chapter and
this part of the course,

267
00:12:00,230 --> 00:12:06,372
we're interested in time
sharing, TDMA and contention.

268
00:12:06,372 --> 00:12:08,080
So before I tell you
about the protocols,

269
00:12:08,080 --> 00:12:10,300
I want to tell you a
little bit about what

270
00:12:10,300 --> 00:12:12,460
we would like, what
makes the protocol good

271
00:12:12,460 --> 00:12:15,383
and what doesn't, what's bad.

272
00:12:15,383 --> 00:12:17,800
So if I tell you that you have
a bunch of these nodes that

273
00:12:17,800 --> 00:12:20,500
are trying to share
this medium and you

274
00:12:20,500 --> 00:12:23,980
would like to get good
performance in this protocol

275
00:12:23,980 --> 00:12:28,270
to share access to the channel,
by what metric or metrics

276
00:12:28,270 --> 00:12:32,630
would you measure
this performance?

277
00:12:32,630 --> 00:12:35,740
How would you know
it's good or bad?

278
00:12:35,740 --> 00:12:36,240
Yes?

279
00:12:36,240 --> 00:12:39,730
AUDIENCE: [INAUDIBLE].

280
00:12:39,730 --> 00:12:42,150
PROFESSOR: Well, the model
here is if two people send

281
00:12:42,150 --> 00:12:44,650
at the same time, you fail.

282
00:12:44,650 --> 00:12:47,164
We fail.

283
00:12:47,164 --> 00:12:49,927
AUDIENCE: [INAUDIBLE].

284
00:12:49,927 --> 00:12:50,510
PROFESSOR: OK.

285
00:12:50,510 --> 00:12:52,160
So good, let's keep
going with that.

286
00:12:52,160 --> 00:12:55,100
Now let's say that someone
observes the system

287
00:12:55,100 --> 00:12:56,990
and watches its
evolution over time.

288
00:12:56,990 --> 00:13:00,560
They observe whether packets
succeed and packets fail

289
00:13:00,560 --> 00:13:01,885
and so forth.

290
00:13:01,885 --> 00:13:03,260
And they want to
count something.

291
00:13:03,260 --> 00:13:04,677
What would they
count to determine

292
00:13:04,677 --> 00:13:05,910
if a protocol is good or bad?

293
00:13:05,910 --> 00:13:06,890
AUDIENCE: Rate of failure?

294
00:13:06,890 --> 00:13:07,645
PROFESSOR: Sorry?

295
00:13:07,645 --> 00:13:08,130
AUDIENCE: Rate of failure?

296
00:13:08,130 --> 00:13:08,870
PROFESSOR: Rate of failure.

297
00:13:08,870 --> 00:13:10,328
I mean, live your
positive, people,

298
00:13:10,328 --> 00:13:11,850
so let's count the
rate of success.

299
00:13:11,850 --> 00:13:14,350
OK, so there's a word
for this rate of success.

300
00:13:14,350 --> 00:13:15,920
It's a measure
of, if you succeed

301
00:13:15,920 --> 00:13:19,020
more, it means you're able
to deliver data faster,

302
00:13:19,020 --> 00:13:22,740
which means you get higher
throughput or a higher rate.

303
00:13:22,740 --> 00:13:27,530
So the first metric that you
have-- so these are metrics.

304
00:13:27,530 --> 00:13:29,771
The first metric that
you have is throughput.

305
00:13:33,540 --> 00:13:36,000
And throughput is generally
measured in bits per second

306
00:13:36,000 --> 00:13:37,765
or packets per second.

307
00:13:37,765 --> 00:13:39,390
So let's just imagine
that it's packets

308
00:13:39,390 --> 00:13:42,300
per second for simplicity to
assume that all the packets are

309
00:13:42,300 --> 00:13:44,110
the same size.

310
00:13:44,110 --> 00:13:47,910
So you can translate
into bits per second.

311
00:13:47,910 --> 00:13:51,820
Now, throughput by
itself is a good metric.

312
00:13:51,820 --> 00:13:54,130
But really, we would
like protocols--

313
00:13:54,130 --> 00:13:56,440
we would like to
evaluate protocols

314
00:13:56,440 --> 00:13:59,830
without worrying about whether
the underlying channel can send

315
00:13:59,830 --> 00:14:03,100
data at 1 megabit per second
or 10 megabits per second

316
00:14:03,100 --> 00:14:05,650
or a gigabit per second or
100 gigabits per second.

317
00:14:05,650 --> 00:14:07,150
I mean, we really
don't want to care

318
00:14:07,150 --> 00:14:09,710
about what the actual
throughput or the rate

319
00:14:09,710 --> 00:14:10,960
supportable by the channel is.

320
00:14:10,960 --> 00:14:13,000
So we're going to
translate this throughput

321
00:14:13,000 --> 00:14:15,100
into a different
word which means--

322
00:14:15,100 --> 00:14:19,106
which is a proxy for throughput
called the utilization.

323
00:14:22,370 --> 00:14:24,700
And we'll represent that by U.

324
00:14:24,700 --> 00:14:28,450
And the utilization
of a MAC protocol--

325
00:14:28,450 --> 00:14:31,240
or in fact, of any
protocol over a network--

326
00:14:31,240 --> 00:14:37,060
is defined as the throughput
that the protocol achieves

327
00:14:37,060 --> 00:14:39,910
divided by the maximum
rate at which it's

328
00:14:39,910 --> 00:14:46,490
possible to send data over that
channel or over that network.

329
00:14:46,490 --> 00:14:49,330
So if you have a sudden maximum
rate at which if everything

330
00:14:49,330 --> 00:14:51,120
were in your favor
you could send data

331
00:14:51,120 --> 00:14:54,700
at a certain maximum rate,
stick that in the denominator.

332
00:14:54,700 --> 00:14:57,010
Look at what throughput
you actually get.

333
00:14:57,010 --> 00:14:59,470
And take the ratio.

334
00:14:59,470 --> 00:15:01,720
The higher the utilization,
the higher the throughput.

335
00:15:01,720 --> 00:15:04,330
We've just normalized
out by the maximum rate.

336
00:15:04,330 --> 00:15:06,580
And of course, by
definition, we know

337
00:15:06,580 --> 00:15:09,930
that the utilization
must be between 0 and 1

338
00:15:09,930 --> 00:15:13,040
because you can't
exceed the maximum.

339
00:15:13,040 --> 00:15:14,650
And this is an
aggregate measure.

340
00:15:14,650 --> 00:15:18,870
So if you have, let's say,
four nodes and the max--

341
00:15:18,870 --> 00:15:20,835
just for example,
let's say the max

342
00:15:20,835 --> 00:15:26,580
rate is 10 megabits per second
and you have four nodes.

343
00:15:26,580 --> 00:15:30,540
And the throughput that the
four nodes get are, let's say,

344
00:15:30,540 --> 00:15:33,110
1 megabits per second,
2 megabits per second,

345
00:15:33,110 --> 00:15:38,260
4 megabits per second,
and 1 megabit per second.

346
00:15:38,260 --> 00:15:42,180
What's the utilization?

347
00:15:42,180 --> 00:15:44,160
The total throughput is
8 megabits per second.

348
00:15:44,160 --> 00:15:45,430
The maximum is 10.

349
00:15:45,430 --> 00:15:51,540
So the utilization in
this example is 0.8.

350
00:15:51,540 --> 00:15:54,667
In fact, if you had--

351
00:15:54,667 --> 00:15:56,750
for the same four nodes,
if the throughput you got

352
00:15:56,750 --> 00:16:09,280
was 0, 1, 7, and 1, the
utilization would also be 0.8.

353
00:16:09,280 --> 00:16:09,990
Can't add.

354
00:16:09,990 --> 00:16:11,960
Can't multiply.

355
00:16:11,960 --> 00:16:14,600
But can convolve.

356
00:16:14,600 --> 00:16:17,023
All right.

357
00:16:17,023 --> 00:16:18,440
Now, which of these
two is better?

358
00:16:21,350 --> 00:16:24,911
That depends on if you're
a Democrat or a Republican.

359
00:16:24,911 --> 00:16:26,430
But which of those
two is better?

360
00:16:29,650 --> 00:16:32,739
If you were designing a network,
which of these would you want?

361
00:16:32,739 --> 00:16:33,614
AUDIENCE: [INAUDIBLE]

362
00:16:33,614 --> 00:16:34,281
PROFESSOR: What?

363
00:16:34,281 --> 00:16:35,420
AUDIENCE: [INAUDIBLE].

364
00:16:35,420 --> 00:16:36,587
PROFESSOR: Yeah, a Democrat.

365
00:16:42,760 --> 00:16:43,870
This is a tough question.

366
00:16:43,870 --> 00:16:46,360
You might say that
everybody should--

367
00:16:46,360 --> 00:16:48,400
they should be as
equal as possible.

368
00:16:48,400 --> 00:16:50,410
You might say that they
should get proportion

369
00:16:50,410 --> 00:16:52,280
to what they pay for.

370
00:16:52,280 --> 00:16:55,570
There's various ways
of thinking about this.

371
00:16:55,570 --> 00:16:57,070
We're not going to
worry about the--

372
00:16:57,070 --> 00:16:58,695
I mean, it's actually
a pretty deep set

373
00:16:58,695 --> 00:17:01,040
of topics that connect with
economics and social justice

374
00:17:01,040 --> 00:17:01,540
and so on.

375
00:17:01,540 --> 00:17:05,150
And a lot of people do work on
what it means to have fairness

376
00:17:05,150 --> 00:17:07,150
and what it means--
different kinds of fairness.

377
00:17:07,150 --> 00:17:08,627
And for those who
are interested,

378
00:17:08,627 --> 00:17:10,210
I can point you to
lots of literature.

379
00:17:10,210 --> 00:17:12,940
And it's still somewhat open in
terms of, what is the right way

380
00:17:12,940 --> 00:17:14,290
to think about it?

381
00:17:14,290 --> 00:17:15,220
We're simple people.

382
00:17:15,220 --> 00:17:18,819
We'll just assume that
absent any other information,

383
00:17:18,819 --> 00:17:20,900
we would like to get
as equal as possible.

384
00:17:20,900 --> 00:17:24,760
And to do that, there are
many ways to define fairness.

385
00:17:24,760 --> 00:17:27,280
And there's a particular
one that I like because it's

386
00:17:27,280 --> 00:17:29,320
simple and somewhat intuitive.

387
00:17:29,320 --> 00:17:31,090
And it's used a
lot in networking.

388
00:17:31,090 --> 00:17:34,840
It's called the Fairness Index.

389
00:17:34,840 --> 00:17:37,410
This isn't the only way
to measure fairness.

390
00:17:37,410 --> 00:17:39,460
But this is one that we'll use.

391
00:17:39,460 --> 00:17:42,340
And the definition
of it is that I

392
00:17:42,340 --> 00:17:46,150
will look at either the
utilization or the throughput.

393
00:17:46,150 --> 00:17:47,650
It doesn't matter.

394
00:17:47,650 --> 00:17:48,940
Let me call that XI.

395
00:17:48,940 --> 00:17:53,360
In other words, XI is the
throughput or the utilization--

396
00:17:53,360 --> 00:17:54,696
let me call it throughput--

397
00:17:58,510 --> 00:18:00,924
achieved by node I.

398
00:18:00,924 --> 00:18:04,060
And if I look at
this number here,

399
00:18:04,060 --> 00:18:12,240
XI squared divided by n
summation XI squared, that's

400
00:18:12,240 --> 00:18:13,343
my definition of fairness.

401
00:18:13,343 --> 00:18:14,760
Now, this looks a
little daunting.

402
00:18:14,760 --> 00:18:17,070
But it's actually very simple.

403
00:18:17,070 --> 00:18:21,360
What it's saying is that I
take each of the throughputs

404
00:18:21,360 --> 00:18:25,440
that I get and I add them
all up and I square them.

405
00:18:25,440 --> 00:18:29,850
So if I were to divide
both sides by n squared--

406
00:18:29,850 --> 00:18:32,910
essentially, this is capturing
for me something that's

407
00:18:32,910 --> 00:18:38,280
related to the ratio of
the square of the mean

408
00:18:38,280 --> 00:18:40,783
to the variance.

409
00:18:40,783 --> 00:18:43,200
So in other words, what ends
up happening with a term like

410
00:18:43,200 --> 00:18:45,420
this-- this is a second
moment kind of a definition

411
00:18:45,420 --> 00:18:46,397
of fairness--

412
00:18:46,397 --> 00:18:48,480
this thing here looks like
the square of the mean.

413
00:18:48,480 --> 00:18:50,272
This thing here is
related to the variance.

414
00:18:50,272 --> 00:18:56,310
And this is capturing the
ratio of those two terms.

415
00:18:56,310 --> 00:18:59,400
If you have a situation
where you have n nodes

416
00:18:59,400 --> 00:19:04,230
and you end up with
everybody getting equal,

417
00:19:04,230 --> 00:19:07,680
then the fairness index
is 1, because if everybody

418
00:19:07,680 --> 00:19:10,590
has an equal value and you just
run the calculation through,

419
00:19:10,590 --> 00:19:12,590
you'll find that the
answer is equal to 1.

420
00:19:16,690 --> 00:19:19,843
So if this is F, F
is between 0 and 1.

421
00:19:19,843 --> 00:19:21,510
What's the minimum
value of the Fairness

422
00:19:21,510 --> 00:19:23,940
Index from this formula?

423
00:19:23,940 --> 00:19:26,130
Well, that happens
when you have n guys

424
00:19:26,130 --> 00:19:29,082
and the throughput looks
something like this.

425
00:19:29,082 --> 00:19:30,540
One of them gets
all the throughput

426
00:19:30,540 --> 00:19:32,823
and the others get 0.

427
00:19:32,823 --> 00:19:34,740
And if you plug that in
here, what you'll find

428
00:19:34,740 --> 00:19:36,600
is that only one
term survives, the 1

429
00:19:36,600 --> 00:19:39,330
over n term, and
everything else becomes 0.

430
00:19:39,330 --> 00:19:43,758
And so the minimum value of
the fairness is 1 over F.

431
00:19:43,758 --> 00:19:45,300
And this is intuitive
in that it says

432
00:19:45,300 --> 00:19:49,080
that if you have two people
and one guy hogs everything,

433
00:19:49,080 --> 00:19:52,110
that's a little bit less
unfair than if you have

434
00:19:52,110 --> 00:19:54,990
five people and one guy hogs
everything, because in a sense,

435
00:19:54,990 --> 00:19:57,760
one guy hogging everything out
of five is worse than one guy

436
00:19:57,760 --> 00:19:59,010
hogging everything out of two.

437
00:20:02,050 --> 00:20:04,210
The only real reason we
care about this fairness

438
00:20:04,210 --> 00:20:06,730
is we're going to compare
different variants

439
00:20:06,730 --> 00:20:08,680
of a protocol along this index.

440
00:20:08,680 --> 00:20:11,740
And I'd like you to get a feel
for what is a little fairer

441
00:20:11,740 --> 00:20:13,372
and what's less fair.

442
00:20:13,372 --> 00:20:14,830
There's nothing
particularly sacred

443
00:20:14,830 --> 00:20:17,440
about this particular
definition of fairness.

444
00:20:17,440 --> 00:20:19,723
And indeed, people
will argue also

445
00:20:19,723 --> 00:20:21,640
that this is a terrible
definition of fairness

446
00:20:21,640 --> 00:20:23,598
because it doesn't reflect
how much people have

447
00:20:23,598 --> 00:20:24,970
paid for the resource.

448
00:20:24,970 --> 00:20:26,793
But those are
details because you

449
00:20:26,793 --> 00:20:28,210
could have weighted
versions where

450
00:20:28,210 --> 00:20:30,800
people are weighted by how
much they pay, and so forth.

451
00:20:30,800 --> 00:20:33,490
So you can handle
some of that stuff.

452
00:20:33,490 --> 00:20:36,830
Is this kind of clear,
these two basic definitions?

453
00:20:36,830 --> 00:20:39,280
So we're going to worry
about throughput and fairness

454
00:20:39,280 --> 00:20:41,830
in protocols.

455
00:20:41,830 --> 00:20:42,780
Any questions so far?

456
00:20:45,790 --> 00:20:46,290
Yes?

457
00:20:46,290 --> 00:20:49,568
AUDIENCE: [INAUDIBLE].

458
00:20:49,568 --> 00:20:51,860
PROFESSOR: Depends on whether
you care about it or not.

459
00:20:51,860 --> 00:20:54,570
I mean, it depends
on the application.

460
00:20:54,570 --> 00:20:56,190
So typically speaking,
when I look at,

461
00:20:56,190 --> 00:20:58,310
for example, measuring
the performance of my--

462
00:20:58,310 --> 00:21:01,340
let's say I'm
downloading web pages.

463
00:21:01,340 --> 00:21:03,680
When I measure the
performance of web downloads,

464
00:21:03,680 --> 00:21:06,480
all header information
is just pure overhead.

465
00:21:06,480 --> 00:21:09,560
So I only look at how long it's
taken to download my content.

466
00:21:09,560 --> 00:21:13,910
But now I can go in and look
at how well is my TCP, which

467
00:21:13,910 --> 00:21:15,920
is the transport protocol,
or IP, or whatever,

468
00:21:15,920 --> 00:21:18,230
some lower level protocol
working, in which case,

469
00:21:18,230 --> 00:21:19,760
everything else is overhead.

470
00:21:19,760 --> 00:21:23,330
But I will include the
particular headers related

471
00:21:23,330 --> 00:21:25,170
to TCP in my measurement.

472
00:21:25,170 --> 00:21:27,590
So the answer to whether
something is overhead

473
00:21:27,590 --> 00:21:30,532
or not is it sort of depends
on what it is you care about.

474
00:21:30,532 --> 00:21:32,240
So if I'm delivering
video, you know, all

475
00:21:32,240 --> 00:21:34,670
this other stuff is overhead.

476
00:21:34,670 --> 00:21:38,270
And the only thing I care
about is my video frame.

477
00:21:38,270 --> 00:21:41,090
So typically, the
word throughput

478
00:21:41,090 --> 00:21:42,962
is by itself not meaningful.

479
00:21:42,962 --> 00:21:44,420
You have to say
throughput of what.

480
00:21:44,420 --> 00:21:47,090
And here I'm talking about
throughput of a protocol, which

481
00:21:47,090 --> 00:21:47,980
is what you always have to say.

482
00:21:47,980 --> 00:21:49,970
And this is the throughput
of the MAC protocol.

483
00:21:49,970 --> 00:21:52,820
And it does include
the MAC header overhead

484
00:21:52,820 --> 00:21:55,010
if you have any headers.

485
00:21:55,010 --> 00:21:57,660
Any other question?

486
00:21:57,660 --> 00:21:58,160
OK.

487
00:21:58,160 --> 00:21:59,940
There's a third metric
that's important,

488
00:21:59,940 --> 00:22:06,540
which is that we would like
to have reasonable delays.

489
00:22:06,540 --> 00:22:08,330
So in general, delay
is a good metric,

490
00:22:08,330 --> 00:22:11,480
or bounded delay
is a good metric.

491
00:22:11,480 --> 00:22:16,430
And this matters because I can
get extremely high utilization

492
00:22:16,430 --> 00:22:20,090
and extremely high
fairness by doing something

493
00:22:20,090 --> 00:22:24,260
utterly dumb and naive,
which is that if I have all

494
00:22:24,260 --> 00:22:25,820
these nodes with
a lot of packets,

495
00:22:25,820 --> 00:22:28,850
if they're all backlogged,
then what I will say is,

496
00:22:28,850 --> 00:22:32,330
today this node gets
access to the network.

497
00:22:32,330 --> 00:22:34,100
Tomorrow, he gets
access to the network.

498
00:22:34,100 --> 00:22:37,545
Day after tomorrow, he
gets access to the network.

499
00:22:37,545 --> 00:22:39,920
If they're always backlogged,
then clearly the throughput

500
00:22:39,920 --> 00:22:43,040
is-- the utilization is very
high, because the network is

501
00:22:43,040 --> 00:22:44,630
always being used
profitably and there

502
00:22:44,630 --> 00:22:49,340
are no collisions and no
idle slots, no idle time.

503
00:22:49,340 --> 00:22:51,440
The network is fair,
because if I measure

504
00:22:51,440 --> 00:22:54,360
this over a month or
a year or something,

505
00:22:54,360 --> 00:22:56,570
everybody gets equal throughput.

506
00:22:56,570 --> 00:22:59,230
But I've clobbered the delay
because this guy got lucky.

507
00:22:59,230 --> 00:23:00,980
But everybody else is
waiting and waiting.

508
00:23:00,980 --> 00:23:02,570
And in fact, even
he has to wait.

509
00:23:02,570 --> 00:23:04,820
Once today is over, he's
got to wait many days

510
00:23:04,820 --> 00:23:06,260
before he gets a turn.

511
00:23:06,260 --> 00:23:08,330
So you actually would
like to have bounded

512
00:23:08,330 --> 00:23:10,055
delay, or at least low delay.

513
00:23:10,055 --> 00:23:11,930
And this is something
we're going to measure.

514
00:23:11,930 --> 00:23:14,630
We're not going to try to
optimize in the work we're

515
00:23:14,630 --> 00:23:15,730
going to talk about.

516
00:23:15,730 --> 00:23:16,310
OK.

517
00:23:16,310 --> 00:23:18,770
So that's the statement
of the problem

518
00:23:18,770 --> 00:23:22,310
and the statement of the metrics
that we wish to optimize.

519
00:23:22,310 --> 00:23:24,438
You have to ask me questions
because if the problem

520
00:23:24,438 --> 00:23:26,480
setup wasn't clear, the
solution is kind of going

521
00:23:26,480 --> 00:23:28,310
to be completely meaningless.

522
00:23:28,310 --> 00:23:30,770
So does anyone have any
questions about the problem

523
00:23:30,770 --> 00:23:31,778
statement?

524
00:23:36,857 --> 00:23:38,940
It's one of these things
where stating the problem

525
00:23:38,940 --> 00:23:41,320
is actually a little harder
than the actual solution.

526
00:23:41,320 --> 00:23:45,473
So I'm going to tell you now one
method to solve this problem.

527
00:23:45,473 --> 00:23:46,140
I'll get to you.

528
00:23:46,140 --> 00:23:48,432
And the method we're going
to use to solve this problem

529
00:23:48,432 --> 00:23:50,970
was invented in the context
of satellite networks

530
00:23:50,970 --> 00:23:52,440
and then it got
put into ethernet

531
00:23:52,440 --> 00:23:54,380
and then it's now part of Wi-Fi.

532
00:23:54,380 --> 00:23:56,880
So everybody uses a
variant of the method

533
00:23:56,880 --> 00:23:58,270
that we are going to study.

534
00:23:58,270 --> 00:23:58,979
Yes?

535
00:23:58,979 --> 00:24:03,110
AUDIENCE: [INAUDIBLE]
how do you measure delay?

536
00:24:03,110 --> 00:24:05,353
PROFESSOR: The delay
is measured per packet.

537
00:24:05,353 --> 00:24:07,895
It's measured between when the
packets showed up at the queue

538
00:24:07,895 --> 00:24:11,510
to when it actually successfully
got received at the receiver.

539
00:24:11,510 --> 00:24:13,550
And then typically
we'll take an average

540
00:24:13,550 --> 00:24:15,050
across all of the
packets and report

541
00:24:15,050 --> 00:24:18,440
an average delay, and perhaps
the standard deviation.

542
00:24:18,440 --> 00:24:19,190
You had a comment?

543
00:24:23,710 --> 00:24:24,330
All right.

544
00:24:24,330 --> 00:24:26,460
So the solution we're
going to study--

545
00:24:26,460 --> 00:24:29,842
the basic solution is
something called ALOHA.

546
00:24:29,842 --> 00:24:31,800
ALOHA was the protocol
developed by a group led

547
00:24:31,800 --> 00:24:35,910
by Norm Abramson, who was
a professor at the time he

548
00:24:35,910 --> 00:24:38,340
did this at the
University of Hawaii.

549
00:24:38,340 --> 00:24:40,440
I believe he moved
from Stanford to Hawaii

550
00:24:40,440 --> 00:24:42,690
because he was an avid surfer.

551
00:24:42,690 --> 00:24:45,690
And he decided that-- this
was in the late '60s--

552
00:24:45,690 --> 00:24:48,090
that he wanted a
scheme to connect

553
00:24:48,090 --> 00:24:49,382
the different islands together.

554
00:24:49,382 --> 00:24:50,840
There were seven
of these islands--

555
00:24:50,840 --> 00:24:53,370
seven of these stations that
he wanted to connect together.

556
00:24:53,370 --> 00:24:57,540
And he came up with a scheme
that on the face of it

557
00:24:57,540 --> 00:24:59,610
should really not work.

558
00:24:59,610 --> 00:25:02,850
And only think good about it
is how utterly simple it is.

559
00:25:02,850 --> 00:25:05,850
And the fact that
it works is actually

560
00:25:05,850 --> 00:25:07,360
very fortunate and very useful.

561
00:25:07,360 --> 00:25:10,710
And the reason it works
is because, in a way,

562
00:25:10,710 --> 00:25:14,208
nodes doing things that
look completely random--

563
00:25:14,208 --> 00:25:15,750
as long as the
probability with which

564
00:25:15,750 --> 00:25:17,970
they do these things
is controlled,

565
00:25:17,970 --> 00:25:21,220
it turns out they
work pretty well.

566
00:25:21,220 --> 00:25:23,890
So let me first show
you a picture that

567
00:25:23,890 --> 00:25:25,500
will define a few terms.

568
00:25:25,500 --> 00:25:29,070
And I'm going to come up with a
version of this ALOHA protocol

569
00:25:29,070 --> 00:25:31,380
that ends up being a
pretty popular version.

570
00:25:31,380 --> 00:25:33,090
And it's called slotted ALOHA.

571
00:25:43,000 --> 00:25:45,970
And this model that I had from
before where the nodes have

572
00:25:45,970 --> 00:25:50,860
queues, and when two packets
run at the same time they

573
00:25:50,860 --> 00:25:53,120
end up colliding,
all of that remains.

574
00:25:53,120 --> 00:25:56,460
I'm going to add one or two more
restrictions to the kinds of--

575
00:25:56,460 --> 00:25:59,110
to the model.

576
00:25:59,110 --> 00:26:01,270
The first-- an important
thing that defines

577
00:26:01,270 --> 00:26:03,840
slotted ALOHA is
that-- and in fact, it

578
00:26:03,840 --> 00:26:06,730
defines real implementations
of this kind of protocol--

579
00:26:06,730 --> 00:26:07,810
is that time is slotted.

580
00:26:13,140 --> 00:26:16,860
What that means is that
you cannot send a packet

581
00:26:16,860 --> 00:26:21,540
at an arbitrary point in
time onto the network.

582
00:26:21,540 --> 00:26:24,300
Instead, what ends up
happening is that if time--

583
00:26:24,300 --> 00:26:27,630
you view time as a continuous--

584
00:26:27,630 --> 00:26:34,510
as a continuous variable, you
divide up time into time slots.

585
00:26:34,510 --> 00:26:36,570
I mean, these slots
could be any length.

586
00:26:36,570 --> 00:26:38,070
It doesn't matter.

587
00:26:38,070 --> 00:26:40,200
And the assumption
we're going to make

588
00:26:40,200 --> 00:26:43,860
is that packets can only get
transmitted at the beginning

589
00:26:43,860 --> 00:26:45,600
of a time slot.

590
00:26:45,600 --> 00:26:46,500
So these are legal.

591
00:26:50,340 --> 00:26:56,640
Let me-- this is a legal
packet transmission.

592
00:26:56,640 --> 00:26:58,470
And this is a legal
packet transmission.

593
00:26:58,470 --> 00:27:01,340
But this is not a legal
packet transmission.

594
00:27:01,340 --> 00:27:03,140
Not allowed.

595
00:27:03,140 --> 00:27:07,460
And the second assumption is
that every packet is an integer

596
00:27:07,460 --> 00:27:08,910
number of time slots.

597
00:27:08,910 --> 00:27:10,910
So in other words,
this is legal.

598
00:27:10,910 --> 00:27:12,727
But this is not legal.

599
00:27:12,727 --> 00:27:14,810
You cannot have a packet
that starts here and ends

600
00:27:14,810 --> 00:27:16,340
in the middle of there.

601
00:27:16,340 --> 00:27:20,270
All packets are an integer
number of time slots.

602
00:27:20,270 --> 00:27:21,710
OK.

603
00:27:21,710 --> 00:27:24,170
So if I have both of
those assumptions,

604
00:27:24,170 --> 00:27:28,080
that tells me ALOHA.

605
00:27:28,080 --> 00:27:30,020
By slotted ALOHA,
we're also going

606
00:27:30,020 --> 00:27:33,080
to make the additional
assumption that each packet is

607
00:27:33,080 --> 00:27:34,610
exactly one time slot long.

608
00:27:39,390 --> 00:27:41,070
Later on, we'll relax
this assumption.

609
00:27:41,070 --> 00:27:43,028
But I want to come up
with the world's simplest

610
00:27:43,028 --> 00:27:43,770
working protocol.

611
00:27:43,770 --> 00:27:48,610
In other words, the only
legal packets in slotted ALOHA

612
00:27:48,610 --> 00:27:51,580
are like that.

613
00:27:51,580 --> 00:27:52,290
OK.

614
00:27:52,290 --> 00:27:54,450
And as shown on
this picture, this

615
00:27:54,450 --> 00:27:56,760
is a picture of how
slotted ALOHA works.

616
00:27:56,760 --> 00:27:58,560
You have time
going on that axis.

617
00:27:58,560 --> 00:28:00,110
Time's divided into slots.

618
00:28:00,110 --> 00:28:04,830
And I have these three different
nodes-- blue, red, and green.

619
00:28:04,830 --> 00:28:08,130
When no node sends
packets in a time slot,

620
00:28:08,130 --> 00:28:10,950
that time slot is
said to be idle

621
00:28:10,950 --> 00:28:13,650
and the channel is said to
be idle in that time slot.

622
00:28:16,320 --> 00:28:20,340
If you have more than one
node sent in a time slot,

623
00:28:20,340 --> 00:28:22,200
we have a collision.

624
00:28:22,200 --> 00:28:25,080
And in our model,
none of the packets

625
00:28:25,080 --> 00:28:27,840
that sent in that time
slot gets decoded.

626
00:28:27,840 --> 00:28:31,090
All of them are wasted.

627
00:28:31,090 --> 00:28:33,080
And everything
else is a success.

628
00:28:33,080 --> 00:28:36,460
If you have a time slot in which
exactly one packet is sent,

629
00:28:36,460 --> 00:28:39,050
we'll assume in this model
that the packet is successfully

630
00:28:39,050 --> 00:28:43,400
decoded and we get to count
that as a successful packet

631
00:28:43,400 --> 00:28:45,670
reception.

632
00:28:45,670 --> 00:28:48,440
So if you count and
look in this picture,

633
00:28:48,440 --> 00:28:55,400
the utilization here is 65%
because we have 20 time slots

634
00:28:55,400 --> 00:28:56,930
here.

635
00:28:56,930 --> 00:28:59,240
And in 13 of those
time slots, we

636
00:28:59,240 --> 00:29:00,680
were able to
successfully transmit

637
00:29:00,680 --> 00:29:03,360
exactly one packet each.

638
00:29:03,360 --> 00:29:05,570
And that gives us the
utilization of 65%.

639
00:29:05,570 --> 00:29:07,917
And the advantage of
picking many of these things

640
00:29:07,917 --> 00:29:09,500
is you can't really
check in real time

641
00:29:09,500 --> 00:29:12,090
if I got the numbers
right or wrong.

642
00:29:12,090 --> 00:29:13,730
You can check that later on.

643
00:29:13,730 --> 00:29:14,760
I'm pretty sure--

644
00:29:14,760 --> 00:29:16,130
I'm not sure of anything.

645
00:29:16,130 --> 00:29:17,630
It's probably correct.

646
00:29:17,630 --> 00:29:20,540
You should just count the number
of slots in which exactly one

647
00:29:20,540 --> 00:29:22,600
guy is sent.

648
00:29:22,600 --> 00:29:23,320
OK.

649
00:29:23,320 --> 00:29:25,580
So that's the picture here.

650
00:29:25,580 --> 00:29:29,920
So what I want to do now is
to come up with an algorithm,

651
00:29:29,920 --> 00:29:31,900
with a protocol, that
each of the nodes

652
00:29:31,900 --> 00:29:35,890
can implement that
allows us to get

653
00:29:35,890 --> 00:29:38,800
reasonable utilization,
reasonable fairness,

654
00:29:38,800 --> 00:29:41,230
and reasonable delay.

655
00:29:41,230 --> 00:29:43,570
And an example of this
protocol, and one way

656
00:29:43,570 --> 00:29:47,260
of solving this
problem, is to solve

657
00:29:47,260 --> 00:29:49,880
the problem in this context
under these assumptions.

658
00:29:49,880 --> 00:29:51,922
And then we're going to
calculate the utilization

659
00:29:51,922 --> 00:29:53,500
of that protocol.

660
00:29:53,500 --> 00:29:56,080
So let me start by telling
you what the protocol is.

661
00:30:02,500 --> 00:30:05,320
The protocol-- each
node independently

662
00:30:05,320 --> 00:30:08,540
runs a version of this protocol.

663
00:30:08,540 --> 00:30:12,533
And in the protocol,
each node maintains--

664
00:30:12,533 --> 00:30:14,200
in the simplest version
of the protocol,

665
00:30:14,200 --> 00:30:17,140
each node maintains
one variable.

666
00:30:17,140 --> 00:30:20,969
And the variable it
maintains is a probability.

667
00:30:28,460 --> 00:30:30,170
So each node
maintains a variable.

668
00:30:30,170 --> 00:30:32,300
I'm going to call it p.

669
00:30:32,300 --> 00:30:35,420
And p is the
probability with which

670
00:30:35,420 --> 00:30:40,910
the node will transmit a packet
if it has a packet to transmit.

671
00:30:40,910 --> 00:30:43,910
In other words, each
node has its own variant,

672
00:30:43,910 --> 00:30:45,830
its own version of p.

673
00:30:45,830 --> 00:30:52,760
And the semantics of this
is that if backlogged,

674
00:30:52,760 --> 00:30:54,950
we won't just greedily
go ahead and transmit.

675
00:30:54,950 --> 00:30:56,990
But instead, if
we're backlogged,

676
00:30:56,990 --> 00:31:01,970
we will transmit our packet on
the channel with probability p.

677
00:31:06,820 --> 00:31:08,100
How do you generate--

678
00:31:08,100 --> 00:31:10,870
how do you actually do
something with probability p?

679
00:31:10,870 --> 00:31:12,810
Like, what would you
do to do something--

680
00:31:12,810 --> 00:31:15,990
if I were asking
you, write a program

681
00:31:15,990 --> 00:31:18,510
to transmit a packet
with probability p,

682
00:31:18,510 --> 00:31:19,780
how will you actually do that?

683
00:31:24,690 --> 00:31:25,425
Yes?

684
00:31:25,425 --> 00:31:27,925
AUDIENCE: Call a human
to roll a dice for you.

685
00:31:27,925 --> 00:31:29,550
PROFESSOR: Call a
human to roll a dice.

686
00:31:29,550 --> 00:31:30,050
All right.

687
00:31:30,050 --> 00:31:32,210
Let's try to make it a
little more practical.

688
00:31:32,210 --> 00:31:34,110
Actually, a dice has
only got six sides.

689
00:31:34,110 --> 00:31:35,460
How will I get p out of a dice?

690
00:31:35,460 --> 00:31:36,620
AUDIENCE: A lot of dice.

691
00:31:36,620 --> 00:31:38,390
PROFESSOR: A lot of dice.

692
00:31:38,390 --> 00:31:39,660
OK.

693
00:31:39,660 --> 00:31:42,210
What if I want p with
10 to the minus 17?

694
00:31:42,210 --> 00:31:43,530
AUDIENCE: A lot of [INAUDIBLE]?

695
00:31:43,530 --> 00:31:46,260
PROFESSOR: Yeah,
that's-- all right.

696
00:31:46,260 --> 00:31:48,970
Does someone have a slightly
more practical solution?

697
00:31:48,970 --> 00:31:50,350
Yes?

698
00:31:50,350 --> 00:31:53,260
AUDIENCE: Could you have a
random number between 0 and 1

699
00:31:53,260 --> 00:31:54,230
[INAUDIBLE]?

700
00:31:57,483 --> 00:31:58,650
PROFESSOR: That sounds good.

701
00:31:58,650 --> 00:32:00,420
So you pick a random
number between 0 and 1.

702
00:32:00,420 --> 00:32:01,230
I mean, how do you get that?

703
00:32:01,230 --> 00:32:02,438
Well, that's a deep question.

704
00:32:02,438 --> 00:32:05,120
But I would just call
random.random in Python,

705
00:32:05,120 --> 00:32:07,050
or whatever the thing is.

706
00:32:07,050 --> 00:32:09,330
And you know, how
Python does it is very--

707
00:32:09,330 --> 00:32:11,230
there's ways to botch it.

708
00:32:11,230 --> 00:32:13,740
But for our purposes,
we'll assume it's correct.

709
00:32:13,740 --> 00:32:16,470
And if the number you get
is less than or equal to p,

710
00:32:16,470 --> 00:32:19,290
that tells you an event
with probability p.

711
00:32:19,290 --> 00:32:20,070
That's great.

712
00:32:20,070 --> 00:32:21,380
OK.

713
00:32:21,380 --> 00:32:22,680
So suppose we did this.

714
00:32:22,680 --> 00:32:24,797
I'm not telling you
how to pick p yet.

715
00:32:24,797 --> 00:32:27,130
That's magic that's going to
come up a little bit later.

716
00:32:27,130 --> 00:32:29,460
But suppose every
node had a value of p,

717
00:32:29,460 --> 00:32:31,860
that someone came and
told it, you know what?

718
00:32:31,860 --> 00:32:34,240
There are n nodes in the system.

719
00:32:34,240 --> 00:32:37,180
Let's assume there are n
backlog nodes in the system.

720
00:32:37,180 --> 00:32:40,320
And I told you that somebody
came and told each node

721
00:32:40,320 --> 00:32:43,200
that it can transmit with p.

722
00:32:43,200 --> 00:32:44,920
What is the utilization
of this protocol?

723
00:32:44,920 --> 00:32:53,580
So if I have n backlog
nodes, each transmitting

724
00:32:53,580 --> 00:32:57,173
with this probability p,
what is the utilization

725
00:32:57,173 --> 00:32:57,840
of the protocol?

726
00:33:02,070 --> 00:33:04,470
I want to know what is
the utilization, which

727
00:33:04,470 --> 00:33:07,440
is, of course, a
function of n and p?

728
00:33:07,440 --> 00:33:09,760
And the way you have
to answer this question

729
00:33:09,760 --> 00:33:12,660
is, of course, you draw
this picture in time

730
00:33:12,660 --> 00:33:14,145
and you divide time into slots.

731
00:33:17,058 --> 00:33:18,600
You've got some of
these things where

732
00:33:18,600 --> 00:33:20,940
you have one packet going
through, some of these things

733
00:33:20,940 --> 00:33:22,315
where more than
one goes through,

734
00:33:22,315 --> 00:33:25,620
in which case, this
is a collision.

735
00:33:25,620 --> 00:33:28,800
And I ask you, what
is the utilization?

736
00:33:28,800 --> 00:33:30,060
How would you calculate it?

737
00:33:30,060 --> 00:33:32,460
Suppose you observe the
running of the protocol

738
00:33:32,460 --> 00:33:35,395
and you find that in some
time slots there's a collision

739
00:33:35,395 --> 00:33:37,020
and in some time
slots there's nothing.

740
00:33:37,020 --> 00:33:39,754
And in some time slots, there's
exactly one transmission.

741
00:33:45,570 --> 00:33:47,820
If you look at
this, how would you

742
00:33:47,820 --> 00:33:52,000
calculate the utilization
of the protocol?

743
00:33:52,000 --> 00:33:53,780
The utilization
is the throughput

744
00:33:53,780 --> 00:33:56,180
over the maximum rate.

745
00:33:56,180 --> 00:33:58,340
What's the maximum
rate of this channel?

746
00:33:58,340 --> 00:34:01,190
Well, the rate is measured in--

747
00:34:01,190 --> 00:34:03,950
the rate here is measured
in packets per time slot.

748
00:34:03,950 --> 00:34:07,160
And I've said that each
packet occupies one time slot.

749
00:34:07,160 --> 00:34:09,170
So the maximum rate
is every time slot

750
00:34:09,170 --> 00:34:10,860
is occupied with a packet.

751
00:34:10,860 --> 00:34:13,310
So the maximum rate is
one packet per time slot.

752
00:34:13,310 --> 00:34:15,000
You cannot send
faster than that.

753
00:34:15,000 --> 00:34:18,363
So the denominator is just one.

754
00:34:18,363 --> 00:34:20,030
Therefore, the
utilization in this model

755
00:34:20,030 --> 00:34:22,699
is simply equal to the
throughput, which is simply

756
00:34:22,699 --> 00:34:24,710
equal to the number
of time slots

757
00:34:24,710 --> 00:34:27,230
in which I have
exactly one packet.

758
00:34:27,230 --> 00:34:30,469
Or put another way, if I
look for a long enough amount

759
00:34:30,469 --> 00:34:33,139
of time, it's the number of
time slots with exactly one

760
00:34:33,139 --> 00:34:35,060
packet that tells
me the throughput,

761
00:34:35,060 --> 00:34:37,110
and therefore, tells
me the utilization.

762
00:34:40,050 --> 00:34:41,830
So if I look for a
very, very long time

763
00:34:41,830 --> 00:34:44,400
and I count the number
of successful packets,

764
00:34:44,400 --> 00:34:46,320
that's going to tell
me the utilization

765
00:34:46,320 --> 00:34:52,205
if I take the number and divide
by the number of time slots.

766
00:34:52,205 --> 00:34:53,580
And therefore,
the utilization is

767
00:34:53,580 --> 00:34:57,750
equal to simply the
fraction of time slots

768
00:34:57,750 --> 00:35:01,920
in which I have one packet
and exactly one packet sent,

769
00:35:01,920 --> 00:35:04,650
which is equivalent to
asking, what's the probability

770
00:35:04,650 --> 00:35:06,330
that in any given
time slot, I have

771
00:35:06,330 --> 00:35:10,953
exactly one successful--
one exactly one packet sent?

772
00:35:10,953 --> 00:35:12,120
So I'm going to repeat this.

773
00:35:14,640 --> 00:35:16,980
The utilization of this
protocol is exactly

774
00:35:16,980 --> 00:35:19,890
equal to the probability
that in any given time slot,

775
00:35:19,890 --> 00:35:23,820
I have exactly one transmission.

776
00:35:23,820 --> 00:35:25,320
If you disagree
with that statement,

777
00:35:25,320 --> 00:35:28,920
you have to raise your hand now,
or if you don't understand it,

778
00:35:28,920 --> 00:35:30,840
so I can explain it
again, because we're

779
00:35:30,840 --> 00:35:33,450
going to use this idea
repeatedly in pretty much--

780
00:35:33,450 --> 00:35:36,270
there's guaranteed to be some
question on the quiz related

781
00:35:36,270 --> 00:35:37,372
to this idea.

782
00:35:37,372 --> 00:35:39,330
And then you have to work
some probability out.

783
00:35:39,330 --> 00:35:42,150
So does everyone understand why
the utilization of the protocol

784
00:35:42,150 --> 00:35:45,750
is equal to the probability
that in any time slot

785
00:35:45,750 --> 00:35:47,670
there's exactly one
transmission of a packet?

786
00:35:50,600 --> 00:35:53,630
The reason why that's true is
it follows from this definition

787
00:35:53,630 --> 00:35:57,110
because the maximum rate here
is one packet per time slot.

788
00:35:57,110 --> 00:35:59,050
And so I want to know
what the throughput is.

789
00:35:59,050 --> 00:36:01,550
The throughput is simply, I
look over a long period of time,

790
00:36:01,550 --> 00:36:03,080
many time slots,
and I count what's

791
00:36:03,080 --> 00:36:05,225
the number of packets I sent.

792
00:36:05,225 --> 00:36:07,100
So if I take the number
of successful packets

793
00:36:07,100 --> 00:36:09,302
I sent and divide by the
number of time slots,

794
00:36:09,302 --> 00:36:11,510
well, that's actually the
definition of a probability

795
00:36:11,510 --> 00:36:13,427
that in any given time
slot I have exactly one

796
00:36:13,427 --> 00:36:15,290
successful transmission.

797
00:36:15,290 --> 00:36:19,250
And therefore, the utilization
is equal to the probability

798
00:36:19,250 --> 00:36:23,814
that I have exactly
one transmission.

799
00:36:27,450 --> 00:36:29,020
So I have n backlog nodes.

800
00:36:29,020 --> 00:36:33,640
Each guy sends with
probability p in a time slot.

801
00:36:33,640 --> 00:36:36,468
What's the probability that I
have exactly one transmission?

802
00:36:40,452 --> 00:36:41,950
AUDIENCE: [INAUDIBLE].

803
00:36:41,950 --> 00:36:43,367
PROFESSOR: Well,
there's certainly

804
00:36:43,367 --> 00:36:46,210
a p, which is success,
times 1 minus p

805
00:36:46,210 --> 00:36:48,620
to the n minus 1, which is
all the other guys keep quiet.

806
00:36:52,070 --> 00:36:53,370
Is this right?

807
00:36:53,370 --> 00:36:54,445
It's almost right.

808
00:36:54,445 --> 00:36:55,810
AUDIENCE: And then
times n because there's

809
00:36:55,810 --> 00:36:56,720
n ways to [INAUDIBLE].

810
00:36:56,720 --> 00:36:57,512
PROFESSOR: Times n.

811
00:36:57,512 --> 00:36:59,640
There's an n choose
one, which is

812
00:36:59,640 --> 00:37:01,157
there are n ways
to pick the winner,

813
00:37:01,157 --> 00:37:02,490
and therefore that's the answer.

814
00:37:04,960 --> 00:37:05,460
All right.

815
00:37:05,460 --> 00:37:11,250
Let's hold n times-- so
let me write this as u

816
00:37:11,250 --> 00:37:15,990
equals n times p times 1
minus p to the n minus 1.

817
00:37:15,990 --> 00:37:17,370
Suppose you knew n.

818
00:37:17,370 --> 00:37:19,380
Suppose n were some value--

819
00:37:19,380 --> 00:37:20,380
10, 15, whatever.

820
00:37:23,130 --> 00:37:26,010
Therefore, I would view
this-- assuming n is constant,

821
00:37:26,010 --> 00:37:28,590
I could view this
as a function of p.

822
00:37:35,730 --> 00:37:38,550
If I want to maximize
this utilization,

823
00:37:38,550 --> 00:37:41,430
I want to-- obviously I
want to maximize it, right?

824
00:37:41,430 --> 00:37:44,700
If I want to maximize
the utilization,

825
00:37:44,700 --> 00:37:45,595
what should be p be?

826
00:37:55,660 --> 00:37:57,060
Or I'll call it p star.

827
00:37:57,060 --> 00:37:59,670
What's the value of p
equal to p star that

828
00:37:59,670 --> 00:38:01,330
maximizes this utilization?

829
00:38:01,330 --> 00:38:01,830
Yes?

830
00:38:01,830 --> 00:38:03,300
AUDIENCE: 1 over n.

831
00:38:03,300 --> 00:38:04,640
PROFESSOR: 1 over n.

832
00:38:04,640 --> 00:38:07,008
Yeah, you could do this the
hard way or the easy way.

833
00:38:07,008 --> 00:38:10,290
AUDIENCE: Differentiating
[INAUDIBLE]..

834
00:38:10,290 --> 00:38:11,010
PROFESSOR: Great.

835
00:38:11,010 --> 00:38:14,670
So if you did that, the answer
works out to be p star--

836
00:38:14,670 --> 00:38:19,150
if you do u prime of p equals
0 and you solve that, you'll

837
00:38:19,150 --> 00:38:20,940
find that p star is 1 over n.

838
00:38:24,780 --> 00:38:28,337
The long way to do it
is the way you describe.

839
00:38:28,337 --> 00:38:30,420
But the answer is intuitive
because what it really

840
00:38:30,420 --> 00:38:33,750
says is that, if I did
have every node transmit

841
00:38:33,750 --> 00:38:36,940
with probability 1
over n in a time slot,

842
00:38:36,940 --> 00:38:39,330
the expected number of
transmissions within any given

843
00:38:39,330 --> 00:38:44,170
time slot is n times 1 over
n, which is 1, which is

844
00:38:44,170 --> 00:38:45,420
kind of what you would expect.

845
00:38:45,420 --> 00:38:46,795
You would expect
that to maximize

846
00:38:46,795 --> 00:38:49,680
the utilization, the expected
number of nodes that transmit

847
00:38:49,680 --> 00:38:51,840
at any given time slot is 1.

848
00:38:51,840 --> 00:38:53,430
And that's fortunately
what you do

849
00:38:53,430 --> 00:38:57,290
get if you solve the equation.

850
00:38:57,290 --> 00:38:59,440
So p star is 1 over n.

851
00:38:59,440 --> 00:39:01,860
So if somebody told you the
number of backlogged nodes

852
00:39:01,860 --> 00:39:04,290
in the network and
they had the ability

853
00:39:04,290 --> 00:39:08,010
to program each node to set
the appropriate probability,

854
00:39:08,010 --> 00:39:13,540
the probability you
would use is 1 over n.

855
00:39:13,540 --> 00:39:16,230
So let's assume still
this world where we know

856
00:39:16,230 --> 00:39:17,770
the number of backlog nodes.

857
00:39:17,770 --> 00:39:20,580
And somebody came and told us
the probability we should use.

858
00:39:23,730 --> 00:39:25,000
Do I need anything here?

859
00:39:25,000 --> 00:39:27,368
Let me erase this.

860
00:39:27,368 --> 00:39:29,910
If somebody came and told you
the probability you should use,

861
00:39:29,910 --> 00:39:31,380
you would pick 1 over n.

862
00:39:31,380 --> 00:39:32,400
That's great.

863
00:39:32,400 --> 00:39:40,580
So now therefore I
can now view u star

864
00:39:40,580 --> 00:39:43,460
of n, which is the maximum
probability now becomes

865
00:39:43,460 --> 00:39:47,570
a function of n, because I can
go back in here and I can set--

866
00:39:47,570 --> 00:39:50,000
assuming you picked
this value of p,

867
00:39:50,000 --> 00:39:52,900
you can stick p equal to
1 over n in this formula

868
00:39:52,900 --> 00:39:56,668
and then you get a utilization
that's purely a function of n

869
00:39:56,668 --> 00:39:58,460
because I want to draw
this picture of what

870
00:39:58,460 --> 00:39:59,630
it looks like with n.

871
00:39:59,630 --> 00:40:02,600
So you start off n
is equal to n times 1

872
00:40:02,600 --> 00:40:06,230
over n, which is the value of
p that's the best value of p,

873
00:40:06,230 --> 00:40:09,965
times 1 minus 1 over
n to the n minus 1.

874
00:40:09,965 --> 00:40:11,418
Does that makes sense?

875
00:40:11,418 --> 00:40:13,210
Haven't done anything
other than substitute

876
00:40:13,210 --> 00:40:17,430
a value of p star
equal to 1 over n.

877
00:40:17,430 --> 00:40:23,430
And that's equal to 1 minus 1
over n to the power n minus 1.

878
00:40:26,933 --> 00:40:28,600
Now, one of the
questions we want to ask

879
00:40:28,600 --> 00:40:30,610
is, is this how--
this is the best you

880
00:40:30,610 --> 00:40:33,850
can do in this protocol.

881
00:40:33,850 --> 00:40:35,612
How good or how bad is it?

882
00:40:35,612 --> 00:40:37,570
So let's draw a picture
of what this looks like

883
00:40:37,570 --> 00:40:40,850
as n becomes large.

884
00:40:40,850 --> 00:40:45,190
So I want to draw a picture
of n on this axis and the best

885
00:40:45,190 --> 00:40:48,400
value of the utilization, which
is u star of n on this axis.

886
00:40:52,070 --> 00:40:55,740
Well, when n is 1, get to n is
1-- actually, intuitively, when

887
00:40:55,740 --> 00:40:57,672
n is 1, what's the utilization?

888
00:40:57,672 --> 00:40:59,630
When you have one backlog
node and the protocol

889
00:40:59,630 --> 00:41:02,750
runs with the value of
p equal to 1 over n,

890
00:41:02,750 --> 00:41:04,920
what's the utilization?

891
00:41:04,920 --> 00:41:06,950
The utilization is 1.

892
00:41:06,950 --> 00:41:09,390
This formula, you got to
take the limit, and so on.

893
00:41:09,390 --> 00:41:11,120
But the answer is 1.

894
00:41:11,120 --> 00:41:16,080
So let's assume this is 1
and 2 and 3 and 4, and so on.

895
00:41:16,080 --> 00:41:17,360
So it's 1.

896
00:41:17,360 --> 00:41:20,300
What is it when n equals 2?

897
00:41:20,300 --> 00:41:22,320
What's the utilization
when n equals 2?

898
00:41:22,320 --> 00:41:26,040
Well, it's 1/2 to the
power 1, which is 50%.

899
00:41:26,040 --> 00:41:29,030
So I get a value which is 1/2.

900
00:41:29,030 --> 00:41:30,890
When n is 3, what happens?

901
00:41:30,890 --> 00:41:34,360
Well, 1 minus 1/3 squared,
which is 4 over 9.

902
00:41:40,740 --> 00:41:42,610
As n goes bigger and
bigger and bigger,

903
00:41:42,610 --> 00:41:43,810
what does this value become?

904
00:41:46,762 --> 00:41:47,262
Yeah?

905
00:41:47,262 --> 00:41:48,558
AUDIENCE: [INAUDIBLE].

906
00:41:48,558 --> 00:41:50,891
PROFESSOR: Yeah, as n goes
bigger and bigger and bigger,

907
00:41:50,891 --> 00:41:53,610
you do the limit when n goes to
infinity of this thing here. n

908
00:41:53,610 --> 00:41:55,527
minus 1 and n are more
or less the same thing,

909
00:41:55,527 --> 00:41:57,660
so you can get rid of that.

910
00:41:57,660 --> 00:41:59,610
This should be a
well-known limit.

911
00:41:59,610 --> 00:42:03,625
If you don't know
it, you take the log.

912
00:42:03,625 --> 00:42:05,250
You take the log and
you find the limit

913
00:42:05,250 --> 00:42:06,210
as it goes to infinity.

914
00:42:06,210 --> 00:42:08,680
You can expand that
into a power series.

915
00:42:08,680 --> 00:42:10,500
And you'll find
that the answer--

916
00:42:10,500 --> 00:42:13,530
the limit of the log is
minus 1 or this value,

917
00:42:13,530 --> 00:42:15,810
the limit goes to 1 over e.

918
00:42:15,810 --> 00:42:22,020
So in fact, it goes to a
value which is 1 over e when

919
00:42:22,020 --> 00:42:23,850
n is large, or about 37%.

920
00:42:26,760 --> 00:42:27,830
This is actually not bad.

921
00:42:27,830 --> 00:42:28,830
It's actually very good.

922
00:42:28,830 --> 00:42:32,370
For a protocol that did nothing
sophisticated, all it did

923
00:42:32,370 --> 00:42:34,680
was pick a value of
this probability.

924
00:42:34,680 --> 00:42:37,050
The fact that it's able to
get not a zero utilization

925
00:42:37,050 --> 00:42:39,000
but a reasonably
good utilization

926
00:42:39,000 --> 00:42:41,030
is an extremely strong--

927
00:42:41,030 --> 00:42:44,270
is a pretty strong result.

928
00:42:44,270 --> 00:42:47,150
And that's the basic
ALOHA protocol.

929
00:42:47,150 --> 00:42:49,565
The basic ALOHA protocol,
or a fixed probability ALOHA

930
00:42:49,565 --> 00:42:50,940
protocol, is
somebody telling you

931
00:42:50,940 --> 00:42:54,840
the number of backlogged nodes
and you using that information

932
00:42:54,840 --> 00:42:57,570
to make sure that every node
sends with some probability.

933
00:42:57,570 --> 00:43:00,660
And they just-- and
the probability you

934
00:43:00,660 --> 00:43:03,083
would pick is 1 over n.

935
00:43:03,083 --> 00:43:05,250
Now, this is not actually
a very practical protocol,

936
00:43:05,250 --> 00:43:07,950
because how do you know which
nodes have backlogged packets

937
00:43:07,950 --> 00:43:09,360
and which nodes don't?

938
00:43:09,360 --> 00:43:11,670
What we would like us to come
up with a way by which we

939
00:43:11,670 --> 00:43:15,000
automatically have a
protocol that somehow

940
00:43:15,000 --> 00:43:18,900
gets us to the
correct utilization.

941
00:43:18,900 --> 00:43:22,140
And we're going to do that by
adding a method to this ALOHA

942
00:43:22,140 --> 00:43:24,640
protocol that will make
it completely practical.

943
00:43:24,640 --> 00:43:28,890
And that method is
called stabilization.

944
00:43:28,890 --> 00:43:31,740
And the purpose of
stabilization is

945
00:43:31,740 --> 00:43:34,620
to determine at each node
what the actual value of p

946
00:43:34,620 --> 00:43:35,400
it should use is.

947
00:43:35,400 --> 00:43:38,160
And that value of p is
going to change with time

948
00:43:38,160 --> 00:43:42,210
as other nodes have traffic
to send and if nodes go away.

949
00:43:42,210 --> 00:43:45,210
So the magic protocol
is going to be somehow

950
00:43:45,210 --> 00:43:49,290
that we're able to change
the value of p at every node.

951
00:43:49,290 --> 00:43:51,060
Every node runs an
algorithm which adapts

952
00:43:51,060 --> 00:43:53,200
its value of p over time.

953
00:43:53,200 --> 00:43:55,950
And if there's a lot of
competition, the value of p

954
00:43:55,950 --> 00:43:56,880
will reduce.

955
00:43:56,880 --> 00:43:59,070
If there's very little
competition, the value of p

956
00:43:59,070 --> 00:44:00,240
increases.

957
00:44:00,240 --> 00:44:02,220
And if we do that,
we're going to be

958
00:44:02,220 --> 00:44:04,120
able to get pretty
good utilization.

959
00:44:04,120 --> 00:44:09,254
And this process is
called stabilization.

960
00:44:09,254 --> 00:44:11,915
AUDIENCE: Are we still
assuming that all of the nodes

961
00:44:11,915 --> 00:44:13,707
are transmitting with
the same probability?

962
00:44:13,707 --> 00:44:15,930
PROFESSOR: Nope.

963
00:44:15,930 --> 00:44:17,513
The nodes will end
up not transmitting

964
00:44:17,513 --> 00:44:19,430
with the same probability
because they're each

965
00:44:19,430 --> 00:44:21,190
going to be making
independent decisions.

966
00:44:21,190 --> 00:44:22,005
So the first thing
we're going to do

967
00:44:22,005 --> 00:44:24,060
is each node is still
going to have a p.

968
00:44:24,060 --> 00:44:27,390
But in fact, node i is going
to have its own variable.

969
00:44:27,390 --> 00:44:29,640
So we're going to say that
node i has its own variable

970
00:44:29,640 --> 00:44:31,530
that only it knows.

971
00:44:31,530 --> 00:44:35,350
And its probability is p i.

972
00:44:35,350 --> 00:44:37,810
So the way we're going
to do the stabilization

973
00:44:37,810 --> 00:44:40,400
is very, very simple.

974
00:44:40,400 --> 00:44:43,160
We're going to say that at
node i, it's going to do--

975
00:44:43,160 --> 00:44:46,720
well, the only information
it gets is it sends a packet.

976
00:44:46,720 --> 00:44:48,710
And if the packet succeeds,
it knows something.

977
00:44:48,710 --> 00:44:52,240
If the packet doesn't
succeed, it knows something.

978
00:44:52,240 --> 00:44:55,760
So let's say that a node sends
a packet and the packet fails.

979
00:44:55,760 --> 00:44:57,760
And the way you know that
a packet fails-- and I

980
00:44:57,760 --> 00:44:58,843
haven't talked about this.

981
00:44:58,843 --> 00:45:01,210
But the way this protocol--
all these protocols-- end up

982
00:45:01,210 --> 00:45:02,980
working is they send
a packet and then

983
00:45:02,980 --> 00:45:05,830
they watch to see if the
packet succeeds or not.

984
00:45:05,830 --> 00:45:08,140
They can get that information
by an acknowledgment

985
00:45:08,140 --> 00:45:10,222
coming from the receiver.

986
00:45:10,222 --> 00:45:11,680
Or in the case of
certain networks,

987
00:45:11,680 --> 00:45:13,420
like ethernet, when
you send a packet,

988
00:45:13,420 --> 00:45:16,780
if you aren't able to receive
your own packet on that bus,

989
00:45:16,780 --> 00:45:19,320
then you know that it's failed.

990
00:45:19,320 --> 00:45:20,320
So that's just a detail.

991
00:45:20,320 --> 00:45:21,737
But the assumption
here is there's

992
00:45:21,737 --> 00:45:24,760
some feedback that tells
the node whether a packet

993
00:45:24,760 --> 00:45:26,975
transmission succeeded or not.

994
00:45:26,975 --> 00:45:28,600
In general, it's with
an acknowledgment

995
00:45:28,600 --> 00:45:29,808
that comes from the receiver.

996
00:45:29,808 --> 00:45:32,740
If you get an ACK,
it means it succeeds.

997
00:45:32,740 --> 00:45:34,810
So we're going to
have two rules.

998
00:45:34,810 --> 00:45:38,170
If you don't succeed-- in other
words, there's a collision--

999
00:45:38,170 --> 00:45:39,720
then you do something.

1000
00:45:39,720 --> 00:45:44,158
And in contrast, if you
succeed, you do something.

1001
00:45:46,537 --> 00:45:48,370
So what we're going to
do on a collision is,

1002
00:45:48,370 --> 00:45:50,662
let's say that you send a
packet and it didn't succeed.

1003
00:45:50,662 --> 00:45:51,350
It collided.

1004
00:45:51,350 --> 00:45:52,532
Yes?

1005
00:45:52,532 --> 00:45:54,812
AUDIENCE: So with
the acknowledgement,

1006
00:45:54,812 --> 00:45:56,333
what if the
acknowledgement fails?

1007
00:45:56,333 --> 00:45:57,000
PROFESSOR: Yeah.

1008
00:45:59,510 --> 00:46:01,620
You're out of luck,
because in reality,

1009
00:46:01,620 --> 00:46:04,380
in Wi-Fi, when an
acknowledgment fails,

1010
00:46:04,380 --> 00:46:06,840
what ends up happening is you
assume the packet collided.

1011
00:46:06,840 --> 00:46:10,970
So how people deal with this
problem is typically to--

1012
00:46:10,970 --> 00:46:14,283
essentially to do very
strong error protection

1013
00:46:14,283 --> 00:46:15,200
on the acknowledgment.

1014
00:46:15,200 --> 00:46:16,710
You send it at a
very low bitrate.

1015
00:46:16,710 --> 00:46:18,210
And what that really
means is you're

1016
00:46:18,210 --> 00:46:20,293
adding a lot of redundancy
to that acknowledgment.

1017
00:46:20,293 --> 00:46:21,900
So imagine you're
coding the heck out

1018
00:46:21,900 --> 00:46:24,030
of it using channel coding.

1019
00:46:24,030 --> 00:46:25,290
That's what happens.

1020
00:46:28,350 --> 00:46:29,340
OK.

1021
00:46:29,340 --> 00:46:32,490
Let's say you send a
packet and it collides.

1022
00:46:32,490 --> 00:46:37,080
What should you do to the
node's transmission probability?

1023
00:46:37,080 --> 00:46:39,164
Increase it or reduce it?

1024
00:46:39,164 --> 00:46:40,140
AUDIENCE: Reduce it.

1025
00:46:40,140 --> 00:46:41,190
PROFESSOR: Sorry?

1026
00:46:41,190 --> 00:46:41,670
AUDIENCE: Reduce it.

1027
00:46:41,670 --> 00:46:42,540
PROFESSOR: Reduce it,
because the assumption is it

1028
00:46:42,540 --> 00:46:44,873
collided because presumably
there's a lot of competition

1029
00:46:44,873 --> 00:46:45,870
and you're a nice guy.

1030
00:46:45,870 --> 00:46:47,828
And your assumption is
that all the other nodes

1031
00:46:47,828 --> 00:46:51,897
are nice people, too, which
is kind of changing nowadays

1032
00:46:51,897 --> 00:46:53,480
with all these
software defined radios

1033
00:46:53,480 --> 00:46:56,580
and the hacking that you
can do on Wi-Fi cards.

1034
00:46:56,580 --> 00:46:59,890
It's possible for your node
to not actually back off.

1035
00:46:59,890 --> 00:47:02,120
But if you're a nice node,
what you're going to do

1036
00:47:02,120 --> 00:47:03,870
is you're going to
reduce the probability.

1037
00:47:03,870 --> 00:47:06,037
And one way of doing that,
a good way of doing that,

1038
00:47:06,037 --> 00:47:08,480
is called multiplicative
reduction,

1039
00:47:08,480 --> 00:47:09,990
or multiplicative decrease.

1040
00:47:09,990 --> 00:47:12,840
You reduce it by a factor of 2.

1041
00:47:12,840 --> 00:47:14,640
You just halve it.

1042
00:47:14,640 --> 00:47:17,320
And on a success, you could do
a bunch of different things.

1043
00:47:17,320 --> 00:47:20,178
But one thing you can do is
you can be a little bit greedy

1044
00:47:20,178 --> 00:47:20,970
and say, all right.

1045
00:47:20,970 --> 00:47:23,880
I succeeded, which means there's
not that much competition

1046
00:47:23,880 --> 00:47:24,763
in the network.

1047
00:47:24,763 --> 00:47:27,180
Maybe there's nobody else in
the network, in which case, I

1048
00:47:27,180 --> 00:47:29,730
want to keep trying to increase
my transmission probability.

1049
00:47:29,730 --> 00:47:32,190
And maybe you double it.

1050
00:47:32,190 --> 00:47:35,160
And my notes talk about
whether this is right

1051
00:47:35,160 --> 00:47:36,540
or something else is right.

1052
00:47:36,540 --> 00:47:37,790
But it really doesn't matter.

1053
00:47:37,790 --> 00:47:40,620
It turns out the important
rule is this rule.

1054
00:47:40,620 --> 00:47:42,210
The protocol turns
out to be not very

1055
00:47:42,210 --> 00:47:43,470
sensitive to how you increase.

1056
00:47:43,470 --> 00:47:44,470
You do have to increase.

1057
00:47:44,470 --> 00:47:47,260
But it doesn't
matter how you do it.

1058
00:47:47,260 --> 00:47:49,500
Now, of course, the
probabilities can't exceed 1.

1059
00:47:49,500 --> 00:47:55,110
So we're going to actually pick
the minimum of 2 times p and 1.

1060
00:47:55,110 --> 00:47:58,340
This is our basic
stabilization protocol.

1061
00:47:58,340 --> 00:48:01,050
Now, every node has
its own version of p.

1062
00:48:01,050 --> 00:48:03,345
And so you may run
with a p of 0.8

1063
00:48:03,345 --> 00:48:06,100
and I might be at a p of 0.1.

1064
00:48:06,100 --> 00:48:08,100
Presumably, if I succeed,
I'm going to increase.

1065
00:48:08,100 --> 00:48:09,300
If you fail, you're
going to decrease.

1066
00:48:09,300 --> 00:48:10,290
And something happens.

1067
00:48:10,290 --> 00:48:12,420
The question is, what happens?

1068
00:48:12,420 --> 00:48:14,330
And that's what I
want to show you.

1069
00:48:14,330 --> 00:48:16,330
I'm going to skip all the
stuff we went through.

1070
00:48:19,180 --> 00:48:22,080
So if I run this protocol
exactly as I've described

1071
00:48:22,080 --> 00:48:24,480
on this board here-- and
this is an experiment with--

1072
00:48:24,480 --> 00:48:27,180
you'll be doing all this
stuff in the lab yourself.

1073
00:48:27,180 --> 00:48:30,420
This is with 10 nodes.

1074
00:48:30,420 --> 00:48:34,350
What you see is that you have
a utilization of 0.33, which

1075
00:48:34,350 --> 00:48:38,370
is not too far from the 1
over e utilization, which

1076
00:48:38,370 --> 00:48:41,400
is remarkable that this protocol
where everybody just jumped

1077
00:48:41,400 --> 00:48:45,090
around multiplicatively
changing p i like this

1078
00:48:45,090 --> 00:48:47,090
worked out to be a
pretty good utilization.

1079
00:48:47,090 --> 00:48:48,840
But there's a big
problem in the protocol.

1080
00:48:48,840 --> 00:48:51,060
And the problem in the
protocol is that the fairness

1081
00:48:51,060 --> 00:48:52,800
is pretty terrible.

1082
00:48:52,800 --> 00:48:54,510
As it happens, it's 0.47.

1083
00:48:54,510 --> 00:48:56,370
I was reminded that
47% of the nodes

1084
00:48:56,370 --> 00:48:59,026
here got pretty
healthy throughput.

1085
00:48:59,026 --> 00:49:02,410
It's probably looking for
handouts or something.

1086
00:49:02,410 --> 00:49:04,170
But anyway, it's pretty bad.

1087
00:49:04,170 --> 00:49:06,600
And what's going on
here is that when

1088
00:49:06,600 --> 00:49:09,330
a node is running at a high
value of its probability

1089
00:49:09,330 --> 00:49:12,600
and some other node is at a
low value of the probability,

1090
00:49:12,600 --> 00:49:14,700
if they collide, the
guy with the higher

1091
00:49:14,700 --> 00:49:18,012
value of its probability
reduces some by a factor of 2,

1092
00:49:18,012 --> 00:49:19,470
but it's still a
pretty high value,

1093
00:49:19,470 --> 00:49:21,780
whereas if a node has a
probability of transmission,

1094
00:49:21,780 --> 00:49:26,460
somehow it's got screwed and
it's now running at 1 over 32,

1095
00:49:26,460 --> 00:49:29,070
it becomes 1 over
64, then 1 over 128.

1096
00:49:29,070 --> 00:49:30,010
It's practically 0.

1097
00:49:30,010 --> 00:49:33,870
It doesn't ever get out of
that real morass that it's in

1098
00:49:33,870 --> 00:49:37,350
and ever start being able to
successfully transmit again.

1099
00:49:37,350 --> 00:49:39,110
And that's what's
happening here.

1100
00:49:39,110 --> 00:49:40,910
And the way you
solve this problem--

1101
00:49:40,910 --> 00:49:43,810
there's a very simple
solution to this problem.

1102
00:49:43,810 --> 00:49:45,450
The way you solve
this problem is you

1103
00:49:45,450 --> 00:49:48,780
decide that nobody should get
really, really poor, that you

1104
00:49:48,780 --> 00:49:52,400
decide that you're going to have
a value of the probability p

1105
00:49:52,400 --> 00:49:55,630
min that will never
actually get--

1106
00:49:55,630 --> 00:49:57,450
you'll never go below that.

1107
00:49:57,450 --> 00:49:59,070
So you modify the
protocol to do that.

1108
00:50:01,600 --> 00:50:04,620
And if you do that, you end up
with much better performance.

1109
00:50:04,620 --> 00:50:07,560
You end up with performance
that looks like this.

1110
00:50:11,628 --> 00:50:12,920
And you'll see this in the lab.

1111
00:50:12,920 --> 00:50:15,830
But what you find here is
something very puzzling.

1112
00:50:15,830 --> 00:50:18,060
What you find here is that
the fairness is amazing.

1113
00:50:18,060 --> 00:50:21,500
It's 99.99, which is really,
really good fairness.

1114
00:50:21,500 --> 00:50:25,775
But what you find is that
the utilization is 0.71.

1115
00:50:25,775 --> 00:50:28,400
That's actually too
good to be true,

1116
00:50:28,400 --> 00:50:30,710
because the best
utilization you could expect

1117
00:50:30,710 --> 00:50:32,840
is probably around 37%.

1118
00:50:32,840 --> 00:50:36,570
And the fact is, we're getting
something astonishingly good.

1119
00:50:36,570 --> 00:50:38,390
What's happening here
actually is something

1120
00:50:38,390 --> 00:50:39,390
that's really important.

1121
00:50:39,390 --> 00:50:41,480
It took people a few
years to figure it out.

1122
00:50:41,480 --> 00:50:43,100
It's called the capture effect.

1123
00:50:43,100 --> 00:50:45,380
What's happening here is
that some node captures

1124
00:50:45,380 --> 00:50:48,110
the channel for quite a
substantial period of time,

1125
00:50:48,110 --> 00:50:49,640
shutting everybody else out.

1126
00:50:49,640 --> 00:50:51,020
And then some
other node captures

1127
00:50:51,020 --> 00:50:52,220
the channel for
some period of time,

1128
00:50:52,220 --> 00:50:53,600
shutting everybody else out.

1129
00:50:53,600 --> 00:50:55,820
So you get significant
short term unfairness.

1130
00:50:55,820 --> 00:50:58,140
Or equivalently, you
get a long delay.

1131
00:50:58,140 --> 00:51:00,320
So some nodes may end up
waiting for a long time.

1132
00:51:00,320 --> 00:51:01,362
And then they get access.

1133
00:51:01,362 --> 00:51:03,617
And then they keep
access for quite a while.

1134
00:51:03,617 --> 00:51:04,700
And then they lose access.

1135
00:51:04,700 --> 00:51:06,120
And then some
other nodes get it.

1136
00:51:06,120 --> 00:51:07,220
So what's really
going on here is,

1137
00:51:07,220 --> 00:51:10,010
even though you have many, many
nodes competing, at any point

1138
00:51:10,010 --> 00:51:11,900
in time, effectively
the competition is only

1139
00:51:11,900 --> 00:51:14,100
between one or two nodes.

1140
00:51:14,100 --> 00:51:16,693
And this is a problem
called the capture effect.

1141
00:51:16,693 --> 00:51:18,110
And the way you
solve this problem

1142
00:51:18,110 --> 00:51:22,140
is symmetrically to change
this value of the probability,

1143
00:51:22,140 --> 00:51:24,620
there's a maximum
value, which is p max.

1144
00:51:24,620 --> 00:51:27,890
So you have to pick a different
value that's less than 1

1145
00:51:27,890 --> 00:51:29,360
that's the maximum probability.

1146
00:51:29,360 --> 00:51:32,390
In other words, once a node
has a transmission probability

1147
00:51:32,390 --> 00:51:34,355
of, let's say, 0.25
or 0.3, you don't

1148
00:51:34,355 --> 00:51:36,980
want to have it keep increasing,
because what ends up happening

1149
00:51:36,980 --> 00:51:39,190
is then it captures the
channel for quite a while.

1150
00:51:39,190 --> 00:51:41,792
And it's only upon
successive collisions

1151
00:51:41,792 --> 00:51:44,000
that it comes down to the
point where other nodes can

1152
00:51:44,000 --> 00:51:46,003
gain access to the channel.

1153
00:51:46,003 --> 00:51:47,420
So if you put all
of that together

1154
00:51:47,420 --> 00:51:48,837
and run the
experiment, we're just

1155
00:51:48,837 --> 00:51:51,560
putting this protocol
as described exactly

1156
00:51:51,560 --> 00:51:52,280
on this board.

1157
00:51:52,280 --> 00:51:53,947
And you can play
around with this thing.

1158
00:51:53,947 --> 00:51:56,540
There's a lot of leeway in
picking these parameters.

1159
00:51:56,540 --> 00:51:58,595
If you run this protocol,
you get a utilization,

1160
00:51:58,595 --> 00:52:01,318
in this case, of 0.41,
which for n equal to 10

1161
00:52:01,318 --> 00:52:03,110
is pretty much what
you would get according

1162
00:52:03,110 --> 00:52:06,710
to sticking into that formula a
fairness that's extremely high.

1163
00:52:06,710 --> 00:52:09,530
And it's super cool because
this is exactly what you

1164
00:52:09,530 --> 00:52:10,280
would want to get.

1165
00:52:10,280 --> 00:52:13,310
If somebody magically told you
the number of backlogged nodes

1166
00:52:13,310 --> 00:52:15,680
and you theoretically
calculated the optimal value

1167
00:52:15,680 --> 00:52:18,380
of the probability, you couldn't
do better than this protocol.

1168
00:52:18,380 --> 00:52:21,350
And we managed to do it
by simply these nodes that

1169
00:52:21,350 --> 00:52:23,900
are just independently
making these decisions,

1170
00:52:23,900 --> 00:52:26,130
figuring out what
they should do.

1171
00:52:26,130 --> 00:52:28,010
And if you were to plot
the actual evolution

1172
00:52:28,010 --> 00:52:30,560
of the probabilities, you
find that at no point in time

1173
00:52:30,560 --> 00:52:33,980
does any node have
a value of 1 over n.

1174
00:52:33,980 --> 00:52:35,620
Even though in the
experiment there's

1175
00:52:35,620 --> 00:52:38,310
some value of the number
of backlogged nodes,

1176
00:52:38,310 --> 00:52:39,920
the nodes kind of
dance around it.

1177
00:52:39,920 --> 00:52:41,850
But they never
actually stick to it.

1178
00:52:41,850 --> 00:52:43,370
But they conspire
to dance around it

1179
00:52:43,370 --> 00:52:46,370
in a way that gives you
exactly the same result as you

1180
00:52:46,370 --> 00:52:51,692
would get if you, in fact,
had a pretty good thing.

1181
00:52:51,692 --> 00:52:53,400
I'm going to close
with one last comment.

1182
00:52:53,400 --> 00:52:55,250
This is from s
student from about,

1183
00:52:55,250 --> 00:52:57,890
I think, two terms ago, a
guy called Chase Lambert,

1184
00:52:57,890 --> 00:52:59,480
who took this class.

1185
00:52:59,480 --> 00:53:01,145
And I was very
gratified to hear this,

1186
00:53:01,145 --> 00:53:02,520
because it turned
out he interned

1187
00:53:02,520 --> 00:53:04,490
or he is working or
worked or working

1188
00:53:04,490 --> 00:53:08,340
at a company called Quizlet,
which is a startup company.

1189
00:53:08,340 --> 00:53:10,820
And one of the things he had
to do was a load generator.

1190
00:53:10,820 --> 00:53:13,550
And he ended up using exactly
these ideas to come up

1191
00:53:13,550 --> 00:53:15,650
with a load generating
scheme that was stable,

1192
00:53:15,650 --> 00:53:17,275
because you want to
be able to generate

1193
00:53:17,275 --> 00:53:19,820
load that allows you to measure
the throughput of a system.

1194
00:53:19,820 --> 00:53:21,500
And he used this
random back off idea.

1195
00:53:21,500 --> 00:53:24,050
So it's not that you'll
find these ideas useful

1196
00:53:24,050 --> 00:53:27,260
only if you were doing
this kind of networking.

1197
00:53:27,260 --> 00:53:29,967
You actually find these ideas
useful in other contexts.

1198
00:53:29,967 --> 00:53:31,050
So I'm going to stop here.

1199
00:53:31,050 --> 00:53:33,290
We'll pick up on some of
these topics in recitation,

1200
00:53:33,290 --> 00:53:35,650
and then back here on Monday.