WEBVTT

1
00:00.000 --> 00:03.280
So how do we perform this congestion avoidance?

2
00:03.280 --> 00:09.500
Well we have a few mechanisms available including the default of tail drop.

3
00:09.500 --> 00:14.270
Now this tail drop conversation is going to echo the conversation we had

4
00:14.270 --> 00:15.400
earlier about

5
00:15.400 --> 00:19.560
the idea that FIFO is a queuing mechanism.

6
00:19.560 --> 00:23.300
Technically first in first out is a queuing mechanism but it's the default and

7
00:23.300 --> 00:24.320
it's terrible

8
00:24.320 --> 00:29.330
and it's why we are trying to solve the problems that we create or solve the

9
00:29.330 --> 00:30.360
problems using
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:29.330 --> 00:30.360
problems using

10
00:30.360 --> 00:35.180
techniques such as CBWFQ and our LLQ.

11
00:35.180 --> 00:37.080
So tail drop is going to be the same way.

12
00:37.080 --> 00:40.520
It's our default operation and it's also terrible.

13
00:40.520 --> 00:44.400
It presents to us all the problems that we're trying to resolve.

14
00:44.400 --> 00:52.920
So for example, tail drop allows for a full queue.

15
00:52.920 --> 00:56.060
The reason why it's called tail drop is because we're going to fill up our

16
00:56.060 --> 00:57.880
queue all the way

17
00:57.880 --> 01:03.320
and then the packet that we're dropping is the last packet to arrive.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:57.880 --> 01:03.320
and then the packet that we're dropping is the last packet to arrive.

18
01:03.320 --> 01:07.020
This packet might be a very high priority packet, it might be a very low

19
01:07.020 --> 01:08.120
priority packet but

20
01:08.120 --> 01:13.890
we understand that this is going to be a problem if we allow it to be used and

21
01:13.890 --> 01:14.680
keep something

22
01:14.680 --> 01:16.200
in mind in all of this.

23
01:16.200 --> 01:21.350
The tail drop can be applied to a FIFO queue and it can be applied to

24
01:21.350 --> 01:23.000
individual queues

25
01:23.000 --> 01:25.840
within class based weighted fair queuing.

26
01:25.840 --> 01:29.760
In fact we specifically said that with class based weighted fair queuing we're

27
01:29.760 --> 01:30.080
going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:29.760 --> 01:30.080
going to

28
01:30.080 --> 01:35.980
have multiple queues and each one of these is going to run its own tail drop

29
01:35.980 --> 01:36.920
mechanism

30
01:36.920 --> 01:41.000
because it has its own FIFO queue.

31
01:41.000 --> 01:44.760
So keep that in mind that these concepts sort of stack.

32
01:44.760 --> 01:46.520
So each one of these is running FIFO.

33
01:46.520 --> 01:53.020
Now we did say that the best effort queue might run WFQ, weighted fair queuing

34
01:53.020 --> 01:53.800
but each one

35
01:53.800 --> 01:59.480
of those flows is going to be in a tail drop type of queue.

36
01:59.480 --> 02:03.850
So just saying that the default doesn't mean that once we enable CBWFQ that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:59.480 --> 02:03.850
So just saying that the default doesn't mean that once we enable CBWFQ that

37
02:03.850 --> 02:04.760
tail drop goes

38
02:04.760 --> 02:09.430
away, it actually is going to be applied to each of our individual queues

39
02:09.430 --> 02:10.280
within that

40
02:10.280 --> 02:15.580
policy and yes that does include the low latency queue if we build one on top

41
02:15.580 --> 02:15.960
of all

42
02:15.960 --> 02:16.960
of this.

43
02:16.960 --> 02:20.200
It's still FIFO and the default is tail drop.

44
02:20.200 --> 02:26.890
Now the method for each individual queue is, well I should say these are locked

45
02:26.890 --> 02:27.520
in.

46
02:27.520 --> 02:31.050
The FIFO is locked in, weighted fair queuing we can actually change this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
02:27.520 --> 02:31.050
The FIFO is locked in, weighted fair queuing we can actually change this

47
02:31.050 --> 02:31.920
between that or

48
02:31.920 --> 02:33.920
FIFO for best effort.

49
02:33.920 --> 02:37.800
So we do have a choice there but by and large they're locked in.

50
02:37.800 --> 02:44.610
These here are going to allow us to select options and we are absolutely going

51
02:44.610 --> 02:45.360
to want

52
02:45.360 --> 02:49.870
to explore these options because keep in mind we have the two issues that we're

53
02:49.870 --> 02:50.360
trying to

54
02:50.360 --> 02:51.360
address.

