WEBVTT

1
00:00.000 --> 00:06.960
So when we're talking about weighted random early detect or W-red, red with a W

2
00:06.960 --> 00:07.800
, everyone

3
00:07.800 --> 00:14.510
is saying this, we know that as a queue gets filled up, so the queue fills, and

4
00:14.510 --> 00:15.240
we want

5
00:15.240 --> 00:20.200
to start randomly performing drops.

6
00:20.200 --> 00:25.200
Now the random drops on its own, this helps prevent that global TCP

7
00:25.200 --> 00:27.120
synchronization issue.

8
00:27.120 --> 00:32.560
So we want to prevent global sync, and we can do that without the waiting.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:27.120 --> 00:32.560
So we want to prevent global sync, and we can do that without the waiting.

9
00:32.560 --> 00:35.920
We can do that without paying attention to the DSCP tags.

10
00:35.920 --> 00:41.060
But naturally the W in weighted random early detect means that we're going to

11
00:41.060 --> 00:42.120
pay attention

12
00:42.120 --> 00:43.120
to the tags.

13
00:43.120 --> 00:48.250
The tags are going to matter, and as a result if we have multiple tags within a

14
00:48.250 --> 00:48.840
single

15
00:48.840 --> 00:55.220
queue, those random drops, the odds of dropping a packet, will be dependent on

16
00:55.220 --> 00:56.160
the tag.

17
00:56.160 --> 01:00.460
And we're especially going to be paying attention to the per-hot behaviors
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:56.160 --> 01:00.460
And we're especially going to be paying attention to the per-hot behaviors

18
01:00.460 --> 01:03.840
within assured forwarding.

19
01:03.840 --> 01:10.360
Because that second number, technically here, so AF, if we have XY, this Y is

20
01:10.360 --> 01:11.920
meant to represent

21
01:11.920 --> 01:19.070
the drop likelihood, where one equals a low percent chance, two equals a mid

22
01:19.070 --> 01:20.640
percent chance,

23
01:20.640 --> 01:26.180
one three is a higher, or maybe just at least the highest percent chance, that

24
01:26.180 --> 01:26.960
a packet

25
01:26.960 --> 01:28.880
gets dropped.

26
01:28.880 --> 01:31.840
And this is up to us to configure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:28.880 --> 01:31.840
And this is up to us to configure.

27
01:31.840 --> 01:35.920
This isn't something that just automatically happens on a Cisco device, we have

28
01:35.920 --> 01:36.640
to configure

29
01:36.640 --> 01:37.640
it.

30
01:37.640 --> 01:42.190
And so now's the time for us to start to explore how red configuration, or W-

31
01:42.190 --> 01:43.640
red configuration,

32
01:43.640 --> 01:45.040
comes together.

33
01:45.040 --> 01:48.280
Now there's going to be a few important aspects to this.

34
01:48.280 --> 01:53.320
First and foremost, we're going to need to configure thresholds.

35
01:53.320 --> 01:56.620
And we're going to be configuring two different thresholds, we're going to be

36
01:56.620 --> 01:57.320
configuring a

37
01:57.320 --> 02:01.760
minimum threshold, and a maximum threshold.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:57.320 --> 02:01.760
minimum threshold, and a maximum threshold.

38
02:01.760 --> 02:06.800
Up until the minimum threshold, we're going to have a zero percent packet drop.

39
02:06.800 --> 02:12.200
And from the maximum on, we're going to have a 100 percent packet drop.

40
02:12.200 --> 02:15.160
So these thresholds are very important.

41
02:15.160 --> 02:19.170
Now what happens in the middle is a little bit of a conversation we're going to

42
02:19.170 --> 02:19.720
have.

43
02:19.720 --> 02:25.790
It's a linear increase in percent chance of getting dropped as a packet comes

44
02:25.790 --> 02:26.360
in.

45
02:26.360 --> 02:30.520
And that percentage is going to be based on a couple of factors.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:26.360 --> 02:30.520
And that percentage is going to be based on a couple of factors.

46
02:30.520 --> 02:35.160
And we'll get into exactly how that works here momentarily.

