WEBVTT

0:00:03.280000 --> 0:00:08.360000
 Welcome to this video, which is a review
 of QS features for the CCNA bootcamp.

0:00:08.360000 --> 0:00:11.640000
 Here we're going to talk about some features
 which allow us to do congestion

0:00:11.640000 --> 0:00:15.040000
 avoidance with preemptive Q drops.


0:00:15.040000 --> 0:00:22.020000
 We're going to talk about what is Q
-EK-based congestion avoidance and

0:00:22.020000 --> 0:00:23.880000
 the types of congestion
 avoidance you can do.

0:00:23.880000 --> 0:00:26.500000
 We're going to look at these.

0:00:26.500000 --> 0:00:31.240000
 All right, so up until now, the main
 QS features that we've looked at

0:00:31.240000 --> 0:00:36.900000
 to try to prevent Qs from getting full,
 there's really been only one which

0:00:36.900000 --> 0:00:41.640000
 is policing. We've said that policing
 is typically done on the ingress

0:00:41.640000 --> 0:00:45.400000
 side. I gave the example of where
 I am the customer router.

0:00:45.400000 --> 0:00:49.660000
 I'm connected to you, the ISP router,
 and on your side, as I'm sending

0:00:49.660000 --> 0:00:54.020000
 traffic to you, you're monitoring that
 on the ingress side and you're

0:00:54.020000 --> 0:00:57.680000
 policing it. You're monitoring it up to
 a certain rate, and if that traffic

0:00:57.680000 --> 0:01:00.900000
 exceeds a rate, your police
 will destroy it.

0:01:00.900000 --> 0:01:09.960000
 The objective here, why you are doing
 that, is because this here represents

0:01:09.960000 --> 0:01:22.080000
 the customer network, and here's the
 customer router connected to you,

0:01:22.080000 --> 0:01:31.980000
 the ISP router. Now, you as an ISP,
 you've got a lot of other customers

0:01:31.980000 --> 0:01:35.520000
 that are connecting to you.

0:01:35.520000 --> 0:01:40.240000
 This is going to customer two, customer
 three, customer four, and so on

0:01:40.240000 --> 0:01:46.240000
 and so forth. And the problem is, if
 you didn't do any policing on your

0:01:46.240000 --> 0:01:51.500000
 side, if you didn't do any rate limiting,
 this is your interface that

0:01:51.500000 --> 0:01:54.240000
 gets further on into the Internet.


0:01:54.240000 --> 0:02:01.740000
 And this interface right here could
 get congested because as I'm sending

0:02:01.740000 --> 0:02:05.040000
 you traffic and other customers are sending
 you traffic, all of it probably

0:02:05.040000 --> 0:02:07.500000
 needs to go out right here.

0:02:07.500000 --> 0:02:11.220000
 And if we didn't do it, if you as the
 ISP didn't do any kind of QoS, there's

0:02:11.220000 --> 0:02:15.360000
 a very good chance that the outbound memory
 queue associated to that interface

0:02:15.360000 --> 0:02:18.160000
 would get completely saturated,
 completely full.

0:02:18.160000 --> 0:02:22.000000
 And now all of us customers would be
 calling you because our traffic could

0:02:22.000000 --> 0:02:24.340000
 be getting dropped right here.

0:02:24.340000 --> 0:02:30.220000
 So what you're doing is on these ingress
 interfaces that's receiving traffic

0:02:30.220000 --> 0:02:34.220000
 from the customer, you are
 implementing policing.

0:02:34.220000 --> 0:02:38.760000
 That's your way to try to preemptively
 prevent that outbound queue from

0:02:38.760000 --> 0:02:43.860000
 getting full. So what we're going to
 look at now is what are some things

0:02:43.860000 --> 0:02:48.780000
 you could do right here on the queue
 itself to prevent it from getting

0:02:48.780000 --> 0:02:52.200000
 full. And what we're going to look at
 are ways that you can preemptively

0:02:52.200000 --> 0:02:57.080000
 drop traffic as it's trying to get
 into that queue to prevent it from