55
02:51.360 --> 02:56.830
One we have the issue of choice and two we have the issue of TCP

56
02:56.830 --> 02:58.840
synchronization.

57
02:58.840 --> 03:03.110
So both of these continue to apply with tail drop, in fact tail drop is the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

57
02:58.840 --> 03:03.110
So both of these continue to apply with tail drop, in fact tail drop is the

58
03:03.110 --> 03:03.920
cause of both

59
03:03.920 --> 03:05.600
of these issues.

60
03:05.600 --> 03:07.280
So solution number one.

61
03:07.280 --> 03:15.480
We have a congestion avoidance technique known as random early detect which is

62
03:15.480 --> 03:16.600
abbreviated

63
03:16.600 --> 03:21.440
as red, R-E-D.

64
03:21.440 --> 03:25.680
Random early detects function is right there in the name.

65
03:25.680 --> 03:32.100
We are going to perform a random evaluation and early detect the packets that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
03:25.680 --> 03:32.100
We are going to perform a random evaluation and early detect the packets that

66
03:32.100 --> 03:33.200
are arriving

67
03:33.200 --> 03:35.760
and decide whether or not to drop those.

68
03:35.760 --> 03:38.560
Again, based on the random chance.

69
03:38.560 --> 03:43.480
So the idea here is sort of what we said earlier in the last video.

70
03:43.480 --> 03:49.680
I'm going to have a queue and this queue is going to be running first in, first

71
03:49.680 --> 03:50.440
out within

72
03:50.440 --> 03:51.440
the queue.

73
03:51.440 --> 03:55.000
It can be one of these individual queues for example.

74
03:55.000 --> 04:00.040
And then we're going to set a threshold here for when we are going to start to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
03:55.000 --> 04:00.040
And then we're going to set a threshold here for when we are going to start to

75
04:00.040 --> 04:00.800
randomly

76
04:00.800 --> 04:02.200
drop traffic.

77
04:02.200 --> 04:07.780
So let's just say that at 50% full we're going to start to randomly drop

78
04:07.780 --> 04:08.760
traffic.

79
04:08.760 --> 04:12.500
As the queue gets higher and higher or fuller and fuller, more full, we're

80
04:12.500 --> 04:13.160
going to start

81
04:13.160 --> 04:19.980
at a 0% chance of dropping traffic and we're going to ramp up to more or less a

82
04:19.980 --> 04:21.840
100% chance

83
04:21.840 --> 04:23.200
of dropping traffic.

84
04:23.200 --> 04:28.460
I mean eventually we do still have to perform tail drop because packets can

85
04:28.460 --> 04:29.120
show up if the

86
04:29.120 --> 04:30.760
queue is full.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
04:29.120 --> 04:30.760
queue is full.

87
04:30.760 --> 04:34.620
Those are getting dropped and it's not ideal but if the queue is full we don't

88
04:34.620 --> 04:36.680
have a choice.

89
04:36.680 --> 04:38.520
So we're going to ramp this up over time.

90
04:38.520 --> 04:42.420
So as packets are showing up, they're just going to get slotted right into the

91
04:42.420 --> 04:43.280
queue without

92
04:43.280 --> 04:45.840
any kind of evaluation.

93
04:45.840 --> 04:50.280
But now a packet has arrived and we have reached our threshold.

94
04:50.280 --> 04:52.080
The queue is 50% full.

95
04:52.080 --> 04:53.120
What are we going to do?

96
04:53.120 --> 04:55.240
Well, we're going to roll the dice.

97
04:55.240 --> 04:58.960
We're going to perform a little bit of a probability game.

98
04:58.960 --> 05:03.120
So we're going to say that, you know, let's give it a 2% chance of getting
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

98
04:58.960 --> 05:03.120
So we're going to say that, you know, let's give it a 2% chance of getting

99
05:03.120 --> 05:03.920
dropped.

100
05:03.920 --> 05:07.360
We look at this spot right here on our chart.

101
05:07.360 --> 05:10.840
We're going to say that's a 2% chance of getting dropped.

102
05:10.840 --> 05:13.680
Probably it's going to make it into the queue.

103
05:13.680 --> 05:17.400
Well what happens when the next packet arrives?

104
05:17.400 --> 05:21.490
Well the next packet is going to have to go here and we see that the chance of

105
05:21.490 --> 05:22.200
dropping

106
05:22.200 --> 05:23.880
this packet is increased.

107
05:23.880 --> 05:26.640
Maybe it's up to 10% by the time we get here.

108
05:26.640 --> 05:30.400
So now we're going to run a 10% chance to drop it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

108
05:26.640 --> 05:30.400
So now we're going to run a 10% chance to drop it.

