WEBVTT

1
00:00.000 --> 00:02.640
At this point, we should be feeling good.

2
00:02.640 --> 00:08.520
We've got the choice of what packets to drop for the most part in our network.

3
00:08.520 --> 00:12.400
But that phrase for the most part is kind of a big deal because there's another

4
00:12.400 --> 00:12.960
situation

5
00:12.960 --> 00:16.760
that we need to talk about where packets might get dropped.

6
00:16.760 --> 00:18.440
Here's the common situation.

7
00:18.440 --> 00:23.340
Let's say I have a router and I have just connected to an internet service

8
00:23.340 --> 00:24.200
provider.

9
00:24.200 --> 00:29.350
And that internet service provider has sold me a line for 75 megabits per

10
00:29.350 --> 00:30.160
second.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:29.350 --> 00:30.160
second.

11
00:30.160 --> 00:33.880
So what kind of handoff do they give me here to plug into my router?

12
00:33.880 --> 00:38.350
Well, I don't know about you, but I'm not aware of any 75 megabit per second

13
00:38.350 --> 00:38.560
type of

14
00:38.560 --> 00:39.560
connections.

15
00:39.560 --> 00:44.010
So they're probably going to give me a 100 megabit connection, maybe even a gig

16
00:44.010 --> 00:44.240
, but

17
00:44.240 --> 00:47.920
either way, it's going to be a standard ethernet speed.

18
00:47.920 --> 00:49.320
So here's the question.

19
00:49.320 --> 00:55.640
How exactly are they enforcing this 75 megabits per second?

20
00:55.640 --> 01:02.000
And the answer is they're going to be using policing.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:55.640 --> 01:02.000
And the answer is they're going to be using policing.

21
01:02.000 --> 01:06.430
Now policing is a problem for us and we're going to see why, but it's also a

22
01:06.430 --> 01:07.520
very important

23
01:07.520 --> 01:10.680
part of our QoS configuration methodology.

24
01:10.680 --> 01:13.320
So let's see what situation is here.

25
01:13.320 --> 01:16.920
They understand that this router is going to be sending traffic.

26
01:16.920 --> 01:21.120
And because we're receiving all kinds of traffic and we're connected to a 100

27
01:21.120 --> 01:23.200
megabit per second

28
01:23.200 --> 01:26.800
line here, the router could very easily receive all of this.

29
01:26.800 --> 01:30.100
And even with all of our buffering and everything like that, it might try to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:26.800 --> 01:30.100
And even with all of our buffering and everything like that, it might try to

30
01:30.100 --> 01:31.320
send 100 megabits

31
01:31.320 --> 01:32.960
per second.

32
01:32.960 --> 01:37.470
The ISP is going to have some kind of device upstream, maybe it's a router,

33
01:37.470 --> 01:37.840
maybe it's a

34
01:37.840 --> 01:39.160
layer three switch.

35
01:39.160 --> 01:43.640
But either way, this device is going to be receiving 100 megabits per second.

36
01:43.640 --> 01:49.600
It's going to know that we have a policy in place that says 75 megabits per

37
01:49.600 --> 01:50.560
second.

38
01:50.560 --> 01:52.120
And so what's it going to do?

39
01:52.120 --> 01:57.040
It's going to, first of all, allow the 75 megabits per second.

40
01:57.040 --> 01:58.800
So that's good.

41
01:58.800 --> 02:03.240
It's also going to drop 25 megabits per second.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
01:58.800 --> 02:03.240
It's also going to drop 25 megabits per second.

42
02:03.240 --> 02:10.020
And if the upstream ISP router is performing packet drops, well, what just

43
02:10.020 --> 02:11.320
happened to our

44
02:11.320 --> 02:16.320
goal of making sure that I as the organization that I have total control over

45
02:16.320 --> 02:17.240
what packets

46
02:17.240 --> 02:21.720
are getting dropped, this is going to be dropping my AF.

47
02:21.720 --> 02:28.370
Again, we'll use 41, 42, 43 as an example, but it's going to be dropping a 41

48
02:28.370 --> 02:29.400
as much as

49
02:29.400 --> 02:31.840
42 and 43.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
02:29.400 --> 02:31.840
42 and 43.