0:02:57.080000 --> 0:03:06.400000
 getting full. So when we're talking about
 queuing based congestion avoidance,

0:03:06.400000 --> 0:03:09.820000
 we're talking about features you implement
 right there on the queue itself

0:03:09.820000 --> 0:03:15.040000
 using in the transmit direction to preemptively
 drop traffic within the

0:03:15.040000 --> 0:03:20.840000
 queue. So as you can see, this is our
 goal to prevent queues from becoming

0:03:20.840000 --> 0:03:26.040000
 saturated with low priority traffic by
 randomly dropping that low priority

0:03:26.040000 --> 0:03:30.220000
 traffic. So hopefully that leaves some
 room in the queue for the higher

0:03:30.220000 --> 0:03:32.460000
 mission critical traffic.

0:03:32.460000 --> 0:03:39.840000
 Okay, so if we're talking about switches
 here, switches have a variety

0:03:39.840000 --> 0:03:42.100000
 of features you can implement
 that does this.

0:03:42.100000 --> 0:03:46.780000
 They have weighted tail drop, weighted
 random early discard, and something

0:03:46.780000 --> 0:03:48.400000
 called dynamic buffer limiting.

0:03:48.400000 --> 0:03:49.940000
 And there's probably
 others as well.

0:03:49.940000 --> 0:03:55.520000
 You just need to be able to recognize
 these features on routers.

0:03:55.520000 --> 0:03:58.680000
 Routers typically use something called
 weighted random early discard.

0:03:58.680000 --> 0:04:02.820000
 So you can see red or weighted random
 early discard is actually a feature

0:04:02.820000 --> 0:04:06.920000
 that's common to switches
 and routers.

0:04:06.920000 --> 0:04:10.360000
 It's probably of these things you see
 here of the three weighted tail

0:04:10.360000 --> 0:04:12.920000
 drop red and dynamic
 buffer limiting.

0:04:12.920000 --> 0:04:14.460000
 Red is preferred.

0:04:14.460000 --> 0:04:19.960000
 That's the much more common
 feature you will see.

0:04:19.960000 --> 0:04:25.800000
 Okay, so both weighted random early
 discard and weighted tail drop have

0:04:25.800000 --> 0:04:29.020000
 this concept of when you're configuring
 them on an interface, or I should

0:04:29.020000 --> 0:04:33.340000
 say on an interface is Q, you're now
 configuring something called drop

0:04:33.340000 --> 0:04:40.180000
 thresholds. You're saying, okay, once
 this Q gets this full, like 40%

0:04:40.180000 --> 0:04:43.560000
 full or 50% full, now I want
 to start dropping something.

0:04:43.560000 --> 0:04:48.940000
 So that level, that 40 or 50% that
 you've configured is called a drop

0:04:48.940000 --> 0:04:55.040000
 threshold. And so there are minimum
 and maximum drop thresholds.

0:04:55.040000 --> 0:04:59.920000
 A minimum threshold says, okay, when
 the Q, so when my outbound Q gets

0:04:59.920000 --> 0:05:04.400000
 this full, reaches this minimum threshold,
 now I want you to start dropping

0:05:04.400000 --> 0:05:11.820000
 packets. The maximum threshold is the
 point at which 100% of your max

0:05:11.820000 --> 0:05:14.560000
 traffic is dropped.

0:05:14.560000 --> 0:05:19.800000
 All right, so let's start with
 something you used on switches.

0:05:19.800000 --> 0:05:23.540000
 You might see in some switching documentation
 called weighted tail drop.

0:05:23.540000 --> 0:05:29.200000
 So when weighted tail drop, you configure
 these thresholds and you actually

0:05:29.200000 --> 0:05:30.980000
 configure two things.

0:05:30.980000 --> 0:05:34.080000
 So a threshold has two numbers.

0:05:34.080000 --> 0:05:38.900000
 A threshold number one indicates, you
 know, what percentage of the Q is

0:05:38.900000 --> 0:05:46.800000
 full. For example, I might say that
 threshold number one is at, let's