109
05:30.400 --> 05:32.760
Roll the dice, see if the packet makes it in.

110
05:32.760 --> 05:35.080
Maybe this one makes it in as well.

111
05:35.080 --> 05:37.000
Well now we start to get a little more serious.

112
05:37.000 --> 05:43.480
Now there's a 20% chance or a 50% chance or a 75% chance of dropping this

113
05:43.480 --> 05:44.480
packet.

114
05:44.480 --> 05:49.350
Eventually we're throwing packets into this queue and we're dropping every

115
05:49.350 --> 05:50.280
other one.

116
05:50.280 --> 05:55.320
We drop this one, we allow this one in, we drop this one and so on and so forth

117
05:55.320 --> 05:55.360
.

118
05:55.360 --> 05:59.840
We might even be only allowing one in every 5, 6 or 7 packets.

119
05:59.840 --> 06:02.000
Only one of those makes it in.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
05:59.840 --> 06:02.000
Only one of those makes it in.

120
06:02.000 --> 06:05.100
And so what's going to happen here is as fast as we fill this up, we're going

121
06:05.100 --> 06:05.560
to start

122
06:05.560 --> 06:08.640
to slow down as we add packets here.

123
06:08.640 --> 06:11.720
So I finally make a lot of packet in.

124
06:11.720 --> 06:13.320
Then I drop another packet.

125
06:13.320 --> 06:15.280
I drop another packet, I drop another packet.

126
06:15.280 --> 06:17.360
Ooh now I'm going to add a packet.

127
06:17.360 --> 06:21.630
And so we do continue to increase the amount of packets here inside of this

128
06:21.630 --> 06:22.200
queue.

129
06:22.200 --> 06:26.930
However, we're doing it much more slowly because we are randomly dropping

130
06:26.930 --> 06:27.640
packets as

131
06:27.640 --> 06:30.680
they arrive on that interface.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
06:27.640 --> 06:30.680
they arrive on that interface.

132
06:30.680 --> 06:33.600
So that's the concept of random early detect.

133
06:33.600 --> 06:36.640
Do we see a problem though with random early detect?

134
06:36.640 --> 06:40.870
What's something, an important mechanism that we have yet to bring up as part

135
06:40.870 --> 06:43.040
of this design?

136
06:43.040 --> 06:46.200
Well we haven't considered the tag.

137
06:46.200 --> 06:51.030
These tags over here, we've got this probability increase, is completely

138
06:51.030 --> 06:52.400
ignoring the tag.

139
06:52.400 --> 06:58.280
So this packet that was allowed could be an AF41, actually that could be an AF

140
06:58.280 --> 06:59.320
43 which

141
06:59.320 --> 07:05.600
is actually a lower priority than AF41 which is a higher priority.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
06:59.320 --> 07:05.600
is actually a lower priority than AF41 which is a higher priority.

142
07:05.600 --> 07:10.220
So the AF43 could have been allowed, AF41 could have been dropped using random

143
07:10.220 --> 07:12.120
early detect.

144
07:12.120 --> 07:15.200
So we need a little bit better of a solution.

145
07:15.200 --> 07:20.820
However, before we move on to the next solution, do notice one thing here that

146
07:20.820 --> 07:21.520
random early

147
07:21.520 --> 07:29.720
detect is absolutely going to help with TCP global synchronization.

148
07:29.720 --> 07:34.960
Because what we've done here is we have smoothed out the drop rate.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

148
07:29.720 --> 07:34.960
Because what we've done here is we have smoothed out the drop rate.

149
07:34.960 --> 07:40.270
So it's not just 100% transmissions, the whole way and then all of a sudden it

150
07:40.270 --> 07:40.760
drops

151
07:40.760 --> 07:41.760
to zero.

152
07:41.760 --> 07:45.520
Essentially, the graph for that would look like this.

153
07:45.520 --> 07:49.480
Zero percent for the entire time the queue is building up and then all of a

154
07:49.480 --> 07:50.160
sudden it's

155
07:50.160 --> 07:52.160
100%.

156
07:52.160 --> 07:58.760
Instead we are ramping this up such that our drop rate isn't going to fall into

157
07:58.760 --> 07:59.560
the trap

158
07:59.560 --> 08:01.240
of being all or nothing.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
07:59.560 --> 08:01.240
of being all or nothing.

159
08:01.240 --> 08:05.920
So global synchronization, hey we've got a solution for that, it's random early

160
08:05.920 --> 08:06.280
detect.

161
08:06.280 --> 08:11.080
And so this problem is solved.

162
08:11.080 --> 08:13.960
But our choice in the matter is not actually solved.