50
02:31.840 --> 02:36.420
All of these will have an equal chance of getting dropped because the ISP doesn

51
02:36.420 --> 02:36.920
't care

52
02:36.920 --> 02:38.080
about my markings.

53
02:38.080 --> 02:42.480
It's just going to indiscriminately drop packets.

54
02:42.480 --> 02:45.720
Now we're going to talk about the solution to this in the next video.

55
02:45.720 --> 02:52.000
The solution is known as traffic shaping.

56
02:52.000 --> 02:56.180
But in order to properly understand traffic shaping, we need to understand how

57
02:56.180 --> 02:56.680
exactly

58
02:56.680 --> 02:59.080
this policy is getting enforced.

59
02:59.080 --> 03:00.800
How does policing work?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:59.080 --> 03:00.800
How does policing work?

60
03:00.800 --> 03:04.300
And Cisco is even going to expect us to be able to configure policing based on

61
03:04.300 --> 03:04.800
the current

62
03:04.800 --> 03:06.600
blueprint for the exam.

63
03:06.600 --> 03:09.760
So we need to really explore policing first.

64
03:09.760 --> 03:13.950
And then in the next video, we can explore shaping as a solution to get us back

65
03:13.950 --> 03:14.480
to this

66
03:14.480 --> 03:17.880
world where we are controlling all of our traffic drops.

67
03:17.880 --> 03:20.680
So let's talk about policing.

68
03:20.680 --> 03:25.090
Policing is an interesting concept because keep in mind everything we just

69
03:25.090 --> 03:25.920
talked about

70
03:25.920 --> 03:31.480
here, our focus is on bandwidth limits.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
03:25.920 --> 03:31.480
here, our focus is on bandwidth limits.

71
03:31.480 --> 03:36.650
Well that sounds simple, I've said that I'm allowing 75 megabits per second and

72
03:36.650 --> 03:37.200
you just

73
03:37.200 --> 03:39.080
sent me 100 megabits per second.

74
03:39.080 --> 03:40.920
Therefore I can drop 25.

75
03:40.920 --> 03:45.860
Now that might work from a math perspective, but it doesn't work great from a

76
03:45.860 --> 03:46.680
real world

77
03:46.680 --> 03:48.280
perspective.

78
03:48.280 --> 03:49.640
Because here's the problem.

79
03:49.640 --> 03:58.320
Bandwidth is actually measured as a number of bits over time.

80
03:58.320 --> 04:02.380
And if I'm putting time in the denominator, we think back to our middle school,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:58.320 --> 04:02.380
And if I'm putting time in the denominator, we think back to our middle school,

81
04:02.380 --> 04:03.080
high school

82
04:03.080 --> 04:05.920
math, I can't say zero seconds.

83
04:05.920 --> 04:10.660
I can't narrow this time frame down to just a point in time and say what's the

84
04:10.660 --> 04:11.440
bandwidth

85
04:11.440 --> 04:15.040
for this link at 303 PM and zero seconds.

86
04:15.040 --> 04:19.300
I can't do that because I put a zero in the denominator while we know that

87
04:19.300 --> 04:20.200
problems start

88
04:20.200 --> 04:21.200
to occur.

89
04:21.200 --> 04:24.080
And that's not allowed from a math perspective.

90
04:24.080 --> 04:29.780
So instead what I have to look at is I have to use a time interval to measure

91
04:29.780 --> 04:31.000
my bandwidth.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:29.780 --> 04:31.000
my bandwidth.

92
04:31.000 --> 04:33.200
And so what is this time interval?

93
04:33.200 --> 04:39.170
And for that matter, as I'm sending bits throughout this time interval, what

94
04:39.170 --> 04:39.880
does the

95
04:39.880 --> 04:41.480
average bandwidth look like?

96
04:41.480 --> 04:46.020
And at what point do I start dropping my bits and bytes that the downstream

97
04:46.020 --> 04:46.880
device has been

98
04:46.880 --> 04:48.840
sending me?

99
04:48.840 --> 04:52.520
Let's just paint this situation with an example real quick.

100
04:52.520 --> 04:59.820
So let's say that my time interval is measured over one, two, one, two, three,

101
04:59.820 --> 05:01.000
four, five
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
04:59.820 --> 05:01.000
four, five