47
02:35.160 --> 02:40.720
The other thing we need to consider is the queue size.

48
02:40.720 --> 02:45.450
Because we might say that, okay, I want my minimum threshold to be when the

49
02:45.450 --> 02:46.160
queue is,

50
02:46.160 --> 02:48.320
let's say, 60 percent full.

51
02:48.320 --> 02:52.700
Unfortunately for us, this is not how Cisco allows us to configure the minimum

52
02:52.700 --> 02:53.600
threshold.

53
02:53.600 --> 03:05.080
The minimum and the maximum thresholds, these are configured as a packet count.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:53.600 --> 03:05.080
The minimum and the maximum thresholds, these are configured as a packet count.

54
03:05.080 --> 03:08.600
And so the size of the queue is going to matter.

55
03:08.600 --> 03:16.120
For example, a lot of Cisco devices have a default queue length of 40 packets.

56
03:16.120 --> 03:22.040
So if I do want the minimum to start at, let's say, 60 percent full, well 60

57
03:22.040 --> 03:23.000
percent full

58
03:23.000 --> 03:28.560
on 40 is going to be 24 packets in size.

59
03:28.560 --> 03:32.120
10 percent of 40 is four.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
03:28.560 --> 03:32.120
10 percent of 40 is four.

60
03:32.120 --> 03:34.800
So four times six would give us a 24.

61
03:34.800 --> 03:36.240
So that's our math there.

62
03:36.240 --> 03:40.760
That's 60 percent full when there's 24 packets in the queue.

63
03:40.760 --> 03:46.760
And let's say we want the maximum here to be at 80 percent.

64
03:46.760 --> 03:51.280
Well using that same math four times eight, that would be 32 packets.

65
03:51.280 --> 03:56.240
So our thresholds would be established as a number of packets in the queue.

66
03:56.240 --> 04:02.320
And so we'd say maybe 24 and 32 as the minimum and maximum thresholds.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
03:56.240 --> 04:02.320
And so we'd say maybe 24 and 32 as the minimum and maximum thresholds.

67
04:02.320 --> 04:07.480
So it's zero percent drop until we get to 24 packets in the queue.

68
04:07.480 --> 04:12.480
And then while there's between 24 and 32 packets, we're going to be increasing

69
04:12.480 --> 04:13.560
with every packet

70
04:13.560 --> 04:14.560
that's in there.

71
04:14.560 --> 04:18.040
You know, if there's 25 packets in there, it's a lower percent chance.

72
04:18.040 --> 04:21.340
But if there's 30 packets in the queue, it's a pretty high percent chance

73
04:21.340 --> 04:21.600
because it's

74
04:21.600 --> 04:25.320
linearly increasing during that middle stretch.

75
04:25.320 --> 04:28.670
And then once we hit 32 packets and above, we're just going to drop every

76
04:28.670 --> 04:29.400
single packet

77
04:29.400 --> 04:32.600
that comes in for this specific tag.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
04:29.400 --> 04:32.600
that comes in for this specific tag.

78
04:32.600 --> 04:38.870
Again these thresholds are based on the tags because that is the entire purpose

79
04:38.870 --> 04:39.760
of weighted

80
04:39.760 --> 04:41.760
random early detect.

81
04:41.760 --> 04:45.040
Now one other important aspect to this threshold concept.

82
04:45.040 --> 04:49.000
When we're talking about packets in the queue, it's easy to think, okay, the

83
04:49.000 --> 04:50.120
queue has exactly

84
04:50.120 --> 04:53.930
25 packets in there and therefore we're in the middle of that range, something

85
04:53.930 --> 04:54.280
along

86
04:54.280 --> 04:55.280
those lines.

87
04:55.280 --> 04:59.720
Well, we need to understand that Cisco's calculation is actually not going to

88
04:59.720 --> 05:00.360
look at
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
04:59.720 --> 05:00.360
look at

89
05:00.360 --> 05:04.790
the number of packets in the queue, but it's actually going to look at the

90
05:04.790 --> 05:05.880
average number

91
05:05.880 --> 05:09.760
of packets that have been in the queue.