163
08:13.960 --> 08:18.400
We're not choosing whether or not to drop specific packets.

164
08:18.400 --> 08:26.270
So now let's move on to the next solution which is known as weighted random

165
08:26.270 --> 08:27.920
early detect.

166
08:27.920 --> 08:31.960
Otherwise known as red with a W I guess.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

166
08:27.920 --> 08:31.960
Otherwise known as red with a W I guess.

167
08:31.960 --> 08:33.640
I don't know, it's kind of interesting.

168
08:33.640 --> 08:37.760
We have red here, we have red here, the W is silent in the English language.

169
08:37.760 --> 08:41.040
Yeah, we don't do ourselves any favors with these acronyms.

170
08:41.040 --> 08:43.400
So be careful with what we're talking about.

171
08:43.400 --> 08:47.940
I will say in the modern network we almost never deploy legacy random early

172
08:47.940 --> 08:48.680
detect the

173
08:48.680 --> 08:50.520
special ancestor devices.

174
08:50.520 --> 08:54.760
We're almost always deploying the weighted random early detect.

175
08:54.760 --> 09:01.440
So now what we're going to do is we're going to have our queue length here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

175
08:54.760 --> 09:01.440
So now what we're going to do is we're going to have our queue length here.

176
09:01.440 --> 09:06.790
And instead of creating this graph for all packets, we're going to do it on a

177
09:06.790 --> 09:07.360
weighted

178
09:07.360 --> 09:08.700
basis.

179
09:08.700 --> 09:12.360
This is going to be per tag.

180
09:12.360 --> 09:21.520
So let's once again look at our AF 41 AF 42 AF 43.

181
09:21.520 --> 09:22.680
Now recall what we said.

182
09:22.680 --> 09:26.590
This first number is supposed to be the priority level four is a very high

183
09:26.590 --> 09:27.400
priority.

184
09:27.400 --> 09:33.270
The second number is a drop per probability or drop percentage type of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

184
09:27.400 --> 09:33.270
The second number is a drop per probability or drop percentage type of

185
09:33.270 --> 09:34.840
conversation.

186
09:34.840 --> 09:39.500
And what's interesting here is that a 41 is actually the most important one

187
09:39.500 --> 09:40.140
because we

188
09:40.140 --> 09:46.210
actually increase the drop percentage or the drop probability as we increase

189
09:46.210 --> 09:46.980
that second

190
09:46.980 --> 09:48.180
number.

191
09:48.180 --> 09:56.340
So even though a 41 is better than a 31 because four is greater than three.

192
09:56.340 --> 10:02.940
Unfortunately 41 is a better priority than 43 because one is less than three.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

192
09:56.340 --> 10:02.940
Unfortunately 41 is a better priority than 43 because one is less than three.

193
10:02.940 --> 10:06.300
Yeah, I know it gets a little bit backwards in there, which is unfortunate.

194
10:06.300 --> 10:11.900
But keep in mind that the priority value increases like this.

195
10:11.900 --> 10:16.770
We want to think of it truly in terms of number one, number two and number

196
10:16.770 --> 10:17.640
three that

197
10:17.640 --> 10:20.200
that's the consideration we should make here.

198
10:20.200 --> 10:24.470
So in most situations, we have three different types of traffic entering into

199
10:24.470 --> 10:25.100
the single

200
10:25.100 --> 10:26.100
queue.

201
10:26.100 --> 10:32.360
And so a packet could be arriving from all of these at any given time.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

201
10:26.100 --> 10:32.360
And so a packet could be arriving from all of these at any given time.

202
10:32.360 --> 10:35.940
A 41, 42 or 43 in our example.

203
10:35.940 --> 10:42.120
So what we're going to do is we're going to again create a per tag chart for

204
10:42.120 --> 10:43.880
drop probability.

205
10:43.880 --> 10:50.880
So let's just start with let's say AF 43, which is the most likely to drop.

206
10:50.880 --> 10:55.760
So let's say that we make it to about that 50% mark again.

207
10:55.760 --> 11:01.740
And then we ramp it up to 100% there at the very end of the queue.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

207
10:55.760 --> 11:01.740
And then we ramp it up to 100% there at the very end of the queue.

208
11:01.740 --> 11:08.100
So if a pack if our queue, let's say is completely full.

209
11:08.100 --> 11:11.220
Well not completely full, but it's filled up to 50%.

210
11:11.220 --> 11:16.020
And a packet arrives for AF 43.

211
11:16.020 --> 11:17.860
Maybe we'll even throw another packet in here.

212
11:17.860 --> 11:23.010
Well now if it's going to consume this slot, we're going to see that we have a