102
05:01.000 --> 05:02.000
and six.

103
05:02.000 --> 05:03.000
There we go.

104
05:03.000 --> 05:05.770
So let's say that we're measuring over, actually, let's just say three seconds

105
05:05.770 --> 05:06.600
to start with

106
05:06.600 --> 05:08.520
and then we'll expand on this.

107
05:08.520 --> 05:13.840
So let's say that in these first three seconds, this downstream device is

108
05:13.840 --> 05:15.120
flooding me with

109
05:15.120 --> 05:16.120
traffic.

110
05:16.120 --> 05:19.680
I get 100 megabits in the first second.

111
05:19.680 --> 05:21.760
So transmitting 100 megabits per second.

112
05:21.760 --> 05:26.580
I get 100 megabits in the second second and I get 100 megabits in the third

113
05:26.580 --> 05:27.320
second.

114
05:27.320 --> 05:31.290
So over the course of three seconds, I have just transmitted 100 megabits per
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

114
05:27.320 --> 05:31.290
So over the course of three seconds, I have just transmitted 100 megabits per

115
05:31.290 --> 05:31.960
second very

116
05:31.960 --> 05:33.240
consistently.

117
05:33.240 --> 05:36.560
That's 300 megabits divided by three seconds.

118
05:36.560 --> 05:39.800
And so that's 100 megabits per second.

119
05:39.800 --> 05:41.320
That would be a problem.

120
05:41.320 --> 05:47.060
But what if then the device downstream starts sending me 50 megabits per second

121
05:47.060 --> 05:47.320
?

122
05:47.320 --> 05:52.400
So 50 megabits here, 50 megabits here, 50 megabits here.

123
05:52.400 --> 05:57.380
Well if I were to take the interval of three seconds, then that device just

124
05:57.380 --> 05:58.360
transmitted

125
05:58.360 --> 06:01.160
at 100 megabits per second.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
05:58.360 --> 06:01.160
at 100 megabits per second.

126
06:01.160 --> 06:09.400
But if I take the interval of six seconds, that is 450 megabits over six

127
06:09.400 --> 06:10.760
seconds.

128
06:10.760 --> 06:13.800
And if we run the math on that, guess what that comes out to?

129
06:13.800 --> 06:15.920
75 megabits per second.

130
06:15.920 --> 06:18.760
Do we start to see the problem here?

131
06:18.760 --> 06:23.960
Depending on how we define our intervals, depending on how we define what our

132
06:23.960 --> 06:24.760
bandwidth

133
06:24.760 --> 06:29.240
is measured by, if we say it's three seconds, then we had a clear violation.

134
06:29.240 --> 06:32.830
If we're measuring it over what happens to be six seconds here, then it's no
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

134
06:29.240 --> 06:32.830
If we're measuring it over what happens to be six seconds here, then it's no

135
06:32.830 --> 06:33.520
violation

136
06:33.520 --> 06:34.680
at all.

137
06:34.680 --> 06:40.460
And so this is why we can't just say something as simple as this bandwidth math

138
06:40.460 --> 06:41.560
that's basic

139
06:41.560 --> 06:43.680
addition and subtraction.

140
06:43.680 --> 06:45.400
So how are we going to solve this problem?

141
06:45.400 --> 06:50.760
Well, we do have a pretty good solution from Cisco for this, and it is known as

142
06:50.760 --> 06:51.880
the token

143
06:51.880 --> 06:55.480
bucket system.

144
06:55.480 --> 07:00.360
Token bucket system has a basic version and an advanced version.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

144
06:55.480 --> 07:00.360
Token bucket system has a basic version and an advanced version.

145
07:00.360 --> 07:03.780
And so we're not going to drill into all of the advanced stuff that we might be

146
07:03.780 --> 07:04.320
expected

147
07:04.320 --> 07:05.960
to know for higher level exams.

148
07:05.960 --> 07:10.200
Instead, we just really need to understand what the concept is.

149
07:10.200 --> 07:12.240
Here's the idea of the token bucket.

150
07:12.240 --> 07:17.480
We are going to have a bucket of tokens.

151
07:17.480 --> 07:23.700
And any time a packet needs to be sent, I have a packet to send, I'm going to

152
07:23.700 --> 07:24.440
need to