92
05:09.760 --> 05:15.230
And so that is just a little bit of extra information for us to recognize that

93
05:15.230 --> 05:15.920
we might

94
05:15.920 --> 05:20.260
be, if we're really zeroing in and looking at debug and such, we might not

95
05:20.260 --> 05:20.920
quite see

96
05:20.920 --> 05:23.680
that things are lining up exactly how we want.

97
05:23.680 --> 05:28.460
Well, that's because Cisco is taking an average of the packet count over time

98
05:28.460 --> 05:29.000
and matching

99
05:29.000 --> 05:35.060
our thresholds up with the average, not the raw number of packets that are in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
05:29.000 --> 05:35.060
our thresholds up with the average, not the raw number of packets that are in

100
05:35.060 --> 05:35.920
the queue

101
05:35.920 --> 05:37.640
at any moment in time.

102
05:37.640 --> 05:41.240
And this allows the system to sort of absorb burstiness.

103
05:41.240 --> 05:47.700
If the queue spikes up to 33, 34 packets and then immediately gets cleared out,

104
05:47.700 --> 05:47.800
well,

105
05:47.800 --> 05:51.100
we don't necessarily want to drop packets that are coming in, we're going to

106
05:51.100 --> 05:51.560
hope that

107
05:51.560 --> 05:52.760
that clears up.

108
05:52.760 --> 05:57.120
And the average gives us a little bit more of the ability to absorb those types

109
05:57.120 --> 05:57.720
of sharp

110
05:57.720 --> 05:59.520
increases.

111
05:59.520 --> 06:05.760
So now let's zoom in a little bit on this linear increase.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
05:59.520 --> 06:05.760
So now let's zoom in a little bit on this linear increase.

112
06:05.760 --> 06:07.520
So we're going to have a chart here.

113
06:07.520 --> 06:11.720
We're going to say we've got a 0% chance of dropping and 100% chance of

114
06:11.720 --> 06:12.560
dropping.

115
06:12.560 --> 06:17.680
And let's say this is for a particular tag, AF 23.

116
06:17.680 --> 06:22.120
So the three here means it should have a high drop percentage.

117
06:22.120 --> 06:27.700
And so down here, we're going to chart this out over the course of the packets

118
06:27.700 --> 06:28.240
in the

119
06:28.240 --> 06:29.160
queue.

120
06:29.160 --> 06:31.920
And let's just use this 24 and 32.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
06:29.160 --> 06:31.920
And let's just use this 24 and 32.

121
06:31.920 --> 06:36.830
So somewhere over here, we've got 24 packets and then we've got 32 with the max

122
06:36.830 --> 06:38.240
being 40.

123
06:38.240 --> 06:40.760
Down here is zero packets.

124
06:40.760 --> 06:45.240
So we know that as we chart this out, that we're going to be at 0% until we get

125
06:45.240 --> 06:45.800
to that

126
06:45.800 --> 06:47.480
minimum threshold.

127
06:47.480 --> 06:52.040
And then once we get to the maximum threshold, we're at 100% drop.

128
06:52.040 --> 06:55.920
So our inclination might be to think that, okay, over the course of time, we're

129
06:55.920 --> 06:56.480
actually

130
06:56.480 --> 07:00.280
going to increase this linearly until it gets to 100%.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

130
06:56.480 --> 07:00.280
going to increase this linearly until it gets to 100%.

131
07:00.280 --> 07:04.440
Well, believe it or not, that's not actually how it works.

132
07:04.440 --> 07:09.470
There is going to be a slope concept here where, yeah, that was a very sharp

133
07:09.470 --> 07:10.240
slope.

134
07:10.240 --> 07:12.720
But we actually have control over the slope.

135
07:12.720 --> 07:17.480
So we might actually do something like this, where we have a very shallow slope

136
07:17.480 --> 07:17.560
.

137
07:17.560 --> 07:22.920
And then once we get to that 32, all the way up to 100% at that point, which

138
07:22.920 --> 07:23.560
means maybe

139
07:23.560 --> 07:30.320
we only actually had a 10% chance of dropping packets leading up to that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