0:05:46.800000 --> 0:05:49.420000
 just say this right
 here, is at 30%.

0:05:49.420000 --> 0:05:53.840000
 So that's the first thing I would
 configure about that threshold.

0:05:53.840000 --> 0:06:00.700000
 That threshold number one equals, I'll
 just say here, threshold one equals

0:06:00.700000 --> 0:06:07.020000
 30%. And I would say, now what traffic
 is that threshold going to look

0:06:07.020000 --> 0:06:09.700000
 at? I don't necessarily want
 to look at all traffic.

0:06:09.700000 --> 0:06:13.900000
 The reason why they call this weighted
 tail drop is because traffic is

0:06:13.900000 --> 0:06:17.820000
 weighted. The higher the number, the
 higher the priority of the traffic,

0:06:17.820000 --> 0:06:18.620000
 the higher the weight.

0:06:18.620000 --> 0:06:23.120000
 So I might say threshold number one,
 the weight that we're looking at

0:06:23.120000 --> 0:06:29.460000
 is like it says right here, values
 of zero through three.

0:06:29.460000 --> 0:06:35.920000
 Okay, so the way this is going to work
 with weighted tail drop is that

0:06:35.920000 --> 0:06:38.160000
 as traffic is starting to
 get put into this queue.

0:06:38.160000 --> 0:06:42.500000
 So traffic is coming in our inbound
 interfaces being looked up by our

0:06:42.500000 --> 0:06:43.320000
 forwarding engine.

0:06:43.320000 --> 0:06:47.020000
 So the forwarding engine is the component
 of the switch that actually

0:06:47.020000 --> 0:06:50.160000
 looks up traffic and decides
 where it needs to go.

0:06:50.160000 --> 0:06:53.600000
 And the forwarding engine is saying, okay,
 I need to send it to this interface

0:06:53.600000 --> 0:06:58.540000
 right here. Now, like we said earlier,
 if this interface was not congested

0:06:58.540000 --> 0:07:02.880000
 at all, that traffic would go to the
 transmit ring and the transmit ring

0:07:02.880000 --> 0:07:06.660000
 would be able to send it out at full
 line rate of whatever this interface

0:07:06.660000 --> 0:07:10.060000
 was, gigabit speeds, fast e
-centives speeds, whatever.

0:07:10.060000 --> 0:07:12.900000
 But if the forwarding engine is sending
 it to that outbound interface

0:07:12.900000 --> 0:07:16.700000
 and the transmit ring is full, now
 we have to put it in our secondary

0:07:16.700000 --> 0:07:19.300000
 placeholder, which is
 our memory queue.

0:07:19.300000 --> 0:07:20.980000
 And that's what we're configuring
 right here.

0:07:20.980000 --> 0:07:22.960000
 We're telling the memory queue, okay,
 I'm going to put this threshold

0:07:22.960000 --> 0:07:30.560000
 on here. As traffic comes into the
 queue, if it's from zero to 30%, no

0:07:30.560000 --> 0:07:33.900000
 problem. We'll distort the queue and
 play it out when it gets there.

0:07:33.900000 --> 0:07:37.960000
 But let's say as we're putting stuff
 in the queue, the queue says, oh,

0:07:37.960000 --> 0:07:42.160000
 I'm already at 30%, I've just
 reached threshold number one.

0:07:42.160000 --> 0:07:46.040000
 All right. If we've reached threshold
 number one, guess what that means?

0:07:46.040000 --> 0:07:50.480000
 That means that any traffic with a priority
 of zero through three is no

0:07:50.480000 --> 0:07:52.280000
 longer allowed in the queue.

0:07:52.280000 --> 0:07:54.160000
 We're going to drop it.

0:07:54.160000 --> 0:08:00.660000
 So this part of the queue, I can draw
 this right here, this part from

0:08:00.660000 --> 0:08:04.660000
 zero to 30%, is basically open
 for everything, right?

0:08:04.660000 --> 0:08:09.040000
 Like we see here, zero to
 six is allowed in there.