153
07:24.440 --> 07:27.720
consume one of these tokens.

154
07:27.720 --> 07:32.840
So this is essentially the number of packets that I'm able to send.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
07:27.720 --> 07:32.840
So this is essentially the number of packets that I'm able to send.

155
07:32.840 --> 07:41.390
Meanwhile, I'm going to feed this bucket with additional tokens based on

156
07:41.390 --> 07:42.760
whatever my rate

157
07:42.760 --> 07:46.080
is here, let's say 75 megabits per second.

158
07:46.080 --> 07:47.840
So notice what we're not doing here.

159
07:47.840 --> 07:51.160
We're not just feeding directly into the packet flow.

160
07:51.160 --> 07:56.000
If we were, then we could never exceed 75 megabits per second, even for a

161
07:56.000 --> 07:57.200
single second.

162
07:57.200 --> 08:01.530
Instead, we are creating a little bit of a buffer here that allows me to build
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

162
07:57.200 --> 08:01.530
Instead, we are creating a little bit of a buffer here that allows me to build

163
08:01.530 --> 08:02.480
up tokens

164
08:02.480 --> 08:06.860
when my bandwidth is down and consume those extra tokens when my bandwidth is a

165
08:06.860 --> 08:07.360
little

166
08:07.360 --> 08:08.960
bit higher.

167
08:08.960 --> 08:15.010
And the idea here is that if there is a token, then this places us into a

168
08:15.010 --> 08:16.720
status that's known

169
08:16.720 --> 08:19.480
as conforming.

170
08:19.480 --> 08:22.040
This traffic conforms to our policy.

171
08:22.040 --> 08:29.260
If there's no token available, then this is known as an exceeding packet.

172
08:29.260 --> 08:32.120
This packet has exceeded our policy.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

172
08:29.260 --> 08:32.120
This packet has exceeded our policy.

173
08:32.120 --> 08:36.210
Now importantly, there are other bucket methods that get a little bit more

174
08:36.210 --> 08:36.960
complex.

175
08:36.960 --> 08:43.510
For example, we have double bucket systems and two, two colors, single rate,

176
08:43.510 --> 08:44.360
dual rate,

177
08:44.360 --> 08:46.120
three color systems.

178
08:46.120 --> 08:50.340
Essentially what we're saying here is we have the more advanced version that

179
08:50.340 --> 08:50.800
actually

180
08:50.800 --> 08:52.680
has two buckets.

181
08:52.680 --> 08:56.960
And this allows for not only the ability to send packets normally.

182
08:56.960 --> 08:58.880
So this is our normal bucket.

183
08:58.880 --> 09:03.220
But then we also have the ability to store extra tokens over here, which is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

183
08:58.880 --> 09:03.220
But then we also have the ability to store extra tokens over here, which is

184
09:03.220 --> 09:03.960
known as the

185
09:03.960 --> 09:05.160
burst.

186
09:05.160 --> 09:09.000
And so if I have a token in the normal, then I can send it.

187
09:09.000 --> 09:13.680
This again places me into the conform state.

188
09:13.680 --> 09:18.120
And in this case, if I'm bursting, it's going to place me into the exceed state

189
09:18.120 --> 09:18.160
.

190
09:18.160 --> 09:20.880
Well what if I have no token down here?

191
09:20.880 --> 09:25.360
Well that introduces a third situation, which we call violation.

192
09:25.360 --> 09:30.990
So this packet has violated our policy, which sounds even more extreme than
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

192
09:25.360 --> 09:30.990
So this packet has violated our policy, which sounds even more extreme than

193
09:30.990 --> 09:33.560
exceeding it.

194
09:33.560 --> 09:36.560
Now token bucket systems can be pretty complex.

195
09:36.560 --> 09:40.500
And I want to stress that it's really outside the scope of this exam and of

196
09:40.500 --> 09:41.320
this content

197
09:41.320 --> 09:45.810
to really drill into the details of the token bucket system, especially our

198
09:45.810 --> 09:46.960
advanced form.

199
09:46.960 --> 09:51.160
But at the same time, we do need to understand that what we're saying is that

200
09:51.160 --> 09:51.840
we're going

201
09:51.840 --> 09:56.830
to store tokens in some way, send packets when we have tokens, and we're also