139
07:23.560 --> 07:30.320
we only actually had a 10% chance of dropping packets leading up to that

140
07:30.320 --> 07:32.480
maximum threshold.

141
07:32.480 --> 07:34.640
Why would we go about doing this?

142
07:34.640 --> 07:38.000
Why wouldn't we just linearly increase it to 100%?

143
07:38.000 --> 07:42.880
Well, the reason we might do this is because if we think about sharply

144
07:42.880 --> 07:44.120
increasing it up

145
07:44.120 --> 07:47.520
to 100% over the course of just what are we at?

146
07:47.520 --> 07:50.320
Eight packets from 24 to 32?

147
07:50.320 --> 07:54.770
Well as every packet lands in the queue, we're jumping up to 10, 20, 30%

148
07:54.770 --> 07:55.720
chances of dropping

149
07:55.720 --> 08:00.120
packets, which means we are guaranteed to be dropping packets more or less.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

149
07:55.720 --> 08:00.120
packets, which means we are guaranteed to be dropping packets more or less.

150
08:00.120 --> 08:04.950
Statistically speaking, if I'm at 50% packets and I get three packets in, I'm

151
08:04.950 --> 08:05.680
probably dropping

152
08:05.680 --> 08:07.640
at least one of those.

153
08:07.640 --> 08:13.190
So what we're trying to do here is prevent dropping packets during those burst

154
08:13.190 --> 08:13.720
iness.

155
08:13.720 --> 08:18.480
Again, we're doing some things here to prevent a burst of packets that doesn't

156
08:18.480 --> 08:19.320
ultimately

157
08:19.320 --> 08:22.320
cause tail drop, doesn't shoot us up to 40.

158
08:22.320 --> 08:26.820
It just shoots us up into that range, that higher range, and we want to try to

159
08:26.820 --> 08:27.360
absorb

160
08:27.360 --> 08:28.600
that a little bit.

161
08:28.600 --> 08:32.030
So we have average packets in the queue that's going to absorb that a little
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
08:28.600 --> 08:32.030
So we have average packets in the queue that's going to absorb that a little

162
08:32.030 --> 08:32.440
bit.

163
08:32.440 --> 08:36.880
And now we have a more shallow slope, so we're not as likely to be dropping

164
08:36.880 --> 08:37.840
packets.

165
08:37.840 --> 08:40.840
But eventually we do need to start dropping those en masse.

166
08:40.840 --> 08:46.020
And so again, it's AF 23, it's a high prior or high possibility of dropping

167
08:46.020 --> 08:47.120
those packets

168
08:47.120 --> 08:53.520
relative to the other tags in that queue, assuming the AF 22 and AF 21.

169
08:53.520 --> 08:57.680
But so we are going to eventually drop those packets, but we don't necessarily

170
08:57.680 --> 08:58.160
need to

171
08:58.160 --> 09:01.520
scale this up at a very sharp rate.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
08:58.160 --> 09:01.520
scale this up at a very sharp rate.

172
09:01.520 --> 09:05.960
So the question is, how exactly do we define this slope?

173
09:05.960 --> 09:13.500
Well, the slope is going to be determined by a concept known as the mark

174
09:13.500 --> 09:14.960
probability.

175
09:14.960 --> 09:19.800
And this mark probability essentially defines the slope for us.

176
09:19.800 --> 09:24.130
Now it's not, if we get into our algebraic math, it's not actually literally

177
09:24.130 --> 09:24.940
the slope,

178
09:24.940 --> 09:27.560
but it does define this number.

179
09:27.560 --> 09:32.750
What is the maximum percent chance that we're going to drop a packet, which if
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
09:27.560 --> 09:32.750
What is the maximum percent chance that we're going to drop a packet, which if

180
09:32.750 --> 09:34.040
I say 10%,

181
09:34.040 --> 09:36.440
okay, well, that's a pretty shallow amount.

182
09:36.440 --> 09:40.960
If I were to say, I want to go to 50%, well, that's going to be a sharper

183
09:40.960 --> 09:42.160
amount, but still

184
09:42.160 --> 09:45.200
not quite up to 100%.