0:08:09.040000 --> 0:08:17.120000
 But once we get to 30%, zero through
 three is not allowed in the remaining

0:08:17.120000 --> 0:08:20.980000
 70% of memory that's still
 there, still available.

0:08:20.980000 --> 0:08:27.000000
 That is reserved for four, five, six,
 and seven, not zero through three.

0:08:27.000000 --> 0:08:31.480000
 So you see what we're doing here is
 we're saying, okay, we are, once we

0:08:31.480000 --> 0:08:39.360000
 hit 30%, we are putting packets to leave
 room, in this case, 70% of the

0:08:39.360000 --> 0:08:43.100000
 queue is left for room for
 a higher priority traffic.

0:08:43.100000 --> 0:08:48.600000
 And threshold number two, it looks like
 here is set at 100% and clearly

0:08:48.600000 --> 0:08:52.500000
 at that level, everything
 is going to be dropped.

0:08:52.500000 --> 0:08:55.440000
 So this is weighted tail drop.

0:08:55.440000 --> 0:09:00.140000
 Weighted tail drop says we set a threshold,
 we apply that threshold against

0:09:00.140000 --> 0:09:05.700000
 a certain priority value, like maybe
 a DSCP value or an IP precedence

0:09:05.700000 --> 0:09:11.280000
 value. Here is a cost value, we're saying
 that these values will be preemptively

0:09:11.280000 --> 0:09:15.280000
 dropped after we've
 met that threshold.

0:09:15.280000 --> 0:09:22.260000
 Now, this does work, but there's
 a downside to this.

0:09:22.260000 --> 0:09:28.340000
 What if the only thing that was being
 directed to this queue, so let's

0:09:28.340000 --> 0:09:34.580000
 say that these represent some packets
 that are trying to get into the

0:09:34.580000 --> 0:09:38.740000
 queue, there's a stream of packets that
 are trying to get in, here's another

0:09:38.740000 --> 0:09:42.860000
 stream of packets that are trying to get
 in, and let's say one more, here's

0:09:42.860000 --> 0:09:45.940000
 another stream of packets that the
 forwarding engine is trying to send

0:09:45.940000 --> 0:09:47.720000
 into this queue.

0:09:47.720000 --> 0:09:53.020000
 What if all the stuff that's trying
 to get in here is stuff that's zero,

0:09:53.020000 --> 0:09:54.300000
 one, two, or three?

0:09:54.300000 --> 0:10:03.200000
 Like this is a cost value of three, and
 this here is a cost value of zero,

0:10:03.200000 --> 0:10:08.560000
 and this here is a
 cost value of two.

0:10:08.560000 --> 0:10:12.940000
 So there's no traffic above this, there's
 no four, five, six, or sevens

0:10:12.940000 --> 0:10:13.780000
 are trying to get in.

0:10:13.780000 --> 0:10:18.320000
 Well, guess what, once this queue gets
 to 30%, we're not going to allow

0:10:18.320000 --> 0:10:21.540000
 any more of this stuff in, the zeros,
 the twos, the threes, they're going

0:10:21.540000 --> 0:10:25.440000
 to be preemptively dropped, so we have
 some space remaining or some space

0:10:25.440000 --> 0:10:30.780000
 held in reserve for the four, five, sixs,
 and sevens, but there's no four,

0:10:30.780000 --> 0:10:32.880000
 five, six, or sevens that
 need to use this queue.

0:10:32.880000 --> 0:10:35.940000
 They're not even coming in right now,
 so that means our lower priority

0:10:35.940000 --> 0:10:41.240000
 traffic is being penalized, we're dropping
 it in favor of higher priority

0:10:41.240000 --> 0:10:43.900000
 traffic, that's not even
 coming in at all.

0:10:43.900000 --> 0:10:47.160000
 So all of this is as empty.

0:10:47.160000 --> 0:10:53.160000
 We got 70% of the memory that's never
 being used because we're holding

0:10:53.160000 --> 0:10:56.340000
 it in reserve for stuff that's
 never even showing up.

