WEBVTT 0:00:03.220000 --> 0:00:07.200000 Hello and welcome to this video which continues our review of QOS topics 0:00:07.200000 --> 0:00:12.300000 as they pertain to Cisco CCNA 200-301 exam. 0:00:12.300000 --> 0:00:15.360000 And we're going to look at congestion management control with queuing 0:00:15.360000 --> 0:00:23.800000 and scheduling. Okay, so what is the act of queuing? 0:00:23.800000 --> 0:00:26.820000 So I've talked a little bit about this already, just as a recap. 0:00:26.820000 --> 0:00:32.360000 I've mentioned how interfaces, let's just try to draw this here real quick. 0:00:32.360000 --> 0:00:37.160000 So here is an interface that's connected to a cable. 0:00:37.160000 --> 0:00:40.560000 And usually when we think of queuing, we're really concerned with transmit 0:00:40.560000 --> 0:00:43.660000 queuing, although there are received queues as well. 0:00:43.660000 --> 0:00:49.420000 So I mentioned how connected to this interface, there is something called 0:00:49.420000 --> 0:00:53.840000 a transmit ring. 0:00:53.840000 --> 0:00:57.060000 Which is really just memory buffers. 0:00:57.060000 --> 0:01:00.460000 So imagine each one of these little squares here in this type of circle 0:01:00.460000 --> 0:01:07.420000 is a memory buffer capable of holding a packet or frame. 0:01:07.420000 --> 0:01:13.340000 So ideally, here we have our forwarding engine, which might be our CPU 0:01:13.340000 --> 0:01:15.940000 or whatever it is that's looking up a packet. 0:01:15.940000 --> 0:01:19.400000 So once the forwarding engine receives a packet on the inbound side and 0:01:19.400000 --> 0:01:24.780000 decides that that packet needs to go out this particular interface, if 0:01:24.780000 --> 0:01:29.580000 this interface is not congested, if it's operating up to the line rate, 0:01:29.580000 --> 0:01:33.500000 then that packet will be forwarded, it'll be placed into the transmit 0:01:33.500000 --> 0:01:40.960000 ring. And then in just a few microseconds, it'll be transmitted out. 0:01:40.960000 --> 0:01:45.420000 And so as long as this transmit ring is not full, remember each one of 0:01:45.420000 --> 0:01:49.460000 these is a placeholder for a packet or a frame, then we can transmit out 0:01:49.460000 --> 0:01:53.680000 at full line rate on this interface. 0:01:53.680000 --> 0:01:57.820000 Where we start having, where we start having problems is when the forwarding 0:01:57.820000 --> 0:02:01.200000 engine is sending stuff to this outbound interface so quickly, there's 0:02:01.200000 --> 0:02:03.640000 no room left on the transmit ring. 0:02:03.640000 --> 0:02:07.280000 In which case, we need a secondary placeholder to store stuff. 0:02:07.280000 --> 0:02:16.120000 And that is our transmit queue. 0:02:16.120000 --> 0:02:21.520000 Okay, which of course is divide up into memory memory, several memory 0:02:21.520000 --> 0:02:25.180000 cells that can hold our frames and our packets. 0:02:25.180000 --> 0:02:29.940000 So if something has to be stored in here, then it's going to be delayed 0:02:29.940000 --> 0:02:35.180000 a little bit until the transmit ring has an empty spot and we can put 0:02:35.180000 --> 0:02:38.700000 it on the transmit ring and we can send it on its way. 0:02:38.700000 --> 0:02:43.200000 Now, the more this transmit queue gets full, the longer that frames and 0:02:43.200000 --> 0:02:47.520000 packets will have to wait until they get put on the transmit ring. 0:02:47.520000 --> 0:02:51.740000 And the whole idea behind QOS is what happens when this occurs? 0:02:51.740000 --> 0:02:55.100000 What happens when the transmit ring is full and we have to start queuing 0:02:55.100000 --> 0:03:00.280000 stuff? How can we queue it in a logical and orderly manner? 0:03:00.280000 --> 0:03:05.320000 Now like it says here, a single egress interface may have multiple associated 0:03:05.320000 --> 0:03:08.940000 egress queues differentiated by priority. 0:03:08.940000 --> 0:03:13.540000 Normally, when you do not have QOS turned on, when QOS is not enabled 0:03:13.540000 --> 0:03:16.740000 in any way, you just have one big transmit queue. 0:03:16.740000 --> 0:03:20.460000 As first in, first out, as the packet is put in this transmit queue, we 0:03:20.460000 --> 0:03:26.380000 don't really know, we don't really care if it's voice over IP, data, multicast 0:03:26.380000 --> 0:03:28.160000 video, whatever it is. 0:03:28.160000 --> 0:03:30.800000 First in, first out. 0:03:30.800000 --> 0:03:35.300000 So, now when you enable QOS globally, a lot of platforms, what they will 0:03:35.300000 --> 0:03:40.000000 do is they will take this transmit queue and they'll subdivide it into 0:03:40.000000 --> 0:03:40.940000 multiple queues. 0:03:40.940000 --> 0:03:46.120000 They might say, okay, this portion right here is going to be my low priority 0:03:46.120000 --> 0:03:50.260000 queue and that's where most of my traffic is going to go. 0:03:50.260000 --> 0:03:58.340000 And maybe this part right here might be my medium priority queue. 0:03:58.340000 --> 0:04:02.800000 And I don't get a lot of high priority stuff, so I'll divide this part 0:04:02.800000 --> 0:04:06.840000 right here. I'll put that as my high priority queue. 0:04:06.840000 --> 0:04:14.280000 And now the question is, how does the router or switch know which frame 0:04:14.280000 --> 0:04:17.380000 or which packet goes into which queue? 0:04:17.380000 --> 0:04:21.700000 And that's the process of queuing, answering that question. 0:04:21.700000 --> 0:04:25.040000 The question of how are we going to divide this one queue up, are we going 0:04:25.040000 --> 0:04:29.560000 to divide up in two pieces, three pieces, and once we divide it up, how 0:04:29.560000 --> 0:04:33.720000 does the device know which type of data, which type of packet belongs 0:04:33.720000 --> 0:04:39.860000 in which queue? That is what QOS queuing features are designed to give 0:04:39.860000 --> 0:04:40.920000 you control over. 0:04:40.920000 --> 0:04:46.880000 Provide control over which classified traffic is placed into each of these 0:04:46.880000 --> 0:04:55.040000 queues. Now, QOS queuing features can also preemptively drop traffic from 0:04:55.040000 --> 0:04:57.760000 within queues to make room for higher priority traffic. 0:04:57.760000 --> 0:05:00.340000 We've already looked at that when we talked about things like weighted 0:05:00.340000 --> 0:05:03.700000 tail drop and weighted random early discard. 0:05:03.700000 --> 0:05:07.800000 Okay, so that is queuing. 0:05:07.800000 --> 0:05:12.280000 So whenever you see a paper or a document that says this is a QOS queuing 0:05:12.280000 --> 0:05:15.880000 feature, ultimately, a high level, that's what it's doing. 0:05:15.880000 --> 0:05:22.440000 It's giving you control over basically one of two things, either how many 0:05:22.440000 --> 0:05:24.740000 queues we're going to split this thing up into. 0:05:24.740000 --> 0:05:27.560000 And sometimes you have no control over that on some, especially like on 0:05:27.560000 --> 0:05:31.740000 switches. On switches when you enable QOS, you can't control it. 0:05:31.740000 --> 0:05:34.820000 Depending on the platform of the switch, the hardware of the switch, it 0:05:34.820000 --> 0:05:38.080000 might take that one transmit queue and divide it into two pieces or divide 0:05:38.080000 --> 0:05:41.640000 it into four pieces, but you can't change that. 0:05:41.640000 --> 0:05:42.800000 You can't modify it. 0:05:42.800000 --> 0:05:46.600000 On most routers with commands, you can control that. 0:05:46.600000 --> 0:05:49.960000 You can divide the queues into however many you want. 0:05:49.960000 --> 0:05:54.680000 Also as a recap, QOS queuing features, most of the time what they will 0:05:54.680000 --> 0:05:58.060000 do is they will give you the ability to decide for yourself which type 0:05:58.060000 --> 0:06:01.240000 of traffic is directed into each of those queues. 0:06:01.240000 --> 0:06:03.380000 Okay, so now that's where we are. 0:06:03.380000 --> 0:06:06.780000 We divide this up into two or three or four queues. 0:06:06.780000 --> 0:06:11.000000 We've configured from some queuing commands to say, oh, okay, traffic 0:06:11.000000 --> 0:06:14.720000 with an IP presence of zero and one low priority queue. 0:06:14.720000 --> 0:06:18.260000 Traffic with an IP presence of two through four, medium priority queue 0:06:18.260000 --> 0:06:19.400000 and so on and so forth. 0:06:19.400000 --> 0:06:21.020000 So that's where we are right now. 0:06:21.020000 --> 0:06:26.480000 Now the next question is, we've got these queues here with packets inside 0:06:26.480000 --> 0:06:29.260000 of them. How do we service those queues? 0:06:29.260000 --> 0:06:34.040000 How do we decide when to pull traffic out of each queue, put it onto the 0:06:34.040000 --> 0:06:37.100000 transmit ring so it can go out on the wire? 0:06:37.100000 --> 0:06:41.120000 You know, do we just basically take our high priority queue and completely 0:06:41.120000 --> 0:06:45.660000 empty it out and once it's emptied out, then we'll service the other ones. 0:06:45.660000 --> 0:06:49.160000 Do we do what's called like a round robin format where we pull one from 0:06:49.160000 --> 0:06:52.240000 here, one from here, one from here, circle around, one, one, one. 0:06:52.240000 --> 0:06:53.980000 How do we do that? 0:06:53.980000 --> 0:06:58.200000 The answer to that question is dictated by a different set of QOS features 0:06:58.200000 --> 0:07:02.460000 which is called scheduling. 0:07:02.460000 --> 0:07:06.260000 So the scheduler is the process that does that. 0:07:06.260000 --> 0:07:09.360000 The schedule is a process that basically decides how am I going to pull 0:07:09.360000 --> 0:07:15.860000 traffic out of these queues, put on the ring, send it on its way. 0:07:15.860000 --> 0:07:24.300000 And like it says here, so if you're talking about routers, QOS queuing 0:07:24.300000 --> 0:07:27.600000 features typically affect both. 0:07:27.600000 --> 0:07:32.960000 They affect what priorities are going to be put into what queues and a 0:07:32.960000 --> 0:07:36.440000 lot of times in the exact same command on the exact same line, how are 0:07:36.440000 --> 0:07:38.500000 we going to schedule those queues? 0:07:38.500000 --> 0:07:41.000000 On switches a lot of times they're divided up. 0:07:41.000000 --> 0:07:44.920000 Once set of features is just for queuing, another set of features gives 0:07:44.920000 --> 0:07:46.960000 you control over the scheduling. 0:07:46.960000 --> 0:07:52.460000 Traffic shaping as we discussed in a previous video is clearly a function 0:07:52.460000 --> 0:07:56.940000 of scheduling, traffic shaping controls, how am I going to feed traffic 0:07:56.940000 --> 0:08:00.200000 out of this queue on the wire and I'm only going to feed it out at a certain 0:08:00.200000 --> 0:08:04.940000 rate. That's a prime example of a scheduling function. 0:08:04.940000 --> 0:08:15.120000 So congestion management features, okay, so before we were talking about 0:08:15.120000 --> 0:08:19.660000 congestion avoidance features, features that are trying to, that their 0:08:19.660000 --> 0:08:24.700000 main goal is to try to prevent a queue from becoming completely saturated, 0:08:24.700000 --> 0:08:26.520000 completely 100% full. 0:08:26.520000 --> 0:08:31.900000 Congestion management says, okay, as a queue is filling up, how are we 0:08:31.900000 --> 0:08:32.620000 going to deal with that? 0:08:32.620000 --> 0:08:34.380000 How are we going to service that? 0:08:34.380000 --> 0:08:38.000000 So how are we going to control the order in which packets are sent out 0:08:38.000000 --> 0:08:39.520000 on an interface? 0:08:39.520000 --> 0:08:43.680000 So there's all sorts of things that congestion management features can 0:08:43.680000 --> 0:08:48.120000 do. They can control the creation of queues, the assignment of packets 0:08:48.120000 --> 0:08:52.220000 to those queues based on their priority and some congestion management 0:08:52.220000 --> 0:09:00.160000 features even selectively drop packets from queues. 0:09:00.160000 --> 0:09:02.760000 So why do we need congestion management? 0:09:02.760000 --> 0:09:05.860000 Well hopefully this is self-evident at this point in time. 0:09:05.860000 --> 0:09:09.520000 By default, without any queue, it's turned on, like I mentioned, when 0:09:09.520000 --> 0:09:12.180000 I was doing my little drawing here, queues are serviced first in, first 0:09:12.180000 --> 0:09:13.900000 out and that's it. 0:09:13.900000 --> 0:09:18.220000 So there's no thought given to the priority of a packet, what type of 0:09:18.220000 --> 0:09:21.860000 data is in a packet, it's the first in the queue, you're the first one 0:09:21.860000 --> 0:09:30.000000 serviced out. And as it says, FIFO provides no control over the order 0:09:30.000000 --> 0:09:32.540000 of packet transmission. 0:09:32.540000 --> 0:09:41.640000 So a problem here with FIFO is imagine if, imagine if this is my queue 0:09:41.640000 --> 0:09:49.260000 right here, like that, and let's say that packet number one that came 0:09:49.260000 --> 0:09:54.680000 in, all right, let's just do this here, let's do this in red, packet number 0:09:54.680000 --> 0:09:59.760000 one is a big packet with a lot of data, maybe an FTP packet. 0:09:59.760000 --> 0:10:02.360000 So that's put right here. 0:10:02.360000 --> 0:10:09.040000 Packet number two behind that, there's maybe another FTP packet with a 0:10:09.040000 --> 0:10:10.900000 lot of data inside of it. 0:10:10.900000 --> 0:10:18.660000 And then packet number three behind that is a little bit of voice packet, 0:10:18.660000 --> 0:10:22.080000 voice over IP packet number three. 0:10:22.080000 --> 0:10:29.600000 Well, in first in, first out, this voice packet and of these three voices, 0:10:29.600000 --> 0:10:32.900000 the most intolerant of delay. 0:10:32.900000 --> 0:10:36.900000 In other words, if it's taking you a few extra seconds to download your 0:10:36.900000 --> 0:10:40.960000 FTP file or push up an FTP file, that can be a little bit irritating, 0:10:40.960000 --> 0:10:43.320000 but you can still work with it. 0:10:43.320000 --> 0:10:46.820000 But if you're, if you're in a phone conversation on voice over IP and 0:10:46.820000 --> 0:10:50.600000 there's a lot of delay, that can affect things like, you know, have you 0:10:50.600000 --> 0:10:55.140000 ever had the experience where you say hello and yet you know that you 0:10:55.140000 --> 0:10:58.520000 have to count like three or four seconds before your word hello gets to 0:10:58.520000 --> 0:11:03.280000 the other side. And so the two of you end up talking on top of each other 0:11:03.280000 --> 0:11:07.860000 because you will pause, you'll hear silence, you'll think, Oh, okay, I 0:11:07.860000 --> 0:11:10.360000 guess the other person, and then you start talking, now their voice comes 0:11:10.360000 --> 0:11:11.420000 into you, right? 0:11:11.420000 --> 0:11:15.320000 That makes talking on IP phone almost impossible to do. 0:11:15.320000 --> 0:11:19.260000 So we don't want delay to affect the voice over IP traffic, but in first 0:11:19.260000 --> 0:11:22.820000 in first out, this little voice over IP packet right here just has to 0:11:22.820000 --> 0:11:27.960000 wait while our big massive FTP packets are sent out because they came 0:11:27.960000 --> 0:11:32.720000 in first. So that's why we need congestion management to try to deal with 0:11:32.720000 --> 0:11:36.760000 that type of thing and put that voice over IP packet in a high priority 0:11:36.760000 --> 0:11:44.860000 queue, which will be serviced before the lower priority queues. 0:11:44.860000 --> 0:11:50.340000 And of course, incoming bursts can cause congestion, congestion management 0:11:50.340000 --> 0:11:55.280000 techniques provide some control on the order of transmission. 0:11:55.280000 --> 0:11:59.800000 All right, the last thing I want to do here is just I just want to present 0:11:59.800000 --> 0:12:04.260000 to you some names of features so you'll know sort of where they fit in 0:12:04.260000 --> 0:12:11.020000 the scheme of quality of service. 0:12:11.020000 --> 0:12:16.040000 Okay, so these features right here provide queuing features. 0:12:16.040000 --> 0:12:20.100000 These features do things like control how you're going to take that one 0:12:20.100000 --> 0:12:22.260000 queue and divide it up into multiple queues. 0:12:22.260000 --> 0:12:25.800000 For example, class based weighted fair queuing allows you to specify how 0:12:25.800000 --> 0:12:27.380000 many queues you want. 0:12:27.380000 --> 0:12:33.220000 They also control which priorities of traffic are allowed into which of 0:12:33.220000 --> 0:12:36.100000 these queues. So that's all queuing stuff. 0:12:36.100000 --> 0:12:40.060000 So first in first out, well, that's not really doing anything. 0:12:40.060000 --> 0:12:45.700000 Weighted fair queuing, low latency queuing, and class based weighted fair 0:12:45.700000 --> 0:12:49.780000 queuing. Now the CCNA does not expect you to know anything about what 0:12:49.780000 --> 0:12:51.900000 makes these things different from each other. 0:12:51.900000 --> 0:12:55.780000 You should just recognize that these are queuing features and you're free 0:12:55.780000 --> 0:12:57.240000 to Google them and see how they work. 0:12:57.240000 --> 0:13:01.120000 They're pretty fascinating in how they do what they do. 0:13:01.120000 --> 0:13:04.980000 And then scheduling features are the set of features that dictate how 0:13:04.980000 --> 0:13:07.720000 I'm going to pull stuff from the queue and put on the wire. 0:13:07.720000 --> 0:13:10.460000 What order I'm going to do it in, what priority each queue is going to 0:13:10.460000 --> 0:13:14.740000 get. So we've got round robin where every queue is treated equally just 0:13:14.740000 --> 0:13:17.880000 like one packet from each queue and then circle around. 0:13:17.880000 --> 0:13:23.500000 We've got weighted round robin where we might say, okay, our high priority 0:13:23.500000 --> 0:13:25.020000 queue has a higher weight. 0:13:25.020000 --> 0:13:28.620000 So the higher the weight of the queue, the more packets I will service 0:13:28.620000 --> 0:13:31.680000 from that queue before moving on to another queue. 0:13:31.680000 --> 0:13:35.180000 This got a lower weight and I service less packets from that guy. 0:13:35.180000 --> 0:13:39.040000 So I might pull five packets from my high priority queue for every one 0:13:39.040000 --> 0:13:42.700000 packet I pull from my low priority queue because my high priority queue 0:13:42.700000 --> 0:13:45.680000 has a higher weight as weighted fair queuing. 0:13:45.680000 --> 0:13:48.320000 We have low latency queuing. 0:13:48.320000 --> 0:13:51.120000 That's typically the type of thing where you say, hey, I'm going to completely 0:13:51.120000 --> 0:13:53.260000 empty out my high priority queue. 0:13:53.260000 --> 0:13:56.280000 If there's anything inside there, I'm just going to service it until it's 0:13:56.280000 --> 0:13:59.660000 done before I even look at the other queues. 0:13:59.660000 --> 0:14:01.780000 That's low latency queuing. 0:14:01.780000 --> 0:14:04.380000 And then we have class based weighted fair queuing which has elements 0:14:04.380000 --> 0:14:07.640000 of queuing and scheduling built into it. 0:14:07.640000 --> 0:14:10.500000 So that concludes this video. 0:14:10.500000 --> 0:14:11.600000 I hope you found it useful.