185
09:45.200 --> 09:51.150
And so the slope of the line is going to be dependent on this mark probability

186
09:51.150 --> 09:52.160
concept.

187
09:52.160 --> 09:55.040
So how do we define the mark probability?

188
09:55.040 --> 10:04.780
So we're going to use the configuration of the mark probability denominator.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

188
09:55.040 --> 10:04.780
So we're going to use the configuration of the mark probability denominator.

189
10:04.780 --> 10:07.520
So let's look at a little bit of math here.

190
10:07.520 --> 10:13.790
Let's say I wanted to do 10% at the maximum drop, or as the maximum drop

191
10:13.790 --> 10:15.120
percentage for

192
10:15.120 --> 10:19.600
this particular situation, basically exactly what we had drawn out up here.

193
10:19.600 --> 10:21.400
How would we do this?

194
10:21.400 --> 10:27.790
Well 10% is 0.1, it's just decimal math, says it's 0.1, and another way of

195
10:27.790 --> 10:29.040
expressing that

196
10:29.040 --> 10:31.560
is 1/10.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

196
10:29.040 --> 10:31.560
is 1/10.

197
10:31.560 --> 10:34.200
So this is the mark probability.

198
10:34.200 --> 10:35.960
So what's the mark probability denominator?

199
10:35.960 --> 10:39.250
Well, if we think about math terms, the denominator is the bottom of the

200
10:39.250 --> 10:41.240
fraction there, and so

201
10:41.240 --> 10:46.840
the MPD is 10 in this case.

202
10:46.840 --> 10:50.320
Well what if we wanted a 25% chance of dropping it?

203
10:50.320 --> 10:57.960
Well 25 is 1/4, which means that the MPD is 4.

204
10:57.960 --> 11:04.560
And we could go up to 50%, and that's 1/2, and that's an MPD of 2.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

204
10:57.960 --> 11:04.560
And we could go up to 50%, and that's 1/2, and that's an MPD of 2.

205
11:04.560 --> 11:08.500
And if we really wanted to get that super sharp increase to go to 100%, well

206
11:08.500 --> 11:08.880
that's

207
11:08.880 --> 11:13.680
1/1, which means our MPD is 1.

208
11:13.680 --> 11:20.000
So the way that we configure this slope is by configuring the MPD.

209
11:20.000 --> 11:22.800
And we'll see that here coming up with our configuration.

210
11:22.800 --> 11:27.180
In the end, when we configure our weighted random early detect, we have to do a

211
11:27.180 --> 11:28.120
few things.

212
11:28.120 --> 11:31.040
First of all, we have to enable it, and we'll see how we do that coming up.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

212
11:28.120 --> 11:31.040
First of all, we have to enable it, and we'll see how we do that coming up.

213
11:31.040 --> 11:36.110
Second of all, we have to define the minimum and maximum thresholds, and that's

214
11:36.110 --> 11:36.720
in terms

215
11:36.720 --> 11:42.450
of packet count, not in terms of Q percentage, but the number of packets based

216
11:42.450 --> 11:43.600
on the average

217
11:43.600 --> 11:44.600
here.

218
11:44.600 --> 11:48.440
And then we also have to specify the mark probability denominator.

219
11:48.440 --> 11:53.980
In a lot of cases, we might choose something like 10 or 4 or 3 would be a 33%

220
11:53.980 --> 11:54.800
chance, those

221
11:54.800 --> 11:55.800
kinds of things.

222
11:55.800 --> 12:00.620
We've got a lot of options in here, but we do need to understand what that map
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

222
11:55.800 --> 12:00.620
We've got a lot of options in here, but we do need to understand what that map

223
12:00.620 --> 12:01.320
means.

224
12:01.320 --> 12:05.880
So I can't just say MPD of 10, and I'd have no idea what that means.

225
12:05.880 --> 12:10.440
No, that means 10%, whereas a 4 would mean 25%.

226
12:10.440 --> 12:14.760
But we do have to specify the mark probability denominator when we are config

227
12:14.760 --> 12:15.760
uring weighted

228
12:15.760 --> 12:16.920
random early detect.