202
09:56.830 --> 09:59.200
feeding the

203
09:59.200 --> 10:01.920
token bucket with tokens at a particular rate.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

203
09:59.200 --> 10:01.920
token bucket with tokens at a particular rate.

204
10:01.920 --> 10:04.830
The reason why that's important is because later when we're configuring

205
10:04.830 --> 10:05.680
policing, we're

206
10:05.680 --> 10:07.560
going to see these rates mentioned.

207
10:07.560 --> 10:10.630
And so we need to kind of be able to come back and remember what exactly this

208
10:10.630 --> 10:11.080
process

209
10:11.080 --> 10:12.080
looks like.

210
10:12.080 --> 10:16.360
If you want to know more details about token bucket systems, absolutely jump

211
10:16.360 --> 10:17.520
into the collaboration

212
10:17.520 --> 10:24.910
core exam course, make sure that we are searching for token buckets where we

213
10:24.910 --> 10:26.400
explain in a great

214
10:26.400 --> 10:28.880
amount of detail how these come together.

215
10:28.880 --> 10:32.080
And that's if you're just curious and you want to know more information about
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

215
10:28.880 --> 10:32.080
And that's if you're just curious and you want to know more information about

216
10:32.080 --> 10:32.400
how all

217
10:32.400 --> 10:33.960
of that comes together.

218
10:33.960 --> 10:38.360
However, again, keeping things within scope of this conversation, we really

219
10:38.360 --> 10:38.920
just need

220
10:38.920 --> 10:42.680
to kind of understand the mechanism of how this works and ultimately the

221
10:42.680 --> 10:43.520
problem we're

222
10:43.520 --> 10:47.810
trying to solve, which is that bandwidth must be regulated over the course of

223
10:47.810 --> 10:48.760
time, showing

224
10:48.760 --> 10:53.030
a little bit of grace because there are going to be times when we exceed that

225
10:53.030 --> 10:53.640
amount and

226
10:53.640 --> 10:57.900
there's going to be times when we are under that amount and we're trying to be

227
10:57.900 --> 10:58.240
fair to

228
10:58.240 --> 11:00.840
the person who's sending us traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

228
10:58.240 --> 11:00.840
the person who's sending us traffic.

229
11:00.840 --> 11:03.080
So that's the idea there.

230
11:03.080 --> 11:08.400
So notice that we have three different statuses.

231
11:08.400 --> 11:12.910
So this is the status of the packet, but we haven't said yet what we're going

232
11:12.910 --> 11:13.240
to do

233
11:13.240 --> 11:15.200
with the packets.

234
11:15.200 --> 11:21.160
So we need to define the policy for each one of these situations.

235
11:21.160 --> 11:22.800
And we have three different options.

236
11:22.800 --> 11:27.640
Notice we're not hard mapping policy decisions to the status.

237
11:27.640 --> 11:31.950
We're simply presenting ourselves with policy options and then we can decide
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

237
11:27.640 --> 11:31.950
We're simply presenting ourselves with policy options and then we can decide

238
11:31.950 --> 11:32.560
what to do

239
11:32.560 --> 11:35.880
with each one of these are three different policy options.

240
11:35.880 --> 11:39.490
First and foremost, we can allow the packet to go through second of all, of

241
11:39.490 --> 11:40.200
course, we

242
11:40.200 --> 11:43.340
could just deny the packet and drop it and that's mostly what we're here to

243
11:43.340 --> 11:43.880
talk about

244
11:43.880 --> 11:45.360
with policing.

245
11:45.360 --> 11:52.050
But there is a middle ground interesting option, which is to remark the packet

246
11:52.050 --> 11:53.720
and allow it.

247
11:53.720 --> 11:56.280
And so ultimately we're going to transmit it.

248
11:56.280 --> 11:57.280
This is implied.

249
11:57.280 --> 12:00.210
We usually just say it's remarking the packet, but understand that we are
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

249
11:57.280 --> 12:00.210
We usually just say it's remarking the packet, but understand that we are

250
12:00.210 --> 12:01.200
transmitting it

251
12:01.200 --> 12:02.760
as well.

252
12:02.760 --> 12:04.080
So what do we mean by remark?

