WEBVTT

1
00:00.000 --> 00:05.680
Well, that basic policeor that we just described there, that is known as a

2
00:05.680 --> 00:08.280
single rate two-color

3
00:08.280 --> 00:12.480
policeor, which sounds a little bit fancy.

4
00:12.480 --> 00:16.430
But what we're saying here is that single rate that we talked about is the

5
00:16.430 --> 00:17.120
committed

6
00:17.120 --> 00:18.640
information rate or CIR.

7
00:18.640 --> 00:23.560
It's the only rate that we configured in our policeor policy map.

8
00:23.560 --> 00:29.710
The two colors are going to be the two different statuses, which involve con

9
00:29.710 --> 00:31.200
forming traffic,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:29.710 --> 00:31.200
forming traffic,

10
00:31.200 --> 00:35.200
as well as exceeding traffic.

11
00:35.200 --> 00:41.280
Well what if we wanted a third category of traffic?

12
00:41.280 --> 00:46.200
What if we said, you know, we want to transmit the conforming traffic, but we

13
00:46.200 --> 00:47.020
really want

14
00:47.020 --> 00:50.240
to do something in the middle besides dropping.

15
00:50.240 --> 00:54.200
So we've got transmit on this side, we've got dropping on this side, but maybe

16
00:54.200 --> 00:54.600
we want

17
00:54.600 --> 00:56.280
something here in the middle.

18
00:56.280 --> 01:00.680
Again, that idea that I could remark traffic and send it on.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:56.280 --> 01:00.680
Again, that idea that I could remark traffic and send it on.

19
01:00.680 --> 01:05.560
Well at that point, we're going to need a third color or a third status.

20
01:05.560 --> 01:09.640
And so that would be the goal here is for us to create that.

21
01:09.640 --> 01:14.380
So typically what we're looking at here is creating a third class known as

22
01:14.380 --> 01:16.520
violating traffic

23
01:16.520 --> 01:22.080
or violated traffic either way, but this concept here is going to give us the

24
01:22.080 --> 01:23.800
third color,

25
01:23.800 --> 01:28.870
which typically allows us to perform our dropping traffic on the most, the

26
01:28.870 --> 01:29.680
traffic that's way

27
01:29.680 --> 01:33.520
outside the bounds of our configuration that would be violating traffic and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:29.680 --> 01:33.520
outside the bounds of our configuration that would be violating traffic and

28
01:33.520 --> 01:34.120
allow us to

29
01:34.120 --> 01:37.720
deploy a remark policy here in the middle.

30
01:37.720 --> 01:41.670
So again, we've got now three different statuses as well as three different

31
01:41.670 --> 01:42.400
actions and so

32
01:42.400 --> 01:44.640
we tend to match those up.

33
01:44.640 --> 01:47.840
But how exactly do we get this third color?

34
01:47.840 --> 01:51.080
Well, that's going to involve one of two options.

35
01:51.080 --> 01:59.930
The first option is going to be a single rate, but now it is a three color

36
01:59.930 --> 02:01.640
policeer.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:59.930 --> 02:01.640
policeer.

37
02:01.640 --> 02:04.510
Now both of these options, so this is the first option, we'll talk about a

38
02:04.510 --> 02:05.200
second one,

39
02:05.200 --> 02:07.960
both of them are going to involve a second bucket.

40
02:07.960 --> 02:11.850
We're going to require a second bucket because now we're going to have to have

41
02:11.850 --> 02:12.600
two different

42
02:12.600 --> 02:14.520
sets of tokens.

43
02:14.520 --> 02:19.690
So here's our BC bucket, our committed burst, and now we're going to have

44
02:19.690 --> 02:20.880
another bucket

45
02:20.880 --> 02:27.000
here known as BE, which stands for excess burst.

46
02:27.000 --> 02:30.720
So in this case, we still have a single rate, we have our CIR, and that is the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
02:27.000 --> 02:30.720
So in this case, we still have a single rate, we have our CIR, and that is the

47
02:30.720 --> 02:31.400
rate at which

48
02:31.400 --> 02:33.840
we fill up the BC bucket.

49
02:33.840 --> 02:39.850
Now in a, up here with our basic policeer, if we have the bucket and our CIR

50
02:39.850 --> 02:40.700
here and

51
02:40.700 --> 02:45.820
tokens are flowing into the bucket and this bucket is full, well the next token

52
02:45.820 --> 02:46.340
to try

53
02:46.340 --> 02:49.000
to come in here is just going to get dropped.