0:10:56.340000 --> 0:11:04.320000
 So you can say, well, wouldn't it be
 a better idea if when we hit that

0:11:04.320000 --> 0:11:08.900000
 first threshold, that 30%, instead of
 dropping everything that's a zero,

0:11:08.900000 --> 0:11:10.760000
 one, two, or three,
 what if we did this?

0:11:10.760000 --> 0:11:15.060000
 Well, if we said, hey, I'm going to
 start dropping you guys, but I'm not

0:11:15.060000 --> 0:11:19.260000
 going to drop you guys at 100%, I'm
 going to start dropping you guys at

0:11:19.260000 --> 0:11:24.440000
 like 20%, in other words, what I mean
 by that is, as this first threshold

0:11:24.440000 --> 0:11:32.000000
 here is reached, which is 30%,
 I'll just say, queue depth.

0:11:32.000000 --> 0:11:35.360000
 So the queue is now 30% full.

0:11:35.360000 --> 0:11:40.780000
 Now, if we have some more, let's just
 say this is a cost of zero, right

0:11:40.780000 --> 0:11:45.580000
 here, with way to tail drop, all
 these guys would be dropped.

0:11:45.580000 --> 0:11:47.680000
 We can't let any more
 of them in the queue.

0:11:47.680000 --> 0:11:50.680000
 But what if we said, hey, here's
 what I'm going to do.

0:11:50.680000 --> 0:11:54.940000
 I'm going to drop like, I'm going to
 randomly drop maybe one out of every

0:11:54.940000 --> 0:11:56.180000
 four of you guys.

0:11:56.180000 --> 0:11:59.920000
 So you, you pack it right
 there, you're gone.

0:11:59.920000 --> 0:12:04.000000
 That'll still leave a little bit of room
 in the other queue that the rest,

0:12:04.000000 --> 0:12:07.860000
 the 70% that's remaining, they'll still
 maybe free up some room there

0:12:07.860000 --> 0:12:12.040000
 for the higher priority traffic, but
 we're not penalizing all these other

0:12:12.040000 --> 0:12:18.840000
 packets. That's what weighted
 random early discard does.

0:12:18.840000 --> 0:12:23.620000
 Once we hit the first threshold, whatever
 value, whatever IP presence

0:12:23.620000 --> 0:12:28.860000
 or DSCP is mapped to that threshold,
 we just start randomly dropping a

0:12:28.860000 --> 0:12:32.720000
 certain percentage
 of those packets.

0:12:32.720000 --> 0:12:38.180000
 Now, if the queue gets more full and
 more full and more full, that rate

0:12:38.180000 --> 0:12:43.660000
 of drop increases, so maybe right at
 30%, which was just a random number

0:12:43.660000 --> 0:12:47.900000
 I selected for threshold number one,
 we randomly start dropping like maybe

0:12:47.900000 --> 0:12:52.060000
 20% of all low priority
 traffic that comes in.

0:12:52.060000 --> 0:12:55.400000
 Now, we get to 50% full.

0:12:55.400000 --> 0:13:00.500000
 So now we increase our rate of drop
 to maybe 60% of the traffic that's

0:13:00.500000 --> 0:13:05.260000
 coming in. So you can see it increases
 in a linear format until the maximum

0:13:05.260000 --> 0:13:07.600000
 threshold is reached.

0:13:07.600000 --> 0:13:10.600000
 And then once I reach 100%, well,
 then it's game over, right?

0:13:10.600000 --> 0:13:13.780000
 The queue is completely full,
 nothing else can get in.

0:13:13.780000 --> 0:13:17.260000
 So that's how weighted random early discard,
 that's why it's called, that's

0:13:17.260000 --> 0:13:22.360000
 why we have random in the name, because
 the rate of drop is going to increase

0:13:22.360000 --> 0:13:27.060000
 in a random format as the queue
 gets more and more full.

0:13:27.060000 --> 0:13:31.760000
 And this is a much more common congestion
 avoidance mechanism we'll find

0:13:31.760000 --> 0:13:34.480000
 on queuing and routers
 and switches.