213
11:23.010 --> 11:23.940
percentage

214
11:23.940 --> 11:26.860
of maybe 10% that this packet gets dropped.

215
11:26.860 --> 11:28.260
Kind of interesting.

216
11:28.260 --> 11:31.380
So that would be for one of our tags.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

216
11:28.260 --> 11:31.380
So that would be for one of our tags.

217
11:31.380 --> 11:36.100
Now the next tag is going to be for AF 42.

218
11:36.100 --> 11:42.980
And AF 42 is going to come to about 75% let's say, and then ramp up a little

219
11:42.980 --> 11:44.260
bit sharper.

220
11:44.260 --> 11:50.190
Both of these end up at 100% because once we get to a full queue size, then we

221
11:50.190 --> 11:50.420
don't

222
11:50.420 --> 11:52.620
have much of a choice anyways.

223
11:52.620 --> 11:59.180
But notice that if a 42 packet shows up and it's going to go here now in that

224
11:59.180 --> 12:00.780
same spot,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

224
11:59.180 --> 12:00.780
same spot,

225
12:00.780 --> 12:07.480
we said that maybe it was a 10% chance of getting dropped at that point for the

226
12:07.480 --> 12:08.380
AF 43

227
12:08.380 --> 12:09.380
packet.

228
12:09.380 --> 12:12.540
But notice this is still at 0%.

229
12:12.540 --> 12:17.020
We haven't started increasing the drop probability for AF 42.

230
12:17.020 --> 12:23.420
So now AF 42 is not going to start dropping unless the queue is 75% full.

231
12:23.420 --> 12:28.900
And lastly, as we might imagine, AF 41 has the best deal of all.

232
12:28.900 --> 12:34.600
And we are not going to drop this almost never or will probably still do some
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

232
12:28.900 --> 12:34.600
And we are not going to drop this almost never or will probably still do some

233
12:34.600 --> 12:35.620
amount of random

234
12:35.620 --> 12:40.460
dropping there at the end, let's say 90%.

235
12:40.460 --> 12:43.850
And there's still value there because we're still trying to prevent TCP global

236
12:43.850 --> 12:45.100
synchronization,

237
12:45.100 --> 12:49.090
even though we are talking about the most important packets that could show up

238
12:49.090 --> 12:49.500
in that

239
12:49.500 --> 12:50.500
queue.

240
12:50.500 --> 12:53.460
So there might still be a ramp up at 90%.

241
12:53.460 --> 12:57.970
But for the most part, if a packet that is marked with AF 41 is arriving, it's

242
12:57.970 --> 12:58.460
almost

243
12:58.460 --> 13:02.790
always going to go in because no matter where in this queue we are, unless it's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

243
12:58.460 --> 13:02.790
always going to go in because no matter where in this queue we are, unless it's

244
13:02.790 --> 13:03.580
very, very

245
13:03.580 --> 13:07.900
full, we're going to find that we have a very low drop probability.

246
13:07.900 --> 13:10.420
Most often it's going to be a 0%.

247
13:10.420 --> 13:12.340
So that's the idea of weighted red.

248
13:12.340 --> 13:19.330
We create a per tag drop probability, typically using our pH B's, our per hot

249
13:19.330 --> 13:20.620
behaviors for

250
13:20.620 --> 13:26.340
DSCP over here, understanding that the higher the number in here, the greater

251
13:26.340 --> 13:27.380
the increase

252
13:27.380 --> 13:29.460
in drop probability.

253
13:29.460 --> 13:31.060
So we need to focus on that.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

253
13:29.460 --> 13:31.060
So we need to focus on that.

254
13:31.060 --> 13:35.060
But by creating these three different drop probabilities for our three

255
13:35.060 --> 13:36.140
different values

256
13:36.140 --> 13:41.660
that show up within one of our queues, now we are no longer using tail drop.

257
13:41.660 --> 13:46.330
But instead we are solving global or TCP global synchronization by smoothing

258
13:46.330 --> 13:47.220
our drops.

259
13:47.220 --> 13:51.550
And because we're considering this on a per tag basis, we are maintaining our

260
13:51.550 --> 13:52.140
choice and

261
13:52.140 --> 13:57.680
we are trying to make sure that we are never sliding in a low priority packet

262
13:57.680 --> 13:58.180
instead of

263
13:58.180 --> 13:59.340
a high priority packet.

264
13:59.340 --> 14:03.290
We always want to drop the lower priority ones in favor of the higher priority
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

264
13:59.340 --> 14:03.290
We always want to drop the lower priority ones in favor of the higher priority

265
14:03.290 --> 14:03.900
packets.