54
02:49.000 --> 02:51.260
We don't get to keep additional tokens.

55
02:51.260 --> 02:56.730
We defined the size of the bucket and we can't store more bites than what is

56
02:56.730 --> 02:57.720
sitting inside

57
02:57.720 --> 02:59.060
of that bucket.

58
02:59.060 --> 03:04.130
So that's the downside to the single rate two color policeer or one of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
02:59.060 --> 03:04.130
So that's the downside to the single rate two color policeer or one of the

59
03:04.130 --> 03:05.100
downsides.

60
03:05.100 --> 03:09.980
So our BE, what we're going to find is when the bucket is full, we're actually

61
03:09.980 --> 03:11.280
going to

62
03:11.280 --> 03:16.190
overload or take those tokens and put them into the BE bucket and be able to

63
03:16.190 --> 03:16.840
fill up a

64
03:16.840 --> 03:18.400
second bucket.

65
03:18.400 --> 03:22.040
So now we have two different bucket types.

66
03:22.040 --> 03:25.940
And so now we have to think about what happens in different scenarios.

67
03:25.940 --> 03:32.400
First scenario is a packet comes in and there's enough tokens in the BC bucket.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
03:25.940 --> 03:32.400
First scenario is a packet comes in and there's enough tokens in the BC bucket.

68
03:32.400 --> 03:38.770
So we use the BC token or sets of tokens if they're there, the BE is sort of

69
03:38.770 --> 03:40.320
like a backup.

70
03:40.320 --> 03:42.620
So we're not going to use that if we don't have to.

71
03:42.620 --> 03:46.560
And this means that we are a conforming packet.

72
03:46.560 --> 03:49.920
What if however, BC is empty.

73
03:49.920 --> 03:52.220
So there is no BE token.

74
03:52.220 --> 03:56.460
And so we take a BE token instead that excess burst.

75
03:56.460 --> 04:02.660
From now we're going to classify this as an exceeding traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:56.460 --> 04:02.660
From now we're going to classify this as an exceeding traffic.

76
04:02.660 --> 04:07.220
And lastly, there's no or at least not enough tokens in the BC bucket.

77
04:07.220 --> 04:09.740
There's not enough tokens in the BE bucket.

78
04:09.740 --> 04:14.220
Remember each token actually equals one bite.

79
04:14.220 --> 04:16.880
So it depends on the size of the packet of course.

80
04:16.880 --> 04:22.980
And so in this case, it becomes a violating packet.

81
04:22.980 --> 04:24.940
So what actions do we take?

82
04:24.940 --> 04:27.340
Well we get to configure the actions ourselves.

83
04:27.340 --> 04:33.100
I as the admin decide on the actions.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

83
04:27.340 --> 04:33.100
I as the admin decide on the actions.

84
04:33.100 --> 04:36.580
But typically what we're going to do is what we said up at the top.

85
04:36.580 --> 04:38.220
I'm going to transmit.

86
04:38.220 --> 04:45.730
For conforming, I'm going to remark for exceeding and I'm going to drop for

87
04:45.730 --> 04:47.220
violating.

88
04:47.220 --> 04:49.540
Now could I remark harsher on violating?

89
04:49.540 --> 04:50.540
Absolutely.

90
04:50.540 --> 04:51.540
I could do that.

91
04:51.540 --> 04:55.710
I'm going to drop exceeding and violating then why am I running a three color

92
04:55.710 --> 04:56.540
beleaser.

93
04:56.540 --> 05:02.460
So chances are this is probably what we're looking at in the real world.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
04:56.540 --> 05:02.460
So chances are this is probably what we're looking at in the real world.

94
05:02.460 --> 05:04.140
So this has an advantage.

95
05:04.140 --> 05:06.220
It allows me to burst additionally.

96
05:06.220 --> 05:09.420
So before with the two color, it's sort of like this.

97
05:09.420 --> 05:14.820
If I am transmitting up to the CIR amount, then that's great.

98
05:14.820 --> 05:15.940
Everything is fine.

99
05:15.940 --> 05:19.620
But everything over here, this is conforming and this is exceeding.

100
05:19.620 --> 05:25.740
And now we sort of have this CIR and everything is conforming up into this.

101
05:25.740 --> 05:29.890
But then we have this little bit of burst amount here that is exceeding before

102
05:29.890 --> 05:30.220
we get
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

102
05:29.890 --> 05:30.220
we get

103
05:30.220 --> 05:32.740
into the violating section.