253
12:04.080 --> 12:08.310
Well, typically what that means is we're going to take our AF, let's say 41 and

254
12:08.310 --> 12:08.720
we're

255
12:08.720 --> 12:13.200
going to remark it as AF 42 or AF 43.

256
12:13.200 --> 12:17.350
What we've done is we've increased the likelihood that this packet gets dropped

257
12:17.350 --> 12:18.000
later on in

258
12:18.000 --> 12:19.320
the network.

259
12:19.320 --> 12:23.880
We might even find that later on that there's still congestion later and we

260
12:23.880 --> 12:25.000
would want to

261
12:25.000 --> 12:26.720
drop it at that point.

262
12:26.720 --> 12:30.450
Now for an ISP and we're trying to mandate specific policies, we're probably
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

262
12:26.720 --> 12:30.450
Now for an ISP and we're trying to mandate specific policies, we're probably

263
12:30.450 --> 12:30.880
not going

264
12:30.880 --> 12:32.240
to do a whole lot of remarking.

265
12:32.240 --> 12:36.060
We're just going to focus on denying or dropping the packets.

266
12:36.060 --> 12:43.040
But if we are allowing the packets through, then we're not going to remark them

267
12:43.040 --> 12:43.960
at all.

268
12:43.960 --> 12:47.800
So that is, these are our three different policy options.

269
12:47.800 --> 12:53.560
So then the question is how exactly do we want to map these to the status?

270
12:53.560 --> 12:58.700
In a lot of situations we're going to put conforming traffic into the allow

271
12:58.700 --> 12:59.460
category

272
12:59.460 --> 13:02.460
to say that we're just going to transmit that as is.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

272
12:59.460 --> 13:02.460
to say that we're just going to transmit that as is.

273
13:02.460 --> 13:10.000
And we're going to put remarking in for exceeding and dropped packets are for

274
13:10.000 --> 13:12.080
violations.

275
13:12.080 --> 13:15.170
However keep in mind we might be using the more simple token bucket method

276
13:15.170 --> 13:15.720
which only

277
13:15.720 --> 13:20.700
gives us two options conforming exceed at which point deny might actually be

278
13:20.700 --> 13:21.240
what we

279
13:21.240 --> 13:23.600
do for the exceeding traffic.

280
13:23.600 --> 13:27.490
And for that matter, there might be other situations that require us to kind of

281
13:27.490 --> 13:27.920
change

282
13:27.920 --> 13:29.080
these around.

283
13:29.080 --> 13:33.640
And understand that we are in control of the policy as it distributes between
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

283
13:29.080 --> 13:33.640
And understand that we are in control of the policy as it distributes between

284
13:33.640 --> 13:34.620
the category,

285
13:34.620 --> 13:39.530
the status here, of what a packet is, and then what exactly we do with the

286
13:39.530 --> 13:40.540
packet based

287
13:40.540 --> 13:42.980
on that status.

288
13:42.980 --> 13:47.740
Now remember, our goal in talking about policing is number one to be able to

289
13:47.740 --> 13:48.460
understand what

290
13:48.460 --> 13:51.820
exactly it is and how it works so eventually we can configure it.

291
13:51.820 --> 13:55.660
But the other consideration is we want to get back to having a choice over what

292
13:55.660 --> 13:56.100
packets

293
13:56.100 --> 13:57.340
get dropped.

294
13:57.340 --> 14:01.780
And right now, as of this moment, we have said that the ISP is going to be the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

294
13:57.340 --> 14:01.780
And right now, as of this moment, we have said that the ISP is going to be the

295
14:01.780 --> 14:02.700
one dropping

296
14:02.700 --> 14:06.180
all of these packets using their policing policy.

297
14:06.180 --> 14:10.190
In our case, what we want to do is we want to leverage this other solution

298
14:10.190 --> 14:10.900
shaping to

299
14:10.900 --> 14:15.170
try to make it so we never drop a packet on the ISP, we want to make sure that

300
14:15.170 --> 14:15.620
we are

301
14:15.620 --> 14:18.980
always in control over which packets get dropped.

302
14:18.980 --> 14:22.760
So let's take a moment to go explore how shaping can get us back to that goal

303
14:22.760 --> 14:23.220
of always

304
14:23.220 --> 14:24.700
deciding which packets to drop.