104
05:32.740 --> 05:39.450
And this exceeding is based on the number of bits or bytes that can store up

105
05:39.450 --> 05:40.300
here.

106
05:40.300 --> 05:44.040
Now if we think about this overflow mechanism like this, there is a flaw to

107
05:44.040 --> 05:44.860
this strategy

108
05:44.860 --> 05:51.320
which is that if the BE tokens are completely used up, then the CIR is first

109
05:51.320 --> 05:52.540
filling this

110
05:52.540 --> 05:53.700
bucket.

111
05:53.700 --> 05:59.160
And so for a time, potentially an extended time, we might not have anything in

112
05:59.160 --> 05:59.700
the BE

113
05:59.700 --> 06:00.700
bucket.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

113
05:59.700 --> 06:00.700
bucket.

114
06:00.700 --> 06:05.430
Because we have to wait for this bucket to completely fill up and then overflow

115
06:05.430 --> 06:05.820
into

116
06:05.820 --> 06:07.420
the second bucket.

117
06:07.420 --> 06:12.520
So if we have that CIR of 600 megabits per second and we might need this to

118
06:12.520 --> 06:13.340
truly back

119
06:13.340 --> 06:18.940
down to a very low amount, like 400, 300 megabits per second for a very

120
06:18.940 --> 06:20.780
extended time, or we're

121
06:20.780 --> 06:23.980
never going to see the BE bucket fill back up.

122
06:23.980 --> 06:30.210
So that is the downside to the single rate CIR, single rate three color
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

122
06:23.980 --> 06:30.210
So that is the downside to the single rate CIR, single rate three color

123
06:30.210 --> 06:31.460
solution.

124
06:31.460 --> 06:34.460
Well we do have another option here.

125
06:34.460 --> 06:42.900
And that would be option number two, which is the dual rate three color police.

126
06:42.900 --> 06:45.500
Well, we know what the three color means.

127
06:45.500 --> 06:50.380
We're going to get our three different statuses for the packets potentially.

128
06:50.380 --> 06:58.220
But now we have two different buckets still, BC and BE.

129
06:58.220 --> 06:59.820
But there's no overflow concept.

130
06:59.820 --> 07:07.180
Instead, I'm going to take my CIR and I'm going to fill this bucket with tokens
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

130
06:59.820 --> 07:07.180
Instead, I'm going to take my CIR and I'm going to fill this bucket with tokens

131
07:07.180 --> 07:07.340
at a

132
07:07.340 --> 07:09.180
particular rate.

133
07:09.180 --> 07:12.900
And then I'm going to take a different type of rate, the PIR.

134
07:12.900 --> 07:19.500
This is the peak information rate.

135
07:19.500 --> 07:26.180
And I'm going to fill this bucket at the PIR.

136
07:26.180 --> 07:29.960
So for example, I can say that, hey, you know, we're trying to still keep

137
07:29.960 --> 07:30.580
everything
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
07:29.960 --> 07:30.580
everything

138
07:30.580 --> 07:33.020
within 80 kilobits per second here.

139
07:33.020 --> 07:37.380
But I'm going to set a PIR of 100 kilobits per second.

140
07:37.380 --> 07:43.510
And now all of a sudden when we think about this type of diagram, now we have a

141
07:43.510 --> 07:44.340
CIR here

142
07:44.340 --> 07:46.780
and a PIR up here.

143
07:46.780 --> 07:48.820
So it's no longer based on the bytes.

144
07:48.820 --> 07:55.500
This concept here was more of a byte concept for how much data I can consume.

145
07:55.500 --> 08:00.170
Well now we actually have two different rates, this 80K limit and this 100K
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
07:55.500 --> 08:00.170
Well now we actually have two different rates, this 80K limit and this 100K

146
08:00.170 --> 08:00.860
limit, at which

147
08:00.860 --> 08:05.340
point we have conforming traffic, exceeding traffic and violating traffic.

148
08:05.340 --> 08:10.360
We're trying to lock it down to a rate rather than so many bytes that again

149
08:10.360 --> 08:11.180
might take

150
08:11.180 --> 08:13.740
a long time for me to recover from.

151
08:13.740 --> 08:15.700
Now here's what's interesting about this.

152
08:15.700 --> 08:20.260
We noticed that we're filling this bucket at 80K, this bucket at 100K.

153
08:20.260 --> 08:23.980
So do I get 180 kilobits per second of throughput?

154
08:23.980 --> 08:26.420
Well that doesn't really match what I'm doing here.

155
08:26.420 --> 08:30.800
I'm trying to hit 80K and then it's exceeding up to 100K and then it's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

155
08:26.420 --> 08:30.800
I'm trying to hit 80K and then it's exceeding up to 100K and then it's

156
08:30.800 --> 08:33.140
violating past 100K.

157
08:33.140 --> 08:38.800
So no that's not the case but how do I recognize that I'm filling this bucket

158
08:38.800 --> 08:40.100
up at 80 and

159
08:40.100 --> 08:43.260
this bucket up at 100 and not add them up?

160
08:43.260 --> 08:45.580
Well that has to do with how we consume our packets.

161
08:45.580 --> 08:50.390
So once again we have our packets coming in and if a packet comes in it's going

162
08:50.390 --> 08:51.540
to attempt

163
08:51.540 --> 08:56.220
to consume both bucket types at once.

164
08:56.220 --> 09:01.990
In other words I have to have enough tokens in BC and BE in order for this to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

164
08:56.220 --> 09:01.990
In other words I have to have enough tokens in BC and BE in order for this to

165
09:01.990 --> 09:03.380
be a conforming

166
09:03.380 --> 09:09.380
packet and I will consume tokens from each as a result.

167
09:09.380 --> 09:16.210
Meanwhile if I don't have BC but I do have BE tokens, well now that falls into

168
09:16.210 --> 09:17.620
the exceeding

169
09:17.620 --> 09:23.580
category and naturally if I have neither of these BC and BE.

170
09:23.580 --> 09:29.180
So no BC and no BE this would be violating traffic.

171
09:29.180 --> 09:33.020
So likely we're going to take the same actions and apply them here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
09:29.180 --> 09:33.020
So likely we're going to take the same actions and apply them here.

172
09:33.020 --> 09:37.670
Again we are in full control of those actions we can configure those but in the

173
09:37.670 --> 09:38.380
real world

174
09:38.380 --> 09:41.460
that's typically what we're going to end up matching with.

175
09:41.460 --> 09:47.840
But do recognize in this dual rate three color policeor that one packet is

176
09:47.840 --> 09:49.500
going to consume

177
09:49.500 --> 09:55.690
both of these tokens at the same time whereas with our other model over here we

178
09:55.690 --> 09:56.620
're really

179
09:56.620 --> 10:00.580
only consuming either BC or we're consuming BE.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
09:56.620 --> 10:00.580
only consuming either BC or we're consuming BE.

180
10:00.580 --> 10:03.020
We're not consuming both at the same time.

181
10:03.020 --> 10:05.860
So this allows us to ultimately establish this.

182
10:05.860 --> 10:11.100
I mean our takeaway from this conversation is really what is the goal of these

183
10:11.100 --> 10:12.180
policeors.

184
10:12.180 --> 10:16.700
The goal of the policeors are to allow us to burst above a certain amount.

185
10:16.700 --> 10:21.820
In this case with the dual rate it allows me to define that rate as sort of a

186
10:21.820 --> 10:22.540
sliding

187
10:22.540 --> 10:26.640
scale to say that again everything up to 80k is treated one way and then

188
10:26.640 --> 10:27.500
everything up

189
10:27.500 --> 10:31.670
to 100k is treated another way and then everything over 100k is probably
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
10:27.500 --> 10:31.670
to 100k is treated another way and then everything over 100k is probably

190
10:31.670 --> 10:33.700
dropped at that point.

191
10:33.700 --> 10:35.660
That's what we're trying to accomplish here.

192
10:35.660 --> 10:41.900
Whereas again CIR, single rate options, yeah we store up some amount of bytes

193
10:41.900 --> 10:42.620
here in the

194
10:42.620 --> 10:48.220
middle but that can be tricky for us to recover from although it doesn't and

195
10:48.220 --> 10:48.940
again it doesn't

196
10:48.940 --> 10:52.540
make it clear what we can burst up to just however many bytes we can kind of

197
10:52.540 --> 10:53.180
store up

198
10:53.180 --> 10:54.740
for a rainy day.

199
10:54.740 --> 10:59.300
And of course the basic one up here there is no such conversation.

200
10:59.300 --> 11:02.780
It really is just this conversation.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

200
10:59.300 --> 11:02.780
It really is just this conversation.

201
11:02.780 --> 11:07.500
The left of that line is what this is here.

202
11:07.500 --> 11:08.980
So we got lots of options.

203
11:08.980 --> 11:12.340
just go ahead and jump to the CLI and see how we